Skip to content
DeFi Reference

Roadmaps

1. TL;DR

Section titled “1. TL;DR”

Ethereum’s roadmap scales by moving execution to rollups and turning the L1 into a data-availability and settlement layer: blobs (2024), more blobs and account abstraction (Pectra, 2025-05), PeerDAS and a ~60M gas limit (Fusaka, 2025-12), then enshrined proposer-builder separation and block-level access lists (Glamsterdam, planned Q4 2026). Solana’s roadmap scales the single chain: a bigger compute budget per block, a rewritten token program, a second validator client (Firedancer), a new consensus protocol with ~150 ms finality (Alpenglow, approved 2025-09), and later asynchronous execution and multiple concurrent leaders. Both roadmaps are contested from within: Paradigm argues Ethereum ships too slowly, and Solana’s Alpenglow trades a 33% Byzantine bound for a “20+20” model.

2. Explain it simply

Section titled “2. Explain it simply”

Analogy

Section titled “Analogy”

Ethereum is a city that decided its historic downtown (the L1) should stay small and walkable, so it builds many suburbs (rollups) connected by rail and spends its budget on making the rail lines wider and cheaper (blobs, data availability sampling). Solana is a city that keeps everything downtown and instead widens the roads, replaces the traffic-light system (consensus), and rebuilds the busiest intersection (the token program) so more cars flow through the same streets.

ELI5

Section titled “ELI5”

Both networks want to handle far more activity without breaking. Ethereum’s plan is to let separate mini-networks do most of the work and just post their data to Ethereum, so it keeps adding cheap data space and better ways for computers to check that data without downloading all of it. Solana’s plan is to make the one network itself faster: allow more work per block, make common actions cheaper, run a second independent software so one bug cannot stop everything, and switch to a new agreement method that confirms transactions in a fraction of a second instead of about thirteen seconds.

Step-by-step walkthrough

Section titled “Step-by-step walkthrough”

Alice submits one transaction on each chain today and after the next upgrade; a rollup posts its batch containing her Ethereum transaction.

  1. Before (Ethereum, rollup user). Alice’s transaction executes on an L2 in seconds. The rollup batches it with thousands of others and posts a blob to L1; with a target of 3 blobs per block (Dencun, 2024-03) the rollup’s data cost per user depended on blob demand. Every full node downloaded every blob.
  2. After Pectra (2025-05). The blob target rose to 6 with a maximum of 9, halving the pressure on blob fees at the same demand; Alice’s wallet can also act like a smart contract (EIP-7702) to batch approvals.
  3. After Fusaka (2025-12). With PeerDAS, validators sample pieces of blob data instead of downloading everything, and blob-parameter-only forks can raise the count without a full upgrade; the L1 gas limit defaults to about 60M with a per-transaction cap of 16.7M gas, so Alice’s direct L1 transactions compete for roughly double the 2024 blockspace.
  4. Before (Solana). Alice’s transaction is included in a ~400 ms slot, optimistically confirmed in roughly 500–600 ms, and finalised after about 12.8 seconds; her token transfer costs about 4,645 compute units on the legacy token program.
  5. After P-Token and block-size increases (2025). The same transfer costs about 249 CU and the block holds 60M CU instead of 48M, so fewer transactions fail to land during bursts.
  6. After Alpenglow. Validators vote off-chain; if 80% of stake notarises her block in one round it is final after a median of about 150 ms, otherwise after a second round at 60%. Her “confirmed” and “finalized” commitment levels collapse into one, so any app that polled for both must change.

Common misconceptions

Section titled “Common misconceptions”
  • Myth: “Ethereum’s roadmap is about making the L1 fast.” Reality: Paradigm’s Reth team argued Fusaka should “focus its scope on scaling L2s”; L1 gas-limit work is secondary and data-driven (Paradigm, 2025-02).
  • Myth: “Alpenglow makes Solana 100x faster at processing transactions.” Reality: The 100x figure is time-to-finality (12.8 s to 100–150 ms); throughput comes from Firedancer, block-size and P-Token work (Helius, Anza).
  • Myth: “Firedancer replaced the Solana client.” Reality: The full client launched on mainnet 2025-12-12 (secondary reports); through 2025 the hybrid Frankendancer held about 10% of mainnet stake (Solana Foundation, 2025-08).
  • Myth: “Data availability sampling is solved.” Reality: Neu’s 2022 survey lists open problems in realising the sampling model over real networks; PeerDAS is a first deployment, not the end state.
  • Myth: “Solana has no proposer-builder separation.” Reality: Jito’s BAM (2025) explicitly moves Solana “closer to a Proposer-Builder Separation (PBS) like architecture” (Helius).

If you only remember one thing

Section titled “If you only remember one thing”

Ethereum is scaling by fragmenting execution across rollups and making L1 data cheap to verify; Solana is scaling by rebuilding every layer of one machine, from the token program up to consensus.

3. How it works

Section titled “3. How it works”

Ethereum: the rollup-centric roadmap

Section titled “Ethereum: the rollup-centric roadmap”

The premise, stated in 2021, is that “low fees are not an economic mechanism design question but a fundamental blockchain scalability question”, solved by letting supply “scale horizontally” through rollups (Paradigm, Ethereum Blockspace). Rollups post transaction data to L1 and prove execution with fraud or validity proofs; both need data availability. Neu (Paradigm, 2022-08) explains the tool: encode kk data chunks into nn coded chunks with a Reed-Solomon code so any kk recover the file; a withholding producer must hide more than n−kn-k chunks, which sampling a few chunks detects with probability approaching 1. Danksharding applies this to Ethereum; EIP-4844 shipped the blob transaction format (128 KB blobs, 3 target / 6 max) in Dencun (2024-03-13) with a separate exponential fee (see /foundations/fee-markets/); Pectra (2025-05-07) raised targets to 6/9 and added EIP-7702 delegation and larger validator balances (MaxEB); Fusaka (2025-12-03) shipped PeerDAS, blob-parameter-only forks, a 16.7M per-transaction gas cap and a default gas limit near 60M; Glamsterdam (planned Q4 2026) targets enshrined PBS and block-level access lists (ethereum.org roadmap, accessed 2026-08).

The gas-limit debate is data-driven. Paradigm’s series found Ethereum state at about 245.5 GiB growing 2.62 GiB/month (down from a 5.99 GiB/month peak) as of 2024-03, projecting 396–606 GiB in five years; but history grew 19.3 GiB/month (peak 36.0) as of 2024-05, 6–8x faster than state, with rollups generating about two-thirds of recent history until Dencun moved their data into pruned blobs. Hence “history growth is currently the biggest bottleneck”, and EIP-4444 history expiry, statelessness and opcode repricing are the levers before raising the limit (Paradigm, 2024-03/05; Ethereum Acceleration, 2025-01). The gas limit stood at 30M through 2024 (ethresear.ch, 2024-01).

Process is itself a roadmap item. Paradigm’s “Ethereum Acceleration” (2025-01) argues Ethereum “has shipped about one change per year” and should aim for “1-2x hardforks/yr”, that client teams “should have an input, not a veto”, and that ossification “is too risky”. Its Fusaka wishlist: PeerDAS with at least 12 blobs, EOF, ModExp repricing, RIP-7212; its don’ts: ePBS, FOCIL and statelessness in that fork (Paradigm, 2025-02). These are one client team’s opinions; ePBS nonetheless landed on the Glamsterdam agenda.

Solana: scaling one state machine

Section titled “Solana: scaling one state machine”

Solana’s roadmap is bundled under Internet Capital Markets (Anza et al., 2025-07-24; Solana Foundation, 2025-08). Its layers:

  • Capacity. Block limits rose from 48M to 60M CU in 2025 (+25%), with SIMD-0286 proposing 100M; a token transfer uses about 5,000 CU, so 12M extra CU is roughly 2,500 more transfers per block (Solana Foundation, 2025-08).
  • Efficiency. P-Token, a drop-in rewrite of the SPL Token program, cuts Transfer from 4,645 to 249 CU, MintTo from 4,538 to 155 and Burn from 4,753 to 168; Neodyme’s replay of nine days of mainnet showed 12% lower total compute (Solana Foundation, 2025-08).
  • Client diversity and throughput. Firedancer (Jump, C) demonstrated 1M TPS per tile on ingress and 1.2M TPS in distributed tests; the Frankendancer hybrid held about 10% of mainnet stake as of 2025-08 and produced a 100,000 TPS mainnet burst (Solana Foundation; Helius). The full client launched on mainnet on 2025-12-12 (secondary reports, accessed 2026-08).
  • Consensus: Alpenglow. Replaces Proof-of-History and TowerBFT with Votor (voting) and, later, Rotor (dissemination). Votor runs two concurrent paths: fast-finalisation after one round with ≥80%\ge 80\% of stake, slow-finalisation after two rounds with ≥60%\ge 60\%. Votes are sent directly between validators and aggregated into BLS certificates rather than posted as on-chain vote transactions; timeouts replace PoH. Expected finality is about 150 ms median (100 ms fast path) versus 12.8 s today; the “20+20” model tolerates 20% adversarial stake plus 20% offline (Anza, 2025-05; SIMD-0326). Economics: votes cost validators about 1 SOL/day today; SIMD-0326 replaces this with a burned validator admission ticket of about 0.8 SOL/day (1.6 SOL/epoch) and caps the active set at the 2,000 highest-staked validators. Helius estimates the profitability threshold falls from about 4,850 SOL ($800k) to about 450 SOL ($75k) (as of 2025-07). SIMD-0326 passed the community vote in epochs 840–842 with 98.94% yes on 52% stake participation (Blockworks, 2025-09, secondary); the white paper reached v1.2 on 2026-07-29 (Anza).
  • Execution and ordering. Asynchronous Program Execution (APE) removes replay from the critical path (expected post-Alpenglow, 2026); Multiple Concurrent Leaders (MCL, targeted 2027) lets several leaders propose in parallel; BAM (Jito, testnet 2025-07) and Application-Controlled Execution let programs dictate ordering; DoubleZero is a dedicated fibre network cutting up to 100 ms of latency (Anza roadmap, 2025-07).

The speedup arithmetic for Alpenglow is a latency floor, not a throughput claim: if the longest one-way hop from leader to a supermajority is τ\tau, then finality ≈2τ\approx 2\tau, so τ=70\tau = 70 ms gives 120–150 ms (Helius).

4. Worked numeric example

Section titled “4. Worked numeric example”

Following Alice from §2.

Ethereum blob economics. A rollup batch of 100,000 bytes needs one 131,072-byte blob. If blob demand equals target, excess_blob_gas stays flat and bblob=exp⁡(excess/3,338,477)b_{\text{blob}} = \exp(\text{excess}/3{,}338{,}477) stays near the 1-wei floor; at target 3 blobs (Dencun) sustained demand of 6 blobs per block raises excess by 3×131,072=393,2163\times 131{,}072 = 393{,}216 per block, so after 25 blocks bblob=exp⁡(9,830,400/3,338,477)≈e2.94≈19b_{\text{blob}} = \exp(9{,}830{,}400/3{,}338{,}477) \approx e^{2.94}\approx 19 wei, and after 50 blocks ≈360\approx 360 wei. Under Pectra’s 6-blob target the same 6-blob demand adds nothing to excess and the price stays at the floor: doubling the target converts a rising price path into a flat one (parameters from EIP-4844 and ethereum.org; demand hypothetical).

Solana capacity. 60M CU per 400 ms block ÷ 249 CU per P-Token transfer ≈240,000\approx 240{,}000 transfers per block, versus 60M ÷ 4,645 ≈12,900\approx 12{,}900 on the legacy program; in practice signatures, scheduling and account contention bind first, so the Foundation’s own conversion (≈5,000 CU per transfer including overhead) gives 12,000 transfers per block, 30,000 per second.

Alpenglow finality and economics. Fast path: 80% stake × one round; with 65% of stake within 50 ms of a Zurich leader (Anza simulation, 2025-05), median finality ≈150 ms versus 12.8 s, a ≈85×\approx 85\times reduction (Helius rounds to 100x). Validator cost: ~1 SOL/day vote fees → 0.8 SOL/day VAT, a 20% cut, but paid as a burned ticket; if SOL trades at an illustrative $165 (implied by Helius’ 811,604 SOL ≈ $168.5M in 2024-12), that is roughly $132/day.

5. Where it’s used

Section titled “5. Where it’s used”

Ethereum

Section titled “Ethereum”

Solana

Section titled “Solana”
  • Drift, Jupiter and other venues — targets of Application-Controlled Execution (maker-priority matching, time-in-force orders) under BAM (Helius; Anza roadmap co-authored by Drift) — /exchange/order-books/.
  • Stablecoin and token issuers — beneficiaries of P-Token’s 95% compute reduction on the most-used program (1.5M transactions per hour, ~40% of non-vote transactions, as of 2025-08) — /foundations/token-standards/.
  • Small validators — Alpenglow’s removal of vote fees is the largest cut to their operating cost (Helius, 2025) — /staking/issuance-and-staking-economics/.

6. Risks, attacks, and incidents

Section titled “6. Risks, attacks, and incidents”
  • Slow shipping (Ethereum). Paradigm’s assessment that Ethereum ships about one change per year (2025-01); Fusaka shipped in Q4 rather than the requested Q3 2025.
  • History outgrowing nodes. “Within a couple years, history data will exceed the storage capacity of many Ethereum nodes” (Paradigm, 2024-05); blobs and EIP-4444 are the mitigations.
  • Relay fragility. The 2023-04 relay exploit ($20M) and the ensuing reorg spike show that out-of-protocol block building is a consensus risk, motivating ePBS (Paradigm, 2023-04).
  • Solana liveness history. NFT-mint spam halted block production in 2021–2022 (Helius); April 2024 congestion produced a 75.7% revert rate (Helius, 2025-01). Wattenhofer’s 2024 paper “Halting the Solana Blockchain with Epsilon Stake” found liveness weaknesses in the current TowerBFT design (Helius).
  • Alpenglow-specific risks. A ground-up consensus replacement (“The main drawback is the risk related to implementing a big protocol change”, SIMD-0326); 20+20 rather than 33% Byzantine tolerance; reward and slashing mechanics for equivocation unspecified; the commitment-level collapse can silently break apps; VAT of 1.6 SOL/epoch criticised as an entry barrier (forum, 2025-08).

7. Open problems

Section titled “7. Open problems”
  • DAS in practice. Neu lists network-layer questions: who serves samples, how to handle adaptive adversaries and reconstruction, and how light clients gain security without trusting a majority (Paradigm, 2022-08).
  • State expiry vs statelessness. Paradigm supports binary-tree statelessness “for the long term” but not in Fusaka; how gas repricing and block-level warming interact with a higher limit is open (2025-01/02).
  • Which fork gets ePBS and FOCIL. Paradigm’s Reth team opposed both for Fusaka; ethereum.org now lists ePBS for Glamsterdam; FOCIL’s fork is undecided — /mev/mev-burn-tickets-focil-timing/.
  • MCL semantics and Rotor economics on Solana. Write-set partitioning between leaders, per-lane certificate merging, fee logic, cross-lane MEV, relay compensation and equivocation penalties are all unanswered (Helius, 2025).
  • Is a single state machine sustainable? Helius describes Solana as choosing vertical scaling and hitting “some sort of horizontal scaling threshold”; Paradigm’s “L1 Dilemma” (2025-06) argues every incumbent’s dogma invites specialised competitors.

8. Ethereum vs Solana

Section titled “8. Ethereum vs Solana”
AspectEthereumSolana
Scaling thesisRollups + L1 as DA/settlementSingle chain, vertical scaling
Recent upgradesDencun 2024-03; Pectra 2025-05; Fusaka 2025-12Agave 1.18 2024-05; SIMD-0096; 60M CU + P-Token 2025
Next milestonesGlamsterdam Q4 2026 (ePBS, BALs); Hegotá 2027Alpenglow (approved 2025-09); APE 2026; MCL 2027
Data availabilityBlobs, PeerDAS, BPO forksTurbine → Rotor (erasure-coded shreds)
Finality12 s slots; multi-epoch finality12.8 s → ~150 ms median (Alpenglow)
Client diversityMultiple production clients (Reth among them)Agave/Jito-Agave dominant; Firedancer ~10–14%
Block buildingMEV-Boost → ePBSLeader + Jito → BAM/ACE
Governance cadence~1 fork/yr; Paradigm wants 1–2SIMD votes; SIMD-0326 98.94% yes
Main risk debatedShipping speed, history growthConsensus rewrite, 20+20 model, client diversity

Ethereum’s roadmap optimises for many independent execution environments sharing verifiable data, accepting fragmentation and slower L1 change; Solana’s optimises for one execution environment at internet latency, accepting concentrated engineering risk and a smaller fault-tolerance margin in exchange for sub-second finality.

9. Reference doc

Section titled “9. Reference doc”

The reference

Section titled “The reference”

Ethereum Acceleration — Georgios Konstantopoulos, Dan Robinson, Matt Huang, Charlie Noyes (Paradigm), 2025-01-25. https://www.paradigm.xyz/writing/ethereum-acceleration-1

Summary of the reference

Section titled “Summary of the reference”

The post is a position piece in four parts. Shipping faster helps regardless of vision: debates over L1 vs L2 or decentralisation vs efficiency are “premature” until Ethereum reaches “the efficient frontier of what’s possible”; speed dissolves either/or prioritisation into “both”. How could Ethereum ship faster: historically one change a year; the community should decide to do more; ossification is rejected because it cedes competitiveness and abandons the core-dev process as a governance mechanism; concretely, client teams should have input not veto (no N-of-N), the All Core Devs process should be improved along Tim Beiko’s suggestions, and DevOps and testing deserve more resources. We aren’t lacking good ideas: scaling and securing L2s (PeerDAS, blob-parameter-only forks, native rollups), scaling L1 without burdening nodes (opcode repricing, block-level warming, a safe gas-limit increase informed by history and state data, EIP-4444 expiry, statelessness), and account abstraction beyond EIP-7702. How Paradigm contributes: EIPs such as EIP-7862, state/history data analysis, Reth as a production client and SDK that “will never be the bottleneck”, and tooling (Foundry, Alloy, Revm, Viem). The companion post (2025-02) turns this into a Fusaka scope: PeerDAS with at least 12 blobs, EOF, ModExp repricing, RIP-7212; exclude ePBS, FOCIL, statelessness, EVMMAX and RISC-V; aim for 1–2 hardforks a year by decoupling shipping, scoping and research.

Key quotes

Section titled “Key quotes”

“Historically, Ethereum has shipped about one change per year. Ethereum can do more.” — How could Ethereum ship faster? “We think ossification is too risky for Ethereum.” — How could Ethereum ship faster? “client teams should have an input, not a veto.” — How could Ethereum ship faster? “We think it is necessary for Ethereum to ship Fusaka in Q3 2025 and focus its scope on scaling L2s.” — What comes after Ethereum’s Pectra hard fork?, opening

How to read the original

Section titled “How to read the original”

Background: what a hard fork is, the L1/L2 split, and the names of the recent forks. Read the “ideas” list first, then the process argument; skip the tooling section unless you build on Reth. The hardest passage is the ossification argument: the authors treat the core-dev process as Ethereum’s offchain governance, so freezing the protocol would remove the mechanism that lets the social layer respond to changes in L2 and MEV market structure.

What changed since

Section titled “What changed since”

Pectra shipped on 2025-05-07 and Fusaka on 2025-12-03 with PeerDAS, blob-parameter-only forks, a per-transaction gas cap and a default limit near 60M; Glamsterdam is scheduled for Q4 2026 with ePBS and block-level access lists, and Hegotá for 2027 (ethereum.org roadmap, accessed 2026-08). The requested Q3 2025 date slipped one quarter; EOF did not ship in Fusaka according to the ethereum.org summary.

Secondary references

Section titled “Secondary references”
  1. Paradigm, “What comes after Ethereum’s Pectra hard fork?” (2025-02) — read for the concrete Fusaka do/don’t list.
  2. Paradigm, “What comes after Ethereum’s Cancun hard fork?” (2024-01) — read to see how the same team scoped Prague/Pectra.
  3. Paradigm, “How to Raise the Gas Limit” Parts 1–2 (2024) — read for the state/history data behind the gas-limit position.
  4. Neu, “Data Availability Sampling: From Basics to Open Problems” (Paradigm, 2022-08) — read before evaluating PeerDAS.
  5. ethereum.org roadmap — read for shipped dates and upcoming scope.

The reference

Section titled “The reference”

Alpenglow: A New Consensus for Solana — Quentin Kniep, Kobi Sliwinski, Roger Wattenhofer (Anza), 2025-05-19. https://www.anza.xyz/blog/alpenglow-a-new-consensus-for-solana

Summary of the reference

Section titled “Summary of the reference”

The announcement presents Alpenglow as “the biggest change to Solana’s core protocol since, well, ever”. It retires TowerBFT and Proof-of-History, introduces Votor for voting and finalisation, and replaces gossip with direct communication. Rotor refines Turbine’s erasure-coded dissemination with a single relay layer, using bandwidth proportional to stake so total bandwidth is “used asymptotically optimally”, on the insight that dispersal delay is dominated by network latency rather than transmission or computation. Latency: TowerBFT finality was about 12.8 s, with optimistic confirmation as a sub-second stopgap; Alpenglow simulations (current mainnet stake distribution, ignoring computation) give about 150 ms median finality and sometimes 100 ms. A Zurich-leader plot decomposes latency into network floor, Rotor, 60% notarisation and finalisation, noting that about 65% of stake is within 50 ms of Zurich and a long tail exceeds 200 ms. Votor finalises in one round with 80% participation or two rounds with 60%, run concurrently so the faster path wins. Resilience is “20+20”: 20% adversarial plus 20% non-responsive. A white paper with pseudo-code, simulations and proofs accompanies the post (v1.0 2025-05-19, v1.1 2025-07-22, v1.2 2026-07-29). SIMD-0326 (2025-07-25) specifies the Votor subset for mainnet: two-round voting with notarize/skip and fallback votes, five certificate types at 60%/80% thresholds, direct vote broadcast, rewards via leader-posted vote aggregates at slot s+8s+8, a 2,000-validator cap and a burned validator admission ticket of about 0.8 SOL/day; Rotor and asynchronous execution get separate SIMDs.

Key quotes

Section titled “Key quotes”

“With TowerBFT, Solana had about 12.8 sec from block creation until block finality.” — Anza post, paragraph 4 “We expect that Alpenglow can achieve actual finality in about 150 ms (median).” — Anza post, paragraph 4 “Alpenglow’s voting component Votor finalizes blocks in a record single round of voting if 80% of the stake is participating, and in two rounds if only 60% of the stake is responsive.” — Anza post, “So where is this high performance coming from?” “tolerating up to 20% adversarial stake and an additional 20% non-responsive stake” — Anza post, penultimate paragraph “The main drawback is the risk related to implementing a big protocol change.” — SIMD-0326, Drawbacks

How to read the original

Section titled “How to read the original”

Background: what stake-weighted voting and erasure coding are, and Solana’s slot/epoch structure. Read the Anza post fully (it is short), then SIMD-0326’s Voting, Certificates and VAT sections; leave the white paper’s proofs for later. The hardest idea is the concurrent fast/slow path: validators do not choose a mode; both certificate types are collected at once and a block is final the moment either an 80% one-round certificate or a 60% two-round pair exists, which is why finality latency tracks the network floor when participation is high.

What changed since

Section titled “What changed since”

SIMD-0326 was approved by validator vote in epochs 840–842 (98.94% yes, 52% participation; Blockworks, 2025-09, secondary). Helius (2025) expected mainnet rollout “by early next year” and flagged open questions on rewards, Rotor relay compensation, MEV under 150 ms finality and RPC commitment levels. The Anza roadmap (2025-07) sequences Alpenglow before APE (2026) and MCL (2027); DoubleZero targeted mainnet in 2025-09. Firedancer’s full client launched on mainnet in 2025-12 (secondary), and Jito’s BAM began layering PBS-like block building on top.

Secondary references

Section titled “Secondary references”
  1. Helius, “Alpenglow: Solana’s Great Consensus Rewrite” (2025) — read for the long-form explanation, validator economics and risk list.
  2. SIMD-0326 — read for the normative voting and certificate rules.
  3. Anza et al., “The Internet Capital Markets Roadmap” (2025-07) — read to place Alpenglow among APE, MCL and BAM.
  4. Solana Foundation, “Increase Bandwidth, Reduce Latency” (2025-08) — read for the capacity and P-Token numbers.
  5. Helius, “What is Firedancer?” — read for the client’s architecture.

10. Sources

Section titled “10. Sources”