EIP-2537:從2020到2025的漫長歷程

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

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

提案背景

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

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

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

2018年5月,Justin Drake發文指出以太坊未來的PoS和分片升級可使用基於BLS12-381的BLS多籤算法。這爲後來的ETH2升級奠定了基礎。

隨着ETH2開發,將BLS12-381引入執行層的呼聲漸起。2020年2月,研究人員提出EIP-2537,希望與ETH2測試網一同測試。EIP-2537作者Alex Stokes呼籲將其納入Berlin硬分叉。

值得一提的是,EIP-2537作者也是Matter Labs聯合創始人,該公司最著名的產品是ZKSync。

Berlin動蕩

在介紹後續內容前,需先了解EIP-1962。這是Matter Labs 2019年4月提出的首個橢圓曲線域配對預編譯提案,支持BLS12、BN和MNT4/6三種曲線。

EIP-1962計劃一次性增加10個預編譯指令處理不同曲線。但許多開發者認爲過於復雜難以實現,且對智能合約工程師使用不友好。不過Matter Labs已完成算法開發並提供多語言參考實現。

爲解決EIP-1962問題,Matter Labs於2020年2月提出多個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驗證,原設計中存款合約不驗證籤名,而由共識層驗證,若不正確則存款失敗導致資金損失。

因此核心開發者希望引入BLS12-381預編譯,在存款合約中驗證籤名避免資金風險。這也是當時開發者關注EIP-1962和EIP-2537的原因。

EIP-2537提出後,Vitalik立即指出一系列問題,主要集中在文檔內容方面。作者隨後進行了回應和討論。

2020年3月6日的核心開發者會議82討論了EIP-2537。Vitalik認爲它對遞歸SNARK證明很有效,長遠來看不會損害以太坊。會議確認了EIP-2537的優先地位,所有客戶端同意盡快實現並在Berlin升級前完成開發。

隨後EIP-2537成爲高優先級任務。3月20日的會議83再次優先討論該提案,確認其取代EIP-1962成爲核心BLS提案,並納入Berlin升級預選名單。

4月的會議84正式將EIP-2537納入Berlin硬分叉,確定4月實現、5-6月測試的時間線。EIP-2537被列爲最高優先級事項。

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

會議85中討論了ABI編碼問題。由於Matter Labs已基本完成Rust實現,Besu客戶端表示已基本實現EIP-2537功能,但Geth表示尚未開始實現工作。

會議86各節點再次同步實現情況,Geth表示完成部分工作但仍有大量任務待完成。

會議87的核心內容是EIP-2537實現問題。Geth開發者表示存在一個16000行的PR實現EIP-2537,但無法確定是否安全有效,只能通過簡單的模糊測試判斷。Geth認爲大概率無法在Berlin預定時間前完成相關開發。

Hudson Jameson提議爲Geth尋找密碼學工程師協助PR審查,並建議用測試網測試實現安全性。ETH2團隊也可參與測試。

需要補充的是,Geth的EIP-2537實現PR爲保證效率大量使用匯編代碼,很難閱讀理解。Alex Vlasov建議去掉復雜匯編優化降低審查難度。

雖然EIP-2537的一個核心目標是輔助ETH2存款合約,但此次會議存款合約開發者表示不使用EIP-2537的版本已經過審計,部分開發者建議不要再推出使用EIP-2537的新版本。

最後會議決定增加YOLO測試網專門測試EIP-2537。此時可以看出,隨着存款合約完成,EIP-2537的重要性已大幅下降,且Geth開發者認爲很可能無法在Berlin升級前實現。EIP-2537不被納入Berlin似乎已成定局。

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

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

會議90鎖定了7月上線Berlin升級的期限。會議還討論了客戶端多樣性問題,有人提議凍結當前EIP實現以降低其他客戶端開發成本。會議91甚至提出使用模塊化方案增加客戶端多樣性。

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

會議96討論是否將EIP-2539也納入Berlin測試,因Celo已將EIP-2537和EIP-2539納入其網路升級。但Geth開發者反對,認爲EIP-2537本身仍未完全測試。最終決定不在Berlin增加EIP-2696。

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

這就是EIP-2537的早期歷程。它曾是Berlin升級最重要的EIP之一,但因實現問題最終被廢棄。2021年4月以太坊完成Berlin升級,核心EIP如EIP-2565的實現都相對簡單,顯得略顯單薄,正是因爲最復雜的EIP-2537被剔除。

後續發展

衆所周知,以太坊每次升級都有核心提案,如Berlin後的London引入EIP-1559。對曾是核心提案的EIP-2537而言,後續升級很難再將其納入。

London升級時,開發者曾考慮增加EIP-2537。會議109同步了其開發情況,因使用新庫實現引發gas討論。有人提議用EVM384替代。但會議111因復雜性將其移出London升級,主要是依賴庫更換導致gas定價變化,需要重新評估。

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

2022年11月會議150簡短討論是否納入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討論重新定價,Geth開發者建議提高20% gas成本,得到Besu團隊支持。

總結

EIP-2537從提出到被採納經歷了漫長的5年時間。它曾是Berlin升級的核心,因實現困難被放棄。隨後以太坊進入PoS歷史進程,復雜的純執行層EIP不受重視,大量PoS相關EIP成爲核心目標,導致EIP-2537長期未被接受。直到2025年,隨着主要技術難題的解決,EIP-2537終於有望在Pectra升級中實現。

這一歷程表明,EIP能否被納入以太坊升級,不僅取決於自身技術價值,還需要考慮整個以太坊的發展階段和優先事項。每次升級都有其主題,只有符合當前需求且技術成熟的EIP才能最終被採納。