EIP-2537:以太坊BLS12-381預編譯指令的漫長之路

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

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

提案背景

2017年1月,Vitalik Buterin首次介紹了配對算法和alt_bn128曲線。隨後Vitalik和Christian Reitwiessner提出EIP-196和EIP-197,爲EVM增加alt_bn128曲線計算支持。這些提案在2017年10月的Byzantium升級中被正式採納,實現了EVM內部的曲線域配對計算,使ZK-Snarks證明驗證可以在EVM內完成。

隨着密碼學發展,zcash團隊在2017年11月提出了BLS12-381曲線。相比alt_bn128,BLS12-381具有更高的安全性和更好的性能。許多區塊鏈協議開始使用BLS12-381曲線替代alt_bn128曲線。

2018年5月,Justin Drake指出以太坊未來的PoS和分片升級可以使用基於BLS12-381曲線的BLS多籤算法。這使得原本的EIP-1011方案退出了歷史舞臺。事實證明,後來的ETH2升級確實採用了BLS12-381曲線。

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

值得一提的是,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-2537:提供BLS12-381支持
• EIP-2539:提供BLS12-377支持
• PR#2541:提供BLS12-377 (Zexe curve)支持,但未獲得EIP編號

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

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

EIP-2537提出後,Vitalik立即指出了一系列問題,主要集中在EIP文檔內容方面。EIP作者隨後進行了回復和討論。2020年3月6日的核心開發者會議上,Vitalik認爲EIP-2537等EIP對遞歸SNARK證明非常有效,長遠來看不會損害以太坊。會議確認了EIP-2537的優先地位,所有客戶端同意盡快實現並計劃在Berlin升級前完成開發。

此後EIP-2537成爲高優先級任務。3月20日的會議確認EIP-2537替代EIP-1962成爲核心BLS提案,並進入Berlin升級預選名單。4月的會議正式將EIP-2537納入Berlin硬分叉升級,確定了4月實現、5-6月測試的時間線,並將其列爲最高優先級事項。

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

在第85次會議上,開發者討論了EIP-2537的ABI編碼問題。Besu客戶端表示基本實現了功能,但Geth方面表示尚無人開展相關工作。

第86次會議上,Geth表示完成了部分工作,但仍有大量工作待完成。

第87次會議重點討論了EIP-2537的實現問題。Geth開發者表示存在一個16000行的PR實現EIP-2537,但無法確定其安全性和有效性,只能通過簡單的模糊測試判斷。Geth開發者認爲無法在Berlin預定時間前完成EIP-2537的開發。

會議決定增加YOLO測試網專門測試EIP-2537。此時EIP-2537的重要性已大幅下降,Geth開發者認爲該EIP極可能無法納入Berlin升級。

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

第89次會議上出現更嚴重的問題,YOLO測試網出現異常,懷疑是BLS籤名導致,但EIP-2537開發者予以否認。好消息是基於EIP-2537的存款合約基本開發完成,正等待審計。

第90次會議鎖定了7月上線Berlin升級的期限。會議還討論了Geth主導地位的問題,有人提議凍結當前EIP實現以降低其他客戶端開發成本。

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

第96次會議上,Matter Labs希望將EIP-2539也納入YOLO v2測試並進入Berlin升級。但Geth開發者反對,認爲EIP-2537仍未在Geth內完整測試。最終決定不在Berlin升級增加2696。

第99次會議決定將EIP-2537移出YOLO v3測試網和Berlin升級,主要原因是其耗費了核心開發者太多時間,影響了其他EIP開發。次要因素是以太坊基金會提出EVM384作爲替代方案。

2021年4月,以太坊完成Berlin升級,核心包含的EIP-2565等實際實現並不復雜,升級顯得單薄,這是因爲最核心復雜的EIP-2537被剔除。

後續發展

Berlin升級後的London升級引入了EIP-1559。對於曾作爲核心提案的EIP-2537,後續升級都很難將其納入。

London升級中,開發者曾考慮增加EIP-2537。第109次會議同步了EIP-2537開發情況,討論了gas使用問題,有人提議用EVM384替換EIP-2537。但第111次會議因復雜性將EIP-2537移出London升級。主要是EIP-2537標準實現更換了依賴庫,導致gas定價可能變化,各客戶端需要重新評估gas消耗。

2021年6月正式提議將EIP-2537納入Shanghai升級。但Merge升級佔據了開發者大量時間。2022年9月Merge完成後,執行層開發者才有機會繼續討論Shanghai升級目標。

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

Cancun升級一直未討論EIP-2537,因爲其核心是支持EIP-4844,爲二層提供Blob數據可用層。

2024年2月,第181次會議討論在Pectra升級納入EIP-2537,認爲實現已不是問題,僅gas消耗定價存在問題。

2024年12月19日,第202次會議上Nethermind開發者確定了EIP-2537的定價模型。最初提案者Matter Labs此時已近乎退出討論。2025年1月的第203次會議討論了重新定價BLS預編譯,Geth開發者建議將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月:討論具體成本模型,正式解決成本問題

EIP能否納入以太坊升級,既要靠自身努力,也要考慮歷史進程。每次升級都有主題,EIP-2537曾是Berlin升級核心,卻因復雜性被廢棄。之後以太坊聚焦PoS,純執行層EIP不受重視,導致EIP-2537長期未被接受。直到近期,開發者才重新關注並解決了其遺留問題。