以太坊治理觀察：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 團隊基准測試的支持。

總結

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

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。