以太坊"老不死"提案终落地！五年长跑，社区磨叽出啥了？

EIP-2537：五年磨一剑，还是社区治理的慢动作？

最初的雄心：BLS12-381 与以太坊的共识焦虑

EIP-2537 终于要在 Pectra 分叉中落地了，这事儿放在五年前，绝对是社区的头等大事。现在呢？感觉就像是例行公事，甚至有点“终于等到你”的疲惫感。说白了，这提案的核心就是给以太坊虚拟机（EVM）加几个预编译指令，专门用来算 BLS12-381 曲线上的东西，比如配对计算。这玩意儿在密码学里很重要，能搞出各种花活，比如零知识证明啥的。

想当年，Vitalik Buterin 在 2017 年就鼓吹配对算法和 alt_bn128 曲线，紧接着 EIP-196 和 EIP-197 就应运而生，直接给 EVM 安排上了。结果呢？alt_bn128 成了过渡品。密码学这玩意儿，更新迭代比互联网还快。没过多久，Zcash 团队就整出了 BLS12-381，安全性更高，性能更好，直接把 alt_bn128 拍在沙滩上。

这事儿的背景是，以太坊当时正琢磨着 PoS 和分片升级，急需一种靠谱的多重签名算法。Justin Drake 在 2018 年就跳出来说，BLS12-381 曲线可以搞 BLS 多签，完美！之前那个 EIP-1011 方案直接被扫进历史的垃圾堆。后来的 ETH2 升级也确实用了 BLS12-381，没跑。

问题来了，共识层用上了 BLS12-381，执行层也不能闲着啊。于是，2020 年 2 月，EIP-2537 横空出世，目标很明确：让 ETH1（执行层）也能用上 BLS12-381，最好能和 ETH2 测试网一起上线。EIP-2537 的作者 Alex Stokes（也是 Matter Labs 的联合创始人）甚至喊话，要在 Berlin 硬分叉里搞定这事儿。

现在回过头来看，当初的雄心壮志，现在看来更像是一种共识焦虑。以太坊社区害怕错过技术潮流，急于拥抱最新的密码学成果，但现实却给了他们一记响亮的耳光。EIP-2537 的五年长跑，与其说是技术进步的缓慢体现，不如说是社区治理的复杂性和妥协性的集中体现。

接下来，我们会看到，EIP-2537 在 Berlin 升级中遭遇了怎样的困境，又如何在随后的几年里，一次又一次地与以太坊的升级失之交臂。这其中，既有技术上的挑战，也有路线上的选择，更有社区治理的博弈。

柏林升级的闹剧：技术困境与路线之争

EIP-1962 的野心：一步到位还是过度设计？

要说 EIP-2537 的坎坷，就不得不提它的“前身”——EIP-1962。这哥们儿是 Matter Labs 在 2019 年 4 月搞出来的，目标是更宏大的：一次性支持三条曲线的配对计算，包括 BLS12、BN 和 MNT4/6。一口气上 10 个预编译指令，听起来就让人头皮发麻。

EIP-1962 的想法是好的，想搞一个通用的解决方案，但问题也出在这儿。提案过于复杂，开发者根本搞不定。你想啊，一下子来这么多指令，谁记得住？而且，为了追求通用性，EIP-1962 的接口设计也很繁琐，智能合约工程师用起来简直是噩梦。

当然，Matter Labs 还是有点东西的，他们已经完成了椭圆曲线算法的开发工作，还提供了 Rust、Go、C++ 的参考实现。但这并不能掩盖 EIP-1962 的过度设计问题。这就像是想用一把瑞士军刀解决所有问题，结果发现每一样功能都用不好。

Geth 的挣扎：汇编优化是灵丹妙药还是饮鸩止渴？

为了解决 EIP-1962 的问题，Matter Labs 在 2020 年 2 月提出了多个 EIP，把 EIP-1962 拆成了几个小块，EIP-2537 就是其中之一。EIP-2537 专注于 BLS12-381 曲线，目标更明确，也更容易实现。

当时，以太坊社区面临一个迫切的问题：ETH2 存款合约需要验证 BLS 签名，但执行层没有 BLS 验证算法。如果存款合约不验证签名，用户存入的 ETH 可能会因为签名错误而丢失。这可不是闹着玩的。

所以，核心开发者希望引入 BLS12-381 预编译，在存款合约内实现签名验证，避免用户的资金损失。EIP-2537 也因此成为了 Berlin 升级的重点关注对象。

然而，EIP-2537 的实现过程却充满了挑战。Geth 开发者在实现 EIP-2537 时，为了追求性能，大量使用了汇编代码。这部分代码非常难以阅读和理解，给代码审查带来了巨大的困难。

Geth 开发者甚至坦言，他们无法确定这个 16000 行的 PR 是否安全有效地实现了 EIP-2537。他们只能通过最简单粗暴的模糊测试来判断代码的情况。这就像是盲人摸象，根本无法真正理解代码的逻辑。

更糟糕的是，Geth 开发者悲观地表示，他们大概率无法在 Berlin 预定时间前完成 EIP-2537 的相关开发。这意味着，EIP-2537 很有可能无法被 Berlin 升级接纳。

（这里放一张 Geth 开发者抓狂的图片，突出他们当时的困境，图片地址仅为示例）

存款合约的转向：实用主义的胜利还是战略性放弃？

正当 Geth 开发者为了 EIP-2537 焦头烂额的时候，存款合约开发者却传来了一个消息：不需要 EIP-2537 的存款合约已经过审。这意味着，即使没有 EIP-2537，ETH2 存款合约也能正常工作。

这个消息无疑给 EIP-2537 泼了一盆冷水。一些开发者开始质疑，是否还有必要推出一个使用 EIP-2537 的存款合约。毕竟，EIP-2537 的实现难度太高，而且可能会延误 Berlin 升级的进度。

最终，以太坊核心开发者决定增加一个 YOLO 测试网，专门用来测试 EIP-2537。但与此同时，他们也开始重新评估 EIP-2537 的重要性。随着存款合约的完成，EIP-2537 的优先级已经大幅下降。

这是一种实用主义的选择。以太坊社区为了保证 Berlin 升级的顺利进行，不得不放弃 EIP-2537。但这同时也意味着，以太坊社区在技术路线上的战略性放弃。他们放弃了对最新密码学技术的追求，选择了更稳妥、更可靠的方案。

YOLO 测试网的警示：技术债的幽灵挥之不去？

YOLO 测试网的出现，并没有给 EIP-2537 带来转机，反而暴露了更多的问题。Geth 开发者发现，EIP-2537 的实现 PR 存在一系列问题，需要进一步测试和修复。

更严重的是，YOLO 测试网出现了一些问题，开发者怀疑是 BLS 签名导致的。虽然 EIP-2537 开发者对此进行了反驳，但这些问题无疑加剧了开发者对 EIP-2537 的担忧。

在 Ethereum Core Devs Meeting #99 中，以太坊核心开发者最终决定将 EIP-2537 移出 YOLO v3 测试网和 Berlin 升级。最核心的原因是，EIP-2537 浪费了核心开发者太多时间，导致 Berlin 升级内其他 EIP 开发受阻。

另一个因素是，以太坊基金会提出了 EVM384 作为 EIP-2537 的替代方案。EVM384 提供了更加通用的椭圆曲线计算方案。但核心开发者在会议讨论中表达了对安全问题的担心。

就这样，EIP-2537 被 Berlin 升级无情地抛弃了。曾经被视为 Berlin 升级最重要的 EIP 之一，最终却因为实现问题而被废弃。这无疑是以太坊社区的一次重大挫折。

Berlin 升级最终在 2021 年 4 月完成。但这次升级的核心内容并不复杂。这或许是因为最核心复杂的 EIP-2537 被踢出了 Berlin 升级。这就像是原本准备了一桌丰盛的晚餐，结果最后只剩下几道小菜。

漫长的等待：EIP-2537 的漂流记

伦敦升级的边缘：Gas 成本的幽灵再现

柏林升级的失败并没有让 EIP-2537 的支持者放弃。他们试图在随后的伦敦升级中再次推动 EIP-2537 的纳入。然而，历史总是惊人的相似。

在 Ethereum Core Devs Meeting #109 中，开发者同步了 EIP-2537 的开发情况。此时，由于使用了其他库对 EIP-2537 进行实现，引入了一个关于 EIP-2537 使用 gas 的讨论。Gas 成本，这个老生常谈的问题，再次浮出水面。

更糟糕的是，有开发者再次提出了使用 EVM384 替换 EIP-2537 的想法。EVM384 似乎成为了 EIP-2537 挥之不去的阴影。

最终，在 2021 年 4 月的 Ethereum Core Devs Meeting #111 内，EIP-2537 因为复杂性被移出了伦敦升级。核心复杂性在于 EIP-2537 标准实现更换了依赖库，这导致 gas 定价可能出现变化，不同客户端实现需要花费相当时间重新评估 gas 消耗。Gas 成本，成为了压垮 EIP-2537 的最后一根稻草。

伦敦升级的失败，再次证明了 EIP-2537 的推进之艰难。以太坊社区似乎已经对 EIP-2537 失去了耐心。

上海升级的搁浅：PoS 大业下的牺牲品？

伦敦升级之后，以太坊进入了 PoS 的时代。The Merge，这个以太坊历史上最重要的升级之一，占据了开发者的大量时间。执行层开发者需要编写大量代码以实现 PoS 升级。

在这个大背景下，EIP-2537 的命运更加黯淡。虽然在 2021 年 6 月，有人提出了将 EIP-2537 纳入上海升级的提案，但这并没有引起太多的关注。

在 2022 年 11 月， Ethereum Core Devs Meeting #150 内短暂讨论了 EIP-2537 的是否纳入上海升级，但开发者认为 EIP-2537 需要推迟，上海升级的核心是支持 PoS 提款。最终，EIP-2537 没有被纳入以实现提款功能为核心的 Shanghai 升级内部。

上海升级的搁浅，反映了以太坊社区在不同发展阶段的不同 priorities。在 PoS 大业面前，EIP-2537 只能黯然失色。

坎昆升级的缺席：数据可用性叙事下的遗忘

如果说上海升级的搁浅还有情可原，那么坎昆升级的缺席则让人感到一丝悲凉。在整个坎昆升级的讨论过程中，几乎没有人提起 EIP-2537。

坎昆升级的核心是执行层节点支持 EIP-4844。EIP-4844 为以太坊二层提供了 Blob，以方便二层使用以太坊作为数据可用层。数据可用性，成为了坎昆升级的核心叙事。

在这个叙事下，EIP-2537 显得格格不入。它与数据可用性没有任何关系，也无法为以太坊二层带来任何直接的好处。EIP-2537 就像一个被遗忘的角落，静静地等待着命运的安排。

（这里放一张 EIP-2537 被遗忘在角落的图片，突出它的孤单和失落，图片地址仅为示例）

Pectra 升级的曙光：技术债务的清算时刻？

漫长的等待终于迎来了曙光。在 2024 年 2 月的 Ethereum Core Devs Meeting #181 内，开发者讨论在 Pectra 升级内纳入 EIP-2537。

这一次，情况似乎有所不同。开发者认为 EIP-2537 的实现已经不是问题，只有部分问题在 Gas 消耗定价方面。五年时间，足以让技术难题得到解决。

在 2024 年 12 月 19 日的 Ethereum Core Devs Meeting #202 内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。Gas 成本，这个困扰 EIP-2537 多年的难题，终于得到了解决。

Pectra 升级的曙光，似乎预示着 EIP-2537 即将迎来最终的胜利。但这真的是一个圆满的结局吗？还是说，这只是以太坊社区在偿还多年积累的技术债务？

尘埃落定？EIP-2537 的最终命运

Matter Labs 的背影：英雄迟暮还是战略转移？

值得注意的是，作为 EIP-2537 的最初提案者，Matter Labs 此时已经近乎退出了讨论。曾经为了 EIP-2537 四处奔走的身影，如今已经消失在社区的视野中。

这到底是英雄迟暮，还是战略转移？或许，Matter Labs 已经将重心转移到了 ZKSync 的开发上，不再关注 EIP-2537 的命运。毕竟，对于一个 Layer 2 解决方案来说，EIP-2537 的重要性远不如以太坊主链。

无论如何，Matter Labs 的背影，都给 EIP-2537 的故事增添了一丝唏嘘。曾经的开拓者，最终成为了旁观者。

Gas 成本的博弈：社区治理的精打细算？

在 EIP-2537 接近落地的最后阶段，Gas 成本成为了开发者们争论的焦点。在 2025 年 1 月的 Ethereum Core Devs Meeting #203 内，开发者讨论包括重新定价 BLS 预编译，Geth 开发人员 Jared Wasinger 建议将 gas 成本提高 20%，并得到 Besu 团队基准测试的支持。

Gas 成本的博弈，反映了以太坊社区在资源分配上的精打细算。每一项新的功能，都需要与其他功能竞争有限的 Gas 资源。

EIP-2537 的 Gas 成本，最终需要在安全性和可用性之间取得平衡。过高的 Gas 成本会限制 EIP-2537 的使用，而过低的 Gas 成本则可能导致安全风险。

以太坊社区在 Gas 成本上的博弈，体现了社区治理的复杂性和微妙之处。每一个决策，都需要考虑到各方面的利益，并做出权衡。

(这里放一张开发者们争论 Gas 成本的图片，突出社区治理的复杂性，图片地址仅为示例)

超越技术：EIP-2537 的治理启示录

EIP-2537 的故事，不仅仅是一个技术提案的兴衰史，更是一部以太坊社区治理的启示录。

EIP-2537 的五年长跑，暴露了以太坊社区在技术路线选择、资源分配、社区协调等方面的挑战。

EIP-2537 的命运，受到了技术难度、社区优先级、政治博弈等多种因素的影响。

EIP-2537 的故事，告诉我们，即使是最有前景的技术提案，也需要在社区治理的复杂环境中生存和发展。

EIP-2537 最终能否在 Pectra 升级中落地，已经不再是最重要的问题。更重要的是，我们应该从 EIP-2537 的故事中吸取教训，为以太坊社区的未来发展提供借鉴。

毕竟，技术的进步，离不开社区的智慧和力量。而一个健康的社区，需要开放的讨论、有效的协调和理性的决策。EIP-2537 的故事，正是对这些原则的最好诠释。