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:
- 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.
- Unlock EPBS-enabled 4-second slots (requires correctly priced slot time)
- 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.
Connections
- ZK Proving Infrastructure — Real-time ZK proofs enable EEZ and stateless client verification
- Ethereum Staking Dynamics — ePBS, attest cap, and staker incentives are tightly coupled
- Post-Quantum Cryptography — PQ migration is part of the same 2027–2029 roadmap window
- DeFi Institutional Transition — Institutional needs (ordering guarantees, gas predictability) drive L2 design
- P2P Networking in Ethereum — Blob propagation costs; RLNC and PANDAS as P2P layer alternatives
- Autobahn Consensus — Multi-proposer design reference for throughput scaling
- Outcome Pre-Confirmations — Pre-confirmations and MEV on L2s; ePBS is the protocol foundation
- Ethereum Real-Time Blockspace — 100ms mini-blocks as alternative/complementary path to latency reduction
- Ethereum Developer Tooling — EIP-8007 gas repricing (18 proposals for Glamsterdam); EIP process reform; Core Solidity RISC-V backend target
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?