作者：shew

概述

EIP-2537是最新的 Pectra 分叉升级中被确定添加的 EVM 预汇编指令。该指令为 EVM 增加了 BLS12-381 曲线的多种计算功能，比如曲线域上的配对计算等。

EIP-2573 最初在 2020 年被提出，直到 2025 年才被确认加入以太坊升级。本文主要介绍 EIP-2537 的治理历史，探究为什么经过 5 年才会将此提案纳入升级。

提案背景

2017 年 1 月份，Vitalik Buterin 在Exploring Elliptic Curve Pairings第一次介绍了配对算法以及alt_bn128曲线。随后在 2017 年 2 月，Vitalik Buterin 和 Christian Reitwiessner 提出了EIP-196和EIP-197提案，提案内容是向 EVM 增加alt_bn128曲线计算支持。

在 2017 年 10 月份的Byzantium升级内，正式纳入alt_bn128曲线。简单来说，alt_bn128第一次实现了 EVM 内部的曲线域配对计算，这使得 ZK-Snarks 证明验证可以在 EVM 内完成。

但随着密码学发展，2017 年 11 月，zcash 开发团队在BLS12-381: New zk-SNARK Elliptic Curve Construction第一次给出了BLS12-381曲线。相比于alt_bn128而言，BLS12-381具有更高的安全性、更好的性能。相当多的区块链协议在此后都使用了BLS12-381曲线而废弃了alt_bn128曲线。

在 2018 年 5 月，Justin Drake 在 ethresear 内发布了Pragmatic signature aggregation with BLS一文，指出在以太坊未来的 PoS 和分片升级都可以使用基于BLS12-381曲线的 BLS 多签算法。当时，以太坊研究者希望使用EIP-1011解决共识层问题，但是 EIP-1011 方案最多可以容纳 900 个验证者，因此为每个验证者设定了 1500 ETH 的巨大质押规模。随着 BLS 多签方案的提出，EIP-1011 退出了历史舞台。事实证明，后来的 ETH2 升级也最终使用了BLS12-381曲线。

伴随着 ETH2 开发，ETH2 所使用的BLS12-381引入 ETH 执行层开始被呼吁。在 2020 年 2 月，一些研究员提出了EIP-2537，并且希望该提案可以在 ETH2 测试网一起接受测试。EIP-2537 作者 Alex Stokes 在What eth2 needs from eth1 over the next six months文章内呼吁在 Berlin 硬分叉内纳入 EIP-2537。

有趣的是，EIP-2537 的作者也是 Matter Labs 的联合创始人，而 Matter Labs 最为著名的产品就是 ZKSync

Berlin 动荡

我们在介绍后续内容前，需要首先介绍EIP-1962。EIP-1962 是 Matter Labs 在 2019 年 4 月提出的第一个关于椭圆曲线域配对预汇编的提案，该提案支持了三条曲线，分别是：

• BLS12
• BN
• MNT4/6 (Ate pairing)

该 EIP 准备一次性增加 10 个预汇编指令以处理不同的曲线。但是该提案诞生后，相当多的开发者质疑提案过于复杂以至于开发者很难实现。同时由于 EIP1962 高度通用化，对于智能合约工程师而言，调用也是十分麻烦的。当然，作为 EIP-1962 的提出者，Matter Labs 实质上已经完成了椭圆曲线算法的开发工作，并提供了 Rust / Go / C++ 参考实现。

为了解决 EIP-1962 的问题，Matter Labs 于 2020 年 2 月提出了多个 EIP 拆分 EIP-1962，这些 EIP 都部分继承了 EIP-1962 的接口。这些 EIP 包括:

• EIP-2537提供 BLS12-381 的支持
• EIP-2539提供 BLS12-377 的支持
• PR#2541提供 BLS12-377 (Zexe curve) 支持，但注意该提案最终没有获得 EIP 编号，无法在 EIP 文档官网找到

这几个 EIP 内部，最重要的就是 EIP-2537，因为共识层也使用了 BLS12-381 曲线。包括 EIP-1962 和 EIP-2537 的核心目的都是在主网内实现共识层 BLS 签名的验证。在当时，ETH2 正在开发共识层的存款合约设计。在存款合约最初设计时，由于执行层内不包含 BLS 验证算法，所以存款合约不会验证签名，具体的 BLS 签名会在用户存款后由共识层验证，如果发现不正确（对于新的验证者），存款将失败，用户存入的 ETH 将会丢失。

在此背景下，核心开发者希望引入 BLS12-381 预汇编在存款合约内实现签名验证，避免用户存入 ETH2 资金的可能损失。这也是当时大量开发者关注 EIP-1962 和 EIP-2537 的原因。

当 EIP-2537 刚刚提出时，Vitalik 就立即发现了 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 的讨论。接下来，我们可以看看每一次会议都讨论了哪些关于 EIP-2537 的问题。

在Ethereum Core Devs Meeting #85内，Danno 和 Axic 对 EIP-2537 的 ABI 编码问题进行了讨论。随后，核心开发者同步了当前的实现情况，其中由于 EIP-2537 的提案人 Matter Labs 之前已基本完成了 Rust 版本的实现，所以 Besu 客户端声明已基本实现 EIP-2537 的功能，但是 Geth 方面表示目前没有人在为 EIP-2537 的实现工作。

在Ethereum Core Devs Meeting #86内，不同的以太坊节点实现再次同步了 EIP-2537 的实现情况，其中 Geth 表示完成了部分工作，但还有大量工作等待完成。

在Ethereum Core Devs Meeting #87内，此次开发者会议最核心的内容就是 EIP-2537 的实现问题。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 内部的复杂汇编优化来降低审查难度。

我们在上文已经介绍过 EIP-2537 的一个核心目标就是辅助 ETH2 存款合约，但是在此次会议上存款合约开发者表示不使用 EIP-2537 的存款合约已经过审计，所以部分开发者提出最好不要再推出一个使用 EIP-2537 的存款合约。

在最后，会议决定增加 YOLO 测试网，该测试网的核心就是测试 EIP-2537。事实上，在此次会议中，我们就可以看到 EIP-2537 的重要性随着存款合约的完成已经大幅下降，同时 Geth 开发者已经认为该 EIP 极有可能无法在 Berlin 升级前实现。似乎 EIP-2537 不被 Berlin 升级接纳已成定局。

在Ethereum Core Devs Meeting #88内，Geth 开发者发现 EIP-2537 的实现 PR 存在一系列问题，开发者表示还需要进一步测试和修复。此时 Geth 系统内存在两个 EIP-2537 的实现，其中一个实现包含汇编优化，而另一个实现则完全由 go 语言编写，有开发者提议直接使用 go 语言编写版本来降低代码审查的难度。

在Ethereum Core Devs Meeting #89内，更加严重的问题发生了，YOLO 测试出现了一些问题，开发者怀疑是 BLS 签名导致的问题，但 EIP2537 开发者对此进行了反驳，认为测试网问题并不是 BLS 签名导致。对于 EIP-2537 的好消息是，基于 EIP-2537 的存款合约基本开发完成，该合约正在等待合约审计。

在Ethereum Core Devs Meeting #90内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91 会议中，有开发者提议使用模块化方案降低开发成本来增加客户端多样性。假如读者对于以太坊客户端多样性感兴趣，可以去阅读了这两次会议的记录。

在Ethereum Core Devs Meeting #92内，2537 仍旧被确认为 Berlin 升级所需要的 EIP。

在Ethereum Core Devs Meeting #96内，基于 Celo 已经将 EIP-2537 和 EIP-2539 同时纳入了其网络硬分叉升级中，所以 Matter Labs 希望将与 EIP-2537 同时提出的 EIP-2539 也放到 YOLO v2 测试网测试并且进入 Berlin 升级。但是 Geth 开发者反对，认为当前的 EIP-2537 仍没有在 Geth 内部经过完整测试。最终会议决定不在 Berlin 升级内增加 2696，留待未来讨论。

在Ethereum Core Devs Meeting #99内，此次会议决定将 EIP-2537 移出 YOLO v3 测试网和 Berlin 升级，最核心的原因是 EIP-2537 浪费了核心开发者太多时间，导致 Berlin 升级内其他 EIP 开发受阻。次要因素是以太坊基金会提出了EVM384作为 EIP-2537 替代，EVM 384 提供了更加通用的椭圆曲线计算方案。但是核心开发者在会议讨论中表达了对安全问题的担心。

上述内容就是 EIP-2537 的早期历程，我们可以看到 EIP-2537 早期是 Berlin 升级中最重要的 EIP 之一，但是由于实现问题最终被废弃。最后，在 2021 年 4 月，以太坊完成了 Berlin 升级，升级中核心包含的 EIP-2565 等实际实现都并不复杂，看上去 Berlin 升级似乎略显单薄，这是因为最核心复杂的 EIP-2537 被踢出了 Berlin 升级。

后续发展

众所周知，以太坊每一次升级都会有一个核心提案，比如 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 消耗。

在 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 升级内部。

更加凄惨的是 Cancun 升级一直没有对 EIP-2537 进行讨论，因为 Cancun 升级的核心是执行层节点支持 EIP-4844。EIP-4844 为以太坊二层提供了 Blob 以方便二层使用以太坊作为数据可用层。

终于，在 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 团队基准测试的支持。

总结

可见，EIP 是否被纳入以太坊升级，“当然要靠自我奋斗，但是也要考虑到历史的行程”。每一次以太坊升级都会有自己的主题，正如 EIP-2537 一度成为 Berlin 升级最重要的 EIP，但是因为其实现难度和复杂性被废弃。随后的以太坊进入了 PoS 的历史进程，复杂的纯执行层 EIP 不被受到重视，而大量与 PoS 相关的执行 EIP 被视为核心升级目标，这导致长时间内 EIP-2537 不被接受。

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。