What Is a Modular Blockchain?

By Nika, NodeTimes newsroom.

A modular blockchain splits one machine into separate roles that can each be replaced on its own: execution, settlement, consensus and data availability. A monolithic chain performs all four in a single process, which makes it simpler but ties its blocks, its state and its upgrade path together. The practical difference is not in the label but in what you can change without rewriting the rest, and every claim of modularity can be checked against that one question.

One machine, or four roles

The four roles are defined by the job rather than by the product: execution runs transactions and changes state, settlement finalises results and resolves disputes, consensus orders blocks and agrees on their order, and data availability makes block data retrievable and checkable.

Execution: the environment that processes transactions and produces a new state, usually with its own virtual machine. Settlement: the place where results become final and where a dispute about them can be resolved, including the proofs a chain needs to accept an external state. Consensus: the process that fixes the order of blocks and the set of transactions inside them. Data availability: the guarantee that the data behind a block can be obtained and verified by whoever needs it, without trusting the producer's word for it.

A monolithic chain bundles these four in one process because that keeps one guarantee for the whole system: the same validators order blocks, execute them and store the data, so a transaction either lands in a block or it does not. Modularity replaces that single guarantee with a set of interfaces between layers. Where those interfaces are stable, a layer can be swapped; where they are not, the design is monolithic with extra steps. How L0, L1 and L2 relate once those layers are separated is a different question, taken up in the guide to the levels.

• Monolithic: one process, one guarantee, one upgrade path, and one congestion domain for every application on it.
• Modular: separate roles, separate failure modes, and a coordination cost that appears as soon as one layer lags.
• The dividing line: whether a role can be replaced without forking the thing that depends on it.

The four layers and what each can be swapped for

Each layer exposes its own interface, and a swap is only real where that interface is stable enough that the other layers can keep working.

The layer that actually gets swapped is execution, because a rollup's state transition function can be replaced while the settlement contract above it keeps verifying proofs. A change in settlement or in ordering is a different order of difficulty, because it alters what the other layers have to prove, and a proof system is not something you migrate in a weekend.

Monolithic versus modular: the actual trade

Modularity is bought with coordination: the design gains replaceable parts and pays for them in external dependencies and new failure modes.

In a monolithic chain the failure modes are coarse but easy to reason about: the chain is congested, or it is not; it finalises, or it does not. When execution lives outside the chain that settles it, the failure list grows.

The settlement layer can stall while execution keeps accepting transactions. The data layer can lose data, which is worse than a stall, because a rollup cannot reconstruct its state from a block it cannot retrieve. An upgrade in one layer can require a coordinated change in another, and that coordination is exactly the property that modularity was supposed to remove at the application level. Splitting state is not a free way out either: the same tension shows up in sharding, where a state split buys throughput and pays in cross-shard coordination.

• What modularity buys: independent upgrades, specialised layers, and the ability to use a better component without a migration of the whole system.
• What it costs: an extra trust surface per layer, more moving parts to monitor, and fees that now include the cost of the other layers.
• What it does not do by itself: make transactions cheaper. A cheaper execution layer is a fact about that layer, not about modularity as such.

The last point is where most marketing breaks down. Modularity changes which costs are paid where; it does not remove them. Whether a modular design is cheaper depends on the load profile and on the price of the layers it borrows, so the honest version of the claim is that a specific component can become cheaper under a specific workload.

Where rollups fit

A rollup is execution moved out of the main chain, and it borrows the other roles from outside rather than providing them itself.

The state transition happens off the main chain and ends in a state root, the single hash that stands for the whole resulting state. A proof or a challenge window makes that root acceptable on the main chain, and the data that lets anyone recompute that state is published somewhere the main chain accepts as available. That is what makes a rollup a modular system rather than a monolithic one, but it does not make a rollup and a modular blockchain the same thing. In a rollup, the modularity is a property of the arrangement around it: the rollup is the execution layer, and the settlement, ordering and data layers belong to whichever systems it chose to rely on.

A modular L1 goes further, because the chain itself is built so that these roles can be replaced inside it, not only borrowed from outside. How agreement about the resulting state is reached, in either shape, is covered in the explainer on consensus.

Shared sequencing and its compromise

A shared sequencer orders transactions for several rollups at once, which gives them a common ordering and takes a single operator that all of them now depend on.

The benefit is concrete: a bundle can be included across rollups together instead of being split, so a cross-rollup operation either lands on both sides or on neither, and users stop relying on separate light clients to prove one rollup's history to another. The compromise is just as concrete. Whoever orders transactions can delay or reorder them, and a single shared sequencer concentrates that power over every chain that uses it. Atomicity of inclusion is also weaker than it sounds: a guarantee that a bundle is sequenced everywhere is not a guarantee that every transaction in it succeeds, because each transaction still executes against its own rollup's state and can revert on its own.

• What it improves: cross-rollup atomicity of inclusion, one ordering to prove instead of many, and less duplicated infrastructure per rollup.
• What it introduces: a common ordering centre, a new liveness dependency, and a governance question about who runs it and how it is replaced.
• The check to run: ask what happens to each rollup if the shared sequencer stops, and whether any of them can keep producing blocks without it.

How to tell real modularity from a rebrand

A claim of modularity can be tested by looking for interfaces a role can actually be swapped through, rather than for the word in the documentation.

Three checks do the work. First, find the specification of the boundary: an interface that other layers implement against, with its version and its compatibility rules. Second, find an example of the swap: a working deployment where one role was replaced while the others kept running, which is the only evidence that the interface holds. Third, ask what happens to a user whose transaction is in flight during that replacement, because a swap that requires a frozen system is a migration rather than modularity. If none of the three can be answered from the documentation or from a published account of a live swap, the architecture is a description and not a property.

Architecture also does not start and end with this four-layer picture. In some designs the unit that matters is not a layer but a structural element whose contents decide what a node can verify or discard, as in the structure of a cell. The question to carry into any of these models is the same: which part can be replaced, and by whom.

Frequently asked questions

Is a modular blockchain just a rollup?

No. A rollup is execution moved outside the main chain, while modularity is a property of a whole system in which roles can be replaced.

Every rollup is modular in part, but not every modular design is a rollup, and a chain can be modular without having one.

Does modularity make transactions cheaper?

Not by itself. A specific layer can become cheaper, while the bill for coordination between layers is added somewhere else.

Whether the total falls depends on the workload and on what the borrowed layers cost at that moment.

Is a monolithic chain outdated?

No. A monolithic chain is simpler, keeps one guarantee for the whole system, and is enough for a large class of applications.

Modularity is a trade rather than a newer generation, and it pays off where the ability to replace parts matters more than the simplicity.

What does a shared sequencer change?

It gives several rollups a single ordering, so a bundle can be included across them together, and it concentrates that ordering in one operator.

The gain is cross-rollup atomicity of inclusion; the cost is a shared centre that every participating chain now depends on.

How do I check whether a chain is really modular?

By its interfaces: if a role cannot be replaced without forking what depends on it, the replaceability exists only in the description.

Ask for the interface specification and for one deployment where the swap actually happened.