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 客戶端團隊的偏好，並且為了長期保存，鏈接如下：

Erigon 偏好

Besu 偏好

Reth 偏好

Nethermind 偏好

Geth 偏好

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。

原文連結