背景
以太坊的柏林硬分叉[1] 預計在4 月14 日執行，其首個測試網Ropsten 將在3 月10 日執行部署。而在距離測試網部署前5 天柏林硬分叉的內容竟然發生了變更，3 月5 日的第107 次核心開發者會議（以下簡稱ACD）上，EIP-2315 被全體通過移除出升級列表，而這距離其被列入升級列表僅僅過了14 天。
為什麼EIP-2315 在發射前最後一刻啞了火，究竟發生了什麼問題？這還要從一個提案[2] 說起。
多方爭論
3 月3 日，lightclient 發表該提案，回顧了EIP-2315 的複雜歷史，並從技術和社會共識層面提出了反對的理由。在技術層面，他指出Solidity 團隊的兩位成員在推特上表達了對此提案的反對，並給出了合理的推測—— 由於solidity 編譯器佔據了絕大多數市場，如果solidity 團隊不利用這一提案，則大部分智能合約都不會使用這一特性。與此同時，EVM 的複雜性卻大大增加了，看起來似乎得不償失。在共識層面，lightclient 認為其作用有限，同時反駁了“這是為未來升級的鋪墊”。他認為即使是作為未來轉變的基礎EIP，也必須有自己獨特的用處。因為如果一個EIP 本身沒有好處，而只是未來“好處” 的墊腳石，未免風險太大。在升級前臨時剎車是不尋常的事情，lightclient 對其可能造成的困擾表示了歉意。
提案的提出者gcolvin 很快提出了反對。首先，他不同意流程上的妥協，認為“核心開發者確定了的升級列表是不能更改的”，否則會造成不好的先例。從技術上，他解釋了這一提案的初心，他認為solidity 團隊的反對是沒有道理的，因為他們沒有反對過對此提案的分析。同時，即使他們反對也不能說明什麼，因為Vyper （另一個智能合約編譯器）團隊表示會採用這一新的特性，智能合約不僅僅是 solidity 一家說了算。他還指出在此提案已投入太多心血，目前沒有看到一條『他未曾反駁』或『可以影響升級』的反對意見。
Vyper 團隊表示也許這對solidity 團隊現階段沒有用，但他們是會採用的，並期待已久。 『只要有一個編譯器團隊願意使用，就沒有理由不實施』。
Tim Beiko（以太坊核心開發者會議（ACD）的協調人）總結了各客戶端團隊的意見。 Geth 團隊希望等待ACD 的決議，而其它客戶端團隊（Netherland、OpenEthereum、Besu）則表示對保留2315 無異議（需要特別指出，Geth 客戶端的佔有率超過80%）。
看起來誰也不服誰，但在ACD召開之前，2315就被無異議地移除了。是不是很奇怪？
EIP-2315到底是什麼
（如果你不懂技術可以跳過這一節，不影響理解本文的主要觀點）
EIP-2315：為EVM引入簡單的子程序[3]。子程序是計算機領域的一個基本概念，可以認為是程序的一個子集或片段，可以讓一段代碼邏輯被重複調用。子程序和函數有區別，函數有返回值，且一般不顯式地修改全局變量，而子程序沒有返回值，且是對全局變量進行操作。子程序對簡化代碼有許多好處，這也正是EIP-2315 的提出動機。 EVM 目前不支持子程序，但可以通過操作程序計數器來實現這一功能。提案的作者gcolvin 在『動機』章節闡述了他的理由。 『 在過去的30年裡，計算機行業一直在與這種複雜性和開銷作鬥爭，並在提供直接支持子程序的原生操作符方向上取得了進展。至少追溯到50年前，大多數物理機和虛擬機都以某種形式（非原生地）提供這些操作。 』
無需了解子程序的內涵，從上下文中也可以得出幾個結論：
1. 在功能層面，子程序並沒有提供新的功能，而是提供了更簡便的實現方法。 2. 目前以太坊不原生支持子程序，而計算機行業是支持的。如果要問，子程序到底提供了什麼好處，它的代價又是什麼？原生支持究竟會為以太坊帶來多少提升，還是說僅僅是一個技術理想？ EIP-2315 似乎並沒有解釋清楚，它只是給出了一些新的操作符，讓EVM 原生支持子程序。好了，其實這些技術細節，對今天的討論並不重要。
半公開領域的爭吵
我把github、以太坊研究者論壇定義為公開領域，因為每個人都可以不受限制地閱讀和參與討論，並可以使用郵件、RSS 閱讀器等互聯網基礎設施與之交互。而discord 的頻道、telegram 的公開群組則可稱作半公開領域。儘管無需准入就可以加入，但由於其協議相對封閉，與互聯網基礎設施的集成較差，且無法被搜索引擎檢索。
以太坊研究的半公開領域集中在『Eth R&D』的discord服務器上。大部分研究者可以做到對公開領域信息的檢索、聚類和分析，但對半公開領域則投入相對較少，尤其是當它和財富效應關係較小時。顯然，不僅普通研究者是這樣，核心開發者們——例如solidity 的團隊成員也極少參與這裡的討論，他們在推特上發表了對EIP-2315 的反對論點。 Micah 表示不解：『為什麼人們要在推特上反對EIP？ 』
gcolvin 在discord 上對重啟EIP-2315 的討論表示了強烈的反對，他認為這已經被充分討論並在『合適的論壇』上達成了共識，長達一年之久。 Solidity團隊在當初的討論中並未表示強烈的反對，現在他們在推特上反對是他們的自由，但已經沒有意義了。此外，他認為在流程上存在一些問題，『Solidity 沒有派代表參加ACD』，很遺憾他們沒有參與最終決策，但這不會影響EIP-2315 的決策，如果說有可改進的地方，那就是會議議程，應當在討論議題時邀請相關代表（顯然他也認為solidity 團隊沒有參與最終討論使得這個流程不太妥當）。
Geth 客戶端的負責人Peter 也表達了自己的憤怒。他認為在最後時刻去改變升級需求是可怕的，由於代碼和測試都已經完成，誰來重新測試，並且保證所有代碼可用。他認為，如果ACD 決定推遲Berlin 升級，這還可以接受。在保證原升級時間表的情況下刪除EIP-2315 是不可接受的。
lightclient 表示同意。他認為如果要在『推遲Berlin 升級』和『保留一個無用卻會修改EVM 核心功能的EIP』中選擇，那還不如選擇短痛。同時，如果要刪除EIP-2315，他願意幫助重新測試。
Vitalik 表示，推遲Berlin 不可接受。
與此同時，solidity 團隊的Chris 指出，他對此EIP 的狀態表示疑惑，因為它仍然是『DRAFT』，一個草案EIP 怎麼已經列入了升級列表了呢？ James Hancock 說，這確實令人困惑，應當更好地管理這些狀態，讓沒有時間參加ACD 的人也可以知道每個EIP 的狀態變更。
接下來的討論似乎沒有沿著這條路線前進，Alexey、Chris 和Vitalik 對EIP-2315 所涉及的動態跳轉展開了討論。 Peter 此時表示，他已移除2315並成功同步了，但這並不能保證其它客戶端也奏效。
lightclient 催促大家盡快達成共識，他贊成在Berlin 移除EIP-2315，理由仍然是基於內容上的。他認為此提案並不能實現聲稱的好處，但如果大多數人同意可以繼續，本不應該反對提案。然而由於『Solidity 編譯器的使用率遠遠超出其它工具，而他們的開發者認為這個提案是無用的』，因此應當更謹慎地對待此議案。
tkstanzak (Netherland 的開發者)認為這甚至會導致『嚴重損害(damage)』，原因是『無用的代碼增加了EVM 的複雜性，拖慢了它的運行速度，沒有任何人聲稱會使用他』。這種表態激怒了gcolvin，他說『混蛋。 (Bullshit.)』lightclient 顯然對這種氣氛不安並試圖維持秩序，『很不幸我們有麻煩了，我們得花點時間搞清楚我們為什麼會搞成這樣，但現在我們得根據現有信息作出最合適的決定。 』很不幸這種提議並沒有讓tkstanzak 和gcolvin 買賬，他倆展開了一組對話。對話的重心在於『是否有人真正願意使用此提案？ 』
gcolvin 強調，『子程序本身』就是子程序的用例，如果任何人反對這個提案，應該在過去兩年的『以太坊魔術師論壇』的討論中提出，而solidity團隊更應該在ACD上提出反對。
而tkstanzak 認為從來就沒有人給出過該提案的優點（例如可以提升solidity的效率，達到2%），2020年1月，他就這麼問過gcolvin，但並沒有繼續討論下去了。在過去的兩年裡，他一直在等待這個問題的答案，而且一直沒有人告訴他Berlin 什麼時候會來。因此，Berlin 的延期也沒什麼大不了的，因為其中除了EIP-2929 外也沒有什麼特別要緊的提案。他給予了gcolvin高度的讚譽，認為他是EVM 的專家，但如果沒有任何表示會使用他提升Solidity 或其餘編輯器，那麼為什麼要對這個提案有如此高的信心呢？
他還打了個很長的比方，大致的意思是汽車發動機的每一次設計更新都應該有充分的理由，而『70 年代飛機發動機就已經使用這個技術了』不是一個合適的理由。因此，如果移除EIP-2315 會推遲Berlin 升級，那也不得不這樣，但他有信心大家並不需要推遲升級，也能很好地移除該提案。
Tim Beiko做了兩點總結，在今後的流程中，應當（1）明確每個EIP的需求方及理由（2）ACD的討論應當更加廣泛，以提前收集反對意見。
此時，Hudson，過去5年裡ACD的協調人，闡明了他對此次溝通的立場。他首先表示了gcolvin專業知識的尊重，但批判了他的無禮態度，每個人應當都對自己有高標準，即使在情緒衝動時。而關於議事流程，他認為『先例並不是一定要遵守的。流程系統已經崩潰了，需要根本的改善。 』
gcolvin 的情緒似乎有些緩和，但仍在強調ACD 的決議不可推翻。在他看來，流程就是為了防止『最後時刻的噪音』，這被Alexey反對。
此時，Vyper 團隊表示他們會使用子程序帶來的新特性。 Micah 認為這不是什麼安全性問題，而僅僅是Solidity 一個團隊不使用它而已，因此沒必要在最後時刻推翻流程。 lightclient 也表示接受。
而此前關於『DRAFT』的討論得到了Pawel Bylica 的回應，他認為他甚至不知道這個提案被接受了，他以為還在討論呢，關於EIP 的狀態，應當提供RSS Feed 樣式的接口訂閱，以幫助大家了解自己關心的EIP 的變更（不是每個人都會有時間關心每個EIP，每次ACD）。
這似乎給了lightclient靈感。
一次完美的總結
3 月4 日，lightclient 整理了EIP-2315 事件的時間線[4]，詳細梳理了此提案生命流程中的所有大事件。該提案首次被列入討論是ACD 80，最後一次討論是ACD 96，跨度7 個月。但最終並沒有達成結論。儘管第98 和100 次會議沒有會議記錄[5]，所以無法確定是否討論了限制跳轉的問題。 （但lightclient後來重聽了整個會議（總計約4h），確認了並未討論這一議題。）
chriseth 讚美了lightclient 總結的時間線，這印證了他的印象即此提案從未被真正地接受過。此外，他重新陳述了對此提案目標的質疑，由於缺少靜態分析的專家參與，且該提案可能無法起到減少gas 消耗的目標。
3月5日，lightclient 作出了最終陳述[6]，非常精彩，全文翻譯如下：
看來事情的發展傾向於取消EIP-2315，所以我長話短說。
支持EIP-2315 部署在柏林的人的論據來自核心開發者會議過去關於接受這個EIP 的決議。我們有辦法通過流程避免當下的狀況，並讓生活變得更簡單。可只有當人們設計並實施時，這些流程才是密不透風的。人類都會犯錯，這些錯誤隨時隨地都有可能表現出來。我們沒有必要成為自己創作品的受害者。
在此流程中出現了一個錯誤，EIP-2315 不該被接受。早在ACD 81，Geth 團隊就要求提供基準測試的結果，以證明此EIP 所聲稱的收益。基準測試一直沒有人做。在ACD 84 中，@Souptacular 動議將EIP 移至『接受(Accepted)』。 @tkstanczak 重申，如果存在這樣的用例（改進的codegen +靜態分析），他就會支持提案。在沒有找到符合這兩個條件的用例時，此提案被列入了柏林昇級。在ACD 86 中，@MadeofTin 承認，考慮到關於規範的持續爭論，將EIP 轉為『接受』還為時過早。甚至在幾個月後，在我能找到的最後一次ACD 電話中提到EIP 的時候，@Souptacular 指出，圍繞著這個規範還有一些懸而未決的問題。 @gcolvin 表示會在魔術師論壇中線下解決，但並沒有解決。
在整個過程中，幾乎每一步驟中，@axic、@chfast 和@chriseth 都在表達對該提案的擔憂。他們寫了一份分析，並向EIP 開了一個PR，以避免跳入和跳出子程序—— 這可能是對EIP最強烈的抱怨。不幸的是，由於某些原因，他們在去年秋天減少了對EIP 的參與，因此這個提案設法在柏林的備審清單上停留了幾個月的時間。這讓那些不參與討論其可行性的人以為這個EIP 代表了正統性。流程本該保證反對者的抱怨得到解決，但事實並非如此。如果他們能繼續與之抗爭，那就更好了，但他們沒有。他們已經花了幾個月的時間去鬥爭--這個流程本應把此EIP 擱置，除非討論解決。
我對關於此EIP 的技術方面的抱怨並不擅長，因此不適合發表評論。希望@AlexeyAkhunov 的想法結合@chfast 的分析，足以讓諸位承認這個EIP 是否有用仍是存疑的。雖然這是一個極不尋常的提議，但並非是『私人問題』。我對於造成的干擾表示誠摯的歉意。我打算今後儘自己的努力，避免這種情況再次發生。希望我們能夠作為一個團體進行進一步的建設性對話，以改善EIP流程。
隨後，lightclient 敲下了法官的重錘。
這項建議已被ACD 107接受。 EIP-2315將從柏林移除。
gcolvin 也作出了自己的總結，他回顧了自己的心路歷程，並對自己的魯莽表示歉意。在最後，他指出了核心開發者的使命：『我希望這種可悲的事態發展能夠引發嚴肅的反省--我們已投身於一個目前市值1730億美元的網絡的研究、開發和管理。我不知道有多少業務在這個網絡上運行，也不知道它支持了多少人的生活。我們必須學會像專業人員一樣操作。 』
如何制定公共政策
事情似乎告一段落，但這次事件的影響是深遠的。如果以太坊的開發者不能從中吸取教訓，那這類事情一定會再次發生。公共政策的討論可以分為幾個層次。
1. 公共政策的內容2. 公共政策的決策3. 治理程序的完備
第一層是公共政策的內容是否具有『結果正義』。公共政策的目標是什麼，其內容是否可以實現聲稱的目標，尤其是技術上是否具有可行性。實現這個目標會讓多少人受益，讓多少人受損，是否有其它實現方式？在一層，主要需要相關領域的專家對技術可行性及其效用進行評估。在此案例中，幾位技術專家的討論還是比較充分的，他們通過論壇、聊天工具展開了長期的探討，雖然談不上多高效，也談不上有多麼深入。直接在ACD 這類全員會議上展開專業問題的討論，顯然不是什麼好的決定。尤其是針對『子程序』的用例，『基準測試數據』等具體問題，並沒有討論清楚。
第二層是公共政策的決策。即公共政策的推行是否符合『程序正義』，是否徵詢了足夠多人員的意見，是否經過了合適的表決，是否留有足夠多公示時間以避免侵犯到部分人員的利益。很顯然，此次事件中，ACD 在提案沒有得到共識的情況下就將EIP-2315 列入升級列表，應負有重大責任。尤其當有人質疑EIP-2315 的狀態還是『草稿』時，流程組織者Pooja 沒有反思為什麼出現這種情況，而是簡單將『草稿』改成『審議』[7]，頗有種打那指那的灑脫。此外，有兩次會議缺少會議記錄，是否應當有人需要問責？
第三層是治理程序。本文無意探討以太坊的治理這一宏大問題，僅從本次事件的吉光片羽中找出關於EIP的上線流程的建議。譬如，如何判定EIP 的優先級？每個EIP 除了需要一個支持者，一直推進，是否還需要指定一個反對者，始終跟踪進度並持續提出建議？ ACD 會議討論具體的EIP 時，是否應召集所有相關的技術專家和開發者團隊到場？很顯然，EIP-2315 事件反映出現有治理程序存在巨大缺陷。如果在ACD 討論時，能叫上solidity 團隊成員參與，就不會讓這麼荒誕的事情發生。公共政策既需要專家的意見，也需要考慮多方利益的均衡，更需要在合理的流程下達成決策，這樣才能在保證效率的情況下不至於犯錯。
很顯然，以太坊做得算不上好。治理程序不夠完善，執行更是信馬由韁，這讓針對內容的討論低效且無法深入，讓系統建立在沙丘上。
但相比於絕大多數區塊鏈社區，以太坊這已經是幸福的煩惱了。
再議無准入(permissionless) 的系統
我們一般討論無准入系統時，往往是從“技術視角” 切入的，即普通人是否可以運行網絡的全節點，並參與整個網絡的技術共識。例如，任何都可以從誕生之日起，追踪並驗證比特幣和以太坊的所有歷史。在追踪這一事件的過程中，我深刻意識到在信息層面，也需要讓整個網絡保持『無准入』，這樣一個新加入的人才能理解整個社區從哪裡來，要到哪裡去。
以太坊究竟做得怎麼樣呢？簡而言之，就和今天的以太坊全節點一樣，可以同步所有歷史，但成本太高，對硬件的要求也很高。
如果一個研究者想知道以太坊這些年是如何推進的，ACD 和所有EIP 的討論都是重要的參考資料，這些都會在線直播，並且留下視頻和會議記錄（儘管漏了幾期，會議序號也標錯過）。此外，以太坊研究者論壇和以太坊魔術師論壇都是重要的討論陣地，近來EthereumCatHerders 關於EIP 的解讀也非常精彩。總體來說，對於一個研究者來說，素材是比較充分的。然而，這些素材過於瑣碎，缺少結構化的整理。例如，想知道某一個EIP 在哪些會議中被討論過，以及哪些人曾經發表過相關意見，以便梳理研究脈絡和請教，就需要研究者花費大量時間去查詢。
此外，散落在discord、reddit、各類AMA、github 評論區、個人博客上的信息浩如煙海，大部分研究者無法有足夠的精力和敏銳度去追踪這些。換而言之，要同步這些歷史太難了。以EIP-2315 為例，有幾個人能說得清楚它的來龍去脈？若不是lightclient 把時間線梳理清楚，並且提煉出『EIP-2315從未被接受過』的事實，這個錯誤的決定可能就渾水摸魚伴隨著柏林昇級進行了。而Tim Beiko 在核心開發者會議紀要[8] 中甚至沒有提到這一事件，更不要說反思了。
柏林曾經受過多次戰爭的苦難，好在這一次它被拯救了，唯有感謝上蒼保佑。
[1]https://github.com/ethereum/eth1.0-specs/blob/master/network-upgrades/berlin.md
[2]https://github.com/ethereum/pm/issues/263
[3]https://eips.ethereum.org/EIPS/eip-2315
[4]https://github.com/ethereum/pm/issues/263#issuecomment-790381273
[5]https://github.com/ethereum/pm/issues/263#issuecomment-790910171
[6]https://github.com/ethereum/EIPs/pull/3309
[7]https://hackmd.io/@timbeiko/acd-update-001
