ETH上半年开發重心：前有上海 後有坎昆

原文：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 在運行時驗證的內容 (e.g. 堆棧 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 年是非常合適的。

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。

---

標題：ETH上半年开發重心：前有上海 後有坎昆

地址：https://www.torrentbusiness.com/article/23155.html

標籤：