Key Insights: 

• Layer 2 fees fell over 95% as modular execution eased Ethereum network congestion.
• Security remains conditional on accessible data, valid proofs and controlled upgrades.
• Base, OP Mainnet and Celestia show scale improves when verification stays robust.

Modular blockchains are often described as a way to scale without weakening security, but their guarantees depend on how different layers interact. The basic approach is to split blockchain functions into separate layers so no single system must do everything.

This specialization improves efficiency, but it also redistributes trust assumptions. Instead of one monolithic system securing everything, modular systems rely on multiple components that must each behave correctly. The result is not automatic security loss but a more complex security model that depends on coordination between layers.

Ethereum rollups are the clearest real-world example of this design. Optimistic rollups like Arbitrum and OP Mainnet, and ZK rollups like zkSync Era, all execute transactions off-chain while posting compressed data or proofs back to Ethereum for settlement. Ethereum documentation explains that rollups inherit Ethereum’s security when data is published on-chain and disputes can be resolved through fraud or validity proofs.

The key question is not whether modularity increases throughput—it clearly does—but whether the added complexity introduces new failure points that are harder to reason about and govern.

The Core Trade-Off: Efficiency vs. Trust Distribution

At the heart of modular design is a trade-off between computational efficiency and trust distribution. By moving execution off the base layer, systems reduce congestion and cost. However, they also shift responsibility for correctness to mechanisms like fraud proofs, validity proofs, and data availability guarantees.

For example, OP Mainnet relies on optimistic fraud proofs, where invalid state transitions can be challenged during a dispute window. Arbitrum One uses a similar optimistic model, where correctness is assumed unless proven otherwise. In contrast, ZK rollups like zkSync Era attach cryptographic validity proofs to each batch, removing the need for long challenge periods.

Security is therefore no longer concentrated in a single validator set. It is distributed across multiple verification systems that must remain independently reliable. If any one layer becomes weak—especially data availability or dispute resolution—the entire system’s guarantees degrade.

This is why modular scaling is better understood as secure only under a defined set of assumptions.” Those assumptions include honest participation in challenge systems, reliable data publication, and stable governance controls.

Why Data Availability Is the Critical Constraint

Among all modular components, data availability is the most sensitive. Execution can be verified later, but only if the underlying transaction data is accessible. Without it, users cannot reconstruct state or prove fraud.

Ethereum currently serves as the primary data availability layer for many rollups. However, newer systems like Celestia are designed specifically to provide data availability without execution. Celestia uses data availability sampling, allowing light nodes to verify that data is available without downloading full blocks.

The resulting constraint is fundamental: scaling remains safe only when the underlying data stays reliably available. Systems that reduce data redundancy or outsource storage must compensate with strong cryptographic or economic guarantees.

Different designs handle this differently. Ethereum rollups rely on Ethereum calldata or blob space introduced by EIP-4844 (proto-danksharding), which reduces data costs for rollups. Celestia instead separates data availability entirely from execution. Each approach reduces cost, but each also introduces a different trust assumption about who must remain honest or available.

Fault Proofs and the Reality of “Conditional Security”

Fault proofs and validity proofs are often presented as the backbone of modular security. In practice, they define conditional security: the system is secure only if participants actively challenge invalid state or if proofs are correctly generated and verified.

For example, Optimism’s OP Stack introduced permissionless fault proofs to allow anyone to challenge invalid state transitions. Similarly, Arbitrum’s Nitro upgrade strengthened its fraud-proof system to improve dispute resolution guarantees.

This creates a time-dependent security model. During normal operation, users rely on sequencers like those operated by Base or OP Mainnet. During disputes, they rely on cryptographic or game-theoretic mechanisms to correct errors.

However, these systems are not purely automatic. They depend on incentives, participation, and governance. If challenge systems are underused or if upgrade mechanisms are too centralized, the theoretical security guarantees weaken in practice.

Governance as a Hidden Security Layer

A less visible but critical component of modular security is governance. Upgrade keys, parameter changes, and emergency controls can override or bypass parts of the system. For instance, many rollups—including Base (built on OP Stack)—retain upgrade keys controlled by governance councils or foundations. These keys can modify system parameters or upgrade contracts, which introduces a trust assumption beyond cryptography.

Base illustrates the effect at an application scale. BaseScan recorded a record of 20,767,612 transactions on June 5, 2026. Yet Base does not run an entirely separate security system. It uses the OP-Stack, posts data to Ethereum, and introduced permissionless fault proofs in October 2024. In April 2025, Base said it had reached Stage 1 decentralization, allowing anyone to propose or challenge claims about its state. Withdrawals to Ethereum still carry a seven-day challenge period, which slows exits but gives the fault-proof process time to reject invalid state claims.

This introduces a second layer of trust: even if cryptographic systems function correctly, governance decisions can still alter security assumptions. In some cases, this is necessary for responsiveness and bug fixes. In others, it becomes a centralization risk.

As a result, modular security is not only about cryptography or consensus design. It is also about how much authority operators retain over system evolution.

Scaling Without Simplifying the System

The main promise of modular blockchains is that scaling no longer requires increasing the complexity of a single system. Instead, complexity is distributed across layers. Real-world systems illustrate this clearly. Ethereum L2 ecosystems like Arbitrum, Optimism, and Base now process far more transactions than Ethereum L1 alone, while relying on Ethereum for settlement. Meanwhile, Celestia-based rollups experiment with separating data availability entirely from execution.

But distribution does not eliminate complexity—it relocates it. Users and developers must now reason about multiple interacting systems, each with its own failure modes and trust assumptions.

This is why modular scaling is best understood as a re-architecture of security rather than a reduction of it. It improves performance, but it also demands more careful design, monitoring, and governance discipline.

Conclusion: Security Becomes a System of Dependencies

Modular blockchains do not remove security constraints—they reorganize them. Execution becomes cheaper, throughput increases, and systems become more flexible. But security is no longer a single property of one chain.

Instead, it becomes a network of dependencies: Ethereum as a settlement layer, rollups like Arbitrum and OP Mainnet for execution, Celestia for data availability, and governance systems for upgrades all contribute to final guarantees.

The result is a more scalable architecture, but also a more conditional one. Whether modular blockchains can keep scaling safely depends less on individual components and more on how reliably those components continue to work together under stress.