Compute Gas Cost Increase

Abstract

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.

Motivation

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.

Specification

Upon activation of this EIP, the following gas costs will be updated.

Opcodes

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

Precompiles

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

Rationale

Empirical Estimation of Gas Costs

Selecting which Operations to Reprice

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:

• Operations that genuinely need repricing (multiple clients struggle)
• Operations where a specific client needs optimization (only one client struggles)

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.

Data Collection

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.

Runtime Estimation

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:

• Constant term (intercept): Base overhead for executing the test, which includes setup and teardown time
• Operation count (slope): Number of times the operation is executed in the test. This parameter is the one that allows us to estimate the per-operation runtime.
• Operation-specific parameters: Variables like number of rounds, message size, or number of pairs

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.

Conversion to gas costs

New gas costs are calculated using the same target performance of 60Mgas/s. The formula used is:

new_gas = (anchor_rate * runtime_ms) / 1000

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.

Other Projects

Several initiatives have explored the real gas costs of EVM operations, providing valuable context for this EIP. Notable examples include:

• The Gas Cost Estimator project did a similar empirical analysis. It conducted extensive testing across seven widely-used EVM implementations to measure the actual computational effort required by various opcodes and operations. Conducted in a controlled environment to eliminate external variables, the tests produced accurate and reproducible results. The findings highlight misalignments between the current gas cost schedule and the real-world computational complexity of EVM operations.
• EIP-7883 - ModExp Gas Cost Increase: This EIP specifically analyzed the ModExp and proposed a revised pricing scheme. When adjusted with our rescale factor, its costs align with this proposal, requiring no further changes. This consistency validates our measuring approach.
• Nethermind's Gas Benchmarks: This project takes a different approach to measuring gas costs. It uses standalone clients rather than isolated EVM implementations. Despite the methodological difference, its results mirror those of the Gas Cost Estimator, reinforcing our conclusions.
• EVM Memory Analysis by @raxhvl: This project focuses on memory-related costs, providing valuable insights into the memory access and expansion costs.

These projects collectively affirm the need to reassess gas costs and demonstrate broad alignment with our approach.

Computational Complexity Only

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.

Impact of Gas Costs Changes

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 Price

The 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.

Consideration of ZK-SNARK Proof Generation

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.

Backwards Compatibility

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:

• Wallets: Wallets using 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.
• Node Software: RPC methods such as eth_estimateGas MUST incorporate the updated formula for gas calculation with the new state access cost values.
• Contracts with Hardcoded Gas Limits: Contracts that specify hardcoded gas limits for subcalls (e.g., using call(gas, ...)) may face issues if the new gas costs exceed these limits. In these cases, developers MUST review and potentially update these contracts to ensure they function as intended post-upgrade.

Further research might be required to ensure that contracts that use hard coded limits are not broken.

Security Considerations

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

Copyright and related rights waived via CC0.