Modular vs. Monolithic Architecture is Dead

Author: Avi Zurlo; Translator: Block unicorn

Since the rise of Rollups, blockchain expansion has focused on the debate between modularity and monolithicity. Initially, this binary opposition was a useful mental model for reasoning about the scalability of blockchains, but now both camps have surpassed it.

Today, the contrast between modularity and monolithicity brings unnecessary limitations to our scalability mental model.

So, what are the alternatives?

In this article, we will show that horizontal expansion and vertical expansion have always been the basic framework for blockchain scalability, and explain how adopting horizontal expansion and vertical expansion can lead to better expansion solutions.  

Understanding Modular vs. Monolithic

First, some definitions:

Modular chains separate the core functionality of a blockchain into different layers.

Monolithic chains integrate all core functionality into a single, interconnected layer.

We can think of “layers” as “machines” — a monolithic chain has a single validator node that runs all tasks, while a modular chain has multiple (2-3) full nodes that run different tasks.

For example, Rollup typically has two running nodes: a Rollup full node for execution, and an Ethereum full node for settlement + data availability (DA). Validium may utilize three running nodes: a Rollup full node for execution, an Ethereum full node for settlement, and an alternate data availability layer full node for DA.

Modularity distributes the tasks of a blockchain across at least two full nodes. By doing so, a modular blockchain can leverage the computing power of multiple computers when building each block.

This is a form of horizontal scaling.

Modularity is useful when thinking about blockchain scalability because it is a type of horizontal scaling.

On the other hand, most of the monolithic camp chooses to scale through software optimization, implementing parallel virtual machines, data pipelining, faster network protocols, and (most notably) more powerful hardware. In essence, monolithic chains try to extract as much computing power as possible from a single full node.

This is a form of vertical scaling.

Critics argue that this approach tends to centralize: if you rely on increasing the power of a single node to scale, you will inevitably run into the physical limitations of the underlying hardware and be forced to increase hardware requirements to scale further.

However, this criticism is incorrect, as not all monolithic chains rely solely on vertical scaling.

For example, Near is a monolithic L1 blockchain built on a sharded network architecture. This means that Near's full nodes are responsible for all tasks (i.e., execution, settlement, and data availability), but they are only responsible for a small portion of Near's global state. Therefore, Near leverages the computing power of multiple computers by distributing work based on state rather than tasks (just like modular chains).

We can see that both monolithic and modular chains are not limited in the scaling techniques they implement. Both can scale horizontally and/or vertically.

In addition, the modular vs. monolithic debate is always rooted in the framework of horizontal vs. vertical scaling. From a strictly technical perspective, modularity favors horizontal scaling, which is inherent to its design, while monolithicity favors vertical scaling.

Now that we have successfully launched modular chains, the additional scaling advantage is no longer about being “more modular”. The focus is now on how chains can leverage horizontal or vertical scaling techniques.

Adopting a horizontal vs. vertical mental model allows us to easily reason about the tradeoffs each chain makes along the way.

Reframing the Conversation: Horizontal vs. Vertical Scaling

Before diving into the horizontal vs. vertical scaling framework, it is important to acknowledge that its origins date back to the 1970s, when distributed computing research laid the foundation for the concept of horizontal scaling. Today, all scaling techniques can be categorized as either horizontal or vertical scaling.

Vertical Scaling

Vertical scaling increases the hardware utilization or hardware requirements of each node. In blockchain, this is often done through software optimizations such as parallel virtual machines (i.e. multi-threaded processes).

A common example is the EVM vs. the SVM.

The EVM executes transactions sequentially, while the SVM executes transactions in parallel. The SVM does this by utilizing more CPU cores, so the SVM can process more transactions per second than the EVM. Note: This type of vertical scaling is the basis behind Eclipse L2.

In terms of tradeoffs, vertical scaling is limited by available hardware, tends to be centralized due to increased hardware requirements, and is less scalable than horizontal scaling.

Horizontal Scaling

On the other hand, horizontal scaling increases the number of machines a system can access by spreading the workload across multiple nodes. As mentioned earlier, modular chains essentially distribute tasks across multiple machines. However, chains can often achieve a greater degree of horizontal scaling through sharding.

=nil; Here is a useful example.

Last November, the =nil; Foundation introduced a verifiable sharding architecture called zkSharding, which is the basis for the new Ethereum L2. The core of =nil;’s design is to partition its global state across multiple shards. Each shard is run by =nil;’s decentralized committee, who build blocks and manage cross-shard transactions. In addition, each shard generates a validity proof that is sent to the primary shard for aggregation and then published and verified on Ethereum. =nil; The ability to scale horizontally is leveraged in two ways:

• First, =nil; is a modular blockchain that leverages Ethereum’s strong consensus and data availability as guarantees to distribute tasks across multiple full nodes.

• Secondly, Ethereum is a sharded blockchain, and therefore distributes parts of its state across many full nodes.

Both techniques reduce the load that any single machine needs to bear and increase the overall scalability of the network.

So, what are the trade-offs of horizontal scaling? It comes down to two things: network and consensus complexity, and asynchronous communication between machines or shards.

The Endgame of Ethereum Scalability

Neither horizontal nor vertical scaling is limited to modular or monolithic architectures. That’s why the horizontal vs. vertical scaling framework provides more room to explore new solutions to make modular blockchains more scalable.

For example, one option is to scale one layer of the modular stack vertically. A common approach is to implement parallel virtual machines to increase execution throughput. As mentioned above, Eclipse is leveraging SVM and other Rollups, such as Starknet, to implement BlockSTM for parallelization.

However, vertical scaling is always limited to the limitations of a single machine, and we cannot break the laws of physics.

One ​​solution may be to choose to scale horizontally through sharding.

Current modular designs have only just begun to touch the full potential of horizontal scaling. With sharding, we can leverage the computing power of any number of machines (not just 2-3 machines sharing the task).

In other words, many machines can run the same type of tasks in parallel. This is what Ethereum and Celestia hope to achieve through Danksharding and data sharding, respectively. However, sharding is not inherently limited to the data availability layer - it can also be combined with execution (as in the case of =nil; L2).

If we combine the horizontal scaling achieved through the modular stack with the horizontal scaling provided by sharding, we will get a huge increase in available computing power.

But we can do better...

The ultimate goal of blockchain scalability will be to merge horizontal and vertical scaling, resulting in sharded blockchains with parallel virtual machines.

At the  =nil; Foundation, we are systematically moving towards this end-state design. =nil;'s  L2 takes an aggressive scaling roadmap by leveraging a modular, horizontally scalable architecture (zkSharding) and a vertically scalable validator implementation (intra-shard parallelization).

As a result, =nil;'s design can achieve global scale without sacrificing state, liquidity, or user fragmentation.

If you are curious about horizontal expansion and zkSharding, you can join the conversation on the =nil; Foundation's Discord and X.