Modular vs. Monolithic architecture is dead

Author: Avi Zurlo

Compiled by: Block unicorn

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

Today, the contrast between modularity and monolithicity imposes unnecessary constraints on our scalability thinking model.

So, what alternatives are there?

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

Understanding Modularity vs. Monolithicity

First, here are some definitions:

Modular chains separate the core functionalities of the blockchain into different layers.

Monolithic chains integrate all core functionalities 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: one for execution, the Rollup full node, and one for settlement + data availability (DA), the Ethereum full node. Validium might utilize three running nodes: one for execution, the Rollup full node, one for settlement, the Ethereum full node, and one for DA, the backup data availability layer full node.

Modularity assigns blockchain tasks to at least two full nodes. By doing so, modular blockchains can leverage the computational power of multiple machines 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 monolithic camps choose to scale through software optimizations, implementing parallel virtual machines, data pipelines, faster network protocols, and (most notably) more powerful hardware. Essentially, monolithic chains attempt to extract as much computational power as possible from a single full node.

This is a form of vertical scaling.

Critics argue that this approach tends to centralization: if scaling relies on increasing the power of a single node, it will inevitably encounter the physical limits 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 only handle a small portion of Near's global state. Thus, Near allocates work based on state rather than tasks, leveraging the computational power of multiple machines (just like modular chains).

We can see that there are no restrictions on the scaling techniques implemented by either monolithic or modular chains. Both can perform horizontal and/or vertical scaling.

Moreover, the debate between modularity and monolithicity has always been rooted in the framework of horizontal and vertical scaling. From a strictly technical perspective, modularity tends to favor horizontal scaling, which is inherent in its design, while monolithicity tends to favor vertical scaling.

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

Adopting a horizontal vs. vertical thinking model allows us to easily reason about the trade-offs each chain makes in the process.

Redefining the Conversation: Horizontal vs. Vertical Scaling

Before diving into the horizontal vs. vertical scaling framework, it is important to acknowledge that its origins can be traced back to the 1970s, when distributed computing research laid the groundwork for the concept of horizontal scaling. Today, all scaling techniques can be classified 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 achieved through software optimizations such as parallel virtual machines (i.e., multithreaded processes).

A common example is EVM vs. SVM.

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

In terms of trade-offs, vertical scaling is limited by the available hardware, tends to centralization due to increased hardware demands, and has poorer scalability compared to horizontal scaling.

Horizontal Scaling

On the other hand, horizontal scaling increases the number of machines accessible to the system by distributing the workload across multiple nodes. As mentioned earlier, modular chains essentially assign tasks to multiple machines. However, chains can often achieve greater degrees of horizontal scaling through sharding.

=nil; Here is a useful example.

In November last year, the =nil; foundation launched a verifiable sharding architecture called zkSharding, which serves as the foundation for the new Ethereum L2. At the core of =nil; design is the division of its global state into multiple shards. Each shard is run by a decentralized committee of =nil; that builds blocks and manages cross-shard transactions. Additionally, each shard generates a validity proof that is sent to the main shard for aggregation and then published and verified on Ethereum. =nil; leverages the capabilities of horizontal scaling in two ways:

• First, =nil; is a modular blockchain that utilizes Ethereum's robust consensus and data availability as guarantees, thus distributing tasks across multiple full nodes.

• Second, =nil; is a sharded blockchain, thereby distributing parts of the state across many full nodes.

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

So, what are the trade-offs of horizontal scaling? This can be summarized in two points: the complexity of the network and consensus, and asynchronous communication between machines or shards.

The Final Battle for Ethereum Scalability

Both horizontal and vertical scaling are not limited to modular or monolithic architectures. This is why the horizontal vs. vertical scaling framework provides more room to explore new solutions that make modular blockchains more scalable.

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

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

One solution might be to choose horizontal scaling through sharding.

Current modular designs have only just begun to touch the full potential of horizontal scaling. Through sharding, we can leverage the computational power of an arbitrary number of machines (rather than just 2-3 machines sharing tasks).

In other words, many machines can run the same type of task in parallel. This is the goal that Ethereum and Celestia hope to achieve through Danksharding and data sharding, respectively. However, sharding is not inherently limited to data availability layers—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 see a significant increase in available computational power.

But we can do better…

The ultimate goal of blockchain scalability will merge horizontal and vertical scaling to create a sharded blockchain with parallel virtual machines.

At the =nil; foundation, we are systematically designing towards this ultimate state. =nil; L2 is taking an aggressive scaling roadmap by leveraging a modular, horizontally scalable architecture (zkSharding) and vertical scaling validator implementation (parallelization within shards).

Thus, =nil; design can achieve global scale without sacrificing state, liquidity, or user fragmentation.

If you're curious about horizontal scaling and zkSharding, feel free to join the conversation on =nil; foundation's Discord and X.