EIP-2537:從爭議到採納的漫長之路

EIP-2537是以太坊最新Pectra分叉升級中確定添加的EVM預編譯指令。該指令爲EVM增加了BLS12-381曲線的多種計算功能,如曲線域上的配對計算等。

EIP-2537最初於2020年提出,直到2025年才被確認納入以太坊升級。本文將介紹EIP-2537的治理歷程,探討爲何這個提案歷經5年才最終被採納。

提案背景

2017年1月,Vitalik Buterin首次在一篇文章中介紹了配對算法和alt_bn128曲線。隨後,Vitalik和Christian Reitwiessner提出了EIP-196和EIP-197,建議向EVM增加alt_bn128曲線計算支持。

2017年10月的拜佔庭升級正式引入了alt_bn128曲線,實現了EVM內部的曲線域配對計算,使ZK-Snarks證明驗證可以在EVM內完成。

然而,隨着密碼學的發展,2017年11月zcash開發團隊提出了BLS12-381曲線。相比alt_bn128,BLS12-381具有更高的安全性和更好的性能。許多區塊鏈協議後來都採用了BLS12-381曲線,放棄了alt_bn128。

2018年5月,Justin Drake發表文章指出以太坊未來的PoS和分片升級可以使用基於BLS12-381曲線的BLS多重籤名算法。這一方案解決了早期PoS方案中驗證者數量受限的問題。事實證明,後來的ETH2升級確實採用了BLS12-381曲線。

隨着ETH2開發的推進,將BLS12-381引入ETH執行層的呼聲日益高漲。2020年2月,研究人員提出了EIP-2537,並希望該提案能與ETH2測試網一同進行測試。EIP-2537的作者Alex Stokes呼籲在Berlin硬分叉中納入該提案。

值得注意的是,EIP-2537的作者也是ZKSync開發公司Matter Labs的聯合創始人。

Berlin升級的波折

在介紹後續進展之前,我們需要先了解EIP-1962。這是Matter Labs在2019年4月提出的第一個關於橢圓曲線域配對預編譯的提案,支持BLS12、BN和MNT4/6三種曲線。

EIP-1962計劃一次性增加10個預編譯指令來處理不同曲線。但該提案遭到許多開發者質疑,認爲過於復雜難以實現。同時由於高度通用化,對智能合約工程師來說調用也很麻煩。不過作爲提案方,Matter Labs已經完成了橢圓曲線算法的開發工作,並提供了多種語言的參考實現。

爲解決EIP-1962的問題,Matter Labs於2020年2月提出多個EIP來拆分EIP-1962,這些EIP部分繼承了EIP-1962的接口:

• EIP-2537提供BLS12-381支持
• EIP-2539提供BLS12-377支持
• PR#2541提供BLS12-377(Zexe曲線)支持,但該提案最終未獲EIP編號

其中最重要的是EIP-2537,因爲共識層也使用了BLS12-381曲線。EIP-1962和EIP-2537的核心目標都是在主網實現共識層BLS籤名驗證。當時ETH2正在開發共識層存款合約。最初設計中,由於執行層不包含BLS驗證算法,存款合約不會驗證籤名,具體的BLS籤名會在用戶存款後由共識層驗證,如果發現不正確,存款將失敗,用戶存入的ETH可能會丟失。

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

EIP-2537剛提出時,Vitalik就指出了提案存在的一系列問題。這些質疑主要集中在EIP文檔內容方面,隨後EIP作者對此進行了回復和討論。

2020年3月6日的第82次以太坊核心開發者會議討論了EIP-2537。Vitalik認爲該EIP對遞歸SNARK證明非常有效,從長遠來看不會對以太坊造成負面影響。會議確認了EIP-2537的優先地位,所有客戶端都同意盡快實現該EIP並計劃在Berlin升級前完成所有開發。

隨後,EIP-2537成爲優先級較高的任務。3月20日的第83次核心開發者會議再次將其作爲首要討論的提案。會議確認EIP-2537取代EIP-1962成爲核心BLS提案,並列入Berlin升級預選名單。

4月的第84次會議正式將EIP-2537納入Berlin硬分叉升級,並確定了4月實現、5-6月測試的時間線。值得注意的是,EIP-2537在此次討論中被列爲最高優先級事項。

此後,EIP-2537進入大量開發和測試階段,在後續近20次核心開發者會議中幾乎每次都有相關討論。

在第85次會議上,開發者討論了EIP-2537的ABI編碼問題。由於Matter Labs之前已基本完成Rust版本實現,Besu客戶端表示已基本實現EIP-2537功能,但Geth方面稱目前沒有人在開展相關工作。

第86次會議上,不同節點實現再次同步了EIP-2537的進展,Geth表示完成了部分工作,但還有大量任務待完成。

第87次會議重點討論了EIP-2537的實現問題。Geth開發者表示存在一個16000行的PR實現EIP-2537,但無法確定該PR是否安全有效地實現了EIP-2537,只能通過最簡單的模糊測試判斷代碼情況。

Geth開發者表示:"按我的直覺,Geth不可能在7月的主網發布前準備好BLS曲線操作。"

Hudson Jameson提議爲Geth尋找密碼學工程師協助PR審查,並建議使用測試網測試EIP-2537的實現安全性。由於ETH2開發團隊也在實現BLS籤名驗證,可以參與測試。

需要補充的是,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升級採納似乎已成定局。

第88次會議上,Geth開發者發現EIP-2537實現PR存在一系列問題,表示需要進一步測試和修復。此時Geth系統中存在兩個EIP-2537實現,一個包含匯編優化,另一個完全由Go語言編寫。有開發者建議直接使用Go語言版本來降低代碼審查難度。

第89次會議上出現了更嚴重的問題,YOLO測試網出現一些異常,開發者懷疑是BLS籤名導致,但EIP-2537開發者對此進行了反駁。好消息是基於EIP-2537的存款合約基本開發完成,正在等待審計。

第90次會議確定了7月上線Berlin升級的最後期限。會議還討論了客戶端多樣性問題,主要涉及Geth佔主導地位的情況,有開發者建議凍結當前EIP實現來降低其他客戶端的開發成本。第91次會議中,有開發者提議使用模塊化方案降低開發成本以增加客戶端多樣性。

第92次會議仍將EIP-2537確認爲Berlin升級所需的EIP。

第96次會議上,由於Celo已將EIP-2537和EIP-2539同時納入其網路硬分叉,Matter Labs希望將EIP-2539也放到YOLO v2測試並進入Berlin升級。但Geth開發者反對,認爲當前EIP-2537仍未在Geth內完整測試。最終會議決定不在Berlin升級中增加EIP-2696,留待未來討論。

第99次會議決定將EIP-2537移出YOLO v3測試網和Berlin升級,最主要原因是EIP-2537耗費了核心開發者太多時間,導致Berlin升級其他EIP開發受阻。次要因素是以太坊基金會提出了EVM384作爲EIP-2537替代,提供更通用的橢圓曲線計算方案。但核心開發者對安全問題表示擔憂。

這就是EIP-2537的早期歷程。我們可以看到,EIP-2537最初是Berlin升級中最重要的EIP之一,但由於實現問題最終被廢棄。2021年4月,以太坊完成Berlin升級,核心EIP如EIP-2565實際實現並不復雜,升級看起來略顯單薄,這正是因爲最核心復雜的EIP-2537被剔除。

後續發展

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

Berlin後的London升級中,開發者在issues#369考慮增加EIP-2537。第109次核心開發者會議同步了EIP-2537的開發情況,由於使用其他庫實現,引發了關於gas使用的討論。有開發者提議用EVM384替換EIP-2537。但2021年4月的第111次會議上,EIP-2537因復雜性被移出London升級。主要原因是EIP-2537標準實現更換了依賴庫,導致gas定價可能變化,不同客戶端實現需要大量時間重新評估gas消耗。

2021年6月,issues#343正式提出將EIP-2537納入Shanghai升級。但London升級後,The Merge佔據了開發者大量時間,執行層開發者需要編寫大量代碼實現PoS升級。2022年9月,The Merge完成後,執行層開發者才有機會繼續討論Shanghai升級的目標。

2022年11月,第150次核心開發者會議簡要討論是否將EIP-2537納入Shanghai,但開發者認爲應推遲,Shanghai的核心是支持PoS提款。最終EIP-2537未被納入以實現提款爲核心的Shanghai升級。

更不幸的是,Cancun升級一直未討論EIP-2537,因爲Cancun的重點是支持EIP-4844,爲以太坊二層提供Blob以便二層使用以太坊作爲數據可用層。

直到2024年2月的第181次核心開發者會議,開發者才討論在Pectra升級中納入EIP-2537。此時開發者認爲EIP-2537的實現已不是問題,只有部分gas消耗定價問題需解決。

2024年12月19日的第202次會議上,Nethermind開發者最終確定了EIP-2537的定價模型。值得注意的是,作爲EIP-2537最初提案者的Matter Labs此時已基本退出討論。2025年1月的第203次會議討論了重新定價BLS預編譯,Geth開發人員Jared Wasinger建議將gas成本提高20%,並得到Besu團隊基準測試的支持。

總結

EIP-2537從提出到最終被採納經歷了漫長而曲折的過程:

• 2020年2月:拆分自EIP-1962正式提出EIP-2537
• 2020年4月-10月:多次討論實現問題,最終因無法實現被Berlin升級放棄
• 2021年3月-4月:討論gas成本問題,因復雜性被London升級放棄
• 2022年11月:討論是否納入Shanghai升級,未果
• 2024年2月:認爲實現不再是問題,仍存在部分gas成本問題,可納入Pectra升級
• 2024年12月-2025年1月:討論具體成本計算模型,正式解決gas成本