以太坊改進提案及升級流程改進提議
編者按：本文來自以太坊愛好者（ID：ethfans）編者按：本文來自
以太坊愛好者（ID：ethfans）
摘要
二級標題
二級標題
摘要
摘要
這篇文章是Danno Ferrin 和我在DevconV （第六屆以太坊開發者大會）上的談話的粗略記錄。文章中討論了社區在過去一年中提出的一些EIP 流程改進建議，並且將其納入到一個統一的框架中用來指導我們如何讓以太坊更順利地升級。我們把它稱之為“火車站模型”。
二級標題
摘要
我們根據過去一年來社區提出的幾點建議，提出了一種協調以太坊網絡升級的新方法。具體來說，我們認為：
升級應該只包含準備好發布的以太坊改進提案（EIP），任何仍在討論中的改進內容都應該放到下一個升級，而不應延遲當前的升級；
以太坊改進提案應由工作組以獨立的方式製定，並且只有在完成後才應考慮納入升級；
讓我們先簡單談談以太坊的升級歷史。最初的幾次網絡升級，包括前沿，家園，拜占庭和君士坦丁堡，有點像1950 年代的家庭度假，爸爸媽媽會把車子行李打理好，我們會跳上後座，或許還會帶上我們最喜歡的玩具，總之他們會把我們安全地送到目的地。
圖片描述
圖片描述
這是一個過去升級的簡單類比，但是對於這些升級，核心開發人員編寫了大部分的以太坊改進提案，而以太坊社區足夠小，以至於他們可以有組織地，有計劃地與社區溝通，使得分叉和升級順利進行。
圖片描述
然而，這些計劃好的時間節點有多少真正按時完成呢？只有一個，就是剛開始的時候。
圖片描述
當我們得到以太坊伊斯坦布爾最終改進提案列表時，已經是夏天的中期了，按照本來的計劃，這時候我們應該要把客戶端實現做完了。當這種情況發生時，很多人意識到這個開發過程遠遠不及預期，關於我們如何使伊斯坦布爾之後的柏林昇級運行得更加順暢，已經有人提出了很多建議。我們現在將討論一些其中的建議，然後將它們合併到我們所稱的“火車站模型” 中。
圖片描述
二級標題
二級標題
圖片描述
圖片描述
以太坊1.X 會嘗試改變EIP 開發流程
在伊斯坦布爾升級期間，第一個嘗試解決開發流程問題的人是Alexey Akhunov。他寫了一篇博文（編者註：中譯本見文末超鏈接），描述了我們可以如何通過組建工作組、使用ReTestEth 來增加為以太坊協議改進作貢獻的成員數量，同時減輕現有核心開發者的負擔。在“pre-1.x” 的改進流程中，提交的以太坊改進提案將主要由Geth，Parity 和Aleth 的客戶端開發人員實現，在這種情況下，以太坊改進提案將由這些團隊協同改進。一旦客戶就以太坊改進提案的最終規範達成一致，就可以生成參考測試。 Aleth 是唯一可以生成測試的客戶端，因此為了生成這些測試，所有以太坊改進提案都要在Aleth 中得到實現。 EF 的測試團隊隨後將運行這些測試，並編寫所有客戶端都要運行的一致性測試。
二級標題
eEIP 擁護者
圖片描述
圖片描述
圖片描述
二級標題
二級標題
-感謝MP 和Boris 協助舉辦了討論這些事項的研討會-
擁護者的作用是讓其成為一個與以太坊改進提案相關的聯絡節點，他們作為以太坊改進提案的討論協調員，負責確保升級過程順利向前推進並確定合適的人參與到了合理的討論中。他們並不負責所有的工作也不必然要自己去做實現，但他們應該是以太坊改進提案執行過程中的關鍵人物，並致力於在社區內與成員充分溝通升級的過程。
二級標題
以EIP 為中心的分叉
另一個想法，最近由EF 團隊的Martin Holst Swende 提出，是調整以太坊網絡升級過程，使其更加以EIP 為中心。與其以升級為中心、努力確保所有以太坊改進提案在升級的各個階段都步調一致，不如集中精力讓各EIP 成熟，並且僅為成熟、可發布的EIP 計劃升級。
如果有人想讓以太坊改進提案從草稿階段直至成功在主網激活，下面是他們在這個框架下的實現方式（引用了最初的提議，為了可讀性做了一些小的修改）：
步驟1：得到ACD 的肯定
假定以太坊改進提案存在（步驟0），ALCORIEDEV （論壇）將初步決定以太坊改進提案是否“初步接受”。 “初步接受”（ 或“肯定” ）是指主要客戶端和生態系統利益相關者對該以太坊改進提案持有積極的態度，願意接受（精心編寫）的PR 以將EIP 整合到代碼庫中並開始測試……但這一階段不會指定激活的實際區塊高度。
這種“初步接受” 的狀態對於像EF、ConsenSys 甚至MolochDAO 這樣的資助協議升級的組織來說也是一種有用的信號機制。資金資助可以分為幾個階段（即“初步接受” 之前和之後），以確保大多數資金都花在了促進主網上線的計劃上。
步驟2：執行
一旦ACD 給出了明確的方向，開發人員和其他以太坊改進提案作者就可以著手實現，並針對客戶端發布更新。
如果實現的功能被合併到主要的客戶端中，這個里程碑就完成了。
由於該特性現在可以在客戶端中“激活”，因此現在可以為該特性生成跨客戶端測試，測試案例應該包含happy-path 測試和quirk/edgecase 測試，此步驟應交給不僅對該EIP 有深入了解還對EVM （以太坊虛擬機）有了解的人一起執行，以求最大限度的降低出錯的可能性。
“那麼，讓我們在一個月後在測試網上激活這個以太坊改進提案（在區塊X 高度上），兩個月後在主網上激活這個以太坊改進提案（在區塊高度Y 上） 。”所有的客戶端都將在下一個版本中包含升級的內容，從現在起一周內，還可以從實際出發，通過命令行標誌推遲以太坊改進提案。
圖片描述
圖片描述
圖片描述
二級標題
二級標題
-謝謝James Hancock 畫的這麼直觀清楚的圖片！ -
使用這個框架將允許每個以太坊改進提案按自己的步調推動，因此可以減少升級過程中爭論時間和討論的範圍，同時還能減少測試團隊的壓力，因為這個流程相較原來更可預測，測試團隊就不用在截止日前手忙腳亂地集中測試了。
二級標題
1872 號以太坊改進提案
這一提案建議以太坊採用默認的網絡升級時間表，類似於微軟固定週二發布補丁的做法。這樣，運行以太坊節點的人就知道他們大概率該在什麼時候監視潛在的升級。簡而言之，這一提案建議我們這樣做：
讓主網升級默認發生在一個月的第三個星期三，最好是在1 月、4 月、7 月或10 月，以避開大多數主要的美國和歐洲假日。
無論何時何地只要發生問題，即刻解決
二級標題
二級標題
這一EIP 不會限制我們在意外情況發生時的處理能力，只是比較強調默認的周期性，比如6 個月一次的固定升級，以減少市場對升級不確定性的擔憂，同時減少核心開發者在升級過程中的溝通時間。
它還為我們當前的方法和“一個以太坊改進提案，一次升級” 方法（即以EIP 為中心的分叉方法）之間提供了“中間地帶”。
二級標題
火車站模型
結合上述建議的各個部分，我們得出了一個更接近火車站運營方式的流程，而不是我們目前的“更接近機場運營方式” 的流程。
當前，我們的升級類似於購買機票的工作方式：日期和時間是固定的，不管怎樣，我們都會盡量讓每個人都上飛機，哪怕會因為幫他們托運行李而延誤。
我們相信，如果轉向這樣一種模式：人們手拿行李出現在火車站，準備出發，然後乘下一班有座的火車離開，這將有助於使網絡升級比現在更加順暢。
