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月的Byzantium升級正式納入alt_bn128曲線,實現了EVM內部的曲線域配對計算,使ZK-Snarks證明驗證可在EVM內完成。

2017年11月,zcash團隊提出了BLS12-381曲線,相比alt_bn128具有更高安全性和性能。許多區塊鏈協議隨後採用BLS12-381曲線。2018年5月,Justin Drake發文指出以太坊未來的PoS和分片升級可使用基於BLS12-381的BLS多籤算法。

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

值得一提的是,EIP-2537作者同時也是ZKSync開發團隊Matter Labs的聯合創始人。

Berlin升級動蕩

在討論EIP-2537前,需先了解EIP-1962。這是Matter Labs 2019年4月提出的首個橢圓曲線域配對預編譯提案,支持BLS12、BN和MNT4/6三種曲線,計劃一次性增加10個預編譯指令。但該提案被認爲過於復雜難以實現。

爲解決EIP-1962問題,Matter Labs於2020年2月提出多個EIP拆分方案,其中最重要的是EIP-2537,提供BLS12-381支持。當時ETH2正在開發存款合約,引入BLS12-381預編譯可在存款合約中驗證籤名,避免用戶資金損失風險。

EIP-2537剛提出時,Vitalik就指出了一些問題。隨後在3月6日的核心開發者會議上,Vitalik認爲EIP-2537對遞歸SNARK證明很有效,長遠看不會損害以太坊。會議確認了EIP-2537的優先地位,所有客戶端同意盡快實現並計劃在Berlin升級前完成開發。

在後續會議中,EIP-2537取代EIP-1962成爲核心BLS提案,並被納入Berlin升級預選名單。4月的會議正式將EIP-2537納入Berlin硬分叉,並確定了實施時間表。

此後EIP-2537進入大量開發和測試階段,在近20次核心開發者會議中都有相關討論。主要圍繞ABI編碼、實現進度、安全性等問題。

然而,隨着開發推進,EIP-2537的問題逐漸顯現。Geth團隊表示難以在預定時間內完成開發,同時存款合約已完成不使用EIP-2537的版本。EIP-2537的重要性隨之下降。

後續會議中,EIP-2537的實現和測試問題持續存在。最終在第99次核心開發者會議上,決定將EIP-2537移出Berlin升級,主要原因是耗費了太多開發資源,影響了其他EIP的進展。

後續發展

在Berlin升級後的London升級中,開發者曾考慮納入EIP-2537,但因復雜性再次被放棄。Shanghai升級同樣未納入EIP-2537,因爲重點是實現PoS提款功能。

Cancun升級也未討論EIP-2537,因爲重點是支持EIP-4844。

直到2024年2月,開發者才再次討論在Pectra升級中納入EIP-2537。此時EIP-2537的實現已不是主要問題,僅存在部分gas消耗定價問題。

2024年12月至2025年1月,開發者會議最終確定了EIP-2537的定價模型,解決了成本問題。作爲最初提案者的Matter Labs此時已基本退出討論。

總結

EIP-2537的歷程反映了以太坊治理過程的復雜性。從最初被視爲核心升級內容,到多次因實現難度和復雜性被擱置,再到最終被納入升級,EIP-2537經歷了漫長的過程。這一過程折射出以太坊在技術發展、共識達成和優先級選擇等方面的考量和權衡。

每次以太坊升級都有其特定主題和重點,EIP能否被納入不僅取決於其本身的價值,也與當前以太坊的發展階段和重點方向密切相關。EIP-2537的歷程展示了以太坊治理的靈活性,以及社區在面對技術挑戰時的審慎態度。