EIP-2537:从争议到采纳的漫长之路

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

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

提案背景

2017年1月,Vitalik Buterin首次在一篇文章中介绍了配对算法和alt_bn128曲线。随后,Vitalik和Christian Reitwiessner提出了EIP-196和EIP-197,建议向EVM增加alt_bn128曲线计算支持。

2017年10月的拜占庭升级正式引入了alt_bn128曲线,实现了EVM内部的曲线域配对计算,使ZK-Snarks证明验证可以在EVM内完成。

然而,随着密码学的发展,2017年11月zcash开发团队提出了BLS12-381曲线。相比alt_bn128,BLS12-381具有更高的安全性和更好的性能。许多区块链协议后来都采用了BLS12-381曲线,放弃了alt_bn128。

2018年5月,Justin Drake发表文章指出以太坊未来的PoS和分片升级可以使用基于BLS12-381曲线的BLS多重签名算法。这一方案解决了早期PoS方案中验证者数量受限的问题。事实证明,后来的ETH2升级确实采用了BLS12-381曲线。

随着ETH2开发的推进,将BLS12-381引入ETH执行层的呼声日益高涨。2020年2月,研究人员提出了EIP-2537,并希望该提案能与ETH2测试网一同进行测试。EIP-2537的作者Alex Stokes呼吁在Berlin硬分叉中纳入该提案。

值得注意的是,EIP-2537的作者也是ZKSync开发公司Matter Labs的联合创始人。

Berlin升级的波折

在介绍后续进展之前,我们需要先了解EIP-1962。这是Matter Labs在2019年4月提出的第一个关于椭圆曲线域配对预编译的提案,支持BLS12、BN和MNT4/6三种曲线。

EIP-1962计划一次性增加10个预编译指令来处理不同曲线。但该提案遭到许多开发者质疑,认为过于复杂难以实现。同时由于高度通用化,对智能合约工程师来说调用也很麻烦。不过作为提案方,Matter Labs已经完成了椭圆曲线算法的开发工作,并提供了多种语言的参考实现。

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

• EIP-2537提供BLS12-381支持
• EIP-2539提供BLS12-377支持
• PR#2541提供BLS12-377(Zexe曲线)支持,但该提案最终未获EIP编号

其中最重要的是EIP-2537,因为共识层也使用了BLS12-381曲线。EIP-1962和EIP-2537的核心目标都是在主网实现共识层BLS签名验证。当时ETH2正在开发共识层存款合约。最初设计中,由于执行层不包含BLS验证算法,存款合约不会验证签名,具体的BLS签名会在用户存款后由共识层验证,如果发现不正确,存款将失败,用户存入的ETH可能会丢失。

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

EIP-2537刚提出时,Vitalik就指出了提案存在的一系列问题。这些质疑主要集中在EIP文档内容方面,随后EIP作者对此进行了回复和讨论。

2020年3月6日的第82次以太坊核心开发者会议讨论了EIP-2537。Vitalik认为该EIP对递归SNARK证明非常有效,从长远来看不会对以太坊造成负面影响。会议确认了EIP-2537的优先地位,所有客户端都同意尽快实现该EIP并计划在Berlin升级前完成所有开发。

随后,EIP-2537成为优先级较高的任务。3月20日的第83次核心开发者会议再次将其作为首要讨论的提案。会议确认EIP-2537取代EIP-1962成为核心BLS提案,并列入Berlin升级预选名单。

4月的第84次会议正式将EIP-2537纳入Berlin硬分叉升级,并确定了4月实现、5-6月测试的时间线。值得注意的是,EIP-2537在此次讨论中被列为最高优先级事项。

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

在第85次会议上,开发者讨论了EIP-2537的ABI编码问题。由于Matter Labs之前已基本完成Rust版本实现,Besu客户端表示已基本实现EIP-2537功能,但Geth方面称目前没有人在开展相关工作。

第86次会议上,不同节点实现再次同步了EIP-2537的进展,Geth表示完成了部分工作,但还有大量任务待完成。

第87次会议重点讨论了EIP-2537的实现问题。Geth开发者表示存在一个16000行的PR实现EIP-2537,但无法确定该PR是否安全有效地实现了EIP-2537,只能通过最简单的模糊测试判断代码情况。

Geth开发者表示:"按我的直觉,Geth不可能在7月的主网发布前准备好BLS曲线操作。"

Hudson Jameson提议为Geth寻找密码学工程师协助PR审查,并建议使用测试网测试EIP-2537的实现安全性。由于ETH2开发团队也在实现BLS签名验证,可以参与测试。

需要补充的是,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升级采纳似乎已成定局。

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

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

第90次会议确定了7月上线Berlin升级的最后期限。会议还讨论了客户端多样性问题,主要涉及Geth占主导地位的情况,有开发者建议冻结当前EIP实现来降低其他客户端的开发成本。第91次会议中,有开发者提议使用模块化方案降低开发成本以增加客户端多样性。

第92次会议仍将EIP-2537确认为Berlin升级所需的EIP。

第96次会议上,由于Celo已将EIP-2537和EIP-2539同时纳入其网络硬分叉,Matter Labs希望将EIP-2539也放到YOLO v2测试并进入Berlin升级。但Geth开发者反对,认为当前EIP-2537仍未在Geth内完整测试。最终会议决定不在Berlin升级中增加EIP-2696,留待未来讨论。

第99次会议决定将EIP-2537移出YOLO v3测试网和Berlin升级,最主要原因是EIP-2537耗费了核心开发者太多时间,导致Berlin升级其他EIP开发受阻。次要因素是以太坊基金会提出了EVM384作为EIP-2537替代,提供更通用的椭圆曲线计算方案。但核心开发者对安全问题表示担忧。

这就是EIP-2537的早期历程。我们可以看到,EIP-2537最初是Berlin升级中最重要的EIP之一,但由于实现问题最终被废弃。2021年4月,以太坊完成Berlin升级,核心EIP如EIP-2565实际实现并不复杂,升级看起来略显单薄,这正是因为最核心复杂的EIP-2537被剔除。

后续发展

众所周知,以太坊每次升级都会有一个核心提案。Berlin后的London升级引入了以太坊历史上最重要的手续费提案EIP-1559。对于曾经的核心提案EIP-2537而言,后续升级很难再将其纳入。

Berlin后的London升级中,开发者在issues#369考虑增加EIP-2537。第109次核心开发者会议同步了EIP-2537的开发情况,由于使用其他库实现,引发了关于gas使用的讨论。有开发者提议用EVM384替换EIP-2537。但2021年4月的第111次会议上,EIP-2537因复杂性被移出London升级。主要原因是EIP-2537标准实现更换了依赖库,导致gas定价可能变化,不同客户端实现需要大量时间重新评估gas消耗。

2021年6月,issues#343正式提出将EIP-2537纳入Shanghai升级。但London升级后,The Merge占据了开发者大量时间,执行层开发者需要编写大量代码实现PoS升级。2022年9月,The Merge完成后,执行层开发者才有机会继续讨论Shanghai升级的目标。

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

更不幸的是,Cancun升级一直未讨论EIP-2537,因为Cancun的重点是支持EIP-4844,为以太坊二层提供Blob以便二层使用以太坊作为数据可用层。

直到2024年2月的第181次核心开发者会议,开发者才讨论在Pectra升级中纳入EIP-2537。此时开发者认为EIP-2537的实现已不是问题,只有部分gas消耗定价问题需解决。

2024年12月19日的第202次会议上,Nethermind开发者最终确定了EIP-2537的定价模型。值得注意的是,作为EIP-2537最初提案者的Matter Labs此时已基本退出讨论。2025年1月的第203次会议讨论了重新定价BLS预编译,Geth开发人员Jared Wasinger建议将gas成本提高20%,并得到Besu团队基准测试的支持。

总结

EIP-2537从提出到最终被采纳经历了漫长而曲折的过程:

• 2020年2月:拆分自EIP-1962正式提出EIP-2537
• 2020年4月-10月:多次讨论实现问题,最终因无法实现被Berlin升级放弃
• 2021年3月-4月:讨论gas成本问题,因复杂性被London升级放弃
• 2022年11月:讨论是否纳入Shanghai升级,未果
• 2024年2月:认为实现不再是问题,仍存在部分gas成本问题,可纳入Pectra升级
• 2024年12月-2025年1月:讨论具体成本计算模型,正式解决gas成本