以太坊治理觀察：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 不被接受。