Ethereum’s 2026 roadmap centers on two tracks: expanding rollup data capacity through blobs while pushing base-layer execution higher through gas limit changes.
Those gas limit changes depend on validators moving from re-executing blocks to verifying ZK execution proofs.
The first track is already anchored by Fusaka, which shipped Dec. 3, 2025.
Fusaka
Fusaka sets up PeerDAS plus blob parameter only (BPO) changes that can raise blob throughput in measured steps, according to ethereum.org.
The second track is less mechanized because it relies on draft EIPs, client implementation, and validator operations that have to stay within decentralization constraints, including bandwidth, block propagation, and proving market structure.
PeerDAS is positioned as the clearest “capacity ramp” lever because it is designed to scale rollup data availability without forcing every node to download every blob.
According to ethereum.org, blob targets do not jump immediately at activation, then can double every few weeks up to a maximum target of 48 as developers monitor network health.
Optimism’s team framed the upper-end case as “at least 48 blob target per block,” paired with a rollup-side throughput move from about 220 to about 3,500 UOPS under that target, according to optimism.io.
Even in that framing, the practical question for 2026 is whether demand arrives as blob usage rather than bidding up L1 execution.
Another open question is whether p2p stability and node bandwidth remain within operator tolerances as BPO increases rollout.
On the execution side, Ethereum is already testing higher throughput through coordination rather than a hard fork.
GasLimit.pics reported a latest gas limit of 60,000,000, with an about 59,990,755 24-hour average at the time shown.
That level matters because it provides a reference point for what validators have accepted in practice.
It also exposes the ceiling of “social scaling” before latency, validation load, and mempool and MEV pipeline strain become binding.
A simple way to translate gas limit talk into throughput ranges is gas per second, using Ethereum’s 12-second slot time (gas per second equals gas limit divided by 12).
The numbers below keep the math explicit and separate base-layer EVM transactions from rollup throughput claims.
| Scenario | Gas limit | Gas/sec (≈ gas/12) | Tx/sec at 21k gas | Tx/sec at 120k gas |
|---|---|---|---|---|
| Current coordination level | 60,000,000 | 5,000,000 | ≈238 | ≈42 |
| 2× gas limit case | 120,000,000 | 10,000,000 | ≈476 | ≈83 |
| High-end case (requires validation change) | 200,000,000 | 16,666,667 | ≈793 | ≈139 |
Glamsterdam
The planned 2026 upgrade branding wraps several execution-oriented ideas into “Glamsterdam,” a shorthand slate that has been discussed around enshrined proposer-builder separation (ePBS, EIP-7732), Block-Level Access Lists (BALs, EIP-7928), and general repricing (EIP-7904).
Each remains in draft form, according to the EIP pages for EIP-7732, EIP-7928, and EIP-7904.
Repricing targets gas schedule mismatches that have persisted for years.
It argues that correcting mispriced compute can raise usable throughput while acknowledging DoS risk and the reality of contracts that hardcode gas assumptions, according to EIP-7904.
BALs are framed as plumbing for parallelism.
The EIP cites parallel disk reads, parallel transaction validation, parallel state-root computation, and “executionless state updates,” while estimating about 70 to 72 KiB average compressed BAL size as overhead, according to EIP-7928.
In practice, those gains only materialize if clients adopt concurrency across the real bottlenecks.
They also depend on whether the extra data and verification steps avoid becoming their own latency tax.
ePBS sits at the center of both MEV and throughput discussions because it aims to decouple execution validation from consensus validation in time, according to EIP-7732.
That temporal slack is also where new failure modes can show up.
An academic paper on the “free option problem” for ePBS estimates option exercise at about 0.82% of blocks on average under an 8-second option window, reaching about 6% on high-volatility days in its modeled conditions, according to arXiv.
Ethereum in 2026
For 2026 planning, that research pushes attention toward liveness under stress, not only steady-state fee outcomes.
The more structural bet behind “very high” gas limits is validator ZK-proof adoption.
The Ethereum Foundation’s “Realtime Proving” roadmap describes a staged path where a small set of validators first runs ZK clients in production.
Then, only after a supermajority of stake is comfortable, gas limits can rise to levels where proof verification replaces re-execution for practical validation on reasonable hardware, according to the foundation’s July 10, 2025 post on blog.ethereum.org.
The same post lays out constraints that matter for feasibility rather than narrative, including targeting 128-bit security (with 100-bit accepted temporarily), proof size under 300 KiB, and avoiding reliance on recursive wrappers with trusted setups, according to blog.ethereum.org.
The scaling implication is tied to proving markets: real-time proof supply has to be cheap and credible without concentrating into a narrow prover set that recreates today’s relay-style dependencies in another layer of the stack.
After Glamsterdam, “Hegota” is positioned as a later-2026 named slot that is still about process more than scope.
The Ethereum Foundation published a headliner timeline with a Jan. 8 to Feb. 4 proposal window, followed by Feb. 5 to Feb. 26 discussion and finalization, then a window for non-headliners, according to blog.ethereum.org.
A Hegotá meta-EIP exists as draft (EIP-8081) and lists items as considered rather than locked, including FOCIL (EIP-7805) as currently considered, according to EIP-8081.
The near-term reporting value in that schedule is that it creates dated decision points investors and builders can track without inferring commitments from codenames.
The first is that Hegota headliner proposals close Feb. 4.
Analysis,Featured,Privacy,Technology,Web3#Ethereums #roadmap #includes #validator #risk #bigger1766932596
