202602261632-glamsterdam-gas-repricing
🎯 Core Idea
Glamsterdam is a planned Ethereum network upgrade (hard fork) framed around improving L1 scalability. A central lever in that plan is gas repricing: adjusting the gas schedule so that the price of EVM actions better matches the real resources they consume (CPU time, state access overhead, worst-case block bandwidth/size, and related bottlenecks).
The scaling motivation is straightforward: if some operations are underpriced, blocks can be packed with “cheap but slow” work that is hard for nodes to execute and propagate, turning that operation into a throughput limiter and a potential denial-of-service vector. If some operations are overpriced, the network wastes capacity and incentives become skewed.
The repricing work is organized as a bundle of EIPs rather than a single change. EIP-8007 is a meta EIP that tracks the repricing proposals considered in the scope of Glamsterdam, spanning compute opcodes and precompiles (for example EIP-7904), data/bandwidth controls (for example calldata and access list floor costs), and state access / state growth repricings.
🌲 Branching Questions
➡ What is Glamsterdam trying to achieve (in one sentence), and what kinds of repricing changes does it bundle?
Per EIP-8007, the main objective of Glamsterdam is to improve L1 scalability, and a crucial part is aligning gas costs with actual resource usage.
The repricing bundle described in EIP-8007 spans multiple resource classes:
- Compute harmonization: repricing CPU-heavy opcodes and precompiles that benchmark poorly (for example hashing, division/mod, elliptic curve operations, KZG point evaluation).
- Data and bandwidth controls: changes that help bound worst-case block size and propagation burden (for example increasing calldata floor costs and introducing explicit floor pricing for access list data).
- State access and state growth: repricing reads and writes and state creation so they better reflect the cost of interacting with a large and growing state.
A useful way to read the bundle is as an attempt to remove “single bottleneck” operations so that higher throughput does not come with pathological worst-case blocks.
➡ If repricing makes transactions use more gas, why might users still pay the same (or even less) ETH?
It is easy to conflate three different things:
- Gas used (gasUsed): how many gas units a transaction consumes under the protocol’s gas schedule.
- Gas price (base fee + priority fee): how much ETH is paid per gas unit.
- Total ETH paid: roughly gasUsed × (base fee + tip).
Repricing can increase gasUsed for certain transaction patterns, but it is often paired with a plan to increase effective block capacity (for example by raising the gas limit once bottlenecks are removed). If capacity increases and congestion decreases, the base fee could fall, partially or fully offsetting the increase in gasUsed. The gasrepricing.com explainer makes this concrete with a toy example: if capacity increases 3x, a typical tx type becomes 2x more expensive in gas units, and the base fee falls by 60%, then throughput for that tx type rises by about 1.5x and the ETH cost falls by about 20%.
This is not a guarantee. It is a mechanism-level intuition about how EIP-1559’s base fee responds to demand relative to capacity. In the short run, during transitions, specific contract patterns can become more expensive, and tooling (gas estimation, hardcoded gas limits) can break if it implicitly assumes the old schedule.
➡ How is compute gas repricing designed in Glamsterdam (EIP-7904)?
EIP-7904 is a compute-focused repricing proposal with an explicitly empirical methodology.
Key design elements described in the EIP:
-
Selection rule: it targets compute operations and precompiles whose measured performance is worse than 60 million gas per second (60 Mgas/s). The goal is to remove the worst compute bottlenecks first.
-
Multi-client benchmarking: it compares performance across major execution clients (besu, erigon, geth, nethermind, reth). If an operation is slow mainly in one client (for example worst vs second-worst differs by more than 20%), it is treated as a candidate for client optimization rather than automatic repricing.
-
Synthetic blocks and regression: it uses synthetic blocks that isolate operations, runs them repeatedly, and estimates per-operation runtime via non-negative least squares regression.
-
Conversion to gas: once runtime is estimated, gas is computed against the target throughput. The EIP gives a formula of the form:
new_gas = (anchor_rate * runtime_ms) / 1000
where runtime_ms comes from the benchmark models and the anchor rate corresponds to the target performance.
-
Scope: it increases costs for specific opcodes (for example DIV, SDIV, MOD, KECCAK256 base) and several precompiles (including BLAKE2F, ECADD, BLS12_* additions, POINT_EVALUATION).
The EIP also highlights practical compatibility consequences: it is a backwards-incompatible repricing, wallets and nodes must handle updated gas estimation, and contracts that hardcode gas limits for subcalls may break.
➡ How does the meta EIP (EIP-8007) organize repricing work, and what should you track as the bundle evolves?
EIP-8007 is a directory/meta EIP for repricing proposals in the scope of Glamsterdam. It is informational, but it is useful because it provides a single index of which repricing EIPs are considered, and it summarizes the direction of changes across compute, data, and state.
For tracking, the practical watch list is:
- Which EIPs are still “preliminary numbers” and likely to change, versus which ones are stabilizing.
- Whether repricing targets are anchored to a specific throughput goal (for example 60 Mgas/s in EIP-7904) and whether that anchor changes.
- Whether benchmarking reveals the root cause is a protocol mispricing versus an implementation optimization opportunity.
- Where compatibility risk concentrates (contracts with hardcoded gas assumptions, gas estimation tooling, and transaction patterns that heavily use repriced opcodes/precompiles).
📚 References
- Glamsterdam gas repricing explainer: https://gasrepricing.com/
- EIP-8007 (Meta): https://eips.ethereum.org/EIPS/eip-8007
- EIP-7904 (Compute repricing): https://eips.ethereum.org/EIPS/eip-7904
- EIP-7928 (Block-level access lists): https://eips.ethereum.org/EIPS/eip-7928
- EIP-7732 (Enshrined PBS): https://eips.ethereum.org/EIPS/eip-7732
- (Context thread) Worst-case block size and calldata repricing for Glamsterdam: https://ethresear.ch/t/worst-case-block-size-and-calldata-repricing-for-glamsterdam/23895