Ethereum Scaling Roadmap

Ethereum faces simultaneous pressure on four fronts: state bloat, composability fragmentation, staker incentive misalignment, and gas limit constraints. Each has a proposed solution; none is implemented yet. The next 24 months are execution-critical. (→ EthCC[9] — Conference Overview)

State Is the Critical Bottleneck (Han / EF)

  • 63% of storage slots are written once and never touched again — dead weight.
  • Power law: top 1,000 contracts hold 51% of all state.
  • Goal: remove 80% of state as garbage while bounding active state safely.
  • This enables 1 giga-gas/sec DB performance and unlocks the next scaling tier.

Proposed path: State expiry (EIPs 8125/8188 — still research phase). Hot/cold separation for frequently vs. rarely accessed data.

Partial Stateless Nodes / VOPS (CPerezz / EF)

  • VOPS: nodes hold only account trie + selected storage contracts — 59GB, not full state.
  • Enables state markets: stakers become competitive data providers against centralized RPCs.
  • Maintains censorship resistance while reducing full-node burden.
  • Prerequisite: block access lists (declare which state a block touches) + DAS (data availability sampling).

Tension: DeFi-heavy applications may find partial-state data insufficient, forcing reliance on centralized load balancers — a centralization vector.

Gas Limit & Responsive Pricing (Toni Wahrstaetter / EF)

  • Responsive pricing (pioneered by Arbitrum): variable gas pricing that responds to actual bandwidth, not just EIP-1559 fee market.
  • Ed Felten (Offchain Labs): responsive pricing cut peak gas prices 22× (41 gwei → 2.1 gwei on October 10th spike) without increasing gas limit.
  • Han: removing 80% of dead state enables 1 giga-gas/sec target.
  • Timeline: gas limit increases are technically feasible now; political/coordination delay is the constraint.

L2 Specialization & Sequencer Evolution (Matt Pearring / Offchain Labs)

  • Hyperliquid dominates perp futures; Polymarket consumed 84–85% of Polygon gas at peak. Value concentrates on specialized chains.
  • L2s will evolve into app-specific chains with custom execution logic — sequencer ordering becomes a competitive differentiator.
  • Bimodal design: permissionless (first-come-first-serve) lanes for retail + permissioned (priority) lanes for institutions. Both coexist.
  • MEV on L2s: sandwich attacks currently unprofitable (swap sizes too small — <$400 vs. $1,000+ threshold). Will flip as L2 adoption grows.

Ethereum Economic Zone — Restoring Composability (Jordi Baylina / Zisk)

  • Rollups “broke Ethereum into islands” — cross-L2 composability is dead.
  • Real-Time ZK Proofs (RTP): prove L2 blocks in <12 seconds → enable synchronous cross-L2 calls within one Ethereum block.
  • Zisk demo: cross-chain calls returning in a single block.
  • EEZ requirement: all participants accept shared security model + real-time proving capability.
  • Risk: competing interop standards (Optimism’s interop, AggLayer, etc.) could fragment rather than unify.

ePBS — Proposer-Builder Separation (Terence Tsao / Prism)

Today: MEV-Boost requires trusted relays. Builders submit full blocks; proposers must trust relays won’t steal MEV.

ePBS (EIP-7732):

  • Separates payload delivery from block proposal at protocol level.
  • 2 seconds consensus + 10 seconds execution = 12 seconds total (currently 4 seconds max download/verify).
  • Payload Timeliness Committee (512 validators) votes on whether builder delivered block on time.
  • Trustless payment: builder commits to payment before payload; protocol enforces it.
  • Shipping: Q3 2026 tentatively.

Home staker implication: must now configure builder preferences (OFAC compliance, sybil resistance, slashing risk tolerance). No standard configuration file yet. Professional operators gain advantage.

Ethereum Kernel Funding Gap (Martin Hansen / EF)

  • Core infrastructure costs: ~$16M/year (client teams, research, security, specs, testing).
  • 85% of cost is human capital.
  • Current model: client teams funded by corporate sponsors → centralization vector if sponsors reprioritize.
  • Neutral funding (“no strings attached”) is the goal; Protocol Guild is the primary mechanism today.
  • No protocol-native funding mechanism (MEV redistribution, storage rent, state fees) implemented yet.

L2 Launch vs. Operation (Kevin Weaver / Optimism)

  • “Launching an L2 is the easy part.” Real costs: partnerships, wallet integration, legal contracts, compliance.
  • Optimism’s solution: OP Enterprise — bundles infrastructure + legal support as a product.
  • This is the business model that works. Pure open-source without business support doesn’t scale.

Blob Propagation Economics (PeerDAS) — NoConsensus.wtf 2025

The PBS pipeline, not the validator set, bears most of the bandwidth cost of scaling blobs. See P2P Networking in Ethereum for the full analysis; key implications for the scaling roadmap:

  • Relay cost at 48 blobs (post-PeerDAS): ~21 TB/month per relay, ~$2,000/month AWS bandwidth. Must complete within the 4-second attestation deadline.
  • Amplification factor: empirically ~16×, not the theoretical 8× (mesh degree). Fresh data is requested by almost all peers.
  • Risk: if relay economics break, relays may impose an artificial cap on blob count below the protocol’s actual target — an informal governance override of the scaling roadmap.
  • EPBS connection: EPBS distributes propagation responsibility from relays to builders, but doesn’t reduce total bandwidth. It does give more time (2s consensus + 10s execution = 12s total) which helps with propagation deadlines.

GossipSub modifications (e.g., EF’s WFR gossip proposal, RLNC as alternative — see P2P Networking in Ethereum) are likely prerequisites for the blob-only fork targets to be sustainable without relay centralization.

PANDAS and Danksharding P2P

PANDAS (see P2P Networking in Ethereum) provides the P2P protocol layer for DAS under Danksharding — a prerequisite for the full Danksharding roadmap. Key data point: 2.5 seconds to complete blob dissemination + DAS sampling for 20,000 nodes, using direct UDP rather than GossipSub.

Alternative: Multi-Proposer Consensus (Autobahn / Sei Giga)

Autobahn consensus (see Autobahn Consensus) demonstrates a different path to throughput scaling: multiple concurrent proposers + Proof of Availability to decouple data from consensus. Sei Giga claims 5 Ggas / 200k TPS with <400 ms finality as of August 2025. Not a direct Ethereum roadmap item, but relevant as a benchmark and design reference for Ethereum’s own multi-proposer research.

ETHDenver 2026: Roadmap Additions

EIP-7732 (ePBS / Glamsterdam) — Slot Pipelining (Terence Tsao)

The key insight from ETHDenver: ePBS isn’t just about MEV — it’s about reclaiming wasted slot time. Currently, execution payload dominates (90–95% of block) but only gets ~2 seconds of the 12-second slot. ePBS separates payload delivery from proposal:

  • 0–4s: proposer commits to validator set
  • 5–6s: payload builder reveals execution payload
  • 7–9s: 512-validator Payload Timeliness Committee validates
  • 9–12s: finalization

Result: attesters now have 9–12 seconds (vs. 2) to download and verify. ZK provers gain time within each slot. Foundation for 4-second slot times. Enables slot auctions and MEV burning downstream.

Execution Sharding via Native Rollups (Luca Donno / L2BEAT)

The key distinction: consensus should never be sharded (economic security requires full validator set agreement); execution can be sharded without losing validity guarantees.

Why Ethereum’s approach is uniquely safe: Near/Polkadot shard consensus — 71 nodes can finalize an invalid block if compromised, undetected by non-executing validators. Ethereum’s native rollup approach uses ZK proofs so that no node can ever be convinced of invalid state — even with 100% malicious validators.

Trade-off: ZK proofs add complexity and bugginess, but the universal validation property is worth it.

Log-Based Storage for Parallel Execution (Zsolt Felfoldi / EF)

Proposal: store data as immutable event logs rather than state trees.

  • Gas: 1,500 gas per transfer (vs. 5,000–20,000 for state writes)
  • Parallel execution: no write collisions → transactions can execute truly in parallel
  • Log data is multi-chain friendly, time-ordered, prune-able
  • Witnesses are more expensive than state (log-squared complexity) but can be offloaded via account abstraction + ZK batching
  • Historic tables are immutable and easy to sync (vs. constantly changing state)

Monad IO Architecture (Keone Hon / Monad)

Monad demonstrates that Ethereum’s scaling bottleneck is IO, not CPU:

  • EVM itself is not slow; Merkle tree navigation and disk access dominate
  • MonadDB: optimized for Ethereum trie structure with async IO (io_uring, 128 parallel fibers)
  • Parallel execution via optimistic concurrency: execute transactions in parallel, detect conflicts via read/write sets, re-execute only conflicts
  • Pipelining: consensus decoupled from execution; consensus runs at 400ms blocks while execution pipeline catches up
  • Prediction: State management (Monad DB techniques) is the next Ethereum performance frontier; EVM continues to dominate 85%+ of TVL

DoubleZero: Physical Fiber Network (Austin Federa)

Blockchain infrastructure is bottlenecked by public internet (high jitter, unpredictable latency). DoubleZero addresses layers 1–3:

  • 8.8TB/s capacity across 15 fiber contributors
  • Multicast hardware replication: network switches replicate data, not endpoints — many subscribers with no sender bandwidth increase
  • Solana: 100ms+ improvement in state propagation; Jetto MEV: 99.96% bandwidth savings
  • L2s mostly deploy on cloud (high jitter); DoubleZero enables traditional-finance latency

Required for Ethereum to compete with traditional finance at nanosecond scale.

Fusaka Fork Contents (Preston Van Loon + Panel)

Fusaka = next major Ethereum fork (2026):

  • ePBS (EIP-7732) included
  • Additional blob count increases
  • PeerDAS integration
  • EVM performance improvements

Glamsterdam follows Fusaka with additional scaling work. The fork cadence is accelerating: ambition is 2+ forks/year.

Vibehouse: AI-Generated Consensus Client (Lion Dapplion / Lighthouse)

An AI-generated Ethereum consensus client (Vibehouse) shipped the full Glamsterdam spec in 72 hours with all tests passing.

Key insight: the bottleneck is review, not coding. AI breaks the gatekeeping model:

  • Node runners can request features → implemented in minutes vs. weeks
  • Automated devnet testing/fixing enables bugs fixed in hours
  • Vision: 3–4 forks/year instead of 1; AI as development accelerant while humans maintain oversight

Devconnect Argentina: ETH Day & EIP Summit

Vitalik’s Lean Ethereum Vision (Vitalik Buterin, ETH Day)

Vitalik’s framing for the long arc reframes Ethereum’s purpose in two axes: (→ [[devconnect-argentina]])

  • “Centralized trust → anyone can verify”: the shift from trusting operators to verifying state yourself (enabled by ZK proofs and stateless clients)
  • “Don’t be evil → can’t be evil”: cryptographic enforcement replacing policy enforcement

Near-term scaling arc (2025–2026): Gas limit increases (already +50% YoY) + EPBS (EIP-7732) + block-level access lists enabling parallel state execution. These three are coupled: access lists declare which state a block touches, enabling independent transactions to execute truly in parallel within a slot.

Medium-term (2026–2027): Censorship resistance infrastructure + account abstraction maturity. The ordering matters: scalability first, then privacy/censorship resistance tools that work at scale.

Long-term (Lean Ethereum): ZK-friendly VM (Poseidon hashing native, not keccak), post-quantum cryptography migration, faster finality. Multi-year; no firm dates. See ZK Proving Infrastructure and Post-Quantum Cryptography.

EIP-8007: Gas Repricing for Glamsterdam (Maria Inês Silva, EIP Summit)

A meta-EIP aggregating 18 gas repricing proposals targeting the Glamsterdam fork (post-Fusaka).

The mispricing problem: Ethereum’s gas costs were set at launch and never systematically updated as hardware improved. Current operations show 5–15× efficiency loss — EVM charges are not proportional to actual compute, state IO, or state growth costs.

Repricing goals:

  1. Harmonize pricing along single resource dimensions: compute-only operations priced by compute; state IO by IO; state growth by storage. Today all three are conflated in a single gas number.
  2. Unlock EPBS-enabled 4-second slots (requires correctly priced slot time)
  3. Enable block-level access lists for parallel execution (parallelism only helps if operations are correctly priced relative to their actual resource use)

Fusaka interaction: EIP-7825 (gas limit boundaries), part of Fusaka, would invalidate some transactions currently constructed with 30M gas limits. Requires ecosystem education that such transactions can be split.

See also Ethereum Developer Tooling for the EIP process reform discussion from the same summit.

ETHPrague 2026: EZ Synchronous Composability + ZK at L1

EZ — Synchronous L2 Composability (Jordi Baylina + Vitalik Buterin fireside)

The 2025 EEZ concept has crystallized into a concrete proposal — EZ — with smart contracts targeted for experimental mainnet deployment in coming months. Key design points (full coverage at L2 Synchronous Composability):

  • Each rollup keeps sovereignty, state-transition function, and choice of proof systems (ZK, optimistic, multisig, TEE).
  • Inbox/outbox interface: a single call-and-return semantic between chains; outbox on one side must match inbox on the other.
  • Composers aggregate cross-chain transactions; builders construct the L1 block; validators retain final authority over composer/builder selection (same MEV-Boost flow).
  • Proof systems aggregate proofs per system — three rollups using two proof systems produce two proofs, both required to validate the bundle.
  • Failure-mode confinement: if base’s proof system breaks, only contracts that trusted base’s proof system are compromised; Arbitrum’s own state remains correct.

Status as of ETHPrague: smart contracts under final development; Devcon Berlin workshops planned; couple of test chains (Gnosis-fork-like + custom new chain) targeted for initial deployment. Baylina’s honest admission — for years he believed this was impossible, real-time ZK proving (sub-12s) is the precondition that made it feasible.

ZK-EVM Path to L1 (Sergey Shemyakov / L2BEAT)

L1 ZK execution-layer proof timeline confirmed by EF research:

  1. Current (2026) — Hardening phase: ZK clients and provers under heavy audit/formal verification; bugs found weekly; vulnerabilities still common (Jolt 2026 bug; an L2 had to halt due to ZTP issues earlier in year).
  2. Hegota fork (~2027) — EIP-8025 optional proofs: validators may verify a ZK proof instead of re-executing the block. Provers assumed altruistic in the bootstrap version.
  3. Post-Hegota — Optimizations to make L1 more ZK-friendly (deferred decisions).
  4. Long-term — Mandatory proofs; validators only verify proofs.

Critical L1-specific challenges versus L2s:

  • Client diversity must extend to ZK stack — Three guest programs, three proving systems, all must agree. L2s skip this (single-prover deployment is the norm).
  • Real-time proving — ~10 second window per block; 91% of blocks already provable in <10s via parallel GPU. EF cluster (€250K hardware + €100K/year ops, packed with GPUs) is the proposed reference deployment.
  • Permissionless proving economics — Currently only one project allows permissionless proving in production; this is the open coordination problem.
  • Multi-party guest-program upgrades — Onchain registry of trusted programs and provers is the open proposal.

See also ZK Proving Infrastructure.

EIP-8141 — Frame Transactions (Alex Forshtat)

The Hegota-fork native account-abstraction proposal. Replaces single-frame transactions with multiple modular frames (verify / default / sender), each with explicit role: a verify frame can read all Ethereum state but cannot write, and must end with the approve opcode signaling validation success. Native pay-master integration; native pass-key support (P256); native atomic batching; backward-compatible with existing EOAs via canonical UA code.

Mempool propagation requires bounded validation cost (~100K gas verification cap, restricted storage access for validation, canonical pay-master only) to prevent mass mempool-invalidation attacks. Private mempool inclusion has no such limits.

See Account Abstraction for full coverage. Inclusion in Hegota (~2027) is under consideration, not confirmed.

The Ethereum Kernel and Funding the Scaling Roadmap

Martin Hansen’s $18M/year Ethereum Kernel floor (see Ethereum Kernel & Public Goods Funding) is the resource-side counterpart of the scaling roadmap. Each roadmap component (clients, language stack, research, testing/specs, wallet infra, dependencies) has minimum-viable-funding requirements; the kernel framework names them collectively. Sustainable funding (Mehta’s validator-yield-reallocation EIP; Sukhinina’s CRA-driven dependency funding) is now treated as a roadmap-blocking constraint.

Connections

Open Questions

  • Does state expiry get included in a fork before 2028, or does it stay in research indefinitely?
  • Will EEZ win the interop standard competition, or do AggLayer/other approaches fragment the L2 ecosystem?
  • Can ePBS ship in Q3 2026 as planned, given the complexity of PTC configuration?
  • Who funds Ethereum kernel development sustainably? Protocol Guild alone is insufficient at scale.
  • Will relay economics force a de facto blob count cap before the protocol blob-only fork ships?
  • Does PANDAS need protocol-level changes to ship with Danksharding, or is it a client-layer implementation?