This proposal raises the gas costs of 13 compute operations and precompiles performing worse than 60 million gas per second (Mgas/s). By removing these operations as bottlenecks, we can further increase the block gas limit, thus allowing for a higher throughput on the remaining operations.
Recent empirical measurements have shown that EVM operations don't have a price consistent with their computational complexity. Some operations are significantly underpriced, leading to potential bottlenecks in transaction processing. These bottlenecks limit the overall throughput of the Ethereum network, as they consume a disproportionate amount of computational resources relative to their gas cost.
By increasing the gas costs of these underpriced operations, we can alleviate these bottlenecks. This change will enable a higher block gas limit, allowing more transactions to be processed per block. The result is an overall increase in network throughput, improving the efficiency and scalability of the Ethereum blockchain.
Upon activation of this EIP, the following gas costs will be updated.
| Operation | Parameter | Current Gas | New Gas (Rounded) | Change |
|---|---|---|---|---|
| ADDMOD | constant | 8 | 8 | 0.0 |
| DIV | constant | 5 | 15 | 2.0 |
| KECCAK256 | constant | 30 | 45 | 0.5 |
| KECCAK256 | msg_size | 6 | 6 | 0.0 |
| MOD | constant | 5 | 12 | 1.4 |
| MULMOD | constant | 8 | 11 | 0.38 |
| SDIV | constant | 5 | 20 | 3.0 |
| SMOD | constant | 5 | 5 | 0 |
| Operation | Parameter | Current Gas | New Gas (Rounded) | Change |
|---|---|---|---|---|
| BLAKE2F | constant | 0 | 170 | NA |
| BLAKE2F | num_rounds | 1 | 2 | 1.0 |
| BLS12_G1ADD | constant | 375 | 643 | 0.71 |
| BLS12_G2ADD | constant | 600 | 765 | 0.27 |
| ECADD | constant | 150 | 314 | 1.09 |
| ECPAIRING | constant | 45000 | 45000 | 0.0 |
| ECPAIRING | num_pairs | 34000 | 34103 | 0.0 |
| ECRECOVER | constant | 3000 | 3000 | 0 |
| POINT_EVALUATION | constant | 50000 | 89363 | 0.79 |
The operations selected for repricing in this EIP were chosen based on their estimated million gas per second (Mgas/s) performance. For this EIP, a performance target of 60 million gas per second is chosen. With this performance target, we will be able to increase the base throughput of the chain by 3x from our current 20Mgas/s performance.
An important consideration for repricing is whether poor performance is isolated to a single client or affects multiple implementations. This is important for distinguishing between:
To separate these cases, we analyze the performance of each operation the 5 main clients (besu, erigon, geth, nethermind and reth). If the difference in performance between the worst and the second-worst client is higher than 20%, we consider the operation to be a candidate for optimization rather than repricing. All the remaining operations are candidates for repricing.
The report with the full details of this step can be accessed here.
The gas costs proposed in this EIP are based on the actual time each operation takes to run on the various execution clients. Similar to the methodology used in the Gas Cost Estimator project, synthetic blocks that isolate and stress individual EVM operations are generated. To benchmark a single operation, different blocks are created by varying the number of single operations executed and by changing the parameter values to the operation. The EEST benchmark suite contains the tests used to generate these blocks.
Then, the Nethermind's Performance Benchmarking tool is used to collect the needed metrics. This tool returns the total execution time of the block and the number of times each operation was executed. Each test block is run multiple times on each client to account for variability in execution time.
What about dynamic costs?
Some operations have a dynamic component to their costs. For example, the EXP opcode has a gas cost that grows linearly with the exponent's byte size. In these cases, the test benchmarks the operation with a range of inputs to assess how the resource costs vary with different inputs.
What about differences between client implementations?
Ultimately, we require a single cost model that is independent of the client's implementation. Although the decision may be different in a specific situation, the general rule is to take the worst client result that cannot be optimized. This means that the worst-performing client on a given operation and resource combination will define the cost of that operation for the entire network. This is the safer and most conservative choice.
To estimate the runtime of a single operation from the total execution time of the corresponding synthetic blocks, a Non-Negative Least Squares (NNLS) Linear Regression is used. This model enforces that all coefficients are non-negative, thus ensuring execution time cannot be negative. The model estimates runtime as a linear combination of:
For simple operations (i.e., without additional parameters), the model estimates: runtime = intercept + slope × operation_count
For variable operations, the model estimates: runtime = intercept + slope × operation_count + param1_coef × operation_count × param1 + param2_coef × operation_count × param2 + ...
Independent models are created for each client and operation. Only operations and parameters with good model fits (R² > 0.5 and p-value < 0.05) are included in the gas cost proposal to ensure the reliability of the estimates.
The report with the model performance by operation and client can be accessed here, while the key model outputs can be found here.
New gas costs are calculated using the same target performance of 60Mgas/s. The formula used is:
Where runtime_ms is the estimated runtime in milliseconds from the regression models.
The report with the full details of this step can be accessed here.
Several initiatives have explored the real gas costs of EVM operations, providing valuable context for this EIP. Notable examples include:
rescale factor, its costs align with this proposal, requiring no further changes. This consistency validates our measuring approach.These projects collectively affirm the need to reassess gas costs and demonstrate broad alignment with our approach.
This EIP intentionally focuses on computational complexity—measured as execution time on a bare CPU — while excluding network-related costs like state persistency. This ensures the proposed gas cost adjustments remain implementation-agnostic, applicable across diverse EVM clients regardless of their technological stack. By leveraging empirical data from multiple EVM implementations, we establish a universal, verifiable benchmark for computational effort. This focus simplifies estimation and enhances the proposal’s clarity and applicability within Ethereum’s varied ecosystem.
Raising costs for underpriced operations strengthens security by deterring abuse but may increase transaction fees and reduce throughput.
This EIP adopts a conservative strategy, prioritizing increases for operations that empirical data show as underpriced. This allows us to increase the base throughput of the chain without changing the costs of the majority of the other operations.
POINT_EVALUATION and Blob Fee Floor PriceThe proposed increase to POINT_EVALUATION gas cost (from 50,000 to 89,363) has implications for the blob fee floor price mechanism established in EIP-7918. Under EIP-7918, the blob base fee is bounded by execution costs through a reserve price of BLOB_BASE_COST * base_fee_per_gas, ensuring that blob consumers pay at least a relevant fraction of the market rate for the computational resources they impose on nodes. The computational resources imposed by blobs are the KZG proof commitments for blob transactions and, as such, the BLOB_BASE_COST was originally defined based on the cost of the POINT_EVALUATION precompile. However, for simplicity reasons, we decide not to change the BLOB_BASE_COST.
This EIP focuses on optimizing gas costs based on general computational complexity, using a bare CPU as the reference point. Therefore, it does not specifically address the unique demands of ZK-SNARK proof generation. Nevertheless, given that this EIP is only increasing the gas costs of certain operations, it will help rather than hinder proving times for EVM blocks.
This is a backwards-incompatible gas repricing that requires a scheduled network upgrade.
Developers and node operators MUST update gas estimation handling to accommodate the new costs. Specifically:
eth_estimateGas MUST be updated to ensure that they correctly account for the updated gas parameters. Failure to do so could result in underestimating gas, leading to failed transactions.eth_estimateGas MUST incorporate the updated formula for gas calculation with the new state access cost values.Further research might be required to ensure that contracts that use hard coded limits are not broken.
Changing the cost of compute operations could impact the usability of certain applications. More analysis is needed to understand the potential effects on various dApps and user behaviors.
Copyright and related rights waived via CC0.