What this project is for.
Three EF tracks, two upcoming forks, one operational question: do clients hold at 10× mainnet?
The headline numbers we anchor against: mainnet is 381M accounts, 75.9M contracts, 1.56B storage slots, 13.4 GB of code, 221 GB of trie data as of block 24,927,663 (2026-05-05).
Mainnet sampled proof sizes at the same head: account proof p50 = 3,821 B / p95 = 3,929 B; storage proof p50 = 1,211 B / p95 = 2,371 B. These are the lines the bloated multipliers are measured against.
Track 1 — Scale
The Glamsterdam fork (H1 2026) ships the state-access repricings and block-level access lists that make a higher gas limit safe to vote in (the limit itself is validator-voted, not set by the fork). The community is converging on 100M+ gas per block but the supporting evidence is patchy: most published benchmarks stop at mainnet size, where the trie is still warm in OS page cache.
Track 2 — Harden L1
Statelessness is the inflection point. The state tree is being re-cut for a SNARK-friendly, post-quantum future: the roadmap has moved off Verkle toward a unified binary tree (EIP-7864), and the witness now feeds zkEVM real-time proving as much as it feeds light clients. Whichever tree wins is argued against an MPT counterfactual that does not currently exist as numbers — only as folklore.
Track 3 — CROPS
The Ethereum Foundation’s Crypto, Open source, Recursion, Privacy, Security framing is not a checkbox — it is a license to refuse work that doesn’t fit.
Open source
Every script, payload, snapshot, and analysis is published. Reproducibility is a feature, not a side effect.
Security
Identifying where clients degrade is identifying where attackers will probe first. The bench doubles as a stress test.
Censorship resistance
Validator performance degradation is censorship; if state growth quietly slows block production it changes who can include transactions.
What this project is not
- It is not a benchmark contest. We don’t crown a winner; we publish the curves.
- It is not a tree endorsement or rejection. We produce the MPT baseline; the comparison happens elsewhere.
- It is not a one-shot study. The infrastructure is meant to be re-run every fork.
Next Questions
The road-to-10× grant answers does it hold, and it deliberately stops at the MPT baseline — the comparison happens elsewhere. These are the questions that pick up where it ends. Each is something the 5×–10× real-state pipeline is, uniquely, already positioned to measure — and each maps onto a protocol decision being made now rather than a hypothetical.
- The binary-tree proving payoff (EIP-7864). The tree is ~4× deeper (arity 2 vs 16) but each node uses a SNARK-friendly hash instead of Keccak. The net proving cost is the product of those two — and that product has only ever been argued from theory and toy benchmarks, never measured on real state. The hash itself (Poseidon2 / BLAKE3 / Keccak) is not yet chosen, and proving cost is the deciding criterion.
- The gas↔real-cost curve. Cold
SLOADis priced flat (2,100 gas) regardless of state size, while its real latency steps off a cliff once the working set leaves RAM — the same IO knee the Problems page describes, expressed as a real-cost-per-gas slope. That slope is the empirical input behind the state-access repricing in EIP-8038 (with state-creation costs in EIP-8037) — whose gas constants are still being tuned. - The BAL parallelism ceiling (EIP-7928). Block-level access lists are the lever meant to push gas past 100M — and, longer-term, toward 200M — via parallel state pre-fetch and parallel root computation. Parallelism only helps while the bottleneck is compute; at 5–10× state it shifts to random-read IOPS. Whether the speedup survives that shift is unmeasured.
- DB-architecture attribution. The cross-client battery (Track 1) shows that clients diverge; isolating why — RocksDB LSM read-amplification vs Pebble/PBSS path-keying vs MDBX B-tree freelist vs Bonsai — turns the curves into a mechanism, and a portable lesson for the next fork.
- The economics of expiry. “~80% of state is untouched >1 yr” is the premise for state expiry; the unmeasured parts are the resurrection-witness cost (revive-with-proof, MPT vs binary) and whether the hot set itself keeps growing — i.e. whether expiry bounds state or merely delays it.