--- eip: XXXX title: Raise gas costs of hash functions description: Raise the gas costs of hash function opcodes and precompiles, to match prover expenses in ZK-EVMs author: Vitalik Buterin (@vbuterin) discussions-to: YYYY status: Draft type: Standards Track category: Core created: 2024-ZZ-WW --- ## Abstract Raise the gas costs of opcodes and precompiles that involve hash functions. ## Motivation Gas costs for hash function opcodes and precompiles were based on the time that it takes to execute them on a regular CPU. Since then, however, there has emerged another equally important execution substrate that the EVM is executed on: zero knowledge proof (ZK-SNARK) systems. By that standard, these opcodes and precompiles are _very_ underpriced. Blocks that are heavy with hash function executions take much longer to ZK-SNARK prove than average blocks. Today, many layer-2 protocols are using workarounds such as arbitrary limits and centralized sequencer-enforced rules to deal with this issue. These workarounds are often poorly designed and lead to unneeded security and centralization concerns. Additionally, there is a design goal of eventually using ZK-SNARKs to prove the correctness of layer-1 Ethereum blocks. To do this, we need to establish very tight bounds on how long it takes to generate a proof. Today, the difference between average-case proving time and worst-case proving time is large, and hash function executions are the largest reason why. Verkle trees solve the part of this problem that comes from Keccak hashing in the Merkle Patricia tree. Today, the theoretical worst case is a block with `30000000 / 2600 = 11538` account accesses (minus a small percent for EVM overhead), where proving each access would require proving `24000` bytes of code, plus a roughly `512 * log(500m) / log(16) = 3712` byte Merkle-Patricia proof: roughly `305 MB` of hashing spread between `83650` hash calls. Verkle trees solve this. However, using opcodes a block can still contain roughly: | Hash | Cost per word | Maximum bytes from 30 million gas | | - | - | - | | `KECCAK` (opcode) | 6 | 160 million | | `SHA256` (precompile) | 12 | 80 million | | `RIPEMD` (precompile) | 120 | 8 million | | `BLAKE2` (precompile) | 3 (12 per 128 bytes) | 320 million | | `LOG*` (hashing data) | 256 (8 per byte) | 3.75 million | These hashes have been optimized for rapid CPU computation, so CPUs can compute them quickly: for example, this author's laptop can compute a 160-million byte keccak in less than half a second. In ZK-SNARKs, however, these operations are _very_ time-consuming and inefficient. ## Specification | Parameter | Previous value | New value | | - | - | - | | `KECCAK_BASE_COST` | 30 | 300 | | `KECCAK_WORD_COST` | 6 | 60 | | `KECCAK_BASE_COST` | 60 | 300 | | `KECCAK_WORD_COST` | 12 | 60 | | `RIPEMD_BASE_COST` | 600 | 600 | | `RIPEMD_WORD_COST` | 120 | 120 | | `BLAKE2_GFROUND` | 1 | 10 | | `GLOGBYTE` | 8 | 10 | Change the above parameters to their new values. ## Rationale Benchmarking TBD A possible alternative to this approach is to implement either [multidimensional pricing](https://ethresear.ch/t/multidimensional-eip-1559/11651), or "total gas cost floors" similar to [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623) for calldata. However, this approach is much harder to implement for in-EVM gas costs such as hashes than it is for calldata and blobs, because EVM gas limits are set not just by users, for whom new transaction types can easily be added, but also by contracts making sub-calls to other contracts. ## Backwards Compatibility Analysis TBD For most applications, a reasonable upper bound is that data that is getting hashed is getting brought in as calldata. If the hashing being done is binary Merkle proof verification, every 32 bytes of data corresponds to a 64-byte (2-word) hash. A word of costs 512 gas. Under the new costs, the hashing per word in that situation would be `300 + 60 * 2 = 420` gas. Hence, this will increase gas consumption for that component of the application by less than 2x. Concretely, a length-20 Keccak-based binary Merkle proof gas cost would increase from `(512 + 42) * 20 = 11080` to `(512 + 420) * 20 = 18640`. This is a small increase, especially taking into account other costs associated with such an application. ## Security Considerations As the maximum possible block size is reduced, no security concerns were raised. ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md).