Historically, blockchains functioned as unified entities managing all tasks. The modular approach divides these responsibilities into separate layers for execution, settlement, consensus, and data availability. This guide clarifies the structure of the new stack, the need for a data layer for rollups, and the benefits and drawbacks associated with this design.
Summary
- Modular blockchains distribute execution, settlement, consensus, and data availability tasks across specialized layers to improve scalability.
- Rollups process transactions off the primary chain while utilizing shared settlement and data availability layers for security.
- This modular strategy offers greater flexibility and throughput, though it may introduce complexity, fragmentation, and varied trust assumptions.
A modular blockchain separates a network’s essential tasks into distinct, specialized layers instead of relying on a single chain to manage them all. To understand this paradigm shift, it’s essential to recognize the four critical functions a blockchain performs: execution—processing transactions and smart contracts; settlement—finalizing results and resolving disputes; consensus—confirming the order of transactions; and data availability—ensuring transaction data is accessible for verification.
Traditionally, monolithic blockchains executed all four functions within one chain. While straightforward and tightly integrated, this approach faces scalability limitations. It can only maintain speed until congestion or costs rise. The modular paradigm disassembles these functions, enabling various layers to specialize in individual tasks, making it the preferred method for scaling ambitious blockchains. This guide describes the four primary functions, contrasts monolithic and modular frameworks, explains the synergy between rollups and data availability layers, highlights prominent examples, and discusses the tangible trade-offs linked to this modular trajectory.
This distinction is crucial, as scalability has shaped the blockchain landscape for a decade, summarized in the so-called trilemma: the challenge of a single chain to be scalable, secure, and decentralized all at once, often sacrificing one trait. Monolithic chains typically enhance scalability at the expense of decentralization or prioritize decentralization, impacting speed.
The modular thesis proposes an alternative to this trilemma. With no single chain managing everything, each layer can optimize its specific function, allowing the overall system to achieve scalability levels unattainable by monolithic chains while retaining robust security and decentralization where most needed.
By 2026, this principle transitioned from theory to leading architecture, characterized by specialized data availability networks supporting numerous execution chains, effectively creating a comprehensive suite of modular components in action. Thus, understanding the modular design is crucial for comprehending the future direction of blockchain infrastructure.
The Four Jobs of a Blockchain
An understanding of modularity hinges on recognizing the four primary functions a blockchain carries out. Execution refers to the actual computing process: when you exchange tokens or initiate a smart contract, execution pertains to applying your transaction and updating the network’s state to reflect those changes. This layer is where users most commonly engage, necessitating substantial computational resources due to the requirement to process every transaction. Settlement provides finality and serves as the platform for dispute resolution, anchoring the results of execution and establishing an authoritative record for other layers to reference as the definitive account of events, including mechanisms to verify proofs or contest fraudulent claims.
Consensus is the method through which network participants reach agreement on a unified, sequential history of transactions, ensuring that every participant possesses a shared understanding of events and their sequence, which prevents double spending and maintains ledger consistency. Data availability, often unfamiliar to many, proves pivotal in modular design, ensuring that transaction-related data is both accessible and verifiable. Without data availability, there would be no means to confirm network integrity, crafting data availability into a foundational aspect of trust. In a monolithic chain, these four roles coalesce within one integrated system. The insight afforded by modularity lies in the realization that these functions need not coexist; by separating them, each can be executed optimally.
Monolithic versus Modular
The most straightforward way to grasp the modular concept is to directly juxtapose it with the monolithic model. A monolithic blockchain incorporates all functions into a single cohesive chain. Each full node executes every transaction, engages in consensus, stores the entire data set, and treats the chain as the settlement layer. The key strength of this design is its simplicity and tight integration; everything resides in one location, ensuring seamless interaction among applications without the need for separate layers.
An example of a high-performance chain that emphasizes rapid processing encapsulates the monolithic approach, pushing a unified chain to handle significant throughput by demanding powerful hardware from its nodes. The trade-off with this design is the limitations it imposes: since every node must perform all tasks, the chain can only scale to a point before facing increased fees, congestion, or escalating hardware requirements, thus compromising decentralization.
In contrast, a modular blockchain detaches these tasks so that different layers undertake specific roles. A typical modern configuration separates execution from all others; specialized execution layers run transactions and smart contracts while dedicated layers manage settlement, consensus, and data availability. The exemplar of this system is the rollup-centric design, where lightweight execution chains (rollups) perform transaction processing off-chain and subsequently rely on a robust foundational layer for settlement and data availability.
The advantage of this structure lies in specialization: an execution layer can focus solely on efficient, low-cost transaction processing without having to secure the entire system, as it borrows that security from the underlying base layer. Consequently, the overall system can scale by introducing numerous execution layers that share a common base, amplifying capacity in ways unattainable for a single monolithic chain. Monolithic design prioritizes integration and simplicity, while modular design emphasizes specialization and scalability; this represents the fundamental design choice.
Rollups: The Execution Layer of the Modular World
The most crucial modular component to comprehend is the rollup, as rollups exemplify how the modular vision is operationalized in contemporary applications. A rollup operates as a separate execution chain that efficiently processes transactions off the primary chain and subsequently submits a compressed summary of its activities to a base layer for settlement and data availability. The term “rollup” derives from its method of compiling multiple transactions into one batch, allowing the base layer to avoid processing each transaction individually while still serving as the ultimate reference point. This mechanism enables modular systems to scale: numerous transactions occur cost-effectively on the rollup while only a summarized version is relayed to the expensive, secure base layer.
There are two principal categories of rollups distinguished by their methods of ensuring the base layer recognizes the validity of their batched transactions. Optimistic rollups presume the transactions are legitimate by default and introduce a challenge period during which any fraudulent batch can be disputed by submitting a fraud proof, with the base layer mediating the dispute. Zero-knowledge rollups, in contrast, generate a cryptographic validity proof for each batch, mathematically demonstrating the correctness of the processed transactions, which the base layer can verify without rerunning them.
Both types strive to inherit the base layer’s security while executing elsewhere and depend critically on one essential factor: the availability of the data behind their transactions, allowing verification of the rollup’s claims or the reconstruction of state if necessary. A rollup that only provided a summary without the underlying data would require blind trust from the external audience, negating its purpose. This is precisely why data availability, often the overlooked fourth function, emerges as the linchpin of modular architecture.
Data Availability: The Linchpin
Data availability warrants dedicated discussion as it has transitioned from an afterthought to a central element within modular design. When a rollup publishes its batch of transactions, it is crucial that the complete transaction data is made available for anyone to assess that the rollup executed its responsibilities properly, challenge its correctness if it did not, and reconstruct the state in case the rollup operator becomes unavailable.
The method and cost of data publication significantly influence a modular system’s performance, as data publication constitutes a major portion of the expenses incurred by a rollup. This has fostered demand for specialized chains designed solely for data availability: data availability layers. Rather than executing transactions or addressing disputes, these chains exist exclusively to organize data and ensure its availability affordably and reliably for the rollups that depend on them. A pioneering example is a network built specifically as a modular data availability layer, utilizing an efficient technique known as data availability sampling for scaling. Instead of requiring every node to download the entirety of a block for verification, lightweight nodes randomly sample small portions of the block.
With enough independent sampling, the network can assert, with high confidence, that all the data is indeed available without necessitating full downloads. When paired with techniques allowing each application to access only its relevant slice of data, this enables a data availability layer to serve numerous rollups simultaneously, economically and at scale. By 2026, such a layer was providing data availability for dozens of rollups, a tangible indication that the modular separation of data availability into its own dedicated network had materialized into functional infrastructure.
The Leading Modular Stacks
Understanding how these components interact in real systems is beneficial, as the modular sphere is not a singular design but rather a collection of competing and complementary stacks. The most influential of these is the rollup-centric roadmap of the leading smart contract platform, which strategically reoriented itself towards modularity. Rather than striving to scale by making its base layer process faster, it elected to serve primarily as a settlement and data availability foundation, with execution duties delegated to a thriving ecosystem of rollups built atop it.
A pivotal upgrade incorporated dedicated, lower-cost space for rollups to publish their data, often termed ‘blob space,’ which significantly reduced the costs associated with data availability and, in turn, diminished user fees for rollups, bringing many transactions to just a fraction of a cent. Future upgrades aim to further amplify this data capacity over time. The resultant architecture features a secure base layer for settlement and data, complemented by numerous execution-focused rollups managing everyday activities inexpensively.
Additionally, a specialized data availability layer approach exists, where rollups opt to post their data to a dedicated data availability network instead of, or alongside, the base settlement layer, often to achieve lower costs. This connects with another modular concept discussed elsewhere: shared security through restaking, whereby a collective pool of staked funds can secure new services, including data availability layers, granting them solid economic security from the outset without necessitating their own bootstrapping.
Collectively, these elements establish a comprehensive array of modular components: settlement layers, data availability layers, execution rollups, and shared security providers that teams may mix and match to construct a custom chain. A project could launch its own rollup geared towards gaming or social applications, link it to the most affordable data availability layer, and settle on the trusted base layer—without the need to create a validator set or a full-fledged monolithic chain from the ground up. This composability of infrastructure, enabling the assembly of a chain from specialized parts, represents the practical benefits of the modular thesis and contributes significantly to its rapid adoption.
An Analogy: The Restaurant and the Food Court
Given the modular framework’s complexity, an analogy can help solidify understanding before addressing the associated trade-offs. Visualize a monolithic blockchain as a standalone restaurant that handles everything on site: growing its own ingredients, preparing all dishes, seating diners, and managing dishwashing—all with the same staff in one building. The primary advantage here lies in seamless coordination, as all operations occur in one venue without the need for transitions. However, the limitation arises in capacity; that single kitchen can only produce a limited number of meals simultaneously. If there’s a demand for more, you either have to construct a significantly larger, costlier kitchen that few can manage, or you accept higher wait times and prices during peak periods. Similarly, a single integrated chain confronts the same ceilings, as each node performs every role.
Now, envision a food court instead. The building serves as the shared foundation, providing tables, security, and ensuring the space remains open and orderly, while myriad specialized vendors manage cooking, each focusing on a specific culinary style and optimized for efficient service. In this analogy, the shared building is the base layer delivering settlement and data availability, while the various vendors represent the rollups executing tasks.
No single vendor needs to ensure its own security or construct its own premises; they all benefit from the infrastructure provided by the building, allowing them to concentrate solely on delivering food swiftly. The food court can manage a vastly greater number of patrons than the single restaurant, as its capacity expands by adding more vendors rather than overtaxing a single kitchen. This mirrors how a modular system scales through the addition of execution layers upon a shared foundation.
This analogy also accurately depicts the inherent costs. A food court is more intricate than a single restaurant: it incorporates more independent operators, introduces more potential points of failure from individual vendors, and requires increased coordination to maintain an effectively functioning shared space. If you desire a meal that incorporates ingredients from three different vendors, you must navigate between them, which can be less elegant than simply placing an order at one kitchen; likewise, moving assets or building applications across separate rollups can be less convenient compared to operating within a single integrated chain. Furthermore, every vendor relies on the building; should the shared foundation fail to maintain operations, all vendors suffer consequences, just as a rollup inherits risks associated with the data availability and settlement layers under it.
The food court opts to trade the seamless simplicity of a singular restaurant for greater capacity and specialization, accepting additional complexity and coordination in return. This encapsulates the trade-off inherent in modular blockchains, fostering a perspective that conveys both the advantages and costs in an intuitive manner.
What Modularity Buys You
Following the architectural overview, it’s essential to clearly articulate the genuine advantages that the modular approach provides, as these explain its ascendancy. The primary benefit is scalability. By partitioning execution from the base layer and allowing numerous rollups to operate concurrently atop a shared foundation, a modular system can handle significantly more aggregate activity than a solitary monolithic chain, which can only scale by stretching a single chain. The introduction of inexpensive data availability layers further compounds this advantage by reducing the primary expense associated with running a rollup, leading to transaction fees on modern rollups plummeting to mere fractions of a cent for straightforward transfers.
The secondary benefit involves specialization and versatility. As each layer hones in on one specific function, they can be optimized far beyond the capabilities of a one-size-fits-all chain: a data availability layer can efficiently preserve data, an execution rollup can be tailored for a particular application, and a settlement layer can emphasize security and finality. This also grants builders the freedom to create tailored solutions, selecting their execution environment and regulations while inheriting security and data availability from existing layers instead of reconstructing them from scratch.
The third advantage is enhanced decentralization at the verification level. Techniques like data availability sampling allow lightweight nodes to validate a network’s honesty without heavy hardware investment, enabling a larger pool of common participants to maintain system integrity, counteracting the inherent tendency of high-performance monolithic chains to centralize power among those with access to more robust hardware. Scalability, specialization, and verifiable decentralization are the cornerstone objectives that the modular design aims to achieve, which it pursues by diligently avoiding burdening any single chain with the entirety of the workload.
The Trade-offs and Criticisms
Every architecture has its costs, and a fair evaluation of modularity must consider the genuine expenses involved relative to the monolithic simplicity it seeks to supplant. The first drawback pertains to complexity. A modular system has numerous moving parts: execution on one layer, data handling on another, settlement on a third, plus the bridges and proofs interlinking them, generating more potential points of failure compared to a unified chain. More layers translate to a greater likelihood of issues arising and increased seams needing secure connections. The second drawback is fragmentation. As activities disperse among various rollups, liquidity and users also fragment, causing potential difficulties in moving assets or composing applications across different execution layers, sacrificing some of the integrated composability a single monolithic chain offers, where all applications can engage with one another instantaneously.
The third drawback involves a nuanced security concern. The safety of a rollup hinges upon the reliability of the layers it relies on; thus, if the data availability layer falters in maintaining access, or if the settlement layer it depends on faces compromise, the rollup inherits those vulnerabilities. Therefore, modular systems must carefully assess the trust implications of each dependent layer, and a chain that resorts to a less secure data availability layer for cost savings is making a discernible sacrifice in safety, even if this decision isn’t immediately evident to users.
Proponents of the monolithic framework contend that tight integration offers a simpler, more composable, and uniformly secure system. They also argue that high-performance monolithic chains demonstrate the potential for a single chain to scale beyond conventional expectations set by the modular camp. The honest assessment is that neither monolithic nor modular approaches can be strictly deemed ‘better’ or ‘worse’; they constitute differing strategic choices: monolithic favors integration and single-chain performance, while modular bets on specialization and stacking benefits. By 2026, it had become evident that the modular strategy was the prevailing architecture for aspiring new infrastructure, although the associated trade-offs of complexity, fragmentation, and layered trust are significant, and the discourse regarding the ultimate victor of each methodology is anything but conclusive.
Frequently Asked Questions
What is a modular blockchain in simple terms?
A modular blockchain divides the core functions a network must perform into separate, specialized layers instead of relying on a single chain to manage everything. The four main jobs are execution (conducting transactions and smart contracts), settlement (finalizing results and resolving disputes), consensus (establishing transaction order), and data availability (ensuring transaction data is publicly accessible for verification). In contrast, a traditional monolithic chain performs all four functions, limiting its scalability. A modular architecture allows each layer to specialize in its function, enabling far greater scalability while ensuring security.
What is the difference between monolithic and modular blockchains?
A monolithic blockchain combines execution, settlement, consensus, and data availability into one cohesive chain, where every node performs all tasks. While this design offers simplicity and tight integration, it reaches a scalability ceiling, as a single chain handling all tasks can only operate so quickly before fees increase, or hardware demands limit the number of participating nodes. A modular blockchain distributes these functions across layers, typically assigning execution to rollups and delegating settlement and data availability to a foundational layer. This introduces some complexity and reduced composability but significantly enhances scalability and specialization.
What is a rollup and how does it fit in?
A rollup is a distinct execution chain that processes transactions inexpensively off the main chain, subsequently posting a condensed batch back to a secure base layer for settlement and data availability. It aggregates many transactions into one batch, allowing the base layer to avoid processing each one individually while still acting as the ultimate source of truth. There are two primary types of rollups: optimistic rollups, which assume transactions are valid and allow for fraud challenges, and zero-knowledge rollups, which produce cryptographic validity proofs. Rollups are fundamental to realizing the modular vision in practice and depend on data availability to ensure verifiability.
Why is data availability so important?
Verifying any rollup, or blockchain, necessitates that the data supporting its transactions is both made public and accessible. If the data is absent, it is impossible to confirm adherence to rules, challenge fraudulent activities, or reconstruct the state if an operator becomes unavailable. Cost and methodology related to data publication are among the key determinants of a modular system’s expenses, as publishing data constitutes a significant portion of a rollup’s costs. This has prompted the development of specialized data availability layers whose sole purpose is to affordably keep data available, making use of techniques such as sampling for lightweight nodes to assure availability without requiring comprehensive downloads.
What is Celestia and what does a data availability layer do?
A data availability layer is a dedicated chain designed solely for organizing transaction data and ensuring its availability reliably and affordably for rollups that depend on it, instead of executing transactions or resolving disputes. The pioneering example of such a layer employs data availability sampling, where lightweight nodes randomly verify small segments of a block to establish confidence, with high certainty, that the entire data set is present without necessitating complete downloads. By 2026, such a layer was providing data availability for numerous rollups.
What are the downsides of modular blockchains?
There are three primary drawbacks. First, complexity arises from the multitude of layers, along with the interconnections and proofs linking them, increasing the risk of bugs and failures compared to an integrated chain. Second, fragmentation occurs as activities disperse among various rollups, dividing liquidity and users and potentially complicating asset transfers or application composition across layers. This can reduce some of the streamlined integration a monolithic chain offers, where all applications can interact seamlessly. Third, layered trust concerns a rollup’s safety based on the underlying layers; thus, relying on weaker data availability or settlement layers may pose security trade-offs. Proponents of monolithic chains argue that their tight integration yields a simpler and uniformly secure system.
This article serves as educational information, not investment advice. Blockchain architectures, projects, and technical details evolve rapidly, and the descriptions here represent the state of the field as of June 25, 2026. Verify current information from primary sources before relying on anything outlined here.
