Published On Jul 18, 2025
Updated On Jul 18, 2025
Ethereum’s 2025 Scalability Roadmap: From Bottlenecks to a Modular Blockchain Future
A surge in DeFi usage drove Ethereum gas fees to $67 million.
Rollups have now become the primary execution layer, handling over 85% of Ethereum’s transaction volume.
Today, Ethereum has moved beyond scaling a single chain.
It now spans a modular ecosystem of rollups, app-specific L3s, zk-powered compute layers, and ephemeral data systems, each optimised for a different part of the stack.
Whether you’re deploying a DeFi protocol or launching your own rollup, understanding this new stack is essential.
This guide breaks down Ethereum’s scalability journey past, present, and future, covering the architecture, tools, and strategic choices developers need to navigate in 2025.
Let’s get started.
The Early Bottlenecks: Why Ethereum Needed to Scale
Ethereum initially followed a monolithic architecture, where execution, consensus, and data availability were all handled on the same layer.
This structure worked during Ethereum’s formative stage, but as on-chain activity exploded, it exposed fundamental scalability limits.
Execution Congestion Became the Norm
By 2020, DeFi protocols, NFT marketplaces, and high-frequency bots were all competing for limited blockspace.
The Ethereum Virtual Machine (EVM) processed every contract sequentially, with no parallelism and a fixed gas limit per block.
As a result:
- Gas prices became highly volatile, regularly spiking during demand surges.
- Complex dApps became prohibitively expensive for users, especially those outside high-value DeFi transactions.
- Developers optimised for gas savings over maintainability or extensibility.
- Latency increased, making real-time or interactive applications difficult to build.
What emerged was an environment where only the highest-value interactions were economically viable, and everything else was priced out.
State Growth Pressured Node Infrastructure
As more contracts were deployed and tokens minted, Ethereum’s global state, comprising account balances, contract code, and on-chain storage, grew continuously.
Full nodes were responsible for storing and serving this expanding state, which introduced several challenges:
- Increased hardware requirements for validators and node operators.
- Slower sync times for new participants joining the network.
- Growing concerns about long-term decentralisation and node accessibility.
While ideas like state rent and pruning were proposed, no production-grade solution was deployed at the time.
Data Availability Was an Underappreciated Bottleneck
Even before Ethereum’s shift toward rollups, developers encountered problems with how data was posted on-chain.
For applications requiring verifiability, like early L2s or on-chain proofs, data had to be embedded using calldata, which had several issues, like:
- Calldata competed with transaction execution in blockspace, driving up costs.
- It was permanent, contributing to chain bloat and long-term state concerns.
- It lacked structure or specialisation for off-chain consumption.
Rollups, which needed a place to publish transaction batches and proofs, found themselves constrained by a system never designed for scalable data throughput.
The Merge Solved Sustainability, Not Scalability
Ethereum’s 2022 transition to proof-of-stake was a historic upgrade. It has improved energy efficiency by 99.9% and significantly reduced the environmental footprint of the network.
But from a scalability perspective:
- It did not increase transaction throughput.
- It did not reduce gas fees.
- It did not change the architecture that developers had to build around.
The Merge laid the groundwork for future upgrades, but it was only a first step.
That shift began to take hold in 2023 and 2024, as rollups matured and a new paradigm emerged, one where developers no longer built on Ethereum, but next to it.
From L1 to Rollups: The Rollup-Centric Vision Takes Shape
Rollups matured, gained ecosystem dominance, and became the default execution environment. Ethereum L1 moved into its new role: a shared settlement and data availability layer.
Rollups Took Over Application Execution
Instead of trying to scale Layer 1, Ethereum scaled by pushing computation out to Layer 2.
Rollups allowed application execution to happen off-chain while keeping settlement and security rooted on Ethereum.
Rollup adoption was led by two architectural models:
- Optimistic rollups, like Arbitrum and Optimism, used fraud proofs and challenge windows to validate correctness.
- ZK rollups, like zkSync, Scroll, and Starknet, use zero-knowledge proofs for near-instant finality and data compression.
In practice, rollups achieved:
- Lower gas fees are often 10–100x cheaper than L1.
- Higher throughput with independent execution environments.
- Security backed by Ethereum, not standalone trust models.
For developers, this meant building apps that lived off-chain but settled on-chain, shifting the architecture without compromising trust assumptions.
The Rollup-Centric Roadmap Wasn’t Just Theory
Ethereum’s core dev community formalised the vision. Scaling would not happen on L1.
Instead:
- L1 would optimise for data availability and consensus.
- Execution would live on rollups where different VMs, languages, and custom runtimes could evolve independently.
- The protocol would reduce costs and increase bandwidth by separating data from execution.
This wasn’t an experiment. TVL, developer activity, and transaction volume began migrating to rollups in real time.
By late 2024, rollups will process the majority of Ethereum user transactions.
SDKs and Developer Stacks Emerged
As rollups became dominant, tooling followed.
- OP Stack turned Optimism into a modular framework, powering chains like Base and Mode.
- Arbitrum Orbit enabled teams to launch permissionless L3s and app-specific rollups.
- zkStack from zkSync and Polygon CDK offered templates for building zk-powered chains.
This new wave of modular rollup frameworks allowed developers to:
- Deploy rollups with custom configurations like gas models, fee tokens, and governance rules.
- Launch L3s atop existing L2s, optimised for vertical-specific use cases.
- Reclaim control over execution environments, instead of building in shared EVM space.
Ethereum no longer offered one place to build; it offered a network of environments, each optimised for cost, composability, or privacy.
The 2025 Developer Stack: Building in a Modular Ethereum
Developers aren’t just deploying contracts to one chain. They’re making decisions across layers, runtimes, and data systems.
What was once a monolithic environment is now a modular stack that demands clear architectural choices.
Layer 2 Is the Default, Not the Alternative
Rollups are no longer secondary. They're the primary execution layer for most applications. Whether deploying on Arbitrum, Optimism, zkSync, or Scroll, developers now start at Layer 2.
- Arbitrum Stylus expands the EVM with Rust and C, reducing compute costs and supporting performance-heavy logic.
- OP Stack powers a growing Superchain of application-specific L2s that share tooling, bridges, and governance primitives.
- zkSync Era and Scroll bring EVM-equivalent zk-rollups to production, enabling low-latency finality and data compression.
- Starknet and zkVM platforms like RiscZero open up entirely new runtime models for ZK-proven general computation.
Applications are no longer just "on Ethereum." They're settling into Ethereum while executing elsewhere.
App Chains, L3s, and Rollup SDKs: Reshape Deployment Patterns
The rollup boom has introduced Rollup-as-a-Service (RaaS) and customizable SDKs that let teams launch their own execution layers without managing protocol engineering.
- Orbit (Arbitrum) and ZK Stack (zkSync) support permissionless app rollups with full control over fee tokens, governance, and performance.
- Conduit, Caldera, and AltLayer offer production-grade deployment pipelines for L2s and L3s.
- Shared infrastructure is becoming the norm: rollups are launching with pre-integrated bridges, indexers, and oracles.
Instead of deploying contracts to an L2, many teams now deploy the chain itself, optimised for their use case, latency budget, and ecosystem strategy.
The Tooling Stack Has Evolved
With the architecture shift, the development stack has changed as well.
- Foundry remains dominant for Solidity development, with added support for blob simulations and calldata-blobs cost comparisons.
- Viem and Wagmi replace older libraries like Web3.js, offering tighter bundling and better dev ergonomics for modern frontends.
- Blobscan and block explorers now track blobspace and ephemeral data alongside transaction history.
- Cairo, Noir, and zkDSLs are entering mainstream use as ZK-native applications gain traction.
Developer experience in 2025 is fragmented but more powerful. Teams building today are often combining multiple runtimes, data layers, and simulation tools within a single product.
Design Choices Are Strategic, Not Just Technical
Every architecture decision now carries implications.
- Where you execute affects fees, composability, and interoperability.
- Which data layer you choose, like calldata, blobspace, or external DA, determines cost and long-term retrievability.
- What VM you build impacts your language stack, proof system, and developer hiring pipeline.
- How you handle UX wallet abstraction, bridging, or gas sponsorship affects onboarding and retention.
The 2025 Ethereum developer doesn’t just write smart contracts. They design modular systems.
Emerging Challenges in the Modular Era
The modular architecture solves throughput, cost, and flexibility. But it introduces new complexities, especially for teams building at scale.
As rollups and app chains proliferate, developers face a different class of trade-offs: around data, interoperability, composability, and control.
Fragmentation Is the Cost of Flexibility
In a monolithic system, all contracts share the same state and liquidity pool. In a modular world, that coherence breaks down.
- Composability is limited. Calls across rollups aren't synchronous. Cross-chain messages require relays, bridges, or shared sequencers.
- Liquidity is fragmented as bridging assets between rollups add latency and introduce price risk.
- UX suffers as users switching between chains must deal with inconsistent wallets, fees, and interfaces.
Solutions like shared sequencing, atomic bridging protocols, and unified account abstraction are progressing, but full cross-rollup composability remains an open frontier.
Data Availability Isn’t One-Size-Fits-All
The introduction of blobspace via EIP-4844 slashed data posting costs, but also introduced new lifecycle constraints.
Blob data is ephemeral, typically lasting 18 days and isn’t retained by default beyond that window.
Developers now need to choose:
- Blobs: Cost-efficient, ephemeral, great for rollups.
- Calldata: Permanent, expensive, but retrievable.
- External DA layers (EigenDA): Customizable and scalable, but require additional trust assumptions.
Each choice impacts downstream infrastructure like indexing, verifiability, archival access, and compliance.
Security Models Are No Longer Uniform
Ethereum L1’s security guarantees are strong, but not all rollups inherit them equally.
- Optimistic rollups rely on fraud proofs and challenge periods, introducing a time delay and the assumption that someone will monitor and challenge invalid states.
- ZK rollups provide validity proofs, offering faster finality but requiring heavier computation and more advanced tooling.
- L3s and app chains often delegate their security model to their parent rollup, creating new attack surfaces.
Bridges, sequencers, and governance systems introduce additional vectors.
As execution decentralises, application-layer security becomes a shared responsibility between developers, protocols, and operators.
Developer Complexity Has Increased
Modularity gives developers more control. But it also creates more surface area to manage:
- Rollup SDKs evolve rapidly and may break compatibility across upgrades.
- Tooling is fragmented across stacks like Solidity, Cairo, Rust, and zkDSLs, each with its own quirks and build pipelines.
- Monitoring, analytics, and debugging must now span multiple execution layers and data sources.
As modular adoption grows, the challenges have shifted from pure technical limits to coordination and cross-layer complexity.
Ethereum’s next set of upgrades, like full Danksharding, PeerDAS, and statelessness, aims to address these constraints at the protocol level.
Ethereum’s Next Phase: Danksharding, PeerDAS, and the Fusaka Upgrade
EIP-4844 laid the groundwork. Blobs gave rollups cheaper bandwidth. But that was a partial step.
Ethereum’s upcoming upgrades represent a full re-architecture of the base layer, turning it into a scalable DA backbone for modular ecosystems.
Full Danksharding Will Scale Blobspace, Not Execution
Unlike traditional sharding proposals, Ethereum isn’t trying to shard execution. The goal is to scale data availability.
That’s where full Danksharding comes in.
- Each block will support dozens of blobs, instead of the current limit of 6 to 8.
- These blobs won’t be validated by every node. Instead, Ethereum will use data availability sampling (DAS), which is a cryptographic method where nodes verify data integrity by checking random parts of each blob.
- More blobspace means rollups can post more data, faster, and at even lower cost.
This design preserves network composability by separating data availability from execution.
PeerDAS Will Make Sampling Scalable
To support DAS at scale, Ethereum is adopting a peer-optimised protocol like PeerDAS (Peer-to-Peer Data Availability Sampling).
- Instead of broadcasting full blobs to all validators, blobs are distributed in chunks over a P2P network.
- Validators only need to verify partial data, dramatically reducing bandwidth and storage overhead.
- This allows Ethereum to scale blobspace while keeping validator hardware requirements low.
PeerDAS is already in testing and will be a key milestone on the path to full Danksharding.
Verkle Trees and the Fusaka Upgrade
Ethereum’s global state has grown large enough to slow down node syncs and increase validator costs.
To address this, Ethereum will adopt Verkle trees as part of the Fusaka upgrade, a major protocol change focused on state efficiency.
Verkle trees reduce proof sizes dramatically, enabling stateless clients.
- Validators no longer need to store the full state, only verify blocks using compact proofs.
- This will lower resource demands and allow nodes to run on lightweight hardware.
The Fusaka upgrade is a critical step toward Stateless Ethereum, unlocking broader validator participation, faster syncs, and better decentralisation, while preparing Ethereum to serve as a high-throughput DA layer.
Shared Sequencing and Cross-Rollup Coordination Are on the Horizon
Execution layers are scaling independently, but without a shared sequencing layer, composability across rollups remains constrained.
Several efforts are underway to solve this:
- Shared sequencer networks aim to coordinate block production across rollups, enabling atomic cross-chain transactions.
- Interoperability protocols using ZK proofs are exploring faster, trust-minimised bridging.
Ethereum isn’t scaling by increasing TPS on a single chain; it’s scaling by re-architecting how data flows, how state is verified, and how computation is decoupled from consensus.
The result is a base layer optimised for thousands of rollups and ZK-powered systems, all secured by Ethereum’s trust layer.
For developers, this shift demands a new approach that treats architecture, cost modelling, and system design as first principles.
Here’s what that blueprint looks like in 2025.
Your 2025 Developer Blueprint: Architecture, Costs, and Strategic Choices
Developers in 2025 aren’t just choosing what contracts to write. They’re choosing where to execute, how to store data, what sequencing model to rely on, and which trade-offs to accept around cost, performance, and control.
This section lays out the architectural blueprint for building modular, future-ready applications in the current Ethereum landscape.
Select the Right Execution Environment Based on Use Case
In 2025, developers must treat execution layers like infrastructure layers, not just deployment targets. Each layer offers distinct properties around cost, latency, composability, and sovereignty.
- General-purpose L2s like Arbitrum One, Optimism, Base, zkSync Era, and Scroll are ideal for teams looking to plug into deep liquidity, existing dev tooling, and composable DeFi ecosystems.
- App-specific L2s or L3s offer full control. Teams can tailor fee markets, deploy with custom tokens, adjust block times, or experiment with governance logic, all without sacrificing Ethereum’s trust layer.
- zkVM-based platforms (Starknet, RiscZero, Polygon zkVM) unlock verifiable computation and low-latency finality, often suited for privacy, AI inference, or trust-minimised cross-chain operations.
Strategic framing:
- Prioritise general-purpose rollups if you want composability and fast iteration.
- Move to L3 or app-chain models when you need vertical control, performance tuning, or economic sovereignty.
- Choose ZK environments when provable execution or on-chain privacy is core to your value proposition.
Reframe Cost Modelling for the Blob-Native Era
EIP-4844 fundamentally changed the economics of posting data to Ethereum. But it also added complexity.
- Blob storage is temporary. It’s cost-efficient (~10x cheaper than calldata), but only persists for ~18 days. This means rollups must implement external data archiving or DA redundancy if they require long-term access.
- Sequencer economics vary across ecosystems. Some rollups are exploring MEV capture, inclusion fees, or revenue-sharing schemes. Others rely on centralised sequencer operators with opaque fee schedules.
- Operating your own chain or L3 introduces infrastructure overhead: running sequencers, indexing chains, monitoring uptime, and integrating bridges.
Don’t just model contract deployment and gas fees; model long-term operational costs. Understand how data, throughput, and user volume impact infrastructure and blob consumption.
Structure Smart Contracts for Layer-Aware Execution
In a multi-layer system, your architecture must reflect execution locality. The days of deploying a single monolithic contract suite to Ethereum L1 are over. Today:
- Settlement and consensus logic should live on Ethereum L1, e.g., staking contracts, DAO treasuries, and arbitration.
- High-frequency app logic like trading engines, game loops, and social graphs should live on L2s or L3s, where execution is cheaper and faster.
- Cross-layer communication should use verifiable bridges like ZK or optimistic messaging.
For creating it separate logic based on volatility, frequency, and trust assumptions. This keeps core state secure while letting the rest scale horizontally.
Align Tooling, Language, and Audit Strategy with Stack Choice
Tooling decisions follow from execution environment selection. Each stack has a different language, ecosystem maturity, and audit surface.
- Solidity remains the default for EVM-compatible rollups and most L2s.
- Rust and C are gaining traction through Arbitrum Stylus and some zkVM frameworks.
- Cairo is required for Starknet.
- zkDSLs like Noir are powering ZK-native dApps and ZK-powered features.
Beyond language:
- Use Foundry or Hardhat for EVM.
- Viem, Wagmi, and Ethers for frontend interactions.
- Blobscan, The Graph, or Subsquid for blob-indexed or rollup-specific data infrastructure.
Audit requirements differ by VM and runtime. Cairo contracts introduce unique auditing challenges due to custom opcodes and trace-based execution.
Design UX Around Modularity From Day One
Fragmentation in the modular stack introduces friction for users. Developers must abstract it away.
- Bridge flows should be backgrounded, fast, and verifiable. Avoid manual token transfers between chains wherever possible.
- Wallet abstraction is critical. Use account abstraction frameworks, e.g., ERC-4337, native AA from zkSync to reduce onboarding steps.
- Gas sponsorship and native fee abstraction are becoming the norm. Let users interact without managing multiple tokens across chains.
Operational must-haves:
- Simulate multi-layer transactions before mainnet deployment.
- Monitor latency across bridges, sequencers, and relays.
- Implement fallbacks for blobs and off-chain data retrieval.
Plan for Interoperability and Cross-Layer Growth
Teams rarely stay isolated to one execution layer. Successful products in 2025 are planning for:
- Multi-rollup deployments
- Cross-chain liquidity bridges
- Inter-chain messaging and shared sequencers
Design your architecture, tokens, and indexing with this evolution in mind, even if your MVP starts on a single rollup.
Building on Ethereum in 2025 requires system-level decisions, choosing the right layers, structuring execution for scale, managing data lifecycles, and abstracting UX across fragmented environments.
The modular stack offers flexibility, but it rewards teams who plan for complexity early. Developers who design with locality, interoperability, and long-term cost in mind won’t just ship faster, they’ll build systems that last.
Closing Thoughts: Ethereum Isn’t Scaling Up, It’s Scaling Out
Ethereum’s scalability journey isn’t about making a single chain faster; it’s about building a layered system where execution, data, and consensus live independently but work in sync.
Rollups, blobs, app-specific chains, and ZK runtimes have shifted the developer model. You’re no longer building on Ethereum, you’re building next to it, using it as a secure, modular foundation.
What matters now is architectural clarity:
- Where does your logic run?
- How do you handle data availability?
- What trade-offs are you making on cost, latency, and composability?
