ETH上半年開發重心：前有上海 后有坎昆_NBS:NBS幣

原文：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 的幫助和寶貴意見。

目錄

背景

升級的主要內容

信標鏈提款

EIP-4844

其他 EIPs

路線圖和時間線

Shanghai + Capella 升級

下一個升級：坎昆升級

總結

一、背景

我受到 CC 和 Vitalik 的啟發而撰寫了此文。

他們一致認為，學習以太坊的最好方法是觀看核心開發者會議 (All Core Devs)，閱讀相關的會議記錄，查看 hackmd 文檔、issue、PR 以及 EIP，直到你弄清楚以太坊當前的路線圖狀態、核心開發者的關注點和擔憂點以及每個升級/EIP 的作用是什么…

除此之外，我還受到了社區的啟發。

以太坊有著優秀的開源文化，你可以在 EF YouTube 上看到所有的會議視頻，以及在  ethereum/pm 查看未來討論的議程 (還可以看 Tim 和 Kim 的筆記)。以太坊的開發者們正在盡最大的努力讓社區了解以太坊目前的升級和其改進提案。

所以我認為撰寫這類文章對社區是非常有價值的！

二、升級的主要內容

BAYC #8705 以100ETH價格成交:金色財經報道，Etherscan數據顯示，Bored Ape Yacht Club #8705 以100ETH價格成交。[2023/1/2 22:20:45]

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 升級

MakerDAO社區發起在Maker中增加stETH為抵押品的民意投票:10月13日消息，MakerDAO社區發起針對在Maker協議中增加stETH （Lido Staked ETH）作為新的Vault類型的民意投票，投票截止日期為北京時間10月15日00:00。該提議旨在允許用戶在Maker中使用stETH作為抵押品，目前暫無反對票。如投票通過，該提案將被加入未來的執行投票中，執行投票會在本次投票完成后30天內進行。[2021/10/13 20:24:54]

很快，信標鏈在上線兩周內迎來了首次硬分叉，也就是 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 自創世區塊以來就沒有改變多少)。

數據：以太坊2.0抵押地址余額突破110萬ETH:據歐科云鏈OKLink數據顯示，截至今日18時15分，當前以太坊2.0存款合約地址余額突破110萬枚ETH，達1121904枚。[2020/12/6 14:21:24]

簡單地說，目前的 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)

黑客已向dForce地址歸還57992個ETH折合1000萬美金:鏈上數據顯示，黑客已向dForce地址歸還57992個ETH，折合1000萬美金。[2020/4/21]

這個 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 相關的約束條件 (比如數據和代碼的分離，這可能會改變現有的字節碼電路)。

動態 | ETH未確認交易數達到50172筆:根據BTC.com數據顯示，ETH全網算力為168853.74GH/s，全網難度為2600.06T，交易速率為5.74筆/秒，每日收益為0.00010ETH，未確認交易數達到50172筆。[2019/1/14]

? 對于操作碼來說，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 年是非常合適的。

金色早8點

金色財經

Arcane Labs

Odaily星球日報

歐科云鏈

澎湃新聞

深潮TechFlow

MarsBit

BTCStudy

鏈得得

Tags：BSPNBSETH以太坊BSP價格NBS幣ETHSHIB以太坊官網錢包下載教程

中幣下載