以太坊五年「难产」EIP大结局：是技术突破，还是权力游戏？

EIP-2537：五年磨一劍，還是技術官僚主義的勝利？

EIP-2537，一個名字聽起來冰冷而陌生的以太坊改進提案，即將在 Pectra 分叉升級中粉墨登場，以 EVM 預編譯指令的形式。它的使命是為以太坊虛擬機（EVM）引入 BLS12-381 曲線的相關計算功能，包括令人望而生畏的配對計算。說白了，就是讓以太坊在密碼學上更上一層樓。

然而，EIP-2537 的故事並非一帆風順。早在 2020 年，這個提案就已經被提出，卻直到五年後的今天才終於修成正果。這漫長的等待背後，究竟是技術挑戰的難以克服，還是以太坊治理體系固有的官僚主義？是密碼學發展的必然，還是開發者社群內部的權力鬥爭？讓我們撥開迷霧，看看這場長達五年的“馬拉松”，到底跑出了什麼。

理想的開端：BLS12-381 的呼喚

時間回到 2017 年，那時的以太坊還沉浸在對 ZK-Snarks 證明的探索中。Vitalik Buterin 首次介紹了配對算法和 alt_bn128 曲線，隨後便有了 EIP-196 和 EIP-197，旨在為 EVM 增加 alt_bn128 曲線計算支持。同年 10 月，Byzantium 升級正式納入 alt_bn128 曲線，使得 ZK-Snarks 證明驗證得以在 EVM 內部完成。這在當時無疑是一項突破，為以太坊的隱私和擴容帶來了新的可能性。

然而，技術的進步總是日新月異。僅僅一個月後，zcash 開發團隊便推出了 BLS12-381 曲線。與 alt_bn128 相比，BLS12-381 在安全性、性能上都更勝一籌。很快，BLS12-381 成為了眾多區塊鏈協議的選擇，alt_bn128 則逐漸被冷落。

2018 年 5 月，Justin Drake 發文指出，以太坊未來的 PoS 和分片升級可以基於 BLS12-381 曲線使用 BLS 多籤算法。最初，以太坊研究者希望使用 EIP-1011 解決共識層問題，但 EIP-1011 方案最多只能容納 900 個驗證者，因此為每個驗證者設定了 1500 ETH 的巨大質押規模。BLS 多籤方案的提出，讓 EIP-1011 黯然退場。後來的 ETH2 升級也最終使用了 BLS12-381 曲線，證明了 Drake 的遠見。

隨著 ETH2 的開發，將 ETH2 所使用的 BLS12-381 引入以太坊執行層的呼聲越來越高。2020 年 2 月，EIP-2537 應運而生，研究人員希望該提案能在 ETH2 測試網上同步測試。EIP-2537 的作者 Alex Stokes 甚至呼籲在 Berlin 硬分叉中納入 EIP-2537。值得一提的是，Stokes 也是 Matter Labs 的聯合創始人，而 Matter Labs 最著名的產品正是 ZKSync，一個基於 ZK-rollup 的 Layer 2 擴容方案。這也暗示了 EIP-2537 背後，可能存在著 ZK-rollup 技術發展的戰略考量。

Berlin 硬分叉：一場豪賭，一地雞毛

EIP-2537 最初被寄予厚望，被視為 Berlin 硬分叉的關鍵組成部分。然而，理想很豐滿，現實卻很骨感。在推進 EIP-2537 的過程中，以太坊開發者們遭遇了前所未有的挑戰，最終導致 EIP-2537 被排除在 Berlin 升級之外。這段經歷，可以說是以太坊治理歷史上一次慘痛的教訓。

EIP-1962 的野心與幻滅：通用性是萬能藥？

在深入探討 EIP-2537 之前，我們必須先了解 EIP-1962。這是 Matter Labs 在 2019 年 4 月提出的第一個關於橢圓曲線域配對預編譯的提案。EIP-1962 的目標是提供一個通用的解決方案，支持三條曲線：BLS12、BN 和 MNT4/6 (Ate pairing)。為了實現這一目標，EIP-1962 計劃一次性增加 10 個預編譯指令。

然而，EIP-1962 的野心太大，以至於難以實現。許多開發者質疑 EIP-1962 過於複雜，難以理解和實現。此外，EIP-1962 的高度通用性也使得智能合約工程師在使用時感到不便。儘管 Matter Labs 已經完成了橢圓曲線算法的開發工作，並提供了 Rust / Go / C++ 參考實現，但 EIP-1962 仍然未能獲得廣泛的支持。

EIP-1962 的失敗，反映了以太坊開發中的一個重要問題：通用性是否總是好的？在某些情況下，過於追求通用性可能會導致複雜性和難以實現。對於以太坊這樣一個高度複雜的系統來說，簡潔和可維護性往往比通用性更重要。

Geth 的掙扎：安全、效率與時間的賽跑

為了緩解 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-2537 最為重要，因為共識層也使用了 BLS12-381 曲線。

EIP-1962 和 EIP-2537 的核心目標都是在主網內實現共識層 BLS 簽名的驗證。當時，ETH2 正在開發共識層的存款合約。在最初的設計中，由於執行層不包含 BLS 驗證算法，因此存款合約不會驗證簽名。具體的 BLS 簽名會在用戶存款後由共識層驗證，如果發現不正確，存款將失敗，用戶存入的 ETH 將會丟失。

為了避免這種情況的發生，核心開發者希望引入 BLS12-381 預編譯，在存款合約內實現簽名驗證。這也是當時大量開發者關注 EIP-1962 和 EIP-2537 的原因。

然而，EIP-2537 的推進並非一帆風順。Vitalik Buterin 很快就發現了 EIP 存在的一系列問題，主要集中在 EIP 文檔內容方面。隨後，EIP 作者對此進行了回復和討論。

2020 年 3 月 6 日，在 Ethereum Core Devs Meeting #82 會議中，以太坊核心開發者對 EIP-2537 進行了討論。Vitalik 認為 EIP-2537 等 EIP 對於遞歸 SNARK 證明非常有效，而且從長遠來看不會使得以太坊受損。同時，會議還確認了 EIP-2537 的優先地位，所有客戶端都同意盡快實現 EIP-2537 並計劃在 Berlin 升級前完成所有開發。

隨後，EIP-2537 成為了優先級較高的任務。2020 年 3 月 20 日，在 Ethereum Core Devs Meeting #83 中，EIP-2537 依舊是被首先討論的提案。這次會議確認了 EIP-2537 替代 EIP-1962 成為核心 BLS 提案，並成為 Berlin 升級的預選 EIP 名單 (Eligibility for Inclusion (EFI))。

在 2020 年 4 月的 Ethereum Core Devs Meeting #84 會議內，會議正式將 EIP-2537 納入 Berlin 硬分叉升級，並且確定了 4 月份實現、5 - 6 月份進行測試的 Berlin 升級時間線。在此次討論中，EIP-2537 被列為最高優先級事項。

接下來的幾個月，EIP-2537 進入了大量的開發和測試階段。在後續近 20 次核心開發者會議中，每一次會議基本都涉及了 EIP-2537 的討論。然而，在這些討論中，問題也逐漸浮出水面。

在 Ethereum Core Devs Meeting #85 內，Danno 和 Axic 對 EIP-2537 的 ABI 編碼問題進行了討論。隨後，核心開發者同步了當前的實現情況。由於 Matter Labs 之前已基本完成了 Rust 版本的實現，所以 Besu 客戶端聲明已基本實現 EIP-2537 的功能。但 Geth 方面表示目前沒有人在為 EIP-2537 的實現工作。

在 Ethereum Core Devs Meeting #86 內，不同的以太坊節點實現再次同步了 EIP-2537 的實現情況，其中 Geth 表示完成了部分工作，但還有大量工作等待完成。

真正的问题在 Ethereum Core Devs Meeting #87 中爆发。Geth 開發者表示，目前存在一個 16000 行的 PR 實現 EIP-2537，但是 Geth 開發者無法確定 PR 是否安全且有效地實現了 EIP-2537，所以開發者只能通過最為簡單粗暴的模糊測試判斷代碼的情況。

Geth 開發者直言不諱地說：“So my gut reaction is that there is no chance that Geth will be ready with the BLS curve operations for mainnet launch in July.” 意思是 Geth 大概率無法在 Berlin 預定時間前完成 EIP-2537 的相關開發。

Hudson Jameson 提議為 Geth 尋找密碼學工程師協助 PR 審查，並且提議使用測試網測試 EIP-2537 的實現安全性。因為此時 ETH2 開發團隊也在實現 BLS 簽名驗證，所以剛好 ETH2 團隊可以參與測試。

需要注意的是，Geth 的 EIP-2537 實現 PR 為了保證高效，大量使用了彙編代碼。這部分彙編代碼非常難以閱讀和理解，這也增加了審查的難度。因此，Alex Vlasov 建議去掉 PR 內部的複雜彙編優化，來降低審查難度。

Geth 的困境，暴露了以太坊開發中的另一個問題：客戶端實現的差異性。由於不同的客戶端使用不同的編程語言和架構，因此實現同一個 EIP 的難度也可能大相徑庭。對於 Geth 來說，EIP-2537 的實現難度顯然超出了他們的預期。

存款合約的轉向：需求變更的尷尬

更為諷刺的是，就在 Geth 為 EIP-2537 焦頭爛額之際，存款合約開發者卻表示，不使用 EIP-2537 的存款合約已經過審計。這意味著，EIP-2537 的一個核心目標——輔助 ETH2 存款合約——已經失去了意義。

一部分開發者因此提出，最好不要再推出一個使用 EIP-2537 的存款合約。這無疑給 EIP-2537 的前景蒙上了一層陰影。

存款合約的轉向，反映了以太坊開發中的另一個現實：需求可能會隨著時間的推移而發生變化。當初為了滿足存款合約的需求而提出的 EIP-2537，如今卻因為存款合約的變化而失去了意義。

YOLO 測試網的警示：技術債的爆發

儘管如此，以太坊開發者們仍然沒有放棄 EIP-2537。會議決定增加 YOLO 測試網，專門用於測試 EIP-2537。

然而，YOLO 測試網的結果卻並不令人鼓舞。在 Ethereum Core Devs Meeting #89 內，YOLO 測試出現了一些問題，開發者懷疑是 BLS 簽名導致的問題。雖然 EIP2537 開發者對此進行了反駁，認為測試網問題並不是 BLS 簽名導致，但這些問題無疑加劇了開發者們的擔憂。

YOLO 測試網的經歷，暴露了以太坊開發中的另一個風險：技術債。在快速迭代的過程中，開發者們可能會為了趕時間而忽略代碼質量和測試。這些技術債在短期內可能不會造成太大的問題，但隨著時間的推移，它們可能會逐漸累積，最終導致系統崩潰。

客戶端多樣性的暗流：Geth 的獨霸與隱憂

在 Ethereum Core Devs Meeting #90 內，開發者們還討論了客戶端多樣性問題。在這次會議中，開發者們主要討論了 Geth 佔據主導地位的情況。有開發者提議凍結當前 EIP 實現，來降低其他客戶端的開發成本。更有趣的是，在 #91 會議中，有開發者提議使用模塊化方案降低開發成本，來增加客戶端多樣性。

Geth 的主導地位，是以太坊開發中一個長期存在的問題。由於 Geth 的市場份額過大，因此以太坊的安全性也過於依賴 Geth。如果 Geth 出現漏洞，整個以太坊網絡都將受到威脅。

為了提高以太坊的安全性，開發者們一直在努力提高客戶端多樣性。然而，由於 Geth 的技術優勢和先發優勢，其他客戶端很難與之競爭。

EVM384 的魅影：通用方案的誘惑與風險

在 Ethereum Core Devs Meeting #99 內，開發者們最終決定將 EIP-2537 移出 YOLO v3 測試網和 Berlin 升級。最核心的原因是 EIP-2537 浪費了核心開發者太多時間，導致 Berlin 升級內其他 EIP 開發受阻。

更重要的是，以太坊基金會提出了 EVM384 作為 EIP-2537 的替代方案。EVM384 提供了更加通用的橢圓曲線計算方案。雖然核心開發者在會議討論中表達了對安全問題的擔心，但 EVM384 的出現，無疑加速了 EIP-2537 的死亡。

EVM384 的出現，再次引發了關於通用性和專用性的討論。EVM384 試圖提供一個通用的橢圓曲線計算方案，而 EIP-2537 則只關注 BLS12-381 曲線。從理論上講，EVM384 更加靈活，可以支持更多的應用場景。然而，EVM384 的通用性也意味著它可能更加複雜，難以實現和維護。

最终，EIP-2537 被 Berlin 升级拒之门外。2021 年 4 月，以太坊完成了 Berlin 升级，升级中核心包含的 EIP-2565 等实际实现都不复杂。Berlin 升级似乎略显单薄，这是因为最核心复杂的 EIP-2537 被踢出了 Berlin 升级。

(图片URL：/uploads/images/20250327/pPUC5wAX4m5Zy1znDo3k5Bd7sMoOJesrJf6mwTLA.png)

Berlin 升级的经历，给以太坊社区留下了深刻的教训。它提醒我们，技术决策不仅仅是技术问题，更是政治问题、经济问题和文化问题。在制定技术决策时，我们需要考虑到各种因素，包括技术可行性、经济成本、社区共识和长期发展。

漫長的等待：被忽視的五年

Berlin 升級的失敗，對於 EIP-2537 來說，只是一個開端。在接下來的五年裡，EIP-2537 一直在以太坊的升級議程中徘徊，卻始終未能真正被納入。這段漫長的等待，充滿了曲折和無奈，也反映了以太坊發展過程中，不同階段的優先級和關注點的變化。

London、Shanghai、Cancun：被錯過的列車

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

在 Berlin 後的 London 升級中，開發者在 issues#369 曾考慮在 London 升級中增加 EIP-2537。在 Ethereum Core Devs Meeting #109 中，開發者同步了當前 EIP-2537 的開發情況。此時由於使用其他庫對 EIP-2537 進行實現，所以引入了一個關於 EIP-2537 使用 gas 的討論。同時有開發者提出使用 EVM384 替換 EIP-2537。但在 2021 年 4 月的 Ethereum Core Devs Meeting #111 內，EIP-2537 因為複雜性被移出了 London 升級。核心複雜性在於 EIP-2537 標準實現更換了依賴庫，這導致 gas 定價可能出現變化，不同客戶端實現需要花費相當時間重新評估 gas 消耗。

London 升級的核心目標是 EIP-1559，一個旨在改變以太坊交易費用機制的提案。EIP-1559 的引入，對以太坊的經濟模型產生了深遠的影響，也解決了長期以來困擾以太坊社區的交易費用波動問題。相比之下，EIP-2537 的優先級顯然要低得多。

在 2021 年 6 月， issues#343 內正式提出了將 EIP-2537 納入 Shanghai 升級。但是需要注意 London 升級後，實際上 Pairs 升級或者被稱為 The Merge 佔據了開發者大量時間，執行層開發者需要編寫大量代碼以實現 PoS 升級。2022 年 9 月，Pairs 升級完成，執行層開發者終於有機會繼續討論 Shanghai 升級的一些目標。

在 2022 年 11 月， Ethereum Core Devs Meeting #150 內短暫討論了 EIP-2537 的是否納入 Shanghai 升級，但開發者認為 EIP-2537 需要推遲，Shanghai 升級的核心是支持 PoS 提款。最終，EIP-2537 沒有被納入以實現提款功能為核心的 Shanghai 升級內部。

Shanghai 升級的核心目標是支持 PoS 提款，這是以太坊從 PoW 轉向 PoS 的關鍵一步。PoS 提款的實現，解鎖了質押 ETH 的流動性，也為以太坊的長期發展奠定了基礎。在這樣一個重要的升級中，EIP-2537 再次被擱置。

更加悽慘的是 Cancun 升級一直沒有對 EIP-2537 進行討論，因為 Cancun 升級的核心是執行層節點支持 EIP-4844。EIP-4844 為以太坊二層提供了 Blob 以方便二層使用以太坊作為數據可用層。

Cancun 升級的核心目標是 EIP-4844，一個旨在提高以太坊二層網絡性能的提案。EIP-4844 的引入，降低了二層網絡的交易成本，也為以太坊的擴容提供了新的方向。在這樣一個以擴容為主題的升級中，EIP-2537 再次被忽視。

Pectra 的曙光：Gas 成本的最後一哩路

終於，在 2024 年 2 月的 Ethereum Core Devs Meeting #181 內，開發者討論在 Pectra 升級內納入 EIP-2537，並且此時開發者認為 EIP-2537 的實現已經不是問題，只有部分問題在 Gas 消耗定價方面。

在 2024 年 12 月 19 日的 Ethereum Core Devs Meeting #202 內，Nethermind 開發者最終確定了 EIP-2537 的定價模型。是的，作為 EIP-2537 的最初提案者 Matter Labs 此時已經近乎退出了討論。在隨後的，2025 年 1 月的 Ethereum Core Devs Meeting #203 內，開發者討論包括重新定價 BLS 預編譯，Geth 開發人員 Jared Wasinger 建議將 gas 成本提高 20%，並得到 Besu 團隊基準測試的支持。

在 Pectra 升級中，EIP-2537 終於迎來了曙光。經過五年的漫長等待，EIP-2537 的實現問題已經基本解決，剩下的只是 Gas 成本的定價問題。儘管 Matter Labs 已經逐漸淡出 EIP-2537 的討論，但其他開發者仍然在為 EIP-2537 的最終納入而努力。

EIP-2537 的故事，是一個關於堅持和妥協的故事。它告訴我們，在技術發展的道路上，沒有一蹴而就的成功，只有不斷的努力和調整。

EIP-2537 的命運：一場關於優先級與路線的辯論

EIP-2537 從被寄予厚望到屢遭拒絕，再到最終被納入 Pectra 升級，其命運的轉折，並非僅僅是技術問題的解決，更反映了以太坊社區內部對於技術路線、開發優先級以及權力分配的深刻辯論。EIP-2537 的故事，可以看作是以太坊治理機制和社群文化的一次縮影。

技術路線之爭：理想主義與實用主義的碰撞

EIP-2537 的早期推動者，例如 Matter Labs，顯然帶有理想主義色彩。他們希望通過引入更先進的密碼學技術，例如 BLS12-381 曲線，為以太坊的隱私保護和擴容方案提供更強大的基礎。這種理想主義的驅動，促使他們提出了 EIP-1962 這樣具有高度通用性的提案。

然而，以太坊的發展並非一帆風順。在實際開發過程中，開發者們需要面對各種各樣的技術挑戰和資源限制。在這種情況下，實用主義往往會佔據上風。Geth 開發者對於 EIP-2537 複雜性的擔憂，以及對安全性的嚴格要求，都體現了這種實用主義的態度。

EVM384 的出現，更是加劇了理想主義與實用主義之間的衝突。EVM384 試圖提供一個通用的橢圓曲線計算方案，這在理論上更具吸引力。然而，EVM384 的通用性也意味著它可能更加複雜，難以實現和驗證。最終，以太坊社區選擇了更加務實的路線，優先解決了當前最緊迫的問題，例如 PoS 提款和二層網絡擴容。

EIP-2537 的命運，反映了以太坊技術路線選擇上的某種搖擺。在追求理想的同時，以太坊社區也需要保持清醒的頭腦，充分考慮實際情況，避免陷入過於理想化的陷阱。

開發者權力：誰決定以太坊的未來？

EIP-2537 的故事，也揭示了以太坊開發者社群內部權力分配的不均衡。Geth 作為以太坊最主要的客戶端，其開發者的意見往往對 EIP 的命運產生決定性的影響。Geth 開發者對於 EIP-2537 複雜性的擔憂，以及對安全性的嚴格要求，最終導致 EIP-2537 被排除在 Berlin 升級之外。

Matter Labs 作為 EIP-2537 的最初提案者，在 EIP 的推進過程中也發揮了重要的作用。然而，隨著時間的推移，Matter Labs 逐漸淡出 EIP-2537 的討論，這也反映了開發者權力分配的變化。

以太坊的未來，由誰來決定？是少數核心開發者，還是廣大的社群成員？這個問題，一直困擾著以太坊社區。EIP-2537 的故事，提醒我們需要更加重視開發者權力分配的公平性，避免少數人壟斷決策權。

安全至上還是效率優先？以太坊的風險偏好

EIP-2537 的命運，也反映了以太坊在安全性和效率之間的權衡。Geth 開發者對於 EIP-2537 安全性的嚴格要求，體現了以太坊社區對於安全至上的堅持。

然而，過於強調安全性，可能會導致效率的損失。EIP-2537 的複雜性，使得 Geth 開發者難以在短時間內完成安全驗證，這也導致 EIP-2537 被排除在 Berlin 升級之外。

在安全性和效率之間，以太坊應該如何平衡？這個問題，沒有標準答案。EIP-2537 的故事，提醒我們需要根據實際情況，謹慎權衡安全性和效率，避免走極端。

EIP-2537 的故事，充滿了曲折和爭議，也反映了以太坊發展的複雜性。EIP-2537 的最終納入，或許是技術進步的勝利，但更可能是以太坊在各種力量博弈下，達成的一種妥協。EIP-2537 的故事，也給我們帶來了深刻的啟示：在技術發展的道路上，我們需要保持理想，但更需要腳踏實地；我們需要重視創新，但更需要謹慎地權衡風險。