EIP-7667: 提高哈希函数的gas成本
提高哈希函数操作码和预编译的gas成本，以匹配 ZK-EVM 中的 prover 费用
| Authors | Vitalik Buterin (@vbuterin) |
|---|---|
| Created | 2024-03-31 |
| Discussion Link | https://ethereum-magicians.org/t/eip-7562-raise-gas-costs-of-hash-functions/19446 |
摘要
提高涉及哈希函数的操作码和预编译的 gas 成本。
动机
哈希函数操作码和预编译的 Gas 成本最初是根据在常规 CPU 上执行它们所需的时间来设定的。 然而，自那时以来，EVM 执行的另一个同样重要的执行基质已经出现：零知识证明 (ZK-SNARK) 系统。 按照这个标准，相对于其他操作，这些操作码和预编译的定价_非常_低。
与平均区块相比，哈希函数执行量大的区块需要更长的时间来进行 ZK-SNARK 证明。 如今，许多 layer-2 协议都在使用一些变通方法，例如由中心化排序器强制执行的任意限制和规则来解决此问题。 这些变通方法通常设计得很差，并导致不必要的安全和中心化问题。
此外，还有一个设计目标是最终使用 ZK-SNARK 来证明 layer-1 Ethereum 区块的正确性。 为此，我们需要对生成 Ethereum 执行区块正确性的 ZK-SNARK 证明所需的时间建立非常严格的界限。 如今，平均情况证明时间和最坏情况证明时间之间的差异很大，而哈希函数执行是造成这种差异的最大原因。
Verkle 树解决了 Merkle Patricia 树中 Keccak 哈希造成的部分问题。 如今，理论上的最坏情况是具有 30000000 / 2600 = 11538 个帐户访问的区块（减去 EVM 开销的一小部分），其中证明每次访问将需要证明 24000 字节的代码，加上大约 512 * log(500m) / log(16) = 3712 字节的 Merkle-Patricia 证明：大约 305 MB 的哈希分散在 83650 个哈希调用中。 Verkle 树解决了这个问题。 但是，使用操作码，区块执行仍然可能需要大约以下数量的哈希：
| 哈希 | 每个字的成本 | 来自 3000 万 gas 的最大字节数 |
|---|---|---|
KECCAK (操作码) |
6 | 1.6 亿 |
SHA256 (预编译) |
12 | 8000 万 |
RIPEMD (预编译) |
120 | 800 万 |
BLAKE2 (预编译) |
3 (每 128 字节 12) | 3.2 亿 |
LOG* (哈希数据) |
256 (每字节 8) | 375 万 |
这些哈希函数已经过优化，可以进行快速 CPU 计算，因此 CPU 可以快速计算它们：例如，作者的笔记本电脑可以在不到半秒的时间内计算出 1.6 亿字节的 keccak。 然而，在 ZK-SNARK 中，这些操作_非常_耗时且效率低下。 这在基于小域的新型证明系统中得到了缓解，但哈希的定价仍然过低。
规范
| 参数 | 之前的值 | 新值 |
|---|---|---|
KECCAK_BASE_COST |
30 | 300 |
KECCAK_WORD_COST |
6 | 60 |
SHA256_BASE_COST |
60 | 300 |
SHA256_WORD_COST |
12 | 60 |
RIPEMD_BASE_COST |
600 | 600 |
RIPEMD_WORD_COST |
120 | 120 |
BLAKE2_GFROUND |
1 | 10 |
GLOGBYTE |
8 | 10 |
将以上参数更改为新值。
理由
以上增加了所有操作码和预编译的 gas 成本，这些操作码和预编译可用于在 EVM 中需要大量的哈希。 所有哈希成本都增加到每次哈希 300 gas 加上每个字 60 gas（或者如果它们已经高于此值，则保持不变）。 ‘” 这种方法的一个可能的替代方案是实现多维 gas 定价（即，一个单独的浮动 basefee 以及每个区块的哈希目标和限制），或者类似于 EIP-7623 对 calldata 所做的“总 gas 成本下限”。 然而，对于 EVM 内的 gas 成本（例如哈希），这种方法比对于 calldata 和 blobs 更难实现，因为 EVM gas 限制不仅由用户设置，而且用户可以轻松添加指定新要求的限制、max-basefees 和优先级费用的新交易类型，而且还由对其他合约进行子调用的合约设置。
向后兼容性
对于大多数应用程序来说，一个合理的上限是 EVM 中被哈希的数据正在作为 calldata 引入。 如果正在完成的哈希是二进制 Merkle 证明验证，则每 32 字节的数据对应于 64 字节（2 字）的哈希。 一个字的成本为 512 gas。 在新成本下，这种情况下的每个字的哈希将花费 300 + 60 * 2 = 420 gas。 因此，这将使应用程序该组件的 gas 消耗量增加不到 2 倍。
具体来说，基于 Keccak 的长度为 20 的二进制 Merkle 证明 gas 成本将从 (512 + 42) * 20 = 11080 增加到 (512 + 420) * 20 = 18640。 这是一个很小的增加，尤其是考虑到与此类应用程序相关的其他成本。
安全考虑
由于没有引入或降低任何新操作的成本，因此没有提出任何安全问题。
版权
放弃通过 CC0 声明的版权和相关权利。
Citation
Please cite this document as:
Vitalik Buterin (@vbuterin), "EIP-7667: 提高哈希函数的gas成本 [DRAFT]," Ethereum Improvement Proposals, no. 7667, March 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7667.