首頁

Partnered With:

以太坊核心開發者最新會議摘要：EIP-2935和EIP-3074將納入Pectra升級

閱讀本文需 21 分鐘

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

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

原文作者：Christine Kim

原文編譯：Luccy，BlockBeats

編按：

以太坊所有核心開發者共識電話（ACDE）每兩週舉行一次，主要討論和協調對以太坊執行層（EL）的變更。本次為 ACDE 第 185 次電話會議，會議上，開發者們就即將到來的 Prague 硬分叉所需的程式碼變更以及其他 EIPs 進行了深入的討論和評估。

開發者就各項提案進行了激烈的辯論，並就其中一些提案是否應該包含在 Prague 中達成了初步共識。然而，也存在一些爭議，例如關於 EOF 是否應該與 Verkle 升級捆綁在一起的討論。會議的最後，開發者們就下一步的工作計畫達成了一致，並決定在未來的開發網絡中進一步測試和評估各項提案的影響。

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

2024 年4 月11 日，以太坊開發人員齊聚Zoom 參加了All Core Developers Execution (ACDE) call #185 會議。 ACDE 電話會議是一個每兩週舉行一次的系列會議，由以太坊基金會協議支持主管 Tim Beiko 主持，開發人員在會上討論和協調對以太坊執行層（EL）的更改。本週，開發者們討論了應該添加到即將到來的以太坊 EL 升級——Prague 硬分叉中的程式碼變更。 Prague 將與 CL 升級 Electra 同時激活，預計在 2024 年底前完成激活。

最初，開發者同意將 Prague/Electra（Pectra）的範圍確定為包括五個以太坊改進提案（EIPs）。它們分別是：

EIP 2537，BLS12-381 曲線操作的預編譯

EIP 6110，在鏈上供應驗證者存款

EIP 7002，EL 觸發式退出

EIP 7251，增加最大有效餘額

EIP 7549，將委員會索引移出認證外

本週，他們一致同意在上述列表中包含EIP 3074（AUTH 和AUTHCALL 操作碼）和EIP 2935（在狀態中保存歷史區塊雜湊）。他們還決定從 Prague 中排除 EIP 7547（包含清單）和 EIP 7667（提高雜湊函數的 gas 成本）。開發人員強烈傾向於將 EIP 7667 與 Verkle 捆綁在 Prague 之後的下一個 EL 升級 Osaka 中。目前，仍在考慮將 10 個以太坊虛擬機器物件格式（EOF）EIP 和 EIP 7623（增加 calldata 成本）納入 Prague。

回顧Prague 中已包含的內容

在深入討論Prague 中正在考慮的EIP在清單之前，開發人員花了一小段時間回顧了升級中已經包含的EIPs 存在的問題。

EIP 7251

其中一個EIP，EIP 7251，將允許節點運作者將有效餘額高達32 ETH 的驗證者合併為一個有效餘額高達2048 ETH 的大型驗證者。有效餘額指的是驗證者獲得發行獎勵的抵押 ETH 餘額。超過 32 ETH 的餘額不會為驗證者帶來更多的發行獎勵，這就是為什麼節點運營商必須運行多個驗證者以增加他們的發行獎勵。 EIP 7251 旨在透過啟用驗證者合併和抵押獎勵的自動複利來減少以太坊上的活躍驗證者數量。

根據開發人員與Lido 等大型以太坊抵押池的討論，他們已經同意考慮對EIP 進行更改，使驗證者合併成為由EL 上的智能合約觸發的操作。以太坊基金會研究員Alex Stokes 強調了他關於協議內合併如何運作的論文，並要求在電話會議上向客戶端團隊徵求對他提出的程式碼變更的回饋。

EIP 2537

Stokes 也分享了關於EIP 2537 的最新消息，該提案向以太坊虛擬機（EVM）增加了操作，使開發人員能夠使用BLS12-381 曲線構造有效地執行加密簽章驗證。這是比在EL 上使用secp256k1 曲線構造產生的ECDSA 簽名進行驗證更安全和更快的方式。 Stokes 表示，對這些操作定價的初始基準測試工作已經完成，開發人員可以在接下來的幾週內期待對它們的確切 gas 成本的最終更新。同時，鼓勵客戶端團隊按照目前的範圍實施EIP，用於第一個Pectra 開發者測試網路pectra-devnet-0。

辯論Prague 還應該包括什麼

在本週的電話會議之前，EL 客戶端團隊提供了關於他們希望在Prague 中包含的其他EIPs 的書面更新，除了他們已經同意包括在升級中的五個EIPs 之外。 Beiko 在電話會議議程中連結了EL 用戶端團隊的偏好，為了長期保存，連結如下：

Mega EOF 殘局

在討論要在Prague 中包含的其他EIPs 時，Geth 開發人員Guillaume Ballet 表示反對在升級中包含EOF 的變更。他擔心這些變更可能會在 Prague 之後的升級（被稱為 Osaka）中實施 Verkle 變得困難或不可能。對此，Swirlds Labs 的首席軟體工程師 Danno Ferrin 提出了反對意見，稱 EOF 可以與 Verkle 程式碼變更「100% 相容」。 Ballet 對Ferrin 的評估表示懷疑，重申了之前一次ACDE電話會議上關於希望在Verkle 測試網絡上看到EOF 的評論。 Beiko 解釋說，基於 EOF 在未來硬分叉的測試網絡上的功能來評估其與 Verkle 的兼容性並不合理，並詢問 Ballet 是否能澄清 EOF 與 Verkle 兼容性方面的具體顧慮。 Ballet 未作回答。他表示，沒有 EOF 的程式碼規範供他審查。一位開發人員在Zoom 聊天中分享了最新的EOF 規範連結。聊天中也分享了基於客戶端實現的EOF準備情況的連結。

Geth 開發人員 Marius van der Wijden 詢問 EOF 將會增加或更新多少個操作碼。 Beiko 指出，根據最新的規範，EOF 將更改 18 個操作碼。 EOF 是來自10 個不同EIPs的EVM 的程式碼更改捆綁包。 Van der Wijden 表示，他對 EOF 的主要關注點是其複雜性以及客戶端團隊需要花費多少工作來充分測試 EOF 中的所有邊緣情況。 Nethermind 開發人員 Marek Moraczyński 同意 EOF 可能會「引入許多新的共識錯誤」，並且需要「仔細測試」，但不實施這些 EIPs 的負面影響意味著這些對 EVM 的改進將不得不等待另外兩三年。

Ferrin 指出，當開發人員在辯論 EOF 是否應包含在上海昇級中時，他們反對這些程式碼變更範圍過窄。現在，Ferrin 和其他開發人員已經努力使 EOF 更加廣泛，客戶團隊卻因程式碼變更過於複雜和難以實施而反對。 Ferrin 說：「我們無法從所有核心開發人員小組中獲得一致的請求。」他補充說，聽到兩個版本 EOF 的抱怨是「令人沮喪」的。 Reth 和 Erigon 用戶端團隊支援在 Prague 中包含 EOF。 Beiko 建議開發人員轉而討論其他 EIPs，並在電話會議後期回顧 EOF 的討論。

EIP 3074，AUTH 和AUTHCALL 操作碼

Beiko 詢問客戶團隊對EIP 3074 ，即AUTH 和AUTHCALL 操作碼的引入，有何想法。這些操作碼將透過允許智慧合約授權來自 EOA（以太坊的外部擁有帳戶）的交易，為使用者控制的帳戶增加了更多的可編程性。電話會議上的許多開發人員，包括 Georgios Konstantopoulos、Danno Ferrin 和“protolambda”，都支援這一代碼變更。 Protolambda 重新提出了他的建議 EIP 7664，旨在修復與存取清單互動時 EIP 3074 邏輯的漏洞。 Geth 開發人員和EIP 3074 的合著者Matt Garnett，也被稱為“Lightclient”，表示認為EIP 7664是個好主意。另一位開發人員詢問 EIP 3074 將如何影響 ORIGIN 操作碼，該操作會傳回發起交易的位址。 Beiko 表示，這些影響在 EIP 中列出，並詢問是否有任何開發人員反對在 Prague 中包含此程式碼變更。沒有反對意見。

EIP 2935，儲存歷史區塊雜湊狀態

Ballet 在ACDE #184上介紹了EIP 2935，這是一項程式碼更改，將為Verkle 的實作帶來未來的好處。 Reth 用戶端團隊對該 EIP 持「中立到積極」的態度，並表示，考慮到這是一個簡單的改變，他們不反對將其納入 Prague。 Erigon 客戶端團隊持類似態度，但指出，如果 Prague 中包含像 EOF 這樣的更大的程式碼更改，他們對將其納入 Prague 的信心會較低。 Beiko 建議繼續討論其他 EIP，並在電話會議後期回顧 EIP 2935。

EIP 7667，提高雜湊函數的gas 成本

以太坊聯合創始人Vitalik Buterin 提出了一項EIP，旨在提高雜湊函數操作碼和預編譯的gas 成本，使其與透過零知識（ZK）系統（如ZK EVMs）的執行成本相符。有關ZK EVM 的更多信息，請閱讀Galaxy Research 報告。關於重新定價以太坊雜湊函數操作的動機，Buterin 在EIP 7667文件中寫道：「雜湊函數操作碼和預編譯的gas 成本最初是基於在常規CPU 上執行它們所需的時間來設定的。然而，隨後，另一個同樣重要的執行底層出現了: 零知識證明（ZK-SNARK）系統。按照此標準，這些操作碼和預編譯相對於其他操作定價過低。」

Buterin 在電話會議上補充說，很容易低估ZK 證明將日益普遍，不僅用於驗證Layer-2 rollups 等內容，還涉及Layer-1 區塊鏈，如以太坊。他表示：「我認為，甚至在一兩年內，我們都可能具備即時證明以太坊L1 的能力。因此，我認為重要的是要適應這一事實，即ZK 鏈與非ZK 鏈之間不再有區別。我們現在基本上進入了每個嚴肅鏈都是ZK 鏈的模式。」

考慮到在 Osaka 升級中由於 Verkle 會對 gas 定價和計劃進行更改，Ferrin 建議將這項 EIP 與 Verkle 一起實施。 EF 研究員 Carl Beekhuizen 表示，這項 EIP 需要進行大量調查，開發人員必須「非常小心」地分析這些 gas 變化將如何影響以太坊上的智慧合約。 Van der Wijden 同意 Beekhuizen 關於謹慎推進這項 EIP 的看法。 Ferrin 還建議可能先在 Layer-2 rollups 上實施這些更改，而以太坊開發人員進一步調查其對 Layer-1 的影響。 Beiko 同意這種看法，並建議開發人員將 EIP 7667 與 Verkle 一起考慮納入 Osaka 升級，並給予「CFI」或「考慮納入」的狀態。沒有反對意見。

EIP 7623，增加calldata 成本

EIP 7623 的合著者、EF 研究員Toni Wahrstätter分享了他提議增加calldata成本的更新，並詢問客戶端團隊對此的看法。 EF 研究員 Ansgar Dietrichs 和 Nethermind 開發人員 Ahmad Bitar 對此表示贊成。 Beekhuizen 補充說，當 EIP 7623 在最新的 Rollcall 會議上提出時，即 Layer-2 rollup 團隊之間的會議系列，對其實施沒有任何反對意見。 Beiko 建議繼續討論其他 EIP，並在電話會議後期回顧此 EIP。

EIP 7645，將ORIGIN 重新命名為SENDER

Beiko 詢問客戶端團隊對EIP 7645 的看法，該提案旨在更改ORIGIN 操作碼的行為，以防止智能合約誤用。早期投資以太坊並撰寫EIP 7645 的Cyrus Adkisson 指出，更新ORIGIN 操作碼有三種可能的路徑，每種路徑都有不同的權衡。 Ferrin 表示，建議更改操作碼行為的路徑需要安全專業人員和審計公司進行仔細審查，因為以太坊協議開發人員無法充分評估此類變更對現有智慧合約和最終用戶的影響。 Beiko 建議開發人員為了時間考慮，繼續討論其他 EIPs。

EIP 7547，包含清單

Beiko 詢問開發人員對將 EIP 7547 納入 Prague 的看法。從 EL 用戶端團隊的回應來看，似乎並沒有廣泛支援這項程式碼變更。 Beiko 建議將其從升級中排除。沒有反對意見。

發行曲線調整提案

Dietrichs 提出了減少以太坊發行量的提案。考慮到這項變更主要影響以太坊的執行層，Beiko 建議開發人員在 ACDC 電話會議上進一步討論此提案的優點。

重新審視EOF、EIP 7623 和2935 對於Prague

開發人員隨後重新審視了為Prague 提出但尚未達成共識的EIP。 Beiko 詢問 EOF 是否可以與 Verkle 升級捆綁在一起。 Ballet 強烈反對這個想法，稱兩項代碼更改都很複雜，同時進行將會「太冒險」。 Protolambda 強調 EIP 7664 是另一個應考慮納入 Prague 的 EIP。 Garnett 補充說，EIP 7639，一個關於客戶端停止提供合併升級（2022 年 9 月）之前歷史資料的提案，也應該被考慮。

針對 EOF 的包含會給客戶端團隊增加太多額外負擔的擔憂，Reth 開發人員 Georgios Konstantopoulos 鼓勵開發人員「全力以赴」。但是，對於 EOF 仍然沒有共識。開發人員最終同意繼續處理 EOF，特別是需要的測試，並在稍後確定是否應將其納入 Prague。他們也同意推遲對 EIP 7623 的決定。關於 EIP 2935，開發人員同意將其包含在 Prague 中。

對電話會議上所做的所有決定進行總結，Beiko 表示，開發人員將在Pectra 升級的第一個開發網絡中包含EIP 3074 和EIP 2935。在這個開發網路之後，他們同意決定是否在第二個 Pectra 開發網路中包含 EOF 和/或 EIP 7623。