EIP-2537:从2020到2025的漫长历程

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

EIP-2537最初于2020年提出,直到2025年才被确认纳入以太坊升级。本文将介绍EIP-2537的治理历程,探讨为何这一提案经过5年才最终被采纳。

提案背景

2017年1月,Vitalik Buterin首次在一篇文章中介绍了配对算法和alt_bn128曲线。随后在2月,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多签算法。这为后来的ETH2升级奠定了基础。

随着ETH2开发,将BLS12-381引入执行层的呼声渐起。2020年2月,研究人员提出EIP-2537,希望与ETH2测试网一同测试。EIP-2537作者Alex Stokes呼吁将其纳入Berlin硬分叉。

值得一提的是,EIP-2537作者也是Matter Labs联合创始人,该公司最著名的产品是ZKSync。

Berlin动荡

在介绍后续内容前,需先了解EIP-1962。这是Matter Labs 2019年4月提出的首个椭圆曲线域配对预编译提案,支持BLS12、BN和MNT4/6三种曲线。

EIP-1962计划一次性增加10个预编译指令处理不同曲线。但许多开发者认为过于复杂难以实现,且对智能合约工程师使用不友好。不过Matter Labs已完成算法开发并提供多语言参考实现。

为解决EIP-1962问题,Matter Labs于2020年2月提出多个EIP拆分方案:

• 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立即指出一系列问题,主要集中在文档内容方面。作者随后进行了回应和讨论。

2020年3月6日的核心开发者会议82讨论了EIP-2537。Vitalik认为它对递归SNARK证明很有效,长远来看不会损害以太坊。会议确认了EIP-2537的优先地位,所有客户端同意尽快实现并在Berlin升级前完成开发。

随后EIP-2537成为高优先级任务。3月20日的会议83再次优先讨论该提案,确认其取代EIP-1962成为核心BLS提案,并纳入Berlin升级预选名单。

4月的会议84正式将EIP-2537纳入Berlin硬分叉,确定4月实现、5-6月测试的时间线。EIP-2537被列为最高优先级事项。

此后EIP-2537进入大量开发和测试阶段,在后续近20次核心开发者会议中几乎每次都有相关讨论。

会议85中讨论了ABI编码问题。由于Matter Labs已基本完成Rust实现,Besu客户端表示已基本实现EIP-2537功能,但Geth表示尚未开始实现工作。

会议86各节点再次同步实现情况,Geth表示完成部分工作但仍有大量任务待完成。

会议87的核心内容是EIP-2537实现问题。Geth开发者表示存在一个16000行的PR实现EIP-2537,但无法确定是否安全有效,只能通过简单的模糊测试判断。Geth认为大概率无法在Berlin预定时间前完成相关开发。

Hudson Jameson提议为Geth寻找密码学工程师协助PR审查,并建议用测试网测试实现安全性。ETH2团队也可参与测试。

需要补充的是,Geth的EIP-2537实现PR为保证效率大量使用汇编代码,很难阅读理解。Alex Vlasov建议去掉复杂汇编优化降低审查难度。

虽然EIP-2537的一个核心目标是辅助ETH2存款合约,但此次会议存款合约开发者表示不使用EIP-2537的版本已经过审计,部分开发者建议不要再推出使用EIP-2537的新版本。

最后会议决定增加YOLO测试网专门测试EIP-2537。此时可以看出,随着存款合约完成,EIP-2537的重要性已大幅下降,且Geth开发者认为很可能无法在Berlin升级前实现。EIP-2537不被纳入Berlin似乎已成定局。

会议88中Geth开发者发现EIP-2537实现PR存在一系列问题,表示需要进一步测试修复。此时Geth有两个实现版本,一个包含汇编优化,另一个完全用Go编写。有人建议直接使用Go版本以降低代码审查难度。

会议89出现更严重问题,YOLO测试网出现异常,怀疑是BLS签名导致,但EIP-2537开发者予以反驳。好消息是基于EIP-2537的存款合约基本开发完成,正等待审计。

会议90锁定了7月上线Berlin升级的期限。会议还讨论了客户端多样性问题,有人提议冻结当前EIP实现以降低其他客户端开发成本。会议91甚至提出使用模块化方案增加客户端多样性。

会议92再次确认EIP-2537为Berlin升级所需EIP。

会议96讨论是否将EIP-2539也纳入Berlin测试,因Celo已将EIP-2537和EIP-2539纳入其网络升级。但Geth开发者反对,认为EIP-2537本身仍未完全测试。最终决定不在Berlin增加EIP-2696。

会议99决定将EIP-2537移出YOLO v3测试网和Berlin升级,主要原因是它耗费了开发者太多时间影响其他EIP开发。次要因素是以太坊基金会提出EVM384作为替代方案。但开发者对其安全性表示担忧。

这就是EIP-2537的早期历程。它曾是Berlin升级最重要的EIP之一,但因实现问题最终被废弃。2021年4月以太坊完成Berlin升级,核心EIP如EIP-2565的实现都相对简单,显得略显单薄,正是因为最复杂的EIP-2537被剔除。

后续发展

众所周知,以太坊每次升级都有核心提案,如Berlin后的London引入EIP-1559。对曾是核心提案的EIP-2537而言,后续升级很难再将其纳入。

London升级时,开发者曾考虑增加EIP-2537。会议109同步了其开发情况,因使用新库实现引发gas讨论。有人提议用EVM384替代。但会议111因复杂性将其移出London升级,主要是依赖库更换导致gas定价变化,需要重新评估。

2021年6月正式提议将EIP-2537纳入Shanghai升级。但London后The Merge占据了开发者大量时间。2022年9月The Merge完成后,执行层开发者才有机会继续讨论Shanghai目标。

2022年11月会议150简短讨论是否纳入Shanghai,但开发者认为应推迟,Shanghai核心是支持PoS提款。最终EIP-2537未被纳入以提款为核心的Shanghai升级。

更糟的是Cancun升级一直未讨论EIP-2537,因其核心是支持EIP-4844,为二层提供Blob数据可用性。

终于,2024年2月会议181讨论在Pectra升级纳入EIP-2537,开发者认为实现已不是问题,仅存在gas定价问题。

2024年12月19日会议202,Nethermind开发者最终确定EIP-2537定价模型。原提案者Matter Labs此时已近乎退出讨论。2025年1月会议203讨论重新定价,Geth开发者建议提高20% gas成本,得到Besu团队支持。

总结

EIP-2537从提出到被采纳经历了漫长的5年时间。它曾是Berlin升级的核心,因实现困难被放弃。随后以太坊进入PoS历史进程,复杂的纯执行层EIP不受重视,大量PoS相关EIP成为核心目标,导致EIP-2537长期未被接受。直到2025年,随着主要技术难题的解决,EIP-2537终于有望在Pectra升级中实现。

这一历程表明,EIP能否被纳入以太坊升级,不仅取决于自身技术价值,还需要考虑整个以太坊的发展阶段和优先事项。每次升级都有其主题,只有符合当前需求且技术成熟的EIP才能最终被采纳。