EVM Compute Repricing
This dashboard studies the EVM's compute operations — arithmetic, bitwise, comparison, stack, control-flow, hashing, memory, context, and every precompile — from empirical client benchmark runtimes, around a 100 Mgas/s throughput anchor (the rate a plain ETH transfer sustains, which the chain can't exceed). It asks two paired questions:
- Bottlenecks — which operations are already too slow to keep up, i.e. run below 100 Mgas/s in the worst case? Those cannot be repriced cheaper.
- Reprice — of the operations that do keep up, which are overpriced for their measured runtime and should become cheaper, and by how much?
0 of 74 compute operations fall below the 100 Mgas/s ceiling (the Bottleneck page). Of the rest, at this anchor 67 of 79 fitted parameters could be reduced — open Repricing and drag the anchor to see the costs update live.
Bottlenecks
Bottleneck table →
Per-operation worst-case throughput (Mgas/s) across clients, flagging the ops that run below the 100 Mgas/s ceiling.
Bottlenecks Methodology →
How the worst-case throughput is measured from the benchmarks and compared against the 100 Mgas/s ceiling.
Repricing
Repricing table →
Interactive: set the anchor, see current vs. proposed gas, the diff, and which ops get cheaper — recomputed live in the browser.
Throughput loss →
How much throughput each repricing choice wastes — no reprice, reprice + round, reprice + fractional — per op and over real mainnet traffic.
Runtime model →
Per-opcode NNLS fits of runtime against opcode count, filterable by opcode and client.
Glue runtime →
Per-client fits for the priced glue opcodes that the target coefficients are netted against.
Test reference →
The opcode ↔ benchmark mapping: which test and fixture parameters price each operation, and the gas parameters it produces.
Repricing Methodology →
Benchmark suites, regression model, anchor, worst-case selection, and the throughput-loss method.