EIP-2537:以太坊曲線計算的漫長之路

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升級正式納入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多籤算法。這使得之前的EIP-1011方案退出歷史舞臺,後來的ETH2升級也最終採用了BLS12-381曲線。

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

有趣的是,EIP-2537作者也是Matter Labs的聯合創始人,Matter Labs最著名的產品是ZKSync。

Berlin動蕩

在介紹後續內容前,需要先提及EIP-1962。這是Matter Labs在2019年4月提出的首個橢圓曲線域配對預編譯提案,支持BLS12、BN和MNT4/6三條曲線。該EIP計劃一次性增加10個預編譯指令處理不同曲線。但許多開發者質疑提案過於復雜難以實現,且對智能合約工程師使用不便。作爲提案方,Matter Labs已完成橢圓曲線算法開發,提供了多語言參考實現。

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

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

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

接下來EIP-2537進入大量開發測試階段,後續近20次核心開發者會議幾乎每次都涉及相關討論。主要內容包括:

• ABI編碼問題討論
• 各客戶端實現進度同步
• Geth實現PR存在16000行代碼,難以確定安全性和有效性
• 開發者表示Geth難以在7月前完成EIP-2537開發
• 提議尋找密碼學工程師協助PR審查,使用測試網測試實現安全性
• 討論是否去除復雜匯編優化降低審查難度
• 存款合約開發者表示不使用EIP-2537的版本已審計完成,考慮不再推出使用EIP-2537的版本
• 決定增加YOLO測試網專門測試EIP-2537

至此可以看出,EIP-2537重要性隨存款合約完成已大幅下降,且Geth開發者認爲難以在Berlin前實現。EIP-2537不被Berlin接納似成定局。

後續會議中出現更多問題:

• Geth發現EIP-2537實現PR存在問題,需進一步測試修復
• YOLO測試網出現問題,懷疑與BLS籤名相關
• 討論客戶端多樣性問題,考慮凍結當前EIP實現降低其他客戶端開發成本
• Matter Labs希望將EIP-2539也納入測試,但遭Geth開發者反對

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

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

後續發展

Berlin後的London升級中,開發者曾考慮加入EIP-2537,但因實現更換依賴庫導致gas定價可能變化,最終因復雜性再次被放棄。

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

2022年11月,開發者認爲EIP-2537需要推遲,Shanghai升級核心是支持PoS提款。Cancun升級因專注EIP-4844也未討論EIP-2537。

直到2024年2月,開發者才討論在Pectra升級納入EIP-2537,認爲實現已不是問題,僅存在部分gas消耗定價問題。2024年12月至2025年1月,開發者討論具體成本計算模型,最終解決EIP-2537成本問題。

總結

EIP-2537從2020年2月提出到2025年1月最終確定,經歷了近5年時間。其間多次因實現復雜性或與升級主題不符而被推遲。這表明EIP能否納入以太坊升級,不僅取決於自身價值,還需要考慮歷史進程因素。每次以太坊升級都有自己的主題,EIP-2537雖曾是Berlin升級最重要EIP,卻因難度被廢棄。隨後以太坊進入PoS歷史進程,純執行層EIP不受重視,導致EIP-2537長期未被接受。