以太坊治理觀察：EIP-2537預彙編歷程

作者：shew

概述

EIP-2537是最新的 Pectra 分叉升級中被確定添加的 EVM 預彙編指令。該指令為 EVM 增加了 BLS12-381 曲線的多種計算功能，比如曲線域上的配對計算等。

EIP-2573 最初在 2020 年被提出，直到 2025 年才被確認加入以太坊升級。本文主要介紹 EIP-2537 的治理歷史，探究為什麼經過 5 年才會將此提案納入升級。

提案背景

2017 年 1 月份，Vitalik Buterin 在Exploring Elliptic Curve Pairings第一次介紹了配對算法以及alt_bn128曲線。隨後在 2017 年 2 月，Vitalik Buterin 和 Christian Reitwiessner 提出了EIP-196和EIP-197提案，提案內容是向 EVM 增加alt_bn128曲線計算支持。

在 2017 年 10 月份的Byzantium升級內，正式納入alt_bn128曲線。簡單來說，alt_bn128第一次實現了 EVM 內部的曲線域配對計算，這使得 ZK-Snarks 證明驗證可以在 EVM 內完成。

但隨著密碼學發展，2017 年 11 月，zcash 開發團隊在BLS12-381: New zk-SNARK Elliptic Curve Construction第一次給出了BLS12-381曲線。相比於alt_bn128而言，BLS12-381具有更高的安全性、更好的性能。相當多的區塊鏈協議在此後都使用了BLS12-381曲線而廢棄了alt_bn128曲線。

在 2018 年 5 月，Justin Drake 在 ethresear 內發佈了Pragmatic signature aggregation with BLS一文，指出在以太坊未來的 PoS 和分片升級都可以使用基於BLS12-381曲線的 BLS 多籤算法。當時，以太坊研究者希望使用EIP-1011解決共識層問題，但是 EIP-1011 方案最多可以容納 900 個驗證者，因此為每個驗證者設定了 1500 ETH 的巨大質押規模。隨著 BLS 多籤方案的提出，EIP-1011 退出了歷史舞臺。事實證明，後來的 ETH2 升級也最終使用了BLS12-381曲線。

伴隨著 ETH2 開發，ETH2 所使用的BLS12-381引入 ETH 執行層開始被呼籲。在 2020 年 2 月，一些研究員提出了EIP-2537，並且希望該提案可以在 ETH2 測試網一起接受測試。EIP-2537 作者 Alex Stokes 在What eth2 needs from eth1 over the next six months文章內呼籲在 Berlin 硬分叉內納入 EIP-2537。

有趣的是，EIP-2537 的作者也是 Matter Labs 的聯合創始人，而 Matter Labs 最為著名的產品就是 ZKSync

Berlin 動盪

我們在介紹後續內容前，需要首先介紹EIP-1962。EIP-1962 是 Matter Labs 在 2019 年 4 月提出的第一個關於橢圓曲線域配對預彙編的提案，該提案支持了三條曲線，分別是：

• BLS12
• BN
• MNT4/6 (Ate pairing)

該 EIP 準備一次性增加 10 個預彙編指令以處理不同的曲線。但是該提案誕生後，相當多的開發者質疑提案過於複雜以至於開發者很難實現。同時由於 EIP1962 高度通用化，對於智能合約工程師而言，調用也是十分麻煩的。當然，作為 EIP-1962 的提出者，Matter Labs 實質上已經完成了橢圓曲線算法的開發工作，並提供了 Rust / Go / C++ 參考實現。

為了解決 EIP-1962 的問題，Matter Labs 於 2020 年 2 月提出了多個 EIP 拆分 EIP-1962，這些 EIP 都部分繼承了 EIP-1962 的接口。這些 EIP 包括:

• EIP-2537提供 BLS12-381 的支持
• EIP-2539提供 BLS12-377 的支持
• PR#2541提供 BLS12-377 (Zexe curve) 支持，但注意該提案最終沒有獲得 EIP 編號，無法在 EIP 文檔官網找到

這幾個 EIP 內部，最重要的就是 EIP-2537，因為共識層也使用了 BLS12-381 曲線。包括 EIP-1962 和 EIP-2537 的核心目的都是在主網內實現共識層 BLS 簽名的驗證。在當時，ETH2 正在開發共識層的存款合約設計。在存款合約最初設計時，由於執行層內不包含 BLS 驗證算法，所以存款合約不會驗證簽名，具體的 BLS 簽名會在用戶存款後由共識層驗證，如果發現不正確（對於新的驗證者），存款將失敗，用戶存入的 ETH 將會丟失。

在此背景下，核心開發者希望引入 BLS12-381 預彙編在存款合約內實現簽名驗證，避免用戶存入 ETH2 資金的可能損失。這也是當時大量開發者關注 EIP-1962 和 EIP-2537 的原因。

當 EIP-2537 剛剛提出時，Vitalik 就立即發現了 EIP 存在的一系列問題:

這些質疑只要集中在 EIP 文檔內容方面，隨後 EIP 作者對此進行了回覆和討論。隨後，在 2020 年 3 月 6 日，在Ethereum Core Devs Meeting #82會議中，以太坊核心開發者對 EIP-2537 進行討論。在這次會議中，Vitalik 認為 EIP-2537 等 EIP 對於遞歸 SNARK 證明非常有效，而且從長遠來看不會使得以太坊受損。同時，會議還確認了 EIP-2537 的優先地位，所有客戶端都同意儘快實現 EIP-2537 並計劃在 Berlin 升級前完成所有開發。

隨後，EIP-2537 成為了優先級較高的任務。2020 年 3 月 20 日，在Ethereum Core Devs Meeting #83中，EIP-2537 依舊被首先討論的提案。這次會議確認了 EIP-2537 替代 EIP-1962 成為核心 BLS 提案併成為 Berlin 升級的預選 EIP 名單(即 Eligibility for Inclusion (EFI))。

在 2020 年 4 月的Ethereum Core Devs Meeting #84會議內，會議正式將 EIP-2537 納入 Berlin 硬分叉升級，並且確定了 4 月份實現、5 - 6 月份進行測試的 Berlin 升級時間線。值得注意的，在此次討論中，EIP-2537 被列為最高優先級事項。

隨後，EIP-2537 進入了大量的開發和測試階段，在後續近 20 次核心開發者會議中，每一次會議基本都涉及了 EIP-2537 的討論。接下來，我們可以看看每一次會議都討論了哪些關於 EIP-2537 的問題。

在Ethereum Core Devs Meeting #85內，Danno 和 Axic 對 EIP-2537 的 ABI 編碼問題進行了討論。隨後，核心開發者同步了當前的實現情況，其中由於 EIP-2537 的提案人 Matter Labs 之前已基本完成了 Rust 版本的實現，所以 Besu 客戶端聲明已基本實現 EIP-2537 的功能，但是 Geth 方面表示目前沒有人在為 EIP-2537 的實現工作。

在Ethereum Core Devs Meeting #86內，不同的以太坊節點實現再次同步了 EIP-2537 的實現情況，其中 Geth 表示完成了部分工作，但還有大量工作等待完成。

在Ethereum Core Devs Meeting #87內，此次開發者會議最核心的內容就是 EIP-2537 的實現問題。Geth 開發者表示目前存在一個 16000 行的 PR 實現 EIP-2537，但是 Geth 開發者無法確定 PR 是否安全且有效的實現了 EIP-2537，所以開發者只能通過最為簡單粗暴的模糊測試判斷代碼的情況。

Geth 開發者說:"So my gut reaction is that there is no chance that Geth will be ready with the BLS curve operations for mainnet launch in July."，即 Geth 大概率無法在 Berlin 預定時間前完成 EIP-2537 的相關開發。

Hudson Jameson 提議為 Geth 尋找密碼學工程師協助 PR 審查，並且提議使用測試網測試 EIP-2537 的實現安全性。因為此時 ETH2 開發團隊也在實現 BLS 簽名驗證，所以剛好 ETH2 團隊可以參與測試。

在這裡，我們需要補充一個背景知識，就是 Geth 的 EIP-2537 實現 PR 為了保證高效，大量使用了彙編代碼，這部分彙編代碼非常難以閱讀和理解。所以 Alex Vlasov 建議去掉 PR 內部的複雜彙編優化來降低審查難度。

我們在上文已經介紹過 EIP-2537 的一個核心目標就是輔助 ETH2 存款合約，但是在此次會議上存款合約開發者表示不使用 EIP-2537 的存款合約已經過審計，所以部分開發者提出最好不要再推出一個使用 EIP-2537 的存款合約。

在最後，會議決定增加 YOLO 測試網，該測試網的核心就是測試 EIP-2537。事實上，在此次會議中，我們就可以看到 EIP-2537 的重要性隨著存款合約的完成已經大幅下降，同時 Geth 開發者已經認為該 EIP 極有可能無法在 Berlin 升級前實現。似乎 EIP-2537 不被 Berlin 升級接納已成定局。

在Ethereum Core Devs Meeting #88內，Geth 開發者發現 EIP-2537 的實現 PR 存在一系列問題，開發者表示還需要進一步測試和修復。此時 Geth 系統內存在兩個 EIP-2537 的實現，其中一個實現包含彙編優化，而另一個實現則完全由 go 語言編寫，有開發者提議直接使用 go 語言編寫版本來降低代碼審查的難度。

在Ethereum Core Devs Meeting #89內，更加嚴重的問題發生了，YOLO 測試出現了一些問題，開發者懷疑是 BLS 簽名導致的問題，但 EIP2537 開發者對此進行了反駁，認為測試網問題並不是 BLS 簽名導致。對於 EIP-2537 的好消息是，基於 EIP-2537 的存款合約基本開發完成，該合約正在等待合約審計。

在Ethereum Core Devs Meeting #90内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91 會議中，有開發者提議使用模塊化方案降低開發成本來增加客戶端多樣性。假如讀者對於以太坊客戶端多樣性感興趣，可以去閱讀了這兩次會議的記錄。

在Ethereum Core Devs Meeting #92內，2537 仍舊被確認為 Berlin 升級所需要的 EIP。

在Ethereum Core Devs Meeting #96內，基於 Celo 已經將 EIP-2537 和 EIP-2539 同時納入了其網絡硬分叉升級中，所以 Matter Labs 希望將與 EIP-2537 同時提出的 EIP-2539 也放到 YOLO v2 測試網測試並且進入 Berlin 升級。但是 Geth 開發者反對，認為當前的 EIP-2537 仍沒有在 Geth 內部經過完整測試。最終會議決定不在 Berlin 升級內增加 2696，留待未來討論。

在Ethereum Core Devs Meeting #99內，此次會議決定將 EIP-2537 移出 YOLO v3 測試網和 Berlin 升級，最核心的原因是 EIP-2537 浪費了核心開發者太多時間，導致 Berlin 升級內其他 EIP 開發受阻。次要因素是以太坊基金會提出了EVM384作為 EIP-2537 替代，EVM 384 提供了更加通用的橢圓曲線計算方案。但是核心開發者在會議討論中表達了對安全問題的擔心。

上述內容就是 EIP-2537 的早期歷程，我們可以看到 EIP-2537 早期是 Berlin 升級中最重要的 EIP 之一，但是由於實現問題最終被廢棄。最後，在 2021 年 4 月，以太坊完成了 Berlin 升級，升級中核心包含的 EIP-2565 等實際實現都並不複雜，看上去 Berlin 升級似乎略顯單薄，這是因為最核心複雜的 EIP-2537 被踢出了 Berlin 升級。

後續發展

眾所周知，以太坊每一次升級都會有一個核心提案，比如 Berlin 升級後的 London 升級引入以太坊歷史上最重要的手續費提案 EIP-1559。對於曾經作為核心提案的 EIP-2537 而言，後續的歷次升級都很難將這個提案納入。

在 Berlin 後的 London 升級中，開發者在issues#369曾考虑在 London 升级中增加 EIP-2537。在Ethereum Core Devs Meeting #109中，開發者同步了當前 EIP-2537 的開發情況，此時由於使用其他庫對 EIP-2537 進行實現，所以引入了一個關於 EIP-2537 使用 gas 的討論。同時有開發者提出使用 EVM384 替換 EIP-2537。但在 2021 年 4 月的Ethereum Core Devs Meeting #111內，EIP-2537 因為複雜性被移出了 London 升級。核心複雜性在於 EIP-2537 標準實現更換了依賴庫，這導致 gas 定價可能出現變化，不同客戶端實現需要花費相當時間重新評估 gas 消耗。

在 2021 年 6 月，issues#343內正式提出了將 EIP-2537 納入 Shanghai 升級。但是需要注意 London 升級後，實際上 Pairs 升級或者被稱為 The Merge 佔據了開發者大量時間，執行層開發者需要編寫大量代碼以實現 PoS 升級。2022 年 9 月，Pairs 升級完成，執行層開發者終於有機會繼續討論 Shanghai 升級的一些目標。

在 2022 年 11 月，Ethereum Core Devs Meeting #150內短暫討論了 EIP-2537 的是否納入 Shanghai 升級，但開發者認為 EIP-2537 需要推遲，Shanghai 升級的核心是支持 PoS 提款。最終，EIP-2537 沒有被納入以實現提款功能為核心的 Shanghai 升級內部。

更加悽慘的是 Cancun 升級一直沒有對 EIP-2537 進行討論，因為 Cancun 升級的核心是執行層節點支持 EIP-4844。EIP-4844 為以太坊二層提供了 Blob 以方便二層使用以太坊作為數據可用層。

終於，在 2024 年 2 月的Ethereum Core Devs Meeting #181內，開發者討論在 Pectra 升級內納入 EIP-2537，並且此時開發者認為 EIP-2537 的實現已經不是問題，只有部分問題在 Gas 消耗定價方面。

在 2024 年 12 月 19 日的Ethereum Core Devs Meeting #202内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的Ethereum Core Devs Meeting #203內，開發者討論包括重新定價 BLS 預編譯，Geth 開發人員 Jared Wasinger 建議將 gas 成本提高 20%，並得到 Besu 團隊基準測試的支持。

總結

| 日期 | 事件 | | --- | --- | | 2020 年 2 月 | 拆分 EIP-1962 正式提出 EIP-2537 | | 2020 年 4 月 - 2020 年 10 月 | 開發者會議多次討論 EIP-2537 實現問題，並最終因為無法實現而被 Berlin 升級放棄 | | 2021 年 3 月 - 2021 年 4 月 | 開發者會議討論 EIP-2537 gas 成本問題，最終因為複雜性被 London 升級放棄 | | 2022 年 11 月 | 開發者會議討論是否納入 Shanghai 升級，無果 | | 2024 年 2 月 | 開發者認為 EIP-2537 沒有任何實現問題，仍存在部分 gas 成本問題，認為可以納入 Pectra 升級 | | 2024 年 12 月 - 2025 年 1 月 | 開發者會議討論具體的成本計算模型，正式解決 EIP-2537 成本問題 |

可見，EIP 是否被納入以太坊升級，“當然要靠自我奮鬥，但是也要考慮到歷史的行程”。每一次以太坊升級都會有自己的主題，正如 EIP-2537 一度成為 Berlin 升級最重要的 EIP，但是因為其實現難度和複雜性被廢棄。隨後的以太坊進入了 PoS 的歷史進程，複雜的純執行層 EIP 不被受到重視，而大量與 PoS 相關的執行 EIP 被視為核心升級目標，這導致長時間內 EIP-2537 不被接受。