首頁

以太坊核心開發者最新會議摘要：Dencun硬分叉、Prague/Electra提案

閱讀本文需 25 分鐘

1月18日，以太坊所有核心開發人員參加了第179次All Core Developers Execution(ACDE) 電話會議。

原文標題：《Ethereum All Core Developers Execution Call #179 Writeup》

原文作者：Christine Kim

原文編譯：Luccy，BlockBeats

< br>

編按：

以太坊所有核心開發者共識電話（ACDE）每兩週舉行一次，主要討論和協調對以太坊執行層（EL）的變更。本次為 ACDE 第 179 次電話會議，本次會議開發者回顧了 Cancun/Deneb（Dencun）升級在 Goerli 網路上的激活，並就即將在 Sepolia 和 Holesky 測試網絡上激活 Dencun 的事宜達成一致。會議詳細介紹了 Dencun 在 Goerli 啟動後的一些問題，包括網路參與率的下降和 Prysm 用戶端的一個 bug。

此外，開發者們討論了Prague/Electra（Petra）升級的優先事項，對EIP 3074、EIP 6913、EIP 7251 和EIP 7547 改進提案進行了討論。開發者也針對 Layer-2 協議何時開始在 Goerli 提交 blob 交易進行了探討，表達了對 Dencun 升級對 Layer-2 的即時可用性的信心。

Galaxy Digital 研究副總裁Christine Kim 對本次會議要點做了詳細記錄，BlockBeasts 將原文編譯如下：

2024 年1 月18 日，以太坊開發人員齊聚Zoom 參加了All Core Developers Execution (ACDE) call #179 會議。 ACDE 電話會議是一個每兩週舉行一次的系列會議，由以太坊基金會協議支持主管 Tim Beiko 主持，開發人員在會上討論和協調對以太坊執行層（EL）的更改。本週，開發者們分享了在 Goerli 網路上啟動 Cancun/Deneb（Dencun）升級的事後總結。開發者也一致同意在即將到來的 1 月 30 日和 2 月 7 日在 Sepolia 和 Holesky 測試網路上啟動 Dencun。最後，開發者們討論了 Prague/Electra（Petra）升級的優先事項，與會的大多數客戶端團隊一致認為該升級應包含較小的程式碼更改，以便在 2024 年底之前準備在主網上實施。

Goerli 上的Dencun 硬分叉

Dencun 升級於2024 年1 月17 日星期三在Goerli 網路上激活，大約在6:30（UTC）左右。根據以太坊基金會（EF）的 DevOps 工程師 Parithosh Jayanthi 總結，啟動升級後，Goerli 網路的參與率立即下降。這一下降的根本原因是 Prysm（CL）客戶端中存在的一個錯誤。 Prysm 團隊在發現問題不到四個小時後發布了熱修復。一旦運行 Prysm 用戶端軟體的節點營運商更新了他們的設備，網路參與率從大約 40% 上升到 70%，這使得網路能夠完成區塊、Blob 和交易。

自從 Dencun 在 Goerli 網路上啟動以來，EF 測試團隊一直在 Goerli 上提交大量的 Blob 交易，以測試網路處理這些類型交易的能力。 Jayanthi 表示，初步指標，包括 Blob、區塊和 Attestation 傳播速度，看起來很健康。有關這些指標的更詳細分析可以在EF DevOps 團隊的這篇文章中找到。

Prysm 團隊的 Terence Tsao 也分享了有關在 Goerli 上修復的 Prysm 用戶端中的 bug 的更詳細解釋。 Tsao 解釋說，問題是由於 Prysm 用戶端中的歷史根字段為空引起的。歷史根是從先前的以太坊升級 Shanghai/Capella（Shapella）中延續過來的傳統字段，開發者忘記更新為非零值。這是一個「容易」發現的錯誤，Tsao 說，只需要對經歷了 Shapella 等升級的測試網絡進行長時間的分析。所有先前實施 Dencun 的開發網路和影子分叉都在網路上太快地經歷了先前的升級，以至於無法捕捉到這個 bug。展望未來，開發者同意將這種邊緣情況包含在他們的測試向量中，並更加慎重地在升級測試過程中更早測試這種邊緣情況。

關於Dencun 後在Goerli 上觀察到的其他不規則性，Tsao 提到某些CL 用戶端似乎「不管什麼情況都」在請求Blob，甚至是對於沒有KZG 承諾的區塊。鑑於這種行為是「浪費的」，Tsao 建議客戶端團隊研究他們客戶端的行為，並確保僅在具有適當 KZG 承諾的區塊時觸發 Blob 請求。

隨後，Jayanthi 在電話會議上向開發者詢問，關於第二層協議（L2s）何時開始在 Goerli 上提交 Blob 交易的見解。考慮到他的團隊正在「人為地垃圾郵件式」地用 Blob 充斥測試網絡，Jayanthi 表示，在 L2s 準備提交自己的 Blob 交易時，他希望減少這種活動。來自 Prysm 用戶端團隊的 Tsao，該團隊是 L2 協定 Arbitrum 擁有的軟體用戶端，表示 Arbitrum 團隊可能會在 Sepolia 測試網路而非 Goerli 上測試 Blob 交易。 Optimism L2 協議的一位化名開發者，以「Protolambda」為螢幕名，表示 Optimism 團隊計劃在未來幾週開始在 Goerli 上進行測試。 EF 研究員 Ansgar Dietrichs 表示，他將在下一次 Rollcall 會議上提到這個問題，Rollcall 是一個專注於第二層協議的標準化和協調的會議系列。

Dencun 的L2 準備

ACDE 會議主席Tim Beiko 就開發者們對Dencun升級對L2 的立即可用性有多大信心提出了更具體的問題。「我們是否看到4844 在某種程度上對L2s 來說不足夠？顯然，你可以想像它在主網上使用了幾個月，然後L2 選擇使用它。這可能沒問題，但我們希望確認它被認為是可用的的最低確認程度是多少，我們是否已經達到了？」Beiko 說。（4844 是指以太坊改進提案4844，也稱為proto-danksharding，這是Dencun 升級中為L2 設計的主要代碼更改。有關proto-danksharding 的詳細信息，請閱讀這份Galaxy Research 報告。

Protolambda 回應說，雖然Optimism 團隊「接近」能夠支援Dencun，但他對Blob 交易的基礎設施和工具的準備性表示擔憂。「在第一層之外還有更多的基礎設施需要更新，」Protolambda 說。Beiko 澄清說，他不會阻止以太坊主網在L2s 能夠支持升級之前更快地採用Dencun。但是，在激活後不久，L2s 可能會提供「額外的驗證」，以確保Dencun 是以太坊協議的有用變更。

Jayanthi 表示，他將把Goerli 上Blob 的目標垃圾郵件數量從每個Blob 的六個減少到三個，以便在L2 準備好時，他們可以測試Blob 的基礎設施。EF 研究員Alex Stokes 也提到，Flashbots 團隊一直在Goerli 上提供一些包含Blob 的區塊建構器負載，以測試MEV-Boost 工作流程。

執行API 規範變更

Geth（EL）客戶端的一位名為「Lightclient」的開發者提出了與Dencun 升級相關的執行API 規範的待定更改。正如在ACDE＃174上討論的那樣，Blob 交易的引入意味著獲取有關Blob 燃氣價格和費用的新方法。為了與已在以太坊上檢索常規交易有關燃氣資訊的方法的命名一致，提議將執行API 方法中的“eth_blobgasprice”更新為“eth_blobbasefee”。該提案還建議將 Blob 費用資料新增至「eth_feeHistory」執行 API 方法。

開發者同意在Ethereum Research and Development Discord 頻道中發出最後的評論邀請，並明確標記一個可能受到這一變更影響的Infura 代表，以便審查並合併這些變更，如果沒有反對意見的話。

EIP 4788 合約部署

如先前的ACDE＃168通話中討論的那樣，Dencun 升級中的一個代碼變更，即EIP 4788，要求手動部署程式碼並建立一個智慧合約位址，然後可以在硬分叉時啟動。開發者同意提前在以太坊主網上部署程式碼。 Beiko 要求有人在 Ethereum R&D Discord 上自願參與，並表示他將為參與者報銷用於提交交易的燃氣費。

EF 研究員兼 ACDC 通話主席 Danny Ryan 簡要介紹了為 Dencun 發布的新 CL 規範。最新版本將包含在ACDC＃125中提到的分叉選擇過濾更改，以及用於檢查歷史根字段的新測試向量和一些其他小型更新。新版本預計將在本週發布，並成為 CL 用戶端團隊在其各自的程式碼發布中遵循的標準。

Sepolia 和Holesky 分叉時間

接下來，開發者們討論了在最後兩個以太坊公共測試網路Sepolia 和Holesky 上啟動Dencun 的時間安排。在 Goerli 上啟動 Dencun 之前，開發者已經同意在 1 月 30 日和 2 月 7 日分別在 Sepolia 和 Holesky 上啟動 Dencun。在本週的 ACD 通話中，開發者重新確認了這些日期，並同意採取單一客戶端發布的方式進行這兩個升級，以便 Holesky 升級可以更快地進行，即在 Sepolia 升級後的一周。來自 Lighthouse 用戶端團隊的代表在 Zoom 聊天中提到，Sepolia 和 Holesky 的發布可能再次是「預發布」，這意味著這是一個尚未準備好用於主網的發布，可能需要更新。 Prysm 在先前的通話中表示，他們針對 Goerli 升級的發布是一個預發布。目前尚不清楚他們針對Sepolia 和Holesky 的發布是否同樣會是另一個預發布

Sepolia 和Holesky 升級的具體時間可以在Dencun 硬分叉Meta EIP 文件中找到。

Protolambda 在 Zoom 聊天中詢問開發者們對於在最終測試網絡 Holesky 上激活 Dencun 和以太坊主網之間的時間感覺。「在 Holesky 和主網 L1 之間的最小推出時間，大家估計是多少？一個月，兩個月？有足夠時間來測試 L2 效果，包括 blob 過期，會很好，」Protolambda 寫道。作為回應，Beiko 寫道，「我期望的最小時間是一個月？」Jayanthi 表示，最早可以在Goerli 上測試blob 的到期時間是2 月5 日，並建議開發者在之後的ACD 通話中於2月8 日更詳細地討論這個主題。 Danny Ryan 建議 2 到 3 週。

Prague/Electra 提案

接下來，開發人員討論了一些提議納入Petra 升級的EIP< /a>。

EIP 3074

由一位使用螢幕名稱「Foobar」的匿名開發者在通話中介紹，EIP 3074 引入了兩個新的EVM 指令“AUTH”和“AUTHCALL”，以實現更大功能的外部擁有帳戶，其中最重要的之一是能夠簽署批量交易。 Foobar 詳細介紹了為什麼批量交易是以太坊終端用戶的重要功能，將提高其資產安全性，並改善去中心化交易所（DEXs）上的用戶體驗。有關EIP 3074 的更多信息，請閱讀由Foobar 撰寫的這篇部落格文章。

EF 研究員 Ansgar Dietrichs 表示，他對 EIP 3074 的兩個主要反對意見是其在較窄版本的 EIP 上的實現優勢。其次，Dietrichs 表示，在他看來，改進以太坊用戶體驗的 EIP 應首先在 Layer 2 上實施和測試，因為 Layer 2 更靈活，更快地採用新技術，而不是以太坊主網。 VM Capital 創辦人 William Morriss，一家 DeFi 交易公司的創辦人，對 Dietrichs 的第二個反對意見表示不同意。「我認為Layer 2 不應被視為一個功能測試網。製作Layer 2 的開發者非常關心與主網的兼容性，如果他們部署了一個有臨時規範的功能，那麼當最終到達主網時，即使它具有相同的操作碼編號，行為可能會有差異，這對他們來說將是技術債。因此，他們通常不特別有興趣為我們扮演那個角色，」Morriss 說。

Nethermind 用戶端的開發者 Ben Adams 同意 Foobar 的觀點，即大量交易是改善以太坊終端使用者體驗的可取功能。 Lightclient 補充說，在他看來，下一個升級對以太坊使用者體驗進行某種改進的需求很大，因此如果不是 EIP 3074，開發者應考慮另一個更容易實現的版本。 Beiko 建議繼續在Ethereum Magicians上討論EIP 3074 的優點。

EIP 6913

隨後，Morriss 介紹了EIP 6913的不同實作設計。在他的演示中，Morriss了一種名為「SETCODE」的新EVM 指令的動機，該指令能夠取代智慧合約帳戶中的程式碼，而無需將程式碼移轉到新位址。開發者對該 EIP 提出了幾點反對意見。來自 Geth 團隊的 Marius van der Wijden 表示，該 EIP 將破壞對燃氣估算，並在節點上創建 DoS 攻擊向量。 Dietrichs 表示，EIP 6913 應該只在「全面的 AA 路線圖」的背景下考慮，這指的是以太坊上的帳戶抽象路線圖。 Lightclient 表示，在他看來，該 EIP 對於「改變協定並不足夠有用」。 Morriss 同意開發者應該以某種方式在以太坊上實現帳戶抽象，無論是透過 EIP 6913 或其他以 AA 為重點的 EIP。

EIP 7251 和EIP 7545

EF 研究員Mike Neuder 介紹了 EIP-7251和EIP-7547，它們是兩個專注於共識層（CL）的程式碼更改，對執行層（EL）的影響較小。

· EIP-7251 增加了驗證者的最大有效餘額。它需要與 EIP-7002 結合使用，該提案允許驗證者使用其 EL 提款憑證從 Beacon Chain 觸發對 EL 的部分提款。

· EIP-7547 實現了一個機制，透過該機制，區塊提議者可以強制將某些交易包含在一個區塊中。關於透過包含清單強制包含以及它們對幫助防止以太坊上的交易審查的詳細信息，請閱讀Mike Neuder 在Ethereum Research 上的這篇文章。

在會議上，許多開發者支持將 Neuder 提出的 EIP 列為 Petra 的優先考慮。特別是關於EIP 7547，Neuder 強調：「我們目前處於一個稍微微妙的情況中，一些大型礦工已經開始審查某些交易，而有一些礦工則沒有這樣做。如果那些礦工決定開始審查，情況可能會迅速變得糟糕…如果超過九成的區塊都受到審查，這不僅會給我們造成負面形象，而且用戶在獲取這些交易時的體驗將明顯下降。因此，我目前認為情況非常不穩定，越來越多的建設者和驗證者的回饋也讓我認為，在監管事務仍然不確定的情況下，獲得一些固定的包含是非常重要的。

關於Petra 的想法

在提出的Petra 升級的完整EIP 清單中， Beiko 詢問客戶團隊對升級內容的「高層次」想法是什麼。 Reth 客戶團隊的 Georgios Konstantopoulos 表示，他的團隊將支援在年底之前發布的 Petra 升級，其中包括與質押相關的 EIP 和孤立的 EVM 變更。有關將包括哪些EIP 的更詳細概述，請閱讀Reth 關於Petra 升級的部落格文章。

EF 研究員 Alex Stokes 支持 Reth 關於 Petra 的觀點。其他客戶團隊，如 Nethermind 和 Geth，也支援在年底之前發布的升級。大多數客戶團隊也傾向於在之後的升級中專注於Verkle 樹。在會議上有一些關於 EOF 相關代碼變更是否應在 Verkle 升級之前實施的辯論，因為 EOF 可能會增加 Verkle 實施的複雜性。有關EOF 的更多信息，請參閱之前的ACD會議記錄。

基於客戶團隊在會議上對 Petra 的高層次看法，Beiko 建議至少在 Prague 升級中包含 EIP 6110、7002 和 2537。（有關包含在Electra 升級中的伴隨CL 專注的EIP 的討論將在下一次ACDC 會議上進一步詳細討論。）至少將這三個EIP 包含在Prague 升級中，Beiko 還建議將下一次ACDE 會議的重點放在在決定更大、更複雜的程式碼變更的時間表上，如Verkle、EOF 和歷史資料修剪。一個化名為「Potuz」的Prysm 客戶團隊的匿名開發者補充說，如果升級可能在2025 年或之後發布，開發人員應致力於在2024 年底之前將Petra 用於主網實施，因為有關Petra 應包含什麼的意見可能會改變。 Potuz 也向 Reth 團隊的詳細部落格文章致以敬意，該文章闡述了 Petra 的優先事項。他鼓勵其他客戶團隊準備類似的文件。