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。

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 的優先事項。他鼓勵其他客戶團隊準備類似的文檔。

1 月 6 日 Besu 主網活動

由於本周 ACD 會議時間有限，關於1 月 6 日影響 Ethereum 主網上 Besu 節點的故障和在最新的 EF 研究團隊 Reddit AMA中分享的有關少數客戶端性能數字的不準確資訊的最後一個討論項目被跳過。Beiko 表示，這個討論項目將作為下一次 ACDE 會議的第一個話題提出。

原文連結