A blockchain does not become scalable simply because its computers get faster. At some point, the more important question is architectural: who is responsible for doing each part of the work?
A network has to process transactions, agree on their order, make relevant data available and settle the resulting state. A monolithic blockchain keeps much of that machinery together; a modular approach separates some of it across specialised layers.
That sounds technical. It is actually a choice about where a blockchain puts its costs, dependencies and complexity.
Why splitting blockchain work changes the scaling problem
Consider a simple transaction. The network must execute an instruction and update its state. It must also agree on what happened and in what order. Other participants need enough data to verify that the proposed state is legitimate.
These jobs do not necessarily have to be performed by one system.
This is the basic idea behind modular blockchain architecture: separate responsibilities so individual components can be optimised for a particular task. Execution, consensus, settlement and data availability can be handled by different parts of a stack, although not every modular design separates all four in the same way.
The attraction is straightforward. If one layer becomes the bottleneck, developers do not necessarily have to make the entire base network do more work. They can move or specialise part of the workload elsewhere.
The catch is that once a system is divided into components, those components have to communicate, and their security assumptions have to fit together.
A monolithic blockchain keeps more of the machinery together
A monolithic blockchain performs most of its core functions within the same base network. Instead of outsourcing execution or data availability to a separate layer, the chain itself carries a larger share of the workload.
Solana is a useful example. Its transaction pipeline runs through stages on validators including signature verification, account loading, instruction execution and commitment of the result. The main chain handles the transaction-processing pipeline itself.
That can make the architecture easier to reason about: one principal network processes the activity rather than a stack in which execution happens elsewhere.
The trade-off is that the base layer absorbs the consequences of growth. More activity means more processing, communication and storage demands for the machines participating in the network.
Scaling is not only about getting more transactions through. It is also about keeping the network practical to validate and participate in. Ethereum itself notes that keeping the barrier to node operation low is important to avoid centralising computing power.
A modular blockchain moves some of that work elsewhere
A modular architecture takes a different approach. Rather than asking the base chain to handle every job itself, it allows specialised layers to perform specific functions.
Ethereum’s rollup-centred scaling strategy is a good example. Rollups execute transactions outside the Ethereum mainnet, then publish the information needed for Ethereum to verify and settle those state changes.
The mainnet remains an important security and settlement layer while execution can be handled elsewhere.
This is why “modular” should not simply be read as “lots of blockchains”. The distinction is the division of responsibilities.
A rollup can specialise in execution. Ethereum can provide settlement and data availability. Other designs can introduce a dedicated data-availability network or use different combinations of components.
The benefit is that each part can be designed around a narrower job. A rollup does not need to reproduce every function of a general-purpose Layer 1.
Ethereum describes rollups as a way to process transactions offchain and post compressed transaction data back to the main network, reducing pressure on the base layer.
Data availability is where the modular model gets interesting
Data availability sounds abstract until you ask a simple question: if a rollup says “this is the new state”, how can anyone check that the statement is true?
The answer depends on access to the underlying transaction or state data.
Ethereum defines data availability as the assurance that information needed to verify a block or rollup is accessible to the participants who need it. Without that data, independent verification becomes difficult or impossible.
This is why the modular model is subtler than simply “taking transactions off the blockchain”. A rollup can move execution elsewhere, but it still needs a reliable way to publish data for verification.
In Ethereum’s design, rollups can publish data as calldata or in blobs. EIP-4844 introduced blobs as a cheaper way to publish temporary data, but they are not equivalent to permanent archival storage.
Moving one function away from the base layer does not make that function disappear. It changes which component performs it, how other components depend on it and who is responsible for checking the connection.
The architecture eventually shows up in the user experience
Most people will never look at a transaction pipeline when using a blockchain. They notice the architecture in more practical ways.
A congested base layer can mean higher fees. A multi-layer ecosystem can mean using a Layer 2, moving funds between networks or navigating a withdrawal process.
That does not make modular systems inherently worse. The whole point of rollups is to increase capacity and reduce costs by processing transactions away from the base layer. Ethereum says this approach can reduce congestion on Layer 1 and transaction costs for users.
But there is a difference between a simpler underlying architecture and a simpler user experience.
A monolithic design concentrates more of the work in one place. A modular design distributes it and relies on the surrounding software to hide the seams.
Modular does not mean less complexity
This is the trade-off that gets lost when modular blockchains are presented as an obvious answer to scaling.
A monolithic chain carries more responsibility inside the base layer. A modular stack distributes that responsibility. The first approach can become constrained by the capacity of its core network; the second can introduce new dependencies between layers.
Those dependencies can involve security, data availability, bridging or sequencing. Modularity can therefore move complexity rather than remove it.
That is not a flaw in the concept. It is the reason the architecture is worth understanding.
That also explains why “modular” should not be treated as a guarantee of decentralisation, lower fees or higher throughput. Those outcomes depend on the specific design and on the assumptions each layer makes about the others.
Ethereum and Solana are different engineering choices
Ethereum and Solana are effective to compare because they illustrate different answers to the same problem.
Solana keeps transaction processing tightly integrated within its base network. Ethereum has increasingly built its scaling strategy around an ecosystem in which rollups handle execution while the mainnet provides key settlement and data-availability functions.
Neither architecture proves that one model is universally superior.
A highly integrated blockchain is betting that its base layer can scale while remaining practical for the people who need to validate it. A modular ecosystem is betting that specialised components can work together without creating unacceptable fragmentation or trust assumptions.
The real choice is where the work gets done
The debate between modular and monolithic blockchains can sound like a choice between two competing technical philosophies. In practice, it is closer to a decision about system design.
One architecture asks a core network to do more itself. The other breaks the job into components and asks them to coordinate.
Every blockchain still pays the cost of execution, verification, communication and data. Architecture determines where those costs appear — inside one base layer or across a wider stack.
For users and developers trying to understand why blockchain systems are evolving into multiple layers, that is the key idea to keep in mind: modularity is not the removal of complexity. It is the redistribution of complexity.