EIP-2537:以太坊曲线计算的漫长之路

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

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

提案背景

2017年1月,Vitalik Buterin首次介绍了配对算法和alt_bn128曲线。随后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多签算法。这使得之前的EIP-1011方案退出历史舞台,后来的ETH2升级也最终采用了BLS12-381曲线。

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

有趣的是,EIP-2537作者也是Matter Labs的联合创始人,Matter Labs最著名的产品是ZKSync。

Berlin动荡

在介绍后续内容前,需要先提及EIP-1962。这是Matter Labs在2019年4月提出的首个椭圆曲线域配对预编译提案,支持BLS12、BN和MNT4/6三条曲线。该EIP计划一次性增加10个预编译指令处理不同曲线。但许多开发者质疑提案过于复杂难以实现,且对智能合约工程师使用不便。作为提案方,Matter Labs已完成椭圆曲线算法开发,提供了多语言参考实现。

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

• 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就指出其存在一系列问题,主要集中在EIP文档内容方面。随后作者进行回复讨论。2020年3月6日的核心开发者会议上,Vitalik认为EIP-2537等对递归SNARK证明非常有效,长远看不会损害以太坊。会议确认了EIP-2537的优先地位,所有客户端同意尽快实现并计划在Berlin升级前完成开发。

随后EIP-2537成为高优先级任务。3月20日的会议确认EIP-2537替代EIP-1962成为核心BLS提案并进入Berlin升级预选名单。4月的会议正式将EIP-2537纳入Berlin硬分叉升级,确定了4月实现、5-6月测试的时间线,并将其列为最高优先级事项。

接下来EIP-2537进入大量开发测试阶段,后续近20次核心开发者会议几乎每次都涉及相关讨论。主要内容包括:

• ABI编码问题讨论
• 各客户端实现进度同步
• Geth实现PR存在16000行代码,难以确定安全性和有效性
• 开发者表示Geth难以在7月前完成EIP-2537开发
• 提议寻找密码学工程师协助PR审查,使用测试网测试实现安全性
• 讨论是否去除复杂汇编优化降低审查难度
• 存款合约开发者表示不使用EIP-2537的版本已审计完成,考虑不再推出使用EIP-2537的版本
• 决定增加YOLO测试网专门测试EIP-2537

至此可以看出,EIP-2537重要性随存款合约完成已大幅下降,且Geth开发者认为难以在Berlin前实现。EIP-2537不被Berlin接纳似成定局。

后续会议中出现更多问题:

• Geth发现EIP-2537实现PR存在问题,需进一步测试修复
• YOLO测试网出现问题,怀疑与BLS签名相关
• 讨论客户端多样性问题,考虑冻结当前EIP实现降低其他客户端开发成本
• Matter Labs希望将EIP-2539也纳入测试,但遭Geth开发者反对

最终在第99次核心开发者会议上,决定将EIP-2537移出YOLO v3测试网和Berlin升级。主要原因是EIP-2537耗费了核心开发者太多时间,导致其他EIP开发受阻。次要因素是以太坊基金会提出EVM384作为替代方案。

2021年4月,以太坊完成Berlin升级,核心包含的EIP-2565等实现并不复杂,升级略显单薄,这是因为最复杂的EIP-2537被踢出。

后续发展

Berlin后的London升级中,开发者曾考虑加入EIP-2537,但因实现更换依赖库导致gas定价可能变化,最终因复杂性再次被放弃。

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

2022年11月,开发者认为EIP-2537需要推迟,Shanghai升级核心是支持PoS提款。Cancun升级因专注EIP-4844也未讨论EIP-2537。

直到2024年2月,开发者才讨论在Pectra升级纳入EIP-2537,认为实现已不是问题,仅存在部分gas消耗定价问题。2024年12月至2025年1月,开发者讨论具体成本计算模型,最终解决EIP-2537成本问题。

总结

EIP-2537从2020年2月提出到2025年1月最终确定,经历了近5年时间。其间多次因实现复杂性或与升级主题不符而被推迟。这表明EIP能否纳入以太坊升级,不仅取决于自身价值,还需要考虑历史进程因素。每次以太坊升级都有自己的主题,EIP-2537虽曾是Berlin升级最重要EIP,却因难度被废弃。随后以太坊进入PoS历史进程,纯执行层EIP不受重视,导致EIP-2537长期未被接受。