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

2017年11月,zcash团队提出了BLS12-381曲线,相比alt_bn128具有更高安全性和性能。许多区块链协议随后采用BLS12-381曲线。2018年5月,Justin Drake发文指出以太坊未来的PoS和分片升级可使用基于BLS12-381的BLS多签算法。

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

值得一提的是,EIP-2537作者同时也是ZKSync开发团队Matter Labs的联合创始人。

Berlin升级动荡

在讨论EIP-2537前,需先了解EIP-1962。这是Matter Labs 2019年4月提出的首个椭圆曲线域配对预编译提案,支持BLS12、BN和MNT4/6三种曲线,计划一次性增加10个预编译指令。但该提案被认为过于复杂难以实现。

为解决EIP-1962问题,Matter Labs于2020年2月提出多个EIP拆分方案,其中最重要的是EIP-2537,提供BLS12-381支持。当时ETH2正在开发存款合约,引入BLS12-381预编译可在存款合约中验证签名,避免用户资金损失风险。

EIP-2537刚提出时,Vitalik就指出了一些问题。随后在3月6日的核心开发者会议上,Vitalik认为EIP-2537对递归SNARK证明很有效,长远看不会损害以太坊。会议确认了EIP-2537的优先地位,所有客户端同意尽快实现并计划在Berlin升级前完成开发。

在后续会议中,EIP-2537取代EIP-1962成为核心BLS提案,并被纳入Berlin升级预选名单。4月的会议正式将EIP-2537纳入Berlin硬分叉,并确定了实施时间表。

此后EIP-2537进入大量开发和测试阶段,在近20次核心开发者会议中都有相关讨论。主要围绕ABI编码、实现进度、安全性等问题。

然而,随着开发推进,EIP-2537的问题逐渐显现。Geth团队表示难以在预定时间内完成开发,同时存款合约已完成不使用EIP-2537的版本。EIP-2537的重要性随之下降。

后续会议中,EIP-2537的实现和测试问题持续存在。最终在第99次核心开发者会议上,决定将EIP-2537移出Berlin升级,主要原因是耗费了太多开发资源,影响了其他EIP的进展。

后续发展

在Berlin升级后的London升级中,开发者曾考虑纳入EIP-2537,但因复杂性再次被放弃。Shanghai升级同样未纳入EIP-2537,因为重点是实现PoS提款功能。

Cancun升级也未讨论EIP-2537,因为重点是支持EIP-4844。

直到2024年2月,开发者才再次讨论在Pectra升级中纳入EIP-2537。此时EIP-2537的实现已不是主要问题,仅存在部分gas消耗定价问题。

2024年12月至2025年1月,开发者会议最终确定了EIP-2537的定价模型,解决了成本问题。作为最初提案者的Matter Labs此时已基本退出讨论。

总结

EIP-2537的历程反映了以太坊治理过程的复杂性。从最初被视为核心升级内容,到多次因实现难度和复杂性被搁置,再到最终被纳入升级,EIP-2537经历了漫长的过程。这一过程折射出以太坊在技术发展、共识达成和优先级选择等方面的考量和权衡。

每次以太坊升级都有其特定主题和重点,EIP能否被纳入不仅取决于其本身的价值,也与当前以太坊的发展阶段和重点方向密切相关。EIP-2537的历程展示了以太坊治理的灵活性,以及社区在面对技术挑战时的审慎态度。