Ethereum, the foundational layer of countless decentralized applications, is embarking on an ambitious journey with its 2026 roadmap. This vision centers around a dual approach to enhance network capacity and efficiency: significantly expanding rollup data availability through innovative "blobs" and pushing the base-layer execution limits higher. The path to achieving these goals is multifaceted, involving crucial upgrades that are already being rolled out and others still in their early conceptual stages. At its core, this evolution aims to solidify Ethereum's position as a scalable, high-performance blockchain, capable of supporting a global digital economy.
Fusaka: The Blueprint for Rollup Data Scaling
The first major pillar of Ethereum's 2026 roadmap is already in motion with the Fusaka upgrade, which went live on December 3, 2025. Fusaka is a pivotal step towards scaling rollup data capacity, a critical component of Ethereum's modular future. At its heart, Fusaka introduces PeerDAS (Peer Data Availability Sampling) and Blob Parameter Only (BPO) changes. These technical enhancements are designed to incrementally increase blob throughput, allowing rollups to process and store more data without burdening the mainnet.
The core idea behind PeerDAS is revolutionary: it enables the network to scale data availability for rollups without requiring every single node to download every single blob of data. This is achieved by having nodes sample only a portion of the data, ensuring overall data availability while drastically reducing the storage and bandwidth requirements for individual nodes. Ethereum.org outlines a measured approach for blob targets, which do not immediately jump at activation but can double every few weeks, reaching a maximum target of 48 blobs per block as developers continuously monitor network health and stability.
Optimism, a prominent Layer 2 rollup, has painted an optimistic picture for the upper-end case, suggesting "at least 48 blob target per block" could boost rollup-side throughput from approximately 220 to an impressive 3,500 operations per second (UOPS) under that target. This kind of scaling is vital for reducing transaction fees on Layer 2s, making Ethereum more accessible and affordable for everyday users.
However, the journey isn't without its questions. A key consideration for 2026 is whether sufficient demand will materialize as blob usage, or if users will continue to bid up Layer 1 execution costs. Furthermore, as BPO increases roll out, maintaining p2p stability and ensuring node bandwidth remains within acceptable tolerances for network operators presents a significant challenge. These are crucial aspects that will dictate the practical success of Fusaka's promise.
Fusaka cements Ethereum’s modular vision: Layer 1 as the secure settlement layer, and Layer 2s as the user-facing execution layer. This separation of concerns is fundamental to achieving high throughput without compromising decentralization.
Elevating Base-Layer Throughput: The Evolving Gas Limit
Beyond rollup scaling, Ethereum is also actively exploring ways to increase its base-layer execution capacity. Interestingly, this push for higher throughput is currently being tested through network coordination rather than a hard fork, reflecting the community's evolving approach to scaling. Recent reports from GasLimit.pics indicate the network is operating with a gas limit of around 60,000,000, with a 24-hour average very close to that figure.
This operational gas limit is more than just a number; it serves as a critical reference point, showcasing what validators are willing and able to accept in practice. It also reveals the ceiling of "social scaling," where increases can be made through collective agreement before fundamental network constraints become binding. These constraints include latency, the validation load on individual nodes, and potential strain on the mempool and Maximal Extractable Value (MEV) pipelines.
To better understand what these gas limits mean for practical network performance, we can translate them into transactions per second (Tx/sec), considering Ethereum's average 12-second slot time. The following scenarios illustrate the potential throughput at various gas limit levels, differentiating between simple (21k gas) and more complex (120k gas) transactions:
- Current Coordination Level (60,000,000 Gas Limit):
- Gas/sec (approx. gas/12): 5,000,000
- Tx/sec at 21k gas: approx. 238
- Tx/sec at 120k gas: approx. 42
- 2x Gas Limit Case (120,000,000 Gas Limit):
- Gas/sec (approx. gas/12): 10,000,000
- Tx/sec at 21k gas: approx. 476
- Tx/sec at 120k gas: approx. 83
- High-End Case (200,000,000 Gas Limit, requires validation change):
- Gas/sec (approx. gas/12): 16,666,667
- Tx/sec at 21k gas: approx. 793
- Tx/sec at 120k gas: approx. 139
These figures highlight that significant increases in base-layer transaction throughput, particularly to the "high-end case," will necessitate more than just social coordination; they require fundamental changes to how blocks are validated, specifically moving towards zero-knowledge (ZK) execution proofs.
Glamsterdam: Next-Generation Execution Enhancements
The planned 2026 upgrade known as "Glamsterdam" bundles several execution-oriented proposals under one conceptual umbrella. This shorthand slate encompasses critical discussions around enshrined Proposer-Builder Separation (ePBS, EIP-7732), Block-Level Access Lists (BALs, EIP-7928), and general repricing (EIP-7904). It's important to note that, according to their respective EIP pages, all of these remain in draft form, indicating ongoing research, discussion, and development.
Repricing (EIP-7904) aims to address long-standing gas schedule mismatches. The argument here is that by correcting mispriced compute operations, Ethereum can unlock greater usable throughput. However, this must be balanced against the risk of Denial-of-Service (DoS) attacks and the practical reality of existing smart contracts that have hardcoded gas assumptions, which could be impacted by changes.
Block-Level Access Lists (BALs, EIP-7928) are conceptualized as foundational "plumbing" for achieving parallelism within the Ethereum Virtual Machine (EVM). This EIP envisions possibilities like parallel disk reads, parallel transaction validation, parallel state-root computation, and even "executionless state updates." While promising significant performance gains, BALs come with an estimated overhead of about 70 to 72 KiB average compressed size per block. The real challenge will be ensuring that client implementations can effectively adopt concurrency across the true bottlenecks of the network, and that the additional data and verification steps don't inadvertently create their own latency issues.
Enshrined Proposer-Builder Separation (ePBS, EIP-7732) sits at the nexus of both MEV optimization and throughput discussions. Its primary goal is to decouple execution validation from consensus validation, introducing a temporal slack between these processes. While this can mitigate some of the centralization risks associated with MEV, this very "slack" introduces new potential failure modes. Academic research, such as a paper on the "free option problem" for ePBS, estimates that option exercise could occur in about 0.82% of blocks on average under an 8-second option window, potentially spiking to around 6% on high-volatility days under modeled conditions. This highlights a crucial validator risk: ensuring network liveness and stability under stressful conditions, rather than just focusing on steady-state fee outcomes.
The Future of Validation: Embracing ZK-Proofs
A structural bet underpinning the aspiration for "very high" gas limits in Ethereum's 2026 plan is the widespread adoption of validator zero-knowledge (ZK) proofs. The Ethereum Foundation's "Realtime Proving" roadmap outlines a carefully staged path to integrate this advanced technology. Initially, a small, dedicated set of validators will run ZK clients in a production environment. Only after a supermajority of the network's stake feels comfortable and confident with this new paradigm will gas limits be allowed to rise to levels where ZK-proof verification can practically replace the traditional re-execution of blocks, even on reasonable hardware.
This transition is not taken lightly, and the foundation has laid out stringent constraints for feasibility, moving beyond mere narrative. These include:
- Targeting 128-bit security, with 100-bit security accepted temporarily.
- Ensuring proof size remains under 300 KiB to minimize overhead.
- Crucially, avoiding reliance on recursive wrappers that depend on trusted setups, which could introduce centralized points of failure or trust assumptions.
The broader scaling implication here is tied directly to the emergence of robust "proving markets." For this vision to succeed, the supply of real-time ZK proofs must be both cheap and credibly decentralized. The challenge is to prevent the concentration of proof generation into a narrow set of provers, which could inadvertently recreate the relay-style dependencies seen in other layers of the current stack, undermining the very decentralization Ethereum strives for.
Hegota: Shaping the Path Forward in Late 2026
Beyond Glamsterdam, "Hegota" is positioned as a later-2026 named slot in the Ethereum roadmap. This upgrade is currently less about a specific scope of features and more about defining the process for future development and implementation. The Ethereum Foundation has already published a headliner timeline, which includes a proposal window from January 8 to February 4, followed by a discussion and finalization period from February 5 to February 26, after which proposals for non-headliner items will be considered.
A Hegotá meta-EIP (EIP-8081) exists in draft form, listing various items as "considered" rather than locked, such as FOCIL (EIP-7805). The immediate value of this structured schedule for investors and builders is that it provides clear, dated decision points. This allows stakeholders to track actual progress and anticipated changes without having to infer commitments solely from codenames or early discussions, fostering greater transparency and predictability in Ethereum's ongoing evolution.
Post a Comment