原文：Current Ethereum
作者：@LuozhuZhang
翻譯：Franci, ECN
文章概述了以太坊目前開發工作的重心，並整理出了關鍵升級的路線圖和時間線。
譯者註：本文撰寫於2022 年12 月31 日，文章基於第151 次ACD 會議確定的工作計劃展開，因此與目前的路線圖有出入。
需要注意的是，在2023 年1 月5 日進行的第152 次ACD 會議中確定，EOF 相關的EIP 被移出上海昇級。更多關於#152 ACD 會議的中文筆記請看ECN 的整理：#152 以太坊核心開發者會議筆記。
上海昇級的規範請看此處：
https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md#eips-considered-for-inclusion。
特別感謝proto.eth 的幫助和寶貴意見。
目錄
背景
升級的主要內容
-
信標鏈提款
-
EOF
-
EIP-4844
-
其他EIPs
路線圖和時間線
-
時間線
-
Shanghai + Capella 升級
-
下一個升級：坎昆升級
總結
一、背景
我受到CC 和Vitalik 的啟發而撰寫了此文。
他們一致認為，學習以太坊的最好方法是觀看核心開發者會議(All Core Devs)，閱讀相關的會議記錄，查看hackmd 文檔、issue、PR 以及EIP，直到你弄清楚以太坊當前的路線圖狀態、核心開發者的關注點和擔憂點以及每個升級/EIP 的作用是什麼…
除此之外，我還受到了社區的啟發。
以太坊有著優秀的開源文化，你可以在EF YouTube 上看到所有的會議視頻，以及在 ethereum/pm 查看未來討論的議程(還可以看Tim 和Kim 的筆記)。以太坊的開發者們正在盡最大的努力讓社區了解以太坊目前的升級和其改進提案。
所以我認為撰寫這類文章對社區是非常有價值的！
二、升級的主要內容
2022 年9 月15 日，以太坊成功合併後便將其註意力轉到後續的改進提案中：執行層上的上海昇級；共識層上的Capella 升級 。
主要有以下幾點
• 信標鏈提款
• EOF
• EIP-4844
• 其他EIP
他們扮演著不同的角色。信標鏈提款是上海昇級的核心，而EOF 只有在提款不會受到影響而延遲的情況下才會被納入到上海昇級中。 (譯者註：最新的ACD 中確定EOF 從上海昇級中移除)
此外，由於EIP-4844 可能會影響提款的推進時間，它已經被移出了上海昇級的範圍(譯者註：EOF 也是這個原因而被移出上海昇級)。但是我們都知道EIP-4844 是以太坊的一個重要改進提案，所以它將是下一次升級(坎昆升級) 的重心。
以防讀者們是首次了解上海昇級，我將在本文中單獨解釋相關的術語和EIP。
信標鏈提款
理解“提款” 需要對信標鏈的歷史和演變有一些基本的認知。
信標鏈還沒推出
在信標鏈推出之前，以太坊是一條完整的單一型區塊鏈，它的共識引擎(PoW) 和執行引擎(EVM) 在一起工作，沒有耦合和分離。
階段 0
信標鏈在階段0 (2020 年12 月) 推出。
自此，以太坊由單一型區塊鏈轉變為兩條平行鏈的結合(即信標鍊和執行鏈)。
在它們之間通信的唯一方式就是存款合約，存入並鎖定32 個ETH 以成為一名驗證者(這個角色類似於PoW 機制下的礦工)。
Altair 升級
很快，信標鏈在上線兩週內迎來了首次硬分叉，也就是Altair 升級。這次升級做了一些簡單的修復(共識層升級以星星的名字命名)。
Bellatrix 升級
第二次硬分叉升級是Bellatrix，合併就是在此次升級進行的：信標鏈與執行鏈合併。
合併後，以太坊從兩條平行鏈變成一條鏈，但還是由兩層組成，即共識層和執行層。這兩層通過引擎 API 通信。
在終結總難度值(TTD) 58750000000000000000000 中，Bellatrix 升級(在共識層發生) 和Paris 升級 (在執行層發生) 同時推出。通過EIP-3675 和EIP-4399，以太坊成功從PoW 共識過渡至PoS 共識！
Capella 升級
這是信標鏈的第三次硬分叉升級(以Capella 星星命名)，它會與上海昇級(執行層) 同時進行。通過EIP-4895，實現從信標鏈提款至EVM 的功能。
這也是目前共識層和各個客戶端團隊的主要工作。升級完成後，所有驗證者都可以提出他們的ETH。信標鏈的總存款已經超過了15,741,431 ETH，驗證者能夠動態變化對於以太坊經濟層來說非常重要。
EVM 對象格式(EOF)
作為EVM 的超級愛好者，我相信很多人對EOF 期待已久。幾年前，就有關於“ 以太坊賬戶版本化” 的討論和改進提案。直到現在，EOF 就要成為現實，確定納入到上海昇級的範圍內(實際上，EVM 自創世區塊以來就沒有改變多少)。
(譯者註：最新的ACD 中確定EOF 從上海昇級中移除)
簡單地說，目前的EVM 只有一套解釋和驗證規則來處理所有現有的合約(我們將它們稱為“舊式合約”)。
EOF (包含5 個EIP) 引入了一種新的智能合約格式，即“EOF 合約”。而客戶端/EVM 解釋器也有相應的更新。
所以我們現在有兩套EVM 解釋和驗證規則，並且它們是平行存在的。 EVM 將能夠同時處理舊式合約和EOF 合約(在更長遠的未來，我們可能會用EOF 合約取代所有的舊式合約)。
為什麼需要EOF，它有什麼好處？
➤ EVM 版本化。這使得引入或移除功能變得更容易，防止EVM 變得越來越複雜和不優雅。現在移除EVM 的功能非常困難，因為龐大的生態系統/應用層依賴某個特定的EVM 行為，所以移除可能會導致應用層的不兼容性問題。所以如果向EVM 添加某個功能，我們需要默認它可能會永遠存在。
➤ 增加新的控制流操作，完全放棄動態跳轉和運行時的JUMPDEST 分析，性價比更高。 (並使代碼轉換更容易，等等。)
➤將EVM 在運行時驗證的內容(eg 堆棧underflow, overflow) 轉移到部署時間。這使得EVM 的開銷降低，並使合約代碼更加安全(潛在的錯誤不會被部署在以太坊上)。
➤ 代碼和數據分離。我們將有一個可執行但不可讀的代碼部分，以及一個可讀但不可執行的數據部分。
此外，EOF 主要由5 個EIP 組成，我將簡單介紹每個EIP 的作用。如果讀者想了解更多關於EOF 的信息，我建議大家去看過去的討論，比如“EVM 封裝格式” 和“ 關於EVM 的一切”，以及這五個EIP (這裡有一個統一的規範)。這些資料都非常有幫助！
➤ EIP-3540: EVM 對象格式(EOF) v1 (EVM Object Format, EOF v1)
這個EIP 引入了EOF “container” 並規定了所有包含在EOF 合約中的字段(在這裡可以查看完整的字段)。此外，它依賴於EIP-3541，這個EIP 確保EOF 格式的合約部署在上海昇級前會被拒絕。
➤ EIP-3670: EOF – 代碼驗證(EOF – Code Validation)
這個EIP 在EIP-3540 的基礎上，為EOF 合約添加更多的驗證規則。無效的EOF 代碼無法被部署，在這裡查看所有代碼驗證規則。
➤ EIP-4200: EOF – 靜態相對跳轉(EOF – Static relative jumps)
這個EIP 引入了一些新的跳轉指令– RJUMP、RJUMPI 和RJUMV，它們被用來指向已執行代碼的相對位置。通過這個EIP，我們可以初步刪除JUMPDEST 分析(動態跳轉 JUMP 和JUMPI)。
➤ EIP-4750: EOF – 引入函數(EOF – Functions)
這個EIP 在4200 的基礎上更進一步，它引入了“EVM 函數” 的概念(這是一個獨立的子程序)，並且引入了CALLF 和RETF 來調用&返回EVM 函數。通過EIP-4750 和EIP-4200, 我們可以完全拋棄JUMPDEST 分析(動態跳轉 JUMP 和JUMPI)。
➤ EIP-5450: EOF – 堆棧驗證(EOF – Stack Validation)
這個EIP 添加了更多驗證規則，並將堆棧underflow/overflow 、inefficient gas 等從運行時檢查轉移到部署時檢查。這可以進一步減少EVM 的開銷(目前的underflow/overflow 是由EVM 解釋器在運行合約代碼時檢查)。
我個人認為，EOF 對EVM 來說是一個重大的改進，所以我希望在上海昇級中能部署EOF (在不影響提款推進的前提下)。
至於EOF 路線圖，我們將在初期同時保留舊式合約和EOF 合約，然後將現有的舊式合約轉換成EOF 合約(顯然後者不會是我們優先考慮的)。但這可能會對zkEVM 產生一些影響。
➤ 取決於EOF 合約的數量。如果大部分合約是舊格式的，現有的zkEVM 不需要做太多修改就可以與EOF 兼容。
➤ 如果所有現有的合約都轉換為EOF 合約，我們需要在所有電路中增加與EOF 相關的約束條件(比如數據和代碼的分離，這可能會改變現有的字節碼電路)。
➤ 對於操作碼來說，JUMP 和JUMPI 可能會被廢棄，因為EOF 禁用了動態跳轉。而根據Vitalik 的提案，CODECOPY 和CODESIZE 也可能在未來被拋棄。另外，我們需要為新的操作碼編寫約束(例如RJUMP 、RJUMI 、RJUMV 、CALLF 、RETF 等等)。
但總的來說，zkEVM 總是需要隨著EVM 的變化而變化(zkEVM 服務於EVM)，而當zkEVM 用於Layer1 (類型一zkEVM)，每次EVM 升級也會把zkEVM 考慮在內，並且同時升級(EVM + zkEVM) 是有可能的。所以我認為保持zkEVM 更新不是什麼大問題。
至於EOF。未來還有許多改進，比如考慮禁止EOF 代碼被CODECOPY 、CODESIZE 、EXTCODECOPY 、EXTCODESIZE 和EXTCODEHASH 直接讀取，並實現EVM 版本的自動-強制轉換(版本n 的代碼可以自動轉換為版本n+1)。 EVM 代碼甚至可以轉換為其他VM 代碼的等價物。
如果我們將來決定從EVM 轉變為其他VM (例如WASM、Cairo 等)，就有可能自動將EVM 的代碼轉變為具有同等功能的新虛擬機的代碼。
EIP-4844
EIP-4844 完全是為Rollup 設計的，以進一步降低數據提交和驗證的開銷(根據L2fee，L2 的交易費已經比L1 便宜4-20 倍)。
Proto-danksharding 來自proto.eth 在ETH Denver 中對完整版Danksharding 的簡單實現。它比完整版的Danksharding 更容易實現，這對以太坊擴容來說非常重要。
雖然EIP-4844 已經足夠簡單了，但是它的實現仍廣泛涉及以下幾個方面。
• EIP 本身 (已完成)
• 共識規範 (正在進行, 大概完成)
• 引擎API 規範 (已完成)
• 客戶端實現 (正在進行，參考 Geth 和 Prysm)
• KZG 儀式 (已完成，在這裡參加)
• 工具、開發者測試網(正在進行, 大概完成)
• 測試 (正在進行)
雖然EIP-4844 的進展非常快，但仍有許多工作要做(包括客戶端實現和大量測試)。以防4844 的推進會使得提款的進程延遲，在ACD#151 中開發者們決定將EIP-4844 移除出上海昇級(但Péter Szilágyi 和Dankrad Feist 對此表示反對)。
EIP-4844 是以太坊的下一個關鍵改進，我們都知道它的重要性。這也是為什麼上海昇級之後的下一次升級中(坎昆升級) 將以EIP-4844 為重心。
其他EIP
除了提款和EOF，上海昇級還會部署三個獨立的EIP
➤ EIP-3651: Warm COINBASE (降低訪問 COINBASE 地址的gas 開銷)
這個EIP 作為EIP-2929 的補充，為交易執行的開始增加了一個COINBASE 地址。
➤ EIP-3855: PUSH0 instruction (新增操作碼 “PUSH0`)
這個EIP 引入了一個新的指令PUSH0 ，用來把常量 0 值壓入堆棧中。
➤ EIP-3860: Limit and meter initcode (對initcode 的大小設限並引入gas 計量)
這個EIP 擴展了EIP-170。它限制了initcode 的大小上限在49152 的位置，並為initcode 引入每32 字節2 gas 的開銷。
三、路線圖和時間線
作者LuoZhu 對路線圖和時間線的最新補充：
➤ EOF 從上海昇級中移除，會不會在坎昆升級部署需要看1 月19 日的ACD 會議
➤ EOF 可能不會推進的這麼快，比如配合EOF v2 和一個比較完整的路線圖
時間線
基於12 月8 日ACD #151 會議，確定的以太坊升級時間表大致是這樣的
一月
在1 月5 日(下一次ACD 會議#152) 前完成EOF 的客戶端實現和測試，在1 月12 日為上海昇級進行影子分叉，在1 月19 日(第153 次ACD 會議) 前完成EOF 的跨客戶端互操作。
二月
2 月份將進行更多的測試，以確保EOF 和提款足夠穩定。並在公共測試網(Sepolia、Goerli 等) 上部署提款功能。
三月
發布上海昇級(主網上的信標鏈提款！)。
四月
重點轉移到下一次的坎昆升級(以EIP-4844 為中心)，全面測試EIP-4844。如多個主網影子分叉，並使EIP-4844 進入公共測試網。
五月
發布坎昆升級(EIP-4844 上主網! )
Shanghai + Capella 升級
這次升級的核心是信標鏈提款。為了避免任何阻礙提款的可能性，EIP-4844 從上海昇級中移除(你可以在這裡看到完整的上海昇級規範)。
而EOF 的開發進展需要嚴格遵守上述時間線，否則將被移除。兩個比較重要的時間點是：2023 年1 月5 日(ACD #152，EOF 需要完成客戶端的實現和測試) 和2023 年1 月19 日(ACD #153，完成EOF 跨客戶端的互操作)。
上海昇級預計將在3 月發生(共識層和執行層同時升級)。如果一切順利，我們將很快在主網上看到EOF 和提款!
下一次升級：坎昆升級
由於EIP-4844 被移除出上海昇級，我們把它作為下一次升級的重心(你可以在這裡看到坎昆升級的規範)。
預計EIP-4844 的實現和測試將在2023 年4 月完成，並部署在公共測試網上。然後坎昆升級可以在5-6 月啟動，將EIP-4844 部署到主網上。
總結
今天是2022 年的最後一天，在這一年裡我們看到了許多重大的技術進步。例如：成功合併、完成EIP-4844 的規範、rollup 崛起、zkp 湧現了許多創新，以及zkevm 也有許多進展。
我很高興能見證這一年。也為以太坊協議出現這些底層的改進感到興奮。
明年，我們會有更加關鍵的升級：它們是上海+Capella (提款和EOF)，坎昆+Deneb (EIP-4844)，以及Prague + Electra (待定)。
明年仍然會是很值得期待的一年，有很多工作等著我們去做。我們將看到更多的基礎性想法和研究，所以我認為用這篇文章來開啟2023 年是非常合適的。