The Fundamental Shift in Blockchain Architecture
The blockchain industry is undergoing a profound architectural transition. For years, systems like Ethereum packaged execution, consensus, and data availability into a single monolithic layer. This approach simplified design but created hard tradeoffs: throughput suffered because every validator had to execute every transaction and store every byte of data. The scalability ceiling became apparent as transaction costs climbed and block times remained bounded by consensus limitations.
The modular approach inverts this assumption. Instead of forcing all operations into one canonical layer, modular chains separate concerns into distinct roles. One layer handles execution (computing state transitions), another reaches consensus on which transactions are valid, and a third provides persistent data availability guarantees. Each layer optimizes for its specific function rather than compromising to fit a unified design. This separation is not merely theoretical; it reshapes how blockchain systems scale, how developers build applications, and where real economic constraints move.
By 2026, this transition has moved beyond blockchain research papers and experimental networks. Production systems in use today bear the scars of monolithic limitations, and the modular paradigm has proven itself in live networks handling real economic activity. Understanding this shift is no longer optional for developers shipping blockchain systems.
How Monolithic Blockchains Constrain Scalability
Monolithic blockchains like Ethereum operate under a unified security model. Every full node must validate every transaction, execute every smart contract, and store the entire state of the network. This design provides simplicity and ensures that any participant can audit the system end-to-end. However, it creates an inescapable bottleneck.
When a monolithic chain increases its block size or decreases its block time to process more transactions, the bandwidth and computation requirements for running a full node increase proportionally. A user who might run a full node on consumer hardware today cannot do so if block size doubles. This forces centralization: fewer participants can afford the infrastructure to validate blocks, and the network's security guarantees degrade. The monolithic design locks scalability and decentralization into a zero-sum game.
Ethereum addresses this constraint through Layer 2 rollups, which batch transactions off-chain and post compressed proofs or transaction data back to Ethereum. Rollups inherit Ethereum's security assumptions, but they do so by treating Ethereum as a rigid settlement layer. The throughput gains come at the cost of additional complexity, liquidity fragmentation across multiple rollups, and bridging risk. The fundamental monolithic architecture remains unchanged.
Performance becomes measurable in hard numbers. Ethereum's network today processes approximately 15 transactions per second on Layer 1, with a 12-second block time and approximately 32 GB of annual state growth. Every full node must keep up with this rate. A monolithic system cannot increase these numbers without asking node operators to upgrade hardware continuously.
The Three Layers of Modular Architecture
Modular blockchain design splits responsibilities across three distinct layers, each with its own constraints and optimization targets.
Execution Layer
The execution layer is where state transitions occur. Smart contracts execute, balances update, and applications run. The execution layer does not participate in consensus. Instead, it takes transactions from another source, processes them in a deterministic order, and outputs a new state root. This separation means the execution layer can process transactions as fast as the hardware allows, without waiting for a blockchain's consensus mechanism to reach agreement.
An execution environment can be deployed as a separate chain (called an execution chain), or it can exist as a rollup that settles to another chain. What matters is the split: execution is now independent of the consensus process that secures the network. Different execution layers can have different virtual machines, different programming languages, different fee models, or different design philosophies. Solana uses a different execution model than Ethereum; Arbitrum's execution layer has different characteristics than Optimism's. None of them are forced to conform to a single standard because execution is no longer bundled with consensus.
The execution layer's performance ceiling is determined by hardware capability and the complexity of the transactions it processes. A sufficiently powerful machine can execute more transactions per second than any monolithic blockchain's consensus layer can validate and finalize. This decoupling is the core insight that makes modular scaling possible.
Consensus Layer
The consensus layer determines which transactions are valid and in what order they occur. It does not execute transactions itself. Instead, the consensus layer reaches agreement on the ordering of transactions that the execution layer will process.
In Ethereum's current monolithic model, consensus and execution are tightly coupled. Validators run the same virtual machine, execute the same transactions, and verify that the execution is correct. In a modular system, the consensus layer only cares about the ordering and authenticity of transaction data. Consensus reaches agreement on a commitment to transaction ordering without executing transactions itself.
This separation allows the consensus layer to be simpler and faster. It can use a leaner protocol because it no longer needs to validate the computational correctness of every transaction. Proof of validity can be delegated to the execution layer, which produces cryptographic proofs that the execution was correct. The consensus layer verifies the proof, not the computation.
Consider the difference in burden: a monolithic validator must have enough resources to execute every contract call in the network. A consensus-layer validator only needs to reach agreement on transaction ordering and verify lightweight proofs from the execution layer. The consensus layer scales differently because it has fundamentally different work to perform.
Data Availability Layer
The data availability layer guarantees that transaction data exists and is accessible to anyone who needs it. This layer does not execute transactions or reach consensus. It stores transaction data and provides a commitment that the data can be retrieved.
In a monolithic blockchain, every full node stores all transaction history. This requirement ensures data availability trivially: if every node has the data, it is certainly available. However, this is an expensive solution that grows with every transaction.
A modular system can separate the data availability commitment from the requirement that every node store all data. Technologies like data availability sampling allow light clients to verify that data is available by sampling a small random subset of it. The full data exists somewhere in the network, but no individual node needs to store it all. This makes data availability a scalable property rather than a bottleneck.
The Ethereum beacon chain provides consensus for Ethereum mainnet. A dedicated data availability layer could provide data availability for multiple execution chains that build on top of it. Each execution chain is independent, but they all inherit the same security assumption about data availability.
Ethereum's Current Position: L2-Centric Monoliths
Ethereum itself remains fundamentally monolithic in its architecture. It executes transactions, reaches consensus on them, and stores the data that proves what happened. Layer 2 rollups build on top of Ethereum by batching transactions and posting them back to Ethereum's Layer 1.
This design is not accidental. Ethereum's monolithic architecture provides security and censorship resistance that early blockchain systems required. Running a full node is difficult but possible on consumer hardware. Ethereum processes enough transactions per second to serve as a settlement layer for higher-level protocols. It is decentralized enough that no single entity can stop it.
Rollups exploit a key fact: they can prove that a batch of transactions was executed correctly without Ethereum needing to execute those transactions itself. An optimistic rollup (Arbitrum, Optimism) posts transaction data and a state root to Ethereum. If no one disputes the state root within a challenge window, the rollup assumes it is correct. If someone disputes it, Ethereum can re-execute a subset of transactions to determine the truth. A ZK rollup (StarkNet, zkSync) posts a cryptographic proof of correct execution. Ethereum verifies the proof without executing anything.
Both approaches turn Ethereum into a settlement and data availability layer. This is a powerful position, but it is not a clean modular separation. Ethereum's execution layer still processes transactions, still validates them, and still stores state. The rollups are an add-on, not a fundamental architectural redesign.
By 2026, Ethereum's roadmap includes Proto-Danksharding and Danksharding, which optimize Ethereum for the role of data availability layer. The Ethereum Execution Layer (EL) and Beacon Chain continue to handle consensus. Rollups build on top of this unified stack. This is an evolution toward a more modular model, but Ethereum remains a monolithic base layer with modular scaling on top of it.
True Modular Chains: Sovereign Rollups and Beyond
Some blockchain systems have committed to a more radical modular separation. Sovereign rollups, which gained prominence through frameworks like Rollkit and projects built on Cosmos, implement execution and consensus separately but do not rely on an external consensus layer for security.
A sovereign rollup typically uses Celestia or similar systems for data availability. The rollup reaches its own consensus independently, either through a validator set or through a different consensus mechanism. When the rollup creates a block, it posts the data to the data availability layer. As long as the data is available, the rollup can prove its history and state to external observers. The data availability layer does not validate the rollup's state transitions or consensus; it only ensures the data exists.
This design decouples execution from consensus entirely. The rollup's validators execute transactions and reach consensus on the ordering. A separate, lighter-weight process proves that the data is available. The system is fully modular: execution, consensus, and data availability are three separate concerns.
The security tradeoff is real. A sovereign rollup does not inherit the security of an external consensus layer. Instead, it must maintain its own security through its own validator set or consensus mechanism. A rollup with few validators is more vulnerable to attack than a system with many validators. However, this design also provides flexibility: a rollup can upgrade its consensus mechanism or change its validator set without requiring approval from an external chain. It is truly sovereign.
Cosmos chains exemplify this approach. Each zone in the Cosmos ecosystem runs its own execution layer and reaches its own consensus. Many zones use Interchain Security to borrow consensus security from the Cosmos Hub, but they are not required to. The Hub provides a data availability layer through Inter-blockchain Communication (IBC), but each zone remains sovereign.
Rollkit enables developers to build these kinds of chains using familiar frameworks. Rollkit wraps rollup execution in a standard Cosmos SDK application and handles the communication with a data availability layer. Developers write smart contracts or applications using Solidity or the Cosmos SDK, deploy to a rollup, and let Rollkit handle the modular plumbing.
The Data Availability Problem and Solutions
Data availability is often the most misunderstood aspect of modular architecture. When execution and consensus are separated from data storage, someone must guarantee that the data continues to exist and is retrievable.
In a monolithic blockchain, full nodes store all historical data, and all current state. This provides data availability as a side effect: the data must be available because the nodes store it. However, it does not scale. If millions of transactions occur daily, the state and history grow continuously. A new node joining the network must download terabytes of data.
A modular system must explicitly address data availability. One solution is to designate a separate set of nodes whose job is to store and serve data. These nodes do not execute transactions or reach consensus. They receive data from the execution and consensus layers, store it, and serve it to anyone who requests it.
Celestia implements this with data availability sampling. Celestia validators download only a small random sample of each block instead of the entire block. Through the mathematics of erasure coding, sampling allows light clients to verify that the full block is available without downloading the whole thing. If the data is truly available, a client sampling 1% of the block can confidently verify availability. If the data is missing a significant portion, the sampling will detect it with high probability.
This design allows Celestia to scale the amount of data it can commit to per block without forcing every validator to download terabytes. Validators instead download kilobytes of samples and verify cryptographic commitments.
Other data availability solutions exist. EigenLayer provides data availability through a network of operators that stake cryptocurrency. If an operator claims data is available but it actually is not, the operator loses its stake. This creates economic incentives for honest behavior without requiring every operator to store all data.
Avail, created by Polygon and later transferred to a foundation, uses a similar sampling technique to Celestia but with different economics and validator incentives.
The choice of data availability layer affects the cost, security model, and throughput of the entire system. A rollup on Celestia pays Celestia's fees for data. A rollup using Ethereum as a data availability layer pays Ethereum's fees. The modular architecture allows rollups to choose their data availability provider based on their specific cost and security requirements.
How Modular Architecture Changes Developer Experience
For developers building applications, the modular shift reshapes how they deploy and scale systems.
In a monolithic model, a developer writes a smart contract and deploys it to a single chain. If the chain reaches capacity and transaction fees rise, the developer must convince the chain's community to increase capacity, or migrate to a different monolithic chain (Polygon, Avalanche, etc.). Migration requires redeploying contracts, managing liquidity across chains, and dealing with bridging risk.
In a modular system, developers have more choices. If Ethereum Layer 1 becomes expensive, a developer can deploy to an Optimistic Rollup like Arbitrum or Optimism, which settles to Ethereum. If the rollup becomes congested, the developer can deploy to multiple rollups simultaneously and use bridges to provide liquidity. If none of the Ethereum-based options meet their needs, they can deploy to a sovereign rollup like a Cosmos zone or a Rollkit-based chain.
The modular architecture also enables experimentation. A developer can test a new execution environment or consensus mechanism without needing to coordinate with a global set of validators. A rollup can choose to use a ZK proof system instead of optimistic proofs if the tradeoffs suit their application. A Cosmos zone can experiment with a custom virtual machine without modifying the Cosmos SDK.
However, this flexibility comes with fragmentation. Liquidity becomes split across multiple rollups. A user might hold tokens on Arbitrum, Optimism, and a standalone Cosmos zone simultaneously. Bridges enable liquidity flow, but bridges introduce counterparty risk. This is the tradeoff the modular paradigm introduces: scalability and flexibility at the cost of liquidity concentration and cross-chain complexity.
Economic Incentives and Fee Markets
Modular architecture changes how fees are distributed across layers and how economic incentives function.
In a monolithic blockchain, the fee market is centralized. Users compete in a single fee pool. Miners or validators determine which transactions are included based on the fees offered. All fees are collected and distributed to the security providers at that layer.
In a modular system, fees are distributed across layers. A user's transaction might generate fees for the execution layer (if it is a rollup), for the consensus layer (if it uses an external consensus), and for the data availability layer. Each layer has its own fee market and its own incentive structure.
Consider a transaction on Arbitrum, which posts to Ethereum. The transaction pays fees to Arbitrum sequencers for inclusion and execution. The batch is posted to Ethereum, where it competes in Ethereum's fee market for block space. The batch also uses Ethereum data availability, so the cost includes the cost of posting data to Ethereum. The total cost is the sum of these fees, and each component has its own market dynamics.
This separation creates new economic properties. As Ethereum's Layer 1 becomes more expensive, the advantage of posting to a rollup increases. The data availability layer's fee market becomes decoupled from the execution layer's fee market. If the execution layer is congested but data is cheap, transactions can be batched efficiently and posted cheaply.
However, the separation also introduces inefficiency. A single-layer system achieves better capital efficiency for its security providers because all fees go to one place. A modular system distributes fees, which means each layer must attract enough fees to incentivize security provision independently. In practice, this means the total fees paid across modular layers may exceed the fees of a monolithic system processing the same transaction volume, because each layer must maintain its own economic security.
By 2026, most transaction volume on Ethereum occurs on Layer 2 rollups, and this fee distribution pattern is well-established. The economic reality is clear: execution layers (rollups) can charge low fees, pushing users toward them. Data availability and settlement on Ethereum remain the costlier components of the transaction.
Security Implications of Modularity
Modular architecture changes how security is maintained and where risks emerge.
A monolithic blockchain's security comes from the difficulty of attacking the entire system: an attacker would need to compromise the execution layer, the consensus layer, and the data layer simultaneously. If one component is secure, the whole system is secure. The security model is unified.
A modular system's security is only as strong as its weakest modular layer. If the data availability layer is compromised, even an execution layer with perfect security can be attacked. An attacker could prove false execution results if the data that would expose the lie is unavailable. The security is now multiplicative: every layer must be secure for the whole system to remain secure.
This creates new attack surfaces. The data availability layer must be secured against attacks that specifically target availability rather than validity. An attacker does not need to prevent the correct data from existing; they only need to make it inaccessible. This is a different threat model than traditional Byzantine fault tolerance, which assumes an attacker can forge arbitrary data but cannot delete data from the majority of honest nodes.
Solutions like Celestia address this with data availability sampling, which makes large-scale data deletion attacks expensive and detectable. However, the attack surface still exists and requires explicit defense.
Another security concern emerges from the separation of execution and consensus. An execution layer that relies on an external consensus layer must trust that the consensus layer is operating correctly. If the consensus layer is under attack, an execution layer building on top of it inherits that vulnerability. Sovereign rollups face this differently: they must maintain their own consensus security, which is harder than borrowing security from an established layer.
Bridges between modular layers introduce additional risk. A bridge is a smart contract that locks tokens on one chain and mints them on another. If the bridge is exploited, users lose funds. As of 2026, bridge security remains an unsolved category of risk. Each modular system must implement bridges carefully, and users must understand the risk they are accepting when moving value across a bridge.
The 2026 Landscape: Dominance and Experiments
By 2026, the modular paradigm is not theoretical. Several systems are live and handling real transaction volume.
Arbitrum and Optimism are the largest Optimistic Rollups on Ethereum. Both run independent execution layers, post transaction data and state roots to Ethereum, and rely on Ethereum for data availability and settlement. Together, they process more daily transaction volume than Ethereum Layer 1. Their economics and operation are well-understood by developers.
Polygon operates as a separate monolithic chain with its own validators and consensus, but it also recently announced a shift toward an AggLayer that aggregates multiple Polygon Chains, moving toward a more modular model where individual chains can be more lightweight.
Solana remains a monolithic chain, but its execution performance is comparable to or better than most rollups. Its validators handle execution and consensus in a tightly coupled design that prioritizes speed.
Cosmos is the most developed modular ecosystem. Multiple zones (Osmosis, Juno, Stargaze, Stride) run as sovereign chains with their own execution and consensus, often using Cosmos for data availability through Inter-blockchain Communication. Rollkit is emerging as a tool for developers to build these chains more easily.
Celestia has become the primary standalone data availability layer. It reached mainnet in 2024 and has processed gigabytes of data from rollups building on top of it. Its existence proves that data availability as a separate layer is feasible at scale.
StarkNet, an Ethereum-based ZK rollup, uses Cairo as its execution environment, which is fundamentally different from the EVM. This demonstrates that modular architecture allows execution environments to diverge without losing compatibility with the rest of the system.
Experiments continue. Fuel is building a modular execution layer and exploring new virtual machine designs. Espresso is developing a data availability and consensus layer specifically designed for modular systems. Eigenlayer is enabling Ethereum validators to provide services for other modular layers without abandoning Ethereum.
By 2026, the modular paradigm is the dominant architectural direction for new blockchain systems. Monolithic blockchains still exist and still secure significant value, but the innovation and growth is happening in modular designs.
Tradeoffs: When Monolithic Makes Sense
Despite the dominance of modular thinking, monolithic designs still have advantages.
A monolithic blockchain is simpler to understand. The security model is unified. There is one place to look to understand how the system works. For a user, this simplicity is valuable. A user on Ethereum knows that their transaction was executed, validated, and finalized by the same set of validators. The trust model is clean.
Monolithic blockchains may be more capital-efficient for security provision. A single set of validators secures execution, consensus, and data. They are not duplicating security work across multiple layers. If a system can achieve monolithic simplicity without sacrificing scaling ability, it might be more efficient than a modular system.
Monolithic blockchains with very high throughput (like Solana or a hypothetical future Ethereum with much larger blocks) can serve applications that do not require modular scaling. If a single layer can process all transaction demand at acceptable costs, adding modular complexity adds no value.
However, as of 2026, most monolithic blockchains have not achieved the throughput and cost profile that makes them clearly superior to rollups. Solana's throughput is higher than Ethereum's, but it sacrifices decentralization. Ethereum Layer 1 remains slow and expensive. Monolithic designs remain useful for specific niches, but they are not the direction of industry growth.
Implementation Patterns for Modular Systems
Developers building on modular systems use several established patterns.
Rollup as Execution Layer
A rollup is a chain that runs on top of another chain for settlement. The rollup maintains its own sequencer and execution environment. Transactions are ordered by the sequencer, executed off-chain, and batched. The batch is posted to the settlement layer along with a proof or state root. The settlement layer verifies the batch or stores the data for later verification.
Arbitrum uses a sequencer that batches transactions and posts them every few seconds. Optimism does the same. Both chains process transactions at full speed off-chain, then settle in batches to Ethereum.
Implementing a rollup requires a sequencer, a node operator that can execute transactions, a bridge contract on the settlement layer, and some mechanism for users to withdraw value from the rollup back to the settlement layer.
Sovereign Rollup with Rollkit
A sovereign rollup uses Rollkit to handle communication with a data availability layer. The developer writes a blockchain using the Cosmos SDK, and Rollkit wraps it for deployment on top of Celestia or another data availability layer.
The developer's blockchain reaches consensus on its own (either with a validator set or through another consensus mechanism) and executes transactions using the Cosmos SDK virtual machine. Rollkit ensures that blocks are posted to the data availability layer. Users run light clients that verify availability and check state proofs locally.
This pattern reduces the burden of building a blockchain. The developer does not need to implement consensus, data availability, or light client verification. Rollkit and the data availability layer provide these primitives.
Shared Sequencing and MEV Management
A problem emerges in modular systems: who orders transactions at the execution layer? In a monolithic blockchain, the consensus layer orders transactions. In a rollup, a sequencer makes ordering decisions. If the sequencer is a single entity, it can extract maximum extractable value (MEV) by reordering transactions for profit.
Shared sequencers (being developed by projects like Espresso and MerlinChain) provide a service layer that orders transactions for multiple rollups. The shared sequencer reaches consensus with other sequencers, creating a fairer and more decentralized ordering service. Multiple rollups can use the same shared sequencer without needing to bootstrap their own consensus.
This is a new pattern specific to modular systems. A shared sequencer is not a settlement layer or a data availability layer; it is a specialized service layer that sits between execution and consensus.
Looking Forward: The Modular Stack of 2026 and Beyond
By 2026, it is clear that most new blockchain systems will be modular. The architectural advantages are too significant to ignore. However, the exact configuration of modular stacks varies.
Ethereum remains the dominant settlement and data availability layer for Layer 2 rollups. Its position provides network effects and security advantages that are hard to replicate. However, Ethereum's dominance is not universal. Alternative data availability layers like Celestia, Avail, and EigenLayer are competing to serve rollups that do not require Ethereum's security.
The execution layer is where fragmentation is most intense. Each rollup optimizes for different tradeoffs. Arbitrum prioritizes compatibility with Ethereum tooling and the EVM. Optimism makes similar choices. StarkNet uses Cairo to enable more efficient ZK proofs. Other rollups experiment with different virtual machines, different programming languages, and different execution models.
Consensus is increasingly decoupled from execution. Rollups do not need their own consensus; they can rely on external consensus or sampling-based availability proofs. This reduces the burden of building a blockchain and allows execution layers to compete on execution speed and developer experience rather than consensus mechanism.
The modular paradigm is likely to continue evolving. New data availability schemes may emerge. New execution environments may become dominant. The exact stack may change. However, the principle that execution, consensus, and data availability should be independent layers is now established and unlikely to reverse.
For developers, this means opportunity and complexity. Opportunity because new tools and frameworks make it easier to build blockchain systems. Complexity because choosing the right stack for a specific application requires understanding the tradeoffs across multiple layers. The days of deploying to "the blockchain" are over. Developers now must choose: which execution layer, which consensus mechanism, which data availability provider, and how do they combine into a coherent system for their application's needs.
If you are building blockchain infrastructure or shipping applications on modular systems, I provide professional Web3 documentation and full-stack Next.js development work; you can view my Fiverr profile at https://fiverr.com/meric_cintosun.
Top comments (0)