EIP-7904: Compute Gas Cost Analysis

Empirical analysis of EVM compute operation runtimes concluding that no compute gas cost needs repricing at the target throughput

Abstract

This document reports an empirical analysis of the runtime of EVM compute operations and precompiles across the major execution clients. Measurements were taken on clients that include the parallel-execution optimizations enabled by EIP-7928 (Block-Level Access Lists). Using a target throughput of 100 million gas per second (Mgas/s), the analysis finds that every compute operation and precompile examined already performs at or above that target under the current gas schedule. We therefore conclude that no compute operation or precompile requires a gas-cost increase, and this EIP recommends no changes to the gas schedule.

Motivation

Earlier revisions of this proposal were Standards Track and aimed to raise the gas cost of a set of compute operations and precompiles that empirical measurement had shown performing below the target throughput. The intent was to remove these operations as bottlenecks so that the block gas limit could be raised safely.

Since those measurements were taken, the client-side optimizations unlocked by Block-Level Access Lists (EIP-7928) — parallel disk reads, parallel transaction validation, and executionless state updates — have stabilized across all major execution clients. Re-running the benchmark and estimation pipeline against clients with these optimizations in place changes the picture entirely: the operations that previously appeared underpriced now clear the 100 Mgas/s target comfortably at their current gas costs.

Because the original motivation for repricing no longer holds, this EIP is recorded as Informational. Its purpose is to document the analysis, preserve the methodology and data for future repricing work, and state the conclusion that no compute gas cost needs to change.

Specification

This EIP specifies no changes to the Ethereum gas schedule. No opcode or precompile gas cost is modified.

The analysis examined the 18 gas parameters listed below — the opcodes and precompiles that earlier revisions had flagged as candidates for repricing. For each parameter, the table reports the current gas cost against the gas cost implied by the worst-performing client at the 100 Mgas/s target. A proposed value at or below the current value means the operation already meets the throughput target at its current price.

Sixteen of the eighteen parameters measure cheaper than the current schedule, and one (PRECOMPILE_BLAKE2F_PER_ROUND) is unchanged. The only parameter that measures higher than the current schedule is the BLAKE2F base cost, which is currently unpriced (0 gas); the measured value of 94 gas is negligible relative to typical block gas usage and does not constitute a throughput bottleneck. On this basis, no operation is underpriced to a degree that warrants a gas-cost increase.

The full proposal report, including per-client breakdowns and worst-case provenance, accompanies this EIP. A live, regenerated version of the analysis, together with the benchmark and estimation pipeline that produced it, is maintained in a public repository linked from the discussions-to thread.

Rationale

Empirical Estimation of Gas Costs

Target Throughput

A performance target of 100 million gas per second is used as the anchor for the analysis. This target reflects the throughput that the optimized clients are expected to sustain, a substantial increase over the historical baseline. An operation is considered adequately priced if its measured runtime at the current gas cost meets or exceeds this rate.

Data Collection

The estimates 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, we generate synthetic blocks that isolate and stress individual EVM operations.

Concretely, to benchmark a single operation, different blocks are created by varying the number of times the target operation is executed and by changing the parameter values to the operation. The EEST benchmark suite contains the tests used to generate these blocks.

Then, the Benchmarkoor 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. The clients measured in the latest run are Besu, Erigon, ethrex, Geth, Nethermind, and Reth.

What about dynamic costs?

Some operations have a dynamic component to their costs. For example, the KECCAK256 opcode has a gas cost that grows with the size of the input. 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 defines the cost of that operation for the entire network. This is the safer and most conservative choice, and it is the value reported in the table above.

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 relied upon for the conclusion, to ensure the reliability of the estimates.

The model-performance report breaks down the fit by operation and client, while the key model outputs are available as a CSV.

Conversion to gas costs

The measured gas costs in the table are calculated using the target performance of 100 Mgas/s. The formula used is:

gas = (anchor_rate * runtime_ms) / 1000

Where runtime_ms is the estimated runtime in milliseconds from the regression models and anchor_rate is 100 Mgas/s.

The full details of this step are in the proposal report.

Other Projects

Several initiatives have explored the real gas costs of EVM operations, providing valuable context for this analysis. 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 the relationship 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 ModExp and proposed a revised pricing scheme, consistent with the measuring approach used here.
• 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 provide context for reassessing gas costs and demonstrate broad alignment with our measurements.

Interaction with EIP-7928

EIP-7928 introduces Block-Level Access Lists, which enable parallel disk reads, parallel transaction validation, and executionless state updates through client optimizations. The latest benchmarks were run on clients that have these optimizations implemented and stabilized. This is the central reason the analysis reaches a no-repricing conclusion: with the optimizations in place, the compute operations previously identified as bottlenecks now clear the target throughput at their current gas costs.

Computational Complexity Only

This analysis intentionally focuses on computational complexity—measured as execution time on a bare CPU — while excluding network-related costs like state persistency. This ensures the findings 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 analysis’s clarity and applicability within Ethereum’s varied ecosystem.

Why No Repricing Is Recommended

The original proposal adopted a conservative strategy: prioritize gas increases only for operations that empirical data showed as underpriced, so that the base throughput of the chain could be raised without changing the costs of the majority of operations. Applying that same standard to the latest data yields no candidates for repricing — the measured runtimes of all examined operations are consistent with, or cheaper than, their current gas costs at the 100 Mgas/s target. Lowering gas costs is out of scope for this analysis, which was concerned only with identifying and removing underpriced bottlenecks. Consequently, the gas schedule is left unchanged.

Consideration of ZK-SNARK Proof Generation

This analysis focuses 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. Since the analysis recommends no gas-cost changes, it has no effect on proving times for EVM blocks.

Security Considerations

This is an Informational EIP that recommends no changes to the Ethereum protocol or gas schedule. It introduces no consensus changes and therefore no direct security implications.

The analysis itself is conservative: it relies on the worst-performing client for each operation and only draws conclusions from regression models with good statistical fits. Should client performance characteristics change in the future — for example, if an optimization is reverted or a new operation is introduced — the analysis should be re-run before relying on its conclusion that the current compute gas costs are adequate.

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Jacek Glen (@JacekGlen), Lukasz Glen (@lukasz-glen), Maria Silva (@misilva73), "EIP-7904: Compute Gas Cost Analysis [DRAFT]," Ethereum Improvement Proposals, no. 7904, February 2025. Available: https://eips.ethereum.org/EIPS/eip-7904.