EIP-7904 - General Repricing

Abstract

This proposal revises the gas cost schedule for opcodes, precompiles, memory expansion, and data access, prioritizing computational complexity, while excluding network-related costs such as state persistence. The adjustments aim to enhance gas cost accuracy and rebalance the cost structure.

Motivation

Gas costs compromise of two components: network (social) cost and computation cost. Network cost reflects the blockchain’s effort to maintain state, including adding transactions, storage, logs, calldata, and receipts, while computation cost represents the non-durable processing effort of smart contracts.

The importance of adequate gas costs arises from the nature of computations done on the Ethereum blockchain, and has been discussed in many research papers. Moreover it is paramount from the perspective of security and network stability. Gas cost is a natural deterrent from abusing the network's capacity. On the other hand, the network needs to be affordable and efficient to use. Adequate gas cost strikes a balance between these two requirements.

While several EIPs (e.g., EIP-160, EIP-1884) have refined network-related gas costs, computational costs have remained largely static since Ethereum’s inception. With multiple EVM implementations now stable and optimized, alongside advanced tools, we can assess how well the current gas schedule aligns with hardware workload profiles.

Measurements and estimations depend on various factors, including hardware, OS, virtualization, compiler, memory management, EVM, and more. The execution of a single opcode impacts or depends on caching, block preparation, block finalization, garbage collectors, code analysis, parsing etc. Consequently, the individual computational cost is a sum of multiple factors spread over the software stack. Despite this complexity, examinations have shown that the computational cost outline is consistent across EVM implementations, technology stacks, and contexts.

For instance, experimental data might reveal that the computational effort required to execute one opcode is consistently twice that of another opcode across most EVM implementations. In such cases, the gas cost ratio between these opcodes should be set at 2:1 to reflect their relative computational complexity. This approach relies on empirical measurements rather than theoretical assumptions. The gas cost schedule should, therefore, accurately reflect computational complexity.

Observable Outliers

The current gas cost schedule differs in many places from the experimentally determined computational complexity. Many significant outliers have been identified, indicating a need for rebalancing. Many others are reasonable candidates to be rebalanced. The unbalanced gas cost schedule can: expose a risk to the network, open an attack vector, lead to false optimization, and break the principle that gas is the abstract unit of transaction execution effort.

Relative Nature of Gas Costs

The gas cost schedule is inherently relative, adjustable as long as proportions hold. A substantial reduction in the gas costs contained in this proposal has two significant effects: it increases blockchain throughput in terms of transactions per block, and it increases the proportional weight of the network storage costs.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Parameters

Cost formulas

Opcode Costs

Precompiles Costs

The calculated and rescaled cost of 0x06 (ECADD) is higher than the current cost. Still this cost is left unchanged to maintain compatibility with existing contracts.

The remaining precompiles remains unchanged.

Additionally, all precompiles benefit from the lowered cost of *CALL opcodes (see below).

Indirect changes

The formula for these opcodes remains the same, but the total cost calculated is affected by changes to some components.

Rationale

Gas Cost Estimator Project

The Gas Cost Estimator project serves as the empirical foundation for this EIP. This project 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. By recalibrating gas costs based on these measurements, this EIP seeks to align pricing with computational reality, thereby improving Ethereum’s performance and resilience.

This EIP is based on the radical proposal from the Gas Cost Estimator project. This means that all estimates have been additionally rescaled so that basic arithmetic operations cost just 1 gas unit. The rescale factor used is 0.217391304 as defined in the Gas Cost Estimator project. This factor should be used when comparing this proposals to other EIPs or projects.

Other Projects

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

• 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. Our proposal incorporates these findings in the memory_expansion_cost formula.

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

Fractional Gas Price

An alternative considered during this EIP’s development was fractional gas pricing, which would enable more granular cost assignments based on computational effort.

• Pros: This could offer a more precise reflection of resource use, enhancing fairness and efficiency — especially when gas costs drop below 1 (e.g., approaching 0 for simple operations under the radical rescaling).
• Cons: It poses significant practical challenges, requiring extensive modifications to gasometering infrastructure. The potential benefits do not outweigh these implementation hurdles.

Given these trade-offs, we opted against fractional pricing in favor of a simpler, more feasible recalibration.

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. Unlike network costs, which fluctuate with factors like long-term state persistency or blockchain size, computational complexity is directly quantifiable. This focus simplifies estimation and enhances the proposal’s clarity and applicability within Ethereum’s varied ecosystem.

Impact of Gas Costs Changes

Note that, it is safer to decrease because of Backwards Compatibility issues related to gas limits and hard-coded gas limits (see below). Deciding whether to increase or decrease gas costs for specific operations requires balancing efficiency and security.

• Decreasing Gas Costs: Lowering costs for overpriced operations could improve network throughput by enabling more transactions per block, enhancing Ethereum’s scalability. However, if costs are reduced too aggressively, it risks underpricing computationally heavy tasks, potentially exposing the network to DoS attacks.
• Increasing Gas Costs: 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 decreases for operations that empirical data show as overpriced, while ensuring no reductions compromise security. This approach aims to optimize efficiency without introducing new vulnerabilities.

Memory expansion cost

This proposal introduces a simplified memory_expansion_cost formula. The current formula combines a constant cost per word and an additional quadratic cost. The latter is added to prevent attacks exploiting excessive memory usage. Our findings, supported by related projects, indicate the constant cost per word is negligible and already accounted for in opcodes that expand memory. Thus, the revised formula retains only the quadratic cost, preserving security while reducing overall gas costs. As a result, the first 22 words of memory incur no additional cost, as the quadratic penalty begins beyond this threshold.

Estimated Maximum Memory Allocation

The tables below compare the maximum memory allocations under the current and proposed gas schedules, showed for different block gas limits.

Single Opcode Memory Allocation: This table shows the estimated maximum memory allocation achievable with a single opcode:

Multiple Calls Memory Allocation: This table estimates the maximum memory allocation achievable with a transaction that repeatedly makes subcalls in a loop, until block gas limit is reached. Each subcall allocates memory in the most effective way balancing call costs and memory expansion costs. For the current gas schedule, it is 278 words per call, and for the proposed gas schedule, it is 93 words per call.

Experiments with stack depth and recursive calls showed that the maximal total allocated memory at a single moment increases less than 10% comparing Current and Proposed Gas Schedule.

Consideration of ZK-SNARK Proof Generation (EIP-7667)

EIP-7667 proposes an alternative framework for measuring resource consumption, emphasizing the demands of generating ZK-SNARK proofs — an area of growing importance for Ethereum. This includes hashing opcodes and precompiles, which are computationally intensive in ZK-SNARK contexts. Two motivations drive EIP-7667: first, the long-term vision of a ZK-SNARKed Ethereum Layer 1 (L1), where such operations will be critical; second, the immediate challenges faced by ZK-based Layer 2 (L2) solutions, which often limit hashing operations to manage costs. In contrast, this EIP uses a bare CPU as its reference point, focusing on general computational complexity rather than ZK-specific needs. The proposed changes are not expected to significantly alter the average case for ZK-based L2s but may impact worst-case scenarios. While acknowledging the relevance of ZK-SNARKs, this EIP argues that their systemic challenges require distinct solutions beyond the scope of this proposal. There are efforts and progress in the space, still the vision of a ZK-SNARKed L1 seems to be distant enough, to justify the focus on optimizing the current setup for broader network benefits.

Consideration of Block Gas Limit Increase (EIP-7790)

Reducing computational gas costs aims to increase transaction throughput, allowing more transactions per block. EIP-7783 and EIP-7790 pursue a similar outcome by raising the block gas limit — a simpler approach with a controlled impact. However, they do not address mispriced opcodes and precompiles. Our proposal complements these efforts by correcting pricing inaccuracies, and both strategies should be implemented together to maximize throughput while ensuring cost accuracy.

Consideration of Storage Costs

By implementing the proposal, the overall computational cost will decrease, while the storage costs remains the same. This reflects the improvements in EVM software efficiency and the cost of ever growing state. By increasing the relative gap between computational and storage costs, the proposal indirectly incentivizes developers to optimize their contracts and reduce the state size. This is a positive side effect of the proposal.

Address and Storage Access Cost

The proposal modifies two formulas for address_access_cost and storage_access_cost, but for the warm data only. This is because it can be estimated using the same methodology used here. The cold access cost is multi-layered, and depends on the blockchain state, its size and data structure. Accurate measurements would require to devise more suitable methodology.

The two storage opcodes, SLOAD and STORE, are indirectly updated. Their cost formulas are complex and only the warm/cold data access cost ratio is modified. Similarly for CREATE and CREATE2. Only the memory expansion cost factor is modified, which is computational and is consistent with other opcodes that may expand memory.

Precompiles

For the MODEXP precompile, this proposal assumes EIP-7883 is adopted, and its gas cost remains unchanged. For ECPAIRING, the gas cost is reduced by approximately a factor of 5, consistent with similar adjustments in this proposal. Precompiles such as ECRECOVER, IDENTITY, ECADD, ECMUL, BLAKE2F, and POINTEVAL either retain their current gas costs or see moderate reductions.

Projects like Nethermind's Gas Benchmarks highlight a security concern: lowering the gas cost for ECRECOVER could lead to the worst-case scenario where the block computation time exceeds safety threshold. A similar issue applies to MODEXP. As the result, the rescale factor cannot be lower that the proposed 0.217391304 even though there is a room for further reduction. Note that the maximum number of operations in a block depends on the gas cost schedule and the block gas limit.

The Gas Cost Estimator project suggests a slight increase in ECRECOVER’s gas cost, but this proposal avoids that change to maintain backward compatibility and because the impact would be minor.

Hashing

The hashing operations, the precompiles SHA2-256, RIPEMD-160, BLAKE2F, and the KECCAK256 opcode, are not updated here deliberately. The examinations based on current Mainnet EVM implementations discovered settings that could and should be modified. Assuming changes proposed in this EIP as reference, the key findings include:

• The gas cost for BLAKE2F should remain unchanged.
• The per-word gas cost for KECCAK256 should stay the same, with the base cost lowered by a factor of 3.
• For SHA2-256 and RIPEMD-160, the per-word gas cost should be reduced by a factor of 3.

On the other hand, ZK based EVMs emerged for both Layer 2s recently and Mainnet in the future. And these solutions play important role in the ecosystem. Moreover, the situation is dynamic as there are efforts to optimize ZK proofs regarding the hashing operations. Changes in gas cost for these operations should be proposed in another EIP.

Additionally, the potential changes revealed by the examinations might seem substantial, but would not worsen the edge cases outlined in EIP-7667 for instance - they are scenarios for generating ZK proofs in blocks filled entirely with hashing operations.

Backwards Compatibility

The proposed changes to the gas cost schedule will require a hardfork due to their significant impact on the Ethereum network's operational mechanics. Below, we outline the key consequences of these changes and highlight areas where further research is needed to ensure a smooth transition.

The changes have the following consequences:

• Gas Cost Adjustments:
• The gas costs for a wide range of opcodes, precompiles, and other operations (such as memory expansion and access costs) will be modified.
• These adjustments aim to better align gas pricing with the computational complexity of operations, but they will directly impact the cost of executing transactions and smart contracts.
• Transaction Gas Cost Changes:
• It is highly likely that the gas cost of any transaction that invokes a contract will change.
• This is due to the widespread use of affected opcodes and operations within smart contract code.
• Developers and users should prepare for potential variations in transaction fees after the hardfork, which may require updates to gas limit estimations and fee budgeting.
• Impact on 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.
• Such contracts could fail to execute as intended, potentially resulting in transaction failures or unexpected behavior.

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

Test Cases

Test 1

Code:

PUSH1 0x60

Gas cost: 1

Test 2

Code:

PUSH2 0x0202
PUSH2 0x1000
EXP

Gas cost: 1 + 1 + (2 + 4 * 2) = 12

TODO: This EIP is a relatively simple change, but requires updates in many tests (spec, execution API, etc.). Due to the effort needed to update the tests, this will be provided only after the EIP is accepted

Reference Implementation

The reference implementation in Go-Ethereum provides new instruction set and new memoryGasCost function. Additionally it contains a set of overrides for specific gas elements. The actual implementation requires proper versioning of the overrides.

const (
  RepricedGasBaseStep         uint64 = 1
  RepricedGasFastStep         uint64 = 2
  RepricedGasMidStep          uint64 = 3

  //overrides
  WarmStorageReadCost uint64 = 100 // WARM_STORAGE_READ_COST
  ExpGas              uint64 = 2  // Once per EXP instruction
  ExpByteGas          uint64 = 4  // One per byte of the EXP exponent
  CopyGas             uint64 = 1  // One per word of the copied code
                                  // (CALLDATACOPY, CODECOPY, EXTCODECOPY,
                                  // RETURNDATACOPY, MCOPY)
)

func newRepricedInstructionSet() JumpTable {
  instructionSet := newPragueInstructionSet()

  for _, op := range instructionSet {
    if op.isPush || op.isDup || op.isSwap ||
        op.constantGas == GasFastestStep || op.constantGas == GasFastStep {
      op.constantGas = RepricedGasBaseStep
    }
  }
  instructionSet[ADDMOD].constantGas = RepricedGasFastStep
  instructionSet[MULMOD].constantGas = RepricedGasMidStep
  instructionSet[TLOAD].constantGas = WarmStorageReadCost
  instructionSet[TSTORE].constantGas = WarmStorageReadCost

  validateAndFillMaxStack(&instructionSet)
 return instructionSet
}

func memoryGasCost(mem *Memory, newMemSize uint64) (uint64, error) {
 if newMemSize == 0 {
    return 0, nil
  }
  if newMemSize > 0x1FFFFFFFE0 {
    return 0, ErrGasUintOverflow
  }
  newMemSizeWords := ToWordSize(newMemSize)
  newMemSize = newMemSizeWords * 32

  if newMemSize > uint64(mem.Len()) {
    square := newMemSizeWords * newMemSizeWords
    newTotalFee := square / params.QuadCoeffDiv

    fee := newTotalFee - mem.lastGasCost
    mem.lastGasCost = newTotalFee

    return fee, nil
  }
  return 0, nil
}

Security Considerations

The main risk associated with this proposal is the potential for DoS attacks. By reducing gas costs, the proposal could inadvertently make certain operations more affordable, enabling attackers to exploit them for malicious purposes. To mitigate this risk, the proposal focuses on decreasing the gas costs of overpriced operations, ensuring that the adjustments do not compromise network security. By maintaining the relative cost of operations, the proposal makes sure that the reduced prices do not create new vulnerabilities even in the worst-case scenarios.

The reduced memory expansion cost still keeps the quadratic nature of the cost, which prevents attacks exploiting excessive memory usage. Any existing considerations are addressed by EIP‑7825.

The proposal does not address concerns raised in EIP-7667, but it does not worsen the edge cases outlined in that EIP.

Copyright

Copyright and related rights waived via CC0.