編者按：

以太坊所有核心開發者協商電話（ACDE）每周一召開一次，主要討論和協商對以太坊執行層（EL）的變更。本次為 ACDE 第 185 次電話會議，會議上，開發者們即將召開對即將到來的布拉格硬分叉所需的代碼更改以及其他EIP進行了深入的討論和評估。

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

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

2024年4月11日，以太坊開發人員齊聚Zoom參加了All Core 開發工程師s Execution (ACDE) call #185會議。ACDE電話會議是一個每周舉行一次的系列會議，由以太坊基金會協議支持主管Tim Beiko 主持，開發人員在會上討論和協商對以太執行層（EL）的更改。本周，開發人員討論了應該添加到即將到來的坊以太 EL 升級——布拉格硬分叉中的代碼變更。布拉格將與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（在狀態中保存歷史區塊哈希）。他們還決定從布拉格中排除 EIP 7547（包含列表）和 EIP 7667（提高哈希函數的gas成本）。開發人員強烈傾向於將EIP 7667與Verkle捆綁在布拉格後續的下一個EL升級大阪中。目前，接下來考慮將10個坊以太虛擬機對象格式（EOF） EIP 和 EIP 7623（增加 calldata 成本）納入布拉格。

回顧布拉格中已包含的內容

在深入討論布拉格中正在考慮的 EIP 列表之前，開發人員花了一段時間回顧了升級中已經包含的 EIP 存在的問題。

電子IP 7251

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

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

電子IP 2537

Stokes還分享了關於EIP 2537的最新消息，該提案向以太坊虛擬機（EVM）添加了操作，使開發人員能夠使用BLS12-381曲線構建有效地執行加密貨幣簽名驗證。這比在EL上使用secp256k1 Stokes表示，對這些操作定價的最終基準測試工作已經完成，開發人員可以在接下來的幾周內期待對他們的目的氣體成本的最終更新。同時，鼓勵客戶端團隊按照當前的範圍實施EIP，用於第一個Pectra開發者測試網路pectra-devnet-0。

布拉格辯論還應該包括什麼

在本周的電話會議之前，EL 客戶端團隊提供了他們在布拉格中包含的其他 EIP 的書面更新的希望，此外他們已經同意包括在升級中的 5 個 EIP 之外。Beiko 在電話會議中返回鏈接了 EL 客戶端團隊的偏好，並且為了長期保存，鏈接如下：

Erigon 偏好

貝蘇偏好

雷斯偏好

Nethermind 偏好

Geth偏好

巨型EOF殘局

在討論要在布拉格中包含的其他 EIP 時，Geth 開發人員 Guillaume Ballet 表示反對在升級中包含 EOF 的變更。他擔心這些變更可能會在布拉格之後的升級（被稱為大阪）中實施 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 個不同 EIP 的 EVM 的代碼更改捆綁包。Van der Wijden 表示，他對 EOF 的主要關注點是其複雜性以及客戶端團隊花費大量工作來充分測試 EOF 中的所有邊緣情況。Nethermind 開發人員 Marek Moraczyński 同意 EOF 可能會「引入許多新的思想錯誤」 ，並且需要「仔細測試」，但不實施這些 EIP 的負面影響意味著這些對 EVM 的改進將不得不等待另外兩年。

Ferrin 指出，當開發人員在爭論 EOF 是否應包含在上海升級中時，他們反對這些代碼變更範圍過於狹窄。現在，Ferrin 和其他開發人員已經努力使 EOF 更加廣泛，客戶端團隊卻因代碼變更過於複雜Ferrin 說：「我們無法從所有核心開發人員小組中得到一致的請求。」他補充說，聽到有關兩個版本 EOF 的抱怨是「令人沮喪」的。Reth 和 Erigon 客戶端團隊支持在布拉格中包含 EOF。Beiko 建議開發人員轉而討論其他 EIP，並在電話會議後期回顧 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 中啟動，並詢問是否有任何開發人員反對在布拉格中包含此代碼更改。沒有反對意見。

EIP 2935，保存歷史區塊哈希狀態

Ballet 在 ACDE #184 上介紹了 EIP 2935，這是一項代碼更改，將為 Verkle 的實現帶來未來的好處。Reth 客戶端團隊對 EIP 持「中立到積極」的態度，並表示，考慮到這是一個簡單的改變，他們不反對將其納入布拉格。Erigon 客戶端團隊持類似的態度，但指出，如果布拉格中包含像 EOF 這樣的更大的代碼更改，他們對將其納入布拉格的信心會較早低。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鏈的模式。」

考慮到在大阪升級中由於Verkle對天然氣定價和計划進行更改，Ferrin建議將這項EIP與Verkle一起實施。EF研究員Carl Beekhuizen表示，這項EIP需要進行大量調查，開發人員必須「非常小心」地分析這些氣體變化將如何影響以太坊上的智能合約。Van der Wijden 同意 Beekhuizen 關於嚴格推進這一 EIP 的觀點。Ferrin 還建議可能首先在 Layer-2 rollups 上實施這些改變，而以太坊開發坊人員進一步調查其對Layer-1這種影響。Beiko同意看法，並建議開發人員將EIP 7667與Verkle一起考慮納入大阪升級，並給予「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建議開發人員花時間考慮，繼續討論其他EIP。

EIP 7547，包含列表

Beiko詢問開發人員對於將EIP 7547納入布拉格的看法。從EL客戶端團隊的回應來看，似乎並沒有廣泛支持這一代碼更改。Beiko建議將其從升級中取消。沒有反對意見。

釋放曲線造型提案

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

為布拉格重新配置 EOF、EIP 7623 和 2935

開發人員重新部署了布拉格提出但尚未完成共識的 EIP。Beiko 詢問 EOF 是否可以與 Verkle 升級打在一起。Ballet 強烈反對這個想法，稱三個代碼改變非常複雜，同時進行「太冒險」 Protolambda 強調 EIP 7664 是另一個應考慮納入布拉格的 EIP。Garnett 補充說，EIP 7639，一個關於客戶端停止提供合併升級（2022 年 9 月）之前歷史數據的提議，也應該被考慮。

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

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