EIP-2537:以太坊BLS12-381预编译指令的漫长之路

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升级中被正式采纳,实现了EVM内部的曲线域配对计算,使ZK-Snarks证明验证可以在EVM内完成。

随着密码学发展,zcash团队在2017年11月提出了BLS12-381曲线。相比alt_bn128,BLS12-381具有更高的安全性和更好的性能。许多区块链协议开始使用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。

值得一提的是,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-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验证算法,存款合约不会验证签名,具体的BLS签名会在用户存款后由共识层验证,如发现不正确可能导致用户资金损失。

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

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

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

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

在第85次会议上,开发者讨论了EIP-2537的ABI编码问题。Besu客户端表示基本实现了功能,但Geth方面表示尚无人开展相关工作。

第86次会议上,Geth表示完成了部分工作,但仍有大量工作待完成。

第87次会议重点讨论了EIP-2537的实现问题。Geth开发者表示存在一个16000行的PR实现EIP-2537,但无法确定其安全性和有效性,只能通过简单的模糊测试判断。Geth开发者认为无法在Berlin预定时间前完成EIP-2537的开发。

会议决定增加YOLO测试网专门测试EIP-2537。此时EIP-2537的重要性已大幅下降,Geth开发者认为该EIP极可能无法纳入Berlin升级。

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

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

第90次会议锁定了7月上线Berlin升级的期限。会议还讨论了Geth主导地位的问题,有人提议冻结当前EIP实现以降低其他客户端开发成本。

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

第96次会议上,Matter Labs希望将EIP-2539也纳入YOLO v2测试并进入Berlin升级。但Geth开发者反对,认为EIP-2537仍未在Geth内完整测试。最终决定不在Berlin升级增加2696。

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

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

后续发展

Berlin升级后的London升级引入了EIP-1559。对于曾作为核心提案的EIP-2537,后续升级都很难将其纳入。

London升级中,开发者曾考虑增加EIP-2537。第109次会议同步了EIP-2537开发情况,讨论了gas使用问题,有人提议用EVM384替换EIP-2537。但第111次会议因复杂性将EIP-2537移出London升级。主要是EIP-2537标准实现更换了依赖库,导致gas定价可能变化,各客户端需要重新评估gas消耗。

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

2022年11月,第150次会议短暂讨论了是否将EIP-2537纳入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次会议讨论了重新定价BLS预编译,Geth开发者建议将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月:讨论具体成本模型,正式解决成本问题

EIP能否纳入以太坊升级,既要靠自身努力,也要考虑历史进程。每次升级都有主题,EIP-2537曾是Berlin升级核心,却因复杂性被废弃。之后以太坊聚焦PoS,纯执行层EIP不受重视,导致EIP-2537长期未被接受。直到近期,开发者才重新关注并解决了其遗留问题。