以太坊治理观察:EIP-2537预汇编历程
作者:shew
概述
EIP-2537 是最新的 Pectra 分叉升级中被确定添加的 EVM 预汇编指令。该指令为 EVM 增加了 BLS12-381 曲线的多种计算功能,比如曲线域上的配对计算等。
EIP-2573 最初在 2020 年被提出,直到 2025 年才被确认加入以太坊升级。本文主要介绍 EIP-2537 的治理历史,探究为什么经过 5 年才会将此提案纳入升级。
提案背景
2017 年 1 月份,Vitalik Buterin 在 Exploring Elliptic Curve Pairings 第一次介绍了配对算法以及
alt_bn128
曲线。随后在 2017 年 2 月,Vitalik Buterin 和 Christian Reitwiessner 提出了 EIP-196 和 EIP-197 提案,提案内容是向 EVM 增加
alt_bn128
曲线计算支持。
在 2017 年 10 月份的 Byzantium 升级内,正式纳入
alt_bn128
曲线。简单来说,
alt_bn128
第一次实现了 EVM 内部的曲线域配对计算,这使得 ZK-Snarks 证明验证可以在 EVM 内完成。
但随着密码学发展,2017 年 11 月,zcash 开发团队在 BLS12-381: New zk-SNARK Elliptic Curve Construction 第一次给出了
BLS12-381
曲线。相比于
alt_bn128
而言,
BLS12-381
具有更高的安全性、更好的性能。相当多的区块链协议在此后都使用了
BLS12-381
曲线而废弃了
alt_bn128
曲线。
在 2018 年 5 月,Justin Drake 在 ethresear 内发布了 Pragmatic signature aggregation with BLS 一文,指出在以太坊未来的 PoS 和分片升级都可以使用基于
BLS12-381
曲线的 BLS 多签算法。当时,以太坊研究者希望使用 EIP-1011 解决共识层问题,但是 EIP-1011 方案最多可以容纳 900 个验证者,因此为每个验证者设定了 1500 ETH 的巨大质押规模。随着 BLS 多签方案的提出,EIP-1011 退出了历史舞台。事实证明,后来的 ETH2 升级也最终使用了
BLS12-381
曲线。
伴随着 ETH2 开发,ETH2 所使用的
BLS12-381
引入 ETH 执行层开始被呼吁。在 2020 年 2 月,一些研究员提出了 EIP-2537 ,并且希望该提案可以在 ETH2 测试网一起接受测试。EIP-2537 作者 Alex Stokes 在 What eth2 needs from eth1 over the next six months 文章内呼吁在 Berlin 硬分叉内纳入 EIP-2537。
有趣的是,EIP-2537 的作者也是 Matter Labs 的联合创始人,而 Matter Labs 最为著名的产品就是 ZKSync
Berlin 动荡
我们在介绍后续内容前,需要首先介绍 EIP-1962 。EIP-1962 是 Matter Labs 在 2019 年 4 月提出的第一个关于椭圆曲线域配对预汇编的提案,该提案支持了三条曲线,分别是:
- BLS12
- BN
- MNT4/6 (Ate pairing)
该 EIP 准备一次性增加 10 个预汇编指令以处理不同的曲线。但是该提案诞生后,相当多的开发者质疑提案过于复杂以至于开发者很难实现。同时由于 EIP1962 高度通用化,对于智能合约工程师而言,调用也是十分麻烦的。当然,作为 EIP-1962 的提出者,Matter Labs 实质上已经完成了椭圆曲线算法的 开发工作 ,并提供了 Rust / Go / C++ 参考实现。
为了解决 EIP-1962 的问题,Matter Labs 于 2020 年 2 月提出了多个 EIP 拆分 EIP-1962,这些 EIP 都部分继承了 EIP-1962 的接口。这些 EIP 包括:
- EIP-2537 提供 BLS12-381 的支持
- EIP-2539 提供 BLS12-377 的支持
- PR#2541 提供 BLS12-377 (Zexe curve) 支持,但注意该提案最终没有获得 EIP 编号,无法在 EIP 文档官网找到
这几个 EIP 内部,最重要的就是 EIP-2537,因为共识层也使用了 BLS12-381 曲线。包括 EIP-1962 和 EIP-2537 的核心目的都是在主网内实现共识层 BLS 签名的验证。在当时,ETH2 正在开发共识层的存款合约设计。在存款合约最初设计时,由于执行层内不包含 BLS 验证算法,所以存款合约不会验证签名,具体的 BLS 签名会在用户存款后由共识层验证,如果发现不正确(对于新的验证者),存款将失败,用户存入的 ETH 将会丢失。
在此背景下,核心开发者希望引入 BLS12-381 预汇编在存款合约内实现签名验证,避免用户存入 ETH2 资金的可能损失。这也是当时大量开发者关注 EIP-1962 和 EIP-2537 的原因。
当 EIP-2537 刚刚提出时,Vitalik 就立即发现了 EIP 存在的 一系列问题 :
这些质疑只要集中在 EIP 文档内容方面,随后 EIP 作者对此进行了回复和讨论。随后,在 2020 年 3 月 6 日,在 Ethereum Core Devs Meeting #82 会议中,以太坊核心开发者对 EIP-2537 进行讨论。在这次会议中,Vitalik 认为 EIP-2537 等 EIP 对于递归 SNARK 证明非常有效,而且从长远来看不会使得以太坊受损。同时,会议还确认了 EIP-2537 的优先地位,所有客户端都同意尽快实现 EIP-2537 并计划在 Berlin 升级前完成所有开发。
随后,EIP-2537 成为了优先级较高的任务。2020 年 3 月 20 日,在 Ethereum Core Devs Meeting #83 中,EIP-2537 依旧被首先讨论的提案。这次会议确认了 EIP-2537 替代 EIP-1962 成为核心 BLS 提案并成为 Berlin 升级的预选 EIP 名单(即 Eligibility for Inclusion (EFI))。
在 2020 年 4 月的 Ethereum Core Devs Meeting #84 会议内,会议正式将 EIP-2537 纳入 Berlin 硬分叉升级,并且确定了 4 月份实现、5 - 6 月份进行测试的 Berlin 升级时间线。值得注意的,在此次讨论中,EIP-2537 被列为最高优先级事项。
随后,EIP-2537 进入了大量的开发和测试阶段,在后续近 20 次核心开发者会议中,每一次会议基本都涉及了 EIP-2537 的讨论。接下来,我们可以看看每一次会议都讨论了哪些关于 EIP-2537 的问题。
在 Ethereum Core Devs Meeting #85 内,Danno 和 Axic 对 EIP-2537 的 ABI 编码问题进行了讨论。随后,核心开发者同步了当前的实现情况,其中由于 EIP-2537 的提案人 Matter Labs 之前已基本完成了 Rust 版本的实现,所以 Besu 客户端声明已基本实现 EIP-2537 的功能,但是 Geth 方面表示目前没有人在为 EIP-2537 的实现工作。
在 Ethereum Core Devs Meeting #86 内,不同的以太坊节点实现再次同步了 EIP-2537 的实现情况,其中 Geth 表示完成了部分工作,但还有大量工作等待完成。
在 Ethereum Core Devs Meeting #87 内,此次开发者会议最核心的内容就是 EIP-2537 的实现问题。Geth 开发者表示目前存在一个 16000 行的 PR 实现 EIP-2537,但是 Geth 开发者无法确定 PR 是否安全且有效的实现了 EIP-2537,所以开发者只能通过最为简单粗暴的模糊测试判断代码的情况。
Geth 开发者说:"So my gut reaction is that there is no chance that Geth will be ready with the BLS curve operations for mainnet launch in July.",即 Geth 大概率无法在 Berlin 预定时间前完成 EIP-2537 的相关开发。
Hudson Jameson 提议为 Geth 寻找密码学工程师协助 PR 审查,并且提议使用测试网测试 EIP-2537 的实现安全性。因为此时 ETH2 开发团队也在实现 BLS 签名验证,所以刚好 ETH2 团队可以参与测试。
在这里,我们需要补充一个背景知识,就是 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 升级接纳已成定局。
在 Ethereum Core Devs Meeting #88 内,Geth 开发者发现 EIP-2537 的实现 PR 存在一系列问题,开发者表示还需要进一步测试和修复。此时 Geth 系统内存在两个 EIP-2537 的实现,其中一个实现包含汇编优化,而另一个实现则完全由 go 语言编写,有开发者提议直接使用 go 语言编写版本来降低代码审查的难度。
在 Ethereum Core Devs Meeting #89 内,更加严重的问题发生了,YOLO 测试出现了一些问题,开发者怀疑是 BLS 签名导致的问题,但 EIP2537 开发者对此进行了反驳,认为测试网问题并不是 BLS 签名导致。对于 EIP-2537 的好消息是,基于 EIP-2537 的存款合约基本开发完成,该合约正在等待合约审计。
在 Ethereum Core Devs Meeting #90 内,这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然,这次会议另一个有趣的论点是客户端多样性问题,在此次会议中,开发者主要讨论了 Geth 占据主导地位的情况,并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是,在 #91 会议中,有开发者提议使用模块化方案降低开发成本来增加客户端多样性。假如读者对于以太坊客户端多样性感兴趣,可以去阅读了这两次会议的记录。
在 Ethereum Core Devs Meeting #92 内,2537 仍旧被确认为 Berlin 升级所需要的 EIP。
在 Ethereum Core Devs Meeting #96 内,基于 Celo 已经将 EIP-2537 和 EIP-2539 同时纳入了其网络硬分叉升级中,所以 Matter Labs 希望将与 EIP-2537 同时提出的 EIP-2539 也放到 YOLO v2 测试网测试并且进入 Berlin 升级。但是 Geth 开发者反对,认为当前的 EIP-2537 仍没有在 Geth 内部经过完整测试。最终会议决定不在 Berlin 升级内增加 2696,留待未来讨论。
在 Ethereum Core Devs Meeting #99 内,此次会议决定将 EIP-2537 移出 YOLO v3 测试网和 Berlin 升级,最核心的原因是 EIP-2537 浪费了核心开发者太多时间,导致 Berlin 升级内其他 EIP 开发受阻。次要因素是以太坊基金会提出了 EVM384 作为 EIP-2537 替代,EVM 384 提供了更加通用的椭圆曲线计算方案。但是核心开发者在会议讨论中表达了对安全问题的担心。
上述内容就是 EIP-2537 的早期历程,我们可以看到 EIP-2537 早期是 Berlin 升级中最重要的 EIP 之一,但是由于实现问题最终被废弃。最后,在 2021 年 4 月,以太坊完成了 Berlin 升级,升级中核心包含的 EIP-2565 等实际实现都并不复杂,看上去 Berlin 升级似乎略显单薄,这是因为最核心复杂的 EIP-2537 被踢出了 Berlin 升级。
后续发展
众所周知,以太坊每一次升级都会有一个核心提案,比如 Berlin 升级后的 London 升级引入以太坊历史上最重要的手续费提案 EIP-1559。对于曾经作为核心提案的 EIP-2537 而言,后续的历次升级都很难将这个提案纳入。
在 Berlin 后的 London 升级中,开发者在 issues#369 曾考虑在 London 升级中增加 EIP-2537。在 Ethereum Core Devs Meeting #109 中,开发者同步了当前 EIP-2537 的开发情况,此时由于使用其他库对 EIP-2537 进行实现,所以引入了一个关于 EIP-2537 使用 gas 的讨论。同时有开发者提出使用 EVM384 替换 EIP-2537。但在 2021 年 4 月的 Ethereum Core Devs Meeting #111 内,EIP-2537 因为复杂性被移出了 London 升级。核心复杂性在于 EIP-2537 标准实现更换了依赖库,这导致 gas 定价可能出现变化,不同客户端实现需要花费相当时间重新评估 gas 消耗。
在 2021 年 6 月, issues#343 内正式提出了将 EIP-2537 纳入 Shanghai 升级。但是需要注意 London 升级后,实际上 Pairs 升级或者被称为 The Merge 占据了开发者大量时间,执行层开发者需要编写大量代码以实现 PoS 升级。2022 年 9 月,Pairs 升级完成,执行层开发者终于有机会继续讨论 Shanghai 升级的一些目标。
在 2022 年 11 月, Ethereum Core Devs Meeting #150 内短暂讨论了 EIP-2537 的是否纳入 Shanghai 升级,但开发者认为 EIP-2537 需要推迟,Shanghai 升级的核心是支持 PoS 提款。最终,EIP-2537 没有被纳入以实现提款功能为核心的 Shanghai 升级内部。
更加凄惨的是 Cancun 升级一直没有对 EIP-2537 进行讨论,因为 Cancun 升级的核心是执行层节点支持 EIP-4844。EIP-4844 为以太坊二层提供了 Blob 以方便二层使用以太坊作为数据可用层。
终于,在 2024 年 2 月的 Ethereum Core Devs Meeting #181 内,开发者讨论在 Pectra 升级内纳入 EIP-2537,并且此时开发者认为 EIP-2537 的实现已经不是问题,只有部分问题在 Gas 消耗定价方面。
在 2024 年 12 月 19 日的 Ethereum Core Devs Meeting #202 内,Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的,作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的,2025 年 1 月的 Ethereum Core Devs Meeting #203 内,开发者讨论包括重新定价 BLS 预编译,Geth 开发人员 Jared Wasinger 建议将 gas 成本提高 20%,并得到 Besu 团队基准测试的支持。
总结
日期 | 事件 |
---|---|
2020 年 2 月 | 拆分 EIP-1962 正式提出 EIP-2537 |
2020 年 4 月 - 2020 年 10 月 | 开发者会议多次讨论 EIP-2537 实现问题,并最终因为无法实现而被 Berlin 升级放弃 |
2021 年 3 月 - 2021 年 4 月 | 开发者会议讨论 EIP-2537 gas 成本问题,最终因为复杂性被 London 升级放弃 |
2022 年 11 月 | 开发者会议讨论是否纳入 Shanghai 升级,无果 |
2024 年 2 月 | 开发者认为 EIP-2537 没有任何实现问题,仍存在部分 gas 成本问题,认为可以纳入 Pectra 升级 |
2024 年 12 月 - 2025 年 1 月 | 开发者会议讨论具体的成本计算模型,正式解决 EIP-2537 成本问题 |
可见,EIP 是否被纳入以太坊升级,“当然要靠自我奋斗,但是也要考虑到历史的行程”。每一次以太坊升级都会有自己的主题,正如 EIP-2537 一度成为 Berlin 升级最重要的 EIP,但是因为其实现难度和复杂性被废弃。随后的以太坊进入了 PoS 的历史进程,复杂的纯执行层 EIP 不被受到重视,而大量与 PoS 相关的执行 EIP 被视为核心升级目标,这导致长时间内 EIP-2537 不被接受。
Bye Bye Europe: As Binance’s Official Stopped Its USDT Trading in the EEA Region
The post Bye Bye Europe: As Binance’s Official Stopped Its USDT Trading in the EEA Region appeared ...
Best Presales to Buy During Current Market Instability
With Donald Trump’s new reciprocal tariffs set to take effect from tomorrow (April 2), the stage is ...
Arthur Hayes Predicts $250,000 Bitcoin As Fed Caves To QE Pressure
In a new essay published on March 31, former BitMEX CEO Arthur Hayes lays out a case for a $250,000 ...