A blockchain, as we all know, is a distributed database that allows for secure, transparent, and tamper-proof data sharing. But the numerous potential applications of blockchain technology have sparked a heated debate in the crypto community about the best way to scale blockchains.

If you have been paying apt attention to the space, you’ll frequently hear of new protocols launching with claims of X thousand transactions per second. However, if you investigate these claims further, you will discover that they are all theoretical. The majority of them fail upon launch.

To fully comprehend why we require systems capable of thousands of tps, we must first comprehend blockchain design. To do so, we must consider the rivalry between Monolithic and Modular designs.

It is said that there are key points of comparison in every rivalry. The rivalry between Modular and Monolithic blockchains in the world of blockchains can be boiled down to three key areas: scalability, throughput, and data availability. Each has its own set of features, capabilities, and applications.

Let’s take a closer look at these three areas to see how Modular and Monolithic blockchains compare.

What’s a monolithic blockchain?

Consider a country in which only the president is responsible for all aspects of government. A country with no checks and balances. Isn’t it terrifying?

That is a straightforward definition of a monolithic blockchain. It is a blockchain in which all sets of responsibilities are handled on a single layer without the use of third-party services.

A blockchain performs four main tasks or functions:

The consensus layer is the beacon chain. It informs you of what is true. The data layer informs you of what has already occurred, storage. The execution layer informs you of what is going on, compute.

All these layers are very complex but…

…monolithic blockchains have all nodes and all hardware of the chain trying to do all these three things at once in the same spot.

It is a blockchain that combines the consensus mechanism, data availability layer, settlement layer, and execution layer into a single layer. Typically, settlement and execution are linked.

All key features or responsibilities of a blockchain system are addressed internally in a monolithic blockchain. They typically prioritize decentralization and security at the expense of scalability (optimizing one attribute of the blockchain and restricting others).

…on the other hand, we have modular blockchains.

What’s a modular blockchain?

Modular blockchains are blockchains that operate on the modularity principle. They typically handle a specialized set of duties (often off-chain) and then outsource them to one or more separate layers.

Instead of the blockchain performing all three functions simultaneously (consensus, data availability, and execution), it can divide them into different categories, with the different roles and responsibilities of network participants performing these functions separately.

In that case, the execution layer is decoupled from the bottom consensus and data availability layers, allowing nodes to execute transactions independently rather than performing all transactions to test validity within a limited space or block.

These distinct components/layers can be combined to achieve a variety of objectives. Similar to pluggable modules, they provide greater flexibility and portability. It enables developers to optimize the various blockchain components in order to create a complete system. They enable the launch of new blockchains by simply outsourcing security, much like current layer 2 solutions.

Let’s look at Rollups as an example.

They are a common type of modular blockchain. Rollups process transactions (transactions) and delegate consensus, data availability, and settlement to their parent chain.

Ethereum was the first to begin the transition to a sharded modular blockchain structure. The chain is sharded into multiple sub-chains, each of which is responsible for a portion of network activity. These shards can now decide whether to process transactions or store data.

Now that we’ve discussed the differences between monolithic and modular blockchains, let’s look at their benefits and drawbacks.

Benefits of monolithic blockchains:

Benefits of modular blockchain:

Now, regardless of the significant benefits of both blockchains, there are always trade-offs when deciding between different approaches. Let’s take a look at the disadvantages.

Drawbacks of monolithic blockchains:

Drawbacks of modular blockchains:

Even though modular blockchains solve various issues where monolithic blockchain lags behind, modular architecture comes with its own set of drawbacks.

Further Comparative analysis

First, let’s recap the definition of modular vs monolith

So to tell if a chain is modular or monolithic, simply ask: “Does it need to be combined with another chain to function?” Yes? → modular. No? → monolithic.

Keeping this recap in mind…

i. Does Arbitrum (or any rollup) have a modular or monolithic design?

Well, Arbitrum requires another chain to post data to and resolve fraud, otherwise, it simply does not work. Hence, it is modular.

ii. Is Ethereum modular or monolithic in nature?

It is monolithic. Rollups can be deployed on top of Ethereum (as can any L1), but rollups are not required for Ethereum to function. It should also be noted that once launched, Ethereum’s danksharding component will be modular.

iii. What about Avalanche and its subnets? Is it modular or monolithic?

Each subnet is a standalone blockchain. They don’t need another chain to work. Hence, it is monolithic. It is important to note that just because a subnet’s code is built with a modular software stack does not make it a modular protocol!!

The modular blockchain layout is significantly more flexible than the monolithic blockchain layout. It is intended to provide miners with features not available in the monolithic blockchain. When miners focus less on specific functions such as consensus, they are able to leverage the layout and create new blockchains more quickly, regardless of blockchain architecture.

It’s also worth noting that in modular blockchains, consensus and data availability (DA) are inextricably linked. They must always be present as a single component of the DA layer in order to provide an accurate chronology of events. These two elements must always be present.

Next, we must also address the scalability trilemma, which states that a blockchain can only prioritize two of three factors: scalability, decentralization, and security.

Assume we have three teams to demonstrate this. A, B, and C are the respective teams.

We have high TPS chains like Solana and Binance Smart Chain on team A, which sacrifice decentralization. On team B, we have chains like Cosmos that sacrifice security, and on team C, we have chains like Bitcoin and Ethereum which focus on decentralization and security and therefore lose out on scalability. They make a sacrifice in some way.

This is true for all monolithic blockchains, but the idea is that we can achieve all of these factors in a blockchain using a modular approach.

Typically, in a monolithic blockchain design, all four tasks are carried out on the same layer which can be inefficient as the chain scales. With modular blockchains, each task can be specifically performed by one layer while the remaining tasks are off-loaded to other layers.

By allowing layers to focus on their specific task they can be specialized to do their objective really well. This increases flexibility because you are no longer required to make certain concessions in order to fit within the constraints of a monolithic blockchain.

Now, let’s explain this point better, using the Ethereum network.

In a monolithic blockchain, there’s one single blockchain within one chain of blocks that progresses. Furthermore, all validators validate that single chain. In the Ethereum protocol, there’s a gigantic pool of validators, around 300,000.

We can use this pool of validators and distribute it later on when we get shards. Instead of having all of the validators validating a single monolithic blockchain — when we get shards, which are more chains and more block space — we can actually spread these validators out across many shards. So, instead of 300,000 validators validating a single chain, we can have 5,000 validators validating a single shard and then adding more and more shards that are all combined together.

This would increase the amount of block space available at L1 while maintaining decentralization. So the data layer is a history/storage layer that contains everything computed. The rollups will then use these shards as information storage and will settle on them. The first shard iteration will add approximately 18 times more data than the Ethereum L1. This means Ethereum will be approximately 18 times more scalable.

When you add roughly 18 times more scale to the Ethereum L1, it’s not 18 times more scalable on the rollups, it’s much, much more due to the compression in the rollups.

When a small amount of data is added to Ethereum’s L1, the L2s can then use orders of magnitude more data because they eventually compress it down to a very small package of data and settle that on the L1. As a result, one megabyte on the L1 becomes equivalent to one gigabyte of transactional data on the L2. When you linearly increase the number of shards on Ethereum, you exponentially increase the number of transactions rollups can process.

The more validators we have, the more capital we have to protect and secure the blockchain, and the more validators we have, the more shards we can create, which adds more block space, and creates a lot of scale along the L2s.

Conclusion:

The only way out of the scalability trilemma is through decentralization.

If you only optimize for scalability, as many alternate layers 1 do, you increase hardware and node requirements, reducing the number of network participants and thus losing decentralization. When you optimize for execution, those chains move very quickly and the blocks are added to the ledger very quickly, but the only computers that can keep up with these chains are extremely powerful ones. If your computer is slow, you will fall behind.

Roll-ups, such as zkr, optimistic, and the like, are examples of modular blockchain approaches that have become popular topics in the crypto space. Celestia is another example, with a specific focus on the data availability layer.

On the other hand, some examples of a monolithic approach include chains such as Bitcoin, Solana, and even Ethereum 1.0. (prior to recent upgrades).

Both monolithic and modular approaches, as demonstrated in this article, are effective in their own right. As a result, developers must decide which approach is best for their specific use case. For example, a DeFi app may prioritize security and thus choose a monolithic design to provide a stronger security posture. However, if that same application is to prioritize throughput and execution speed, a modular design may be best suited for their use case.

This demonstrates that both designs serve a purpose.