文章概述了以太坊目前開發工作的重心，並整理出了關鍵升級的路線圖和時間線。
作者：@LuozhuZhang
翻譯： Franci, ECN
封面： Photo by Shubham's Web3 on Unsplash
譯者註：本文撰寫於 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 年是非常合適的。新年快樂!
免責聲明：作為區塊鏈信息平台，本站所發布文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。文章內的信息僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
