Ethereum roadmap 2026: Impact on nodes & validators

Ethereum is now ten years old, with its initial mainnet launch in July 2015.
To mark this milestone, the Ethereum Foundation recently introduced a series of comprehensive roadmaps, mandates, and visions to enhance its performance, security, and decentralization:
- EF Mandate is a manifesto that outlines the principles and guides on the role of the Ethereum Foundation
- Lean Ethereum is the overarching vision guiding the roadmap and manifesto on key areas: consensus, cryptography, governance, and overall protocol efficiency
- Strawmap is a detailed roadmap of research and engineering updates until 2030
The broader web3 industry has taken note of these developments. As major Bitcoin investor Nic Carter remarked on his podcast:
- “Frankly, I wish I were in Ethereum. I’d be thrilled right now.”
For node providers, these initiatives represent major improvements, as they aim to modernize node communication, increase the number of validators to make Ethereum more decentralized, and improve overall network health. However, most are still in the research phase, and their drawbacks remain unknown or untested.
This article analyzes these initiatives and their potential impact, especially on nodes and validators that run the network, including those operated by Chainstack.
Ethereum’s decentralization vision for nodes
What the EF Mandate means for node providers
The EF Mandate defines the principles Ethereum must preserve as it scales and directly calls out the role nodes play in maintaining protocol decentralization, before any technical details are defined.
In describing the EF Mandate, Vitalik Buterin, the founder of Ethereum, calls Ethereum a “decentralization-first blockchain.” The core principles defined in the mandate ensure decentralized properties to protect “self-sovereignty” and enable “cooperation without coercion.”
Why CROPS matters for infrastructure
Ethereum is partially powered by “centralized surfaces” such as wallets and RPCs, but the mandate emphasizes that current infrastructure must take a CROPS approach:
- Censorship resistance
- Open source
- Privacy
- Security
Chainstack already adopts CROPS principles into its node API infrastructure. Chainstack node APIs run on bare-metal, enterprise-grade environments with encrypted endpoints, SOC 2 Type II compliance, and automated threat mitigation. Users can now also deploy, manage, and monitor them on their own hardware or in a cloud environment using Chainstack Self-Hosted.
From a broader perspective, for node providers, the CROPS philosophy translates into three practical infrastructure objectives.
- Ethereum must remain verifiable by as many participants as possible. This principle supports efforts to reduce the hardware burden of running nodes by using lighter clients, simpler protocol components, and improved networking.
- The mandate emphasizes minimizing reliance on centralized intermediaries. Ethereum should not depend on a small number of infrastructure providers to function. Nodes and validators are the means by which the network maintains neutrality and resistance to censorship.
- The mandate emphasizes simplicity as a security feature. Excessive complexity makes it harder for independent clients to implement and increases the chance of protocol failures. Keeping the system clear and modular allows more teams to develop node software and supports client diversity.
These principles guide many technical updates in development, as outlined by Lean Ethereum and Strawmap, specifically regarding node communication, block validation, and participation in consensus.
Lean Ethereum, a Better Ethereum
The four Lean Ethereum workstreams
Lean Ethereum is the technical blueprint for simplifying and improving Ethereum’s performance. Many of its proposed changes directly affect how nodes operate.
Designed as a long-term vision extending through 2030, Lean Ethereum aims to make Ethereum easier to secure, implement, and scale, as articulated by the Ethereum Foundation with this presentation slide:

Lean Ethereum is a complete redesign of the consensus layer, organized around four interconnected workstreams:
- Lean Consensus redesigns of Ethereum’s consensus layer focused on faster finality, stronger security guarantees, and improved decentralization.
- Lean Cryptography transitions toward simpler cryptographic building blocks, including hash-based signature schemes that are compatible with SNARK systems and resistant to quantum attacks.
- Lean Governance aims to strategically bundle protocol upgrades so complementary improvements ship together instead of through fragmented proposals.
- Lean Craft focuses on an architectural design that is characterized by minimalism, modularity, and formal verification.
Several specific areas within the workstreams identify improvements for nodes, aiming to modernize communication, accelerate consensus, and increase validator participation.
How peer-to-peer networking may change
First, it focuses on improving peer-to-peer networking within Ethereum and how consensus nodes communicate with each other by upgrading to Gossipsub v2.0, and advanced set reconciliation.

Gossipsub v2.0 is an upgraded peer-to-peer messaging protocol that improves reliability and spam resistance. Instead of broadcasting messages at random, nodes form structured communication meshes and prioritize peers who consistently relay messages correctly.
Advanced set reconciliation allows nodes to efficiently identify which transactions or blocks they are missing from one another without rebroadcasting the entire dataset, reducing bandwidth usage and speeding up message propagation, the process by which transactions, blocks, and validator messages spread across the peer-to-peer network.
Modernized node communication would improve transaction speed, especially by decreasing slot times, the periods when a validator proposes a block, and when other validators attest to it.
However, these networking upgrades introduce tradeoffs that researchers are still evaluating. In Gossipsub, each node communicates with a limited number of peers rather than broadcasting to the entire network. This can sometimes increase message propagation latency if transactions or blocks must travel through multiple hops before reaching all validators. Nodes may also receive duplicate messages before the network converges.
More efficient networking could also support broader validator participation. Discussions around reducing the staking requirement from 32 ETH to 1 ETH could dramatically increase the number of validators participating in consensus.
A larger validator set improves decentralization but also increases the volume of network messages that nodes must process and relay. More efficient networking is essential to scaling validator participation without overwhelming node infrastructure.
What’s in the Ethereum technical roadmap
Fast L1, Gigagas L1, and Teragas L2
Strawmap outlines the specific technical upgrades required in a long-term roadmap. Considering the four-year roadmap, some upgrades are well-defined Ethereum Improvement Proposals (EIPs), while others lack a defined scope.

Justin Drake, a lead researcher at the Ethereum Foundation, highlights five major areas:
The roadmap organizes Ethereum’s evolution around five major goals:
- Fast L1 reduces transaction finality times, allowing blocks to be confirmed in seconds rather than minutes.
- Gigagas L1 increases Layer 1 throughput to roughly 1 gigagas per second, enabling Ethereum to process far more transactions directly on the base layer.
- Teragas L2 scales rollups and other Layer 2 systems to handle millions of transactions per second, leveraging improved data availability.
- Post-quantum L1: transitions to quantum-resistant signature schemes to protect the network from quantum computers.
- Private L1 integrates privacy-preserving technologies directly into the protocol.
Each of these goals introduces new technical requirements for the nodes that operate the network.
Fast L1 focuses on reducing finality times. The roadmap includes upgrades such as 2-second slots and one-round finality, both of which shorten the time between block proposals and validator attestations.
The end result is that blocks are finalized within seconds rather than the current ~12–15 minutes (two epochs).
As these slot times shrink, validator nodes must propagate blocks and validator messages across the network much more quickly.
In one-round finality, every validator votes for the block it received; in second-round finality, a certain number of validators must have seen the block, and then another set of validators confirms that they have. Though this speeds up finality, it introduces potential security flaws when malicious validators are involved. Certain measures, such as increasing the percentage of validators needed to block a transaction, would need to be implemented.

Gigagas L1 and Teragas L2 aim to dramatically increase transaction throughput on Ethereum. Today, the base layer processes roughly 15–30 transactions per second, but the roadmap targets around 10,000 TPS at Layer 1 and eventually millions of transactions per second across Layer 2 networks. To support this scale, upgrades enable nodes to handle rollup data more efficiently by verifying data availability without downloading it all.
The well-defined upgrades include:
Blob streaming: Nodes can send blob data to other nodes incrementally rather than waiting for the entire dataset to arrive first. By transmitting blob data pieces as they become available, nodes can share rollup data more quickly and avoid sudden spikes in bandwidth usage when blocks are distributed across the network.
Block-in-Blobs (EIP-8142): This proposal stores the full transaction data for a block within a blob attached to that block. By placing the execution payload in blobs, the data remains available for nodes to retrieve and reconstruct blocks through the data availability layer.
Though intended to lower gas fees for L2s by enabling them to read blobs instead of costly call data, using blobs on Ethereum remains a topic of debate. Each block has 6 blobs, and each blob can store up to 128 KB of data. Storing full transaction data in a blob increases reliance on blobs, reduces available blob space for future use cases, and still incurs gas fees.
Over 17 million blobs, with an average of each storing up to 88 percent of capacity, already exist on Ethereum mainnet. More use of blobs would require additional infrastructure to ensure data availability.

As transaction volumes increase across both Layer 1 and Layer 2 systems, nodes must relay more data and verify more proofs during block validation, making efficient data availability systems a requirement.
Post-quantum and private L1 requirements
Post-quantum L1 and Private L1 introduce new cryptographic systems that nodes must support. Nodes need to support post-quantum signature schemes and privacy-preserving proofs, which are still under active research to reduce signature and proof sizes and improve the speed of generation and verification.

What this means for your node setup
The Lean Ethereum roadmap is not abstract research — three changes have direct infrastructure implications for anyone running Ethereum nodes today.
1. Prepare for Gossipsub v2.0 client updates (2026–2027) Gossipsub v2.0 will require updated consensus client versions across Lighthouse, Prysm, Teku, and Nimbus. Node operators should track client release notes closely from late 2026 onward. Nodes running outdated clients risk degraded peer connectivity and message relay failures as the network migrates.
2. Plan for higher bandwidth with 1 ETH staking Reducing the validator minimum from 32 ETH to 1 ETH could increase the active validator set by an order of magnitude. More validators means significantly higher attestation message volume. Operators running bare-metal nodes should evaluate whether current NIC throughput and RAM headroom can absorb a 10–30x increase in p2p traffic.
3. Blob infrastructure will need scaling Post-Pectra blob targets have already increased. As Block-in-Blobs proposals progress, nodes may need additional storage and bandwidth capacity to handle full execution payloads in blob format. Monitor EIP-8142 status and plan storage provisioning accordingly.
Conclusion
Together, the EF Mandate, Lean Ethereum, and Strawmap outline a long-term direction for how Ethereum plans to scale and preserve its core principles. The mandate defines the values the network must protect, Lean Ethereum provides the technical vision for simplifying and strengthening the protocol, and Strawmap maps those ideas into technical upgrade requirements.
For node operators, these changes improve node infrastructure overall, despite potential implementation challenges as research progresses. Faster finality requires nodes to propagate blocks and validator messages more efficiently. Higher throughput means nodes must relay more data and verify more proofs during block validation. Expanding validator participation increases the importance of efficient networking and reliable node communication.
Start building on Ethereum today with Chainstack. Ethereum is working toward faster finality, higher throughput, and greater decentralization through broader validator participation. Throughout the years, Chainstack has followed the principles and technical standards that Ethereum has recently outlined. Chainstack delivers the performance and consistency required for production systems. Deploy an Ethereum RPC endpoint in seconds and scale globally with automated orchestration, uptime guarantees, and developer-friendly tooling.
FAQ
Lean Ethereum is the Ethereum Foundation’s long-term vision for making Ethereum simpler, faster, and easier to verify. It focuses on improving consensus, cryptography, governance, and protocol design.
The EF Mandate defines Ethereum’s core principles, Lean Ethereum provides the broader technical vision, and Strawmap outlines the long-term roadmap of protocol upgrades and research directions.
Lean Ethereum could change how nodes communicate, validate blocks, process data, and support new cryptographic systems. These upgrades may improve performance, but they also introduce new operational requirements for node operators.
Faster finality reduces the time it takes for blocks to be confirmed, but it also requires validators and node providers to propagate messages more quickly and reliably across the network.
These upgrades aim to increase throughput on Layer 1 and Layer 2, which means nodes may need to handle more data, relay blobs more efficiently, and verify more proofs during block processing.
Because the roadmap directly affects message propagation, validator participation, data availability, and block verification. RPC and node providers will need infrastructure that can keep up with faster finality, higher throughput, and more complex protocol requirements.





