EIP-7266: 移除 BLAKE2 压缩预编译
通过更改预编译行为以导致异常中止来移除 blake2f (0x09) 预编译
| Authors | Pascal Caversaccio (@pcaversaccio) |
|---|---|
| Created | 2023-07-03 |
| Discussion Link | https://ethereum-magicians.org/t/discussion-removal-of-ripemd-160-and-blake2f-precompiles/14857 |
摘要
本 EIP 通过更改预编译行为以导致异常中止来移除 blake2f (0x09) 预编译。
动机
EIP-152 从未在实际用例中获得回报。 这一事实清楚地反映在地址 0x09 被调用的次数中（数据来自创建此 EIP 的日期）：
- 最近一次调用发生在 2022 年 10 月 6 日。
- 自从 2019 年 12 月 7 日作为伊斯坦布尔网络升级的一部分上线（区块号 9,069,000）以来，
0x09仅被调用了 22,131 次。
EIP-152 失败的原因之一是在包含之前没有验证设想的用例。
规范
本文档中使用的关键词“必须 (MUST)”，“禁止 (MUST NOT)”，“需要 (REQUIRED)”，“应该 (SHALL)”，“不应该 (SHALL NOT)”，“应当 (SHOULD)”，“不应当 (SHOULD NOT)”，“推荐 (RECOMMENDED)”，“不推荐 (NOT RECOMMENDED)”，“可以 (MAY)”和“可选 (OPTIONAL)”按照 RFC 2119 和 RFC 8174 中的描述进行解释。
所有对 blake2f 预编译地址 0x09 的 CALL、CALLCODE、DELEGATECALL 和 STATICCALL 调用必须导致异常中止。
理由
EVM 应该针对简单性和面向未来进行优化。 最初的黄皮书指出：这些是所谓的“预编译”合约，旨在作为一种初步的架构，以后可能会成为原生扩展。 考虑到在过去的 3.5 年中没有实现任何用例，我们可以得出结论，预编译 blake2f (0x09) 永远不会过渡到原生 opcode。 从这个意义上说，预编译 blake2f (0x09) 是一个过时的包袱，没有实际应用的吸引力，因此应该删除。 这种删除将简化 EVM，使其仅包含具有实际用例的明确指令。 最终，预编译 blake2f (0x09) 可以安全地用作 EVM 函数逐步淘汰和删除的测试运行。
向后兼容性
此 EIP 需要进行硬分叉，因为它修改了共识规则。 请注意，受此更改影响的应用程序很少，并且 6-12 个月的提前期可以认为是足够的。
安全注意事项
此项更改没有引入已知的额外安全注意事项。
版权
通过 CC0 放弃版权及相关权利。
Citation
Please cite this document as:
Pascal Caversaccio (@pcaversaccio), "EIP-7266: 移除 BLAKE2 压缩预编译 [DRAFT]," Ethereum Improvement Proposals, no. 7266, July 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7266.