Modular vs. Monolithic Is Dead

Since the rise of rollups, blockchain scaling has been focused on the modular vs. monolithic debate. Initially this dichotomy was a useful mental model for reasoning about blockchain scalability, but both camps have outgrown it. 

Today, modular vs. monolithic puts unnecessary limits on our mental models for scalability. 

So, what’s the alternative? 

In this article, we show that horizontal vs. vertical scaling has always been a foundational framework in blockchain scalability and explain how adopting horizontal vs. vertical leads to better scaling solutions.

Where We Started: Understanding Modular vs. Monolithic

First, some definitions:

Modular chains separate a blockchain’s core functions into distinct layers.

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

We can think of “layers” as equivalent to “machines” – monolithic chains have a single validator node that runs all tasks, whereas modular chains have multiple (2-3) full-nodes that run distinct tasks. 

For example, a rollup typically has two operating nodes: a rollup full-node for execution and an Ethereum full-node for settlement + data availability (DA). A validium might take advantage of three operating nodes: a rollup full-node for execution, an Ethereum full-node for settlement, and an alternative data availability layer full-node for DA.

Modularity splits the tasks of a blockchain over at least two full-nodes. By doing so, modular blockchains tap into the computing power of multiple machines when building each block. 

This is a form of horizontal scaling. 

Modularity was useful for thinking about blockchain scaling because it’s a type of horizontal scalability.

On the other hand, most of the monolithic camp opted for scaling through software optimizations, implementing parallelized virtual machines, data pipelining, faster networking protocols, and (most notably) more powerful hardware. In essence, monolithic chains tried to squeeze as much computational power out of a single full-node as possible. 

This is a form of vertical scaling.

Critics say that this approach trends toward centralization: if you rely on increasing the power of a single node to scale, you inevitably hit physical constraints of the underlying hardware and are forced to increase hardware requirements to scale further. 

However, this criticism is misplaced because not all monolithic chains rely solely on vertical scaling. 

For example, Near is a monolithic L1 blockchain built upon a sharding network architecture. This means Near full nodes are responsible for all tasks (i.e. execution, settlement and data availability), but they are only responsible for a fraction of Near’s global state. Therefore, Near taps into the power of multiple machines (just like modular chains) by dividing the work based on state as opposed to tasks. 

We can see that neither monolithic nor modular chains are limited in terms of the scaling techniques they implement. Both can scale horizontally and/or vertically.

Further, the modular vs. monolithic debate has always been rooted in the horizontal vs. vertical scaling framework. From a strictly technical perspective, modularity skewed towards horizontal scaling, which is inherent to its design, and monolithics skewed towards vertical scaling. 

Now that we’ve successfully launched modular chains, additional scaling benefits no longer lie in going “more modular”. The focus is now on how a chain utilizes horizontal or vertical scaling techniques.

Adopting the horizontal vs. vertical mental model allows us to easily reason about the trade-offs each chain is making in the process. 

Reframing the Conversation: Horizontal vs. Vertical Scaling

Before digging deeper into the horizontal vs. vertical scaling framework, it’s important to acknowledge its origins date back to the 1970s when distributed computing research laid the groundwork for horizontal scaling concepts. Today, all scaling techniques can be categorized as horizontal or vertical scaling. 

Vertical Scaling

Vertical scaling increases the hardware utilization or hardware requirements of each node. In blockchains, this is commonly done through software optimizations like parallelized VMs (i.e. multithreaded processes). 

A popular example here is the EVM vs. SVM. 

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

In terms of trade offs, vertical scaling is limited by available hardware, trends towards centralization due to increasing 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 splitting the workload over many nodes. As outlined earlier, modular chains inherently distribute tasks over multiple machines. However, chains can usually achieve a larger degree of horizontal scale through sharding.

=nil; provides a useful example here. 

Last November, =nil; Foundation introduced a provable sharding architecture called zkSharding, which serves as the basis for =nil;, the new Ethereum L2. Core to =nil;’s design is the partitioning of its global state across many shards. Each shard is run by a decentralized committee of =nil; validators who build blocks and manage cross shard transactions. Additionally, each shard generates a validity proof that gets sent to the main shard for aggregation before being posted and verified on Ethereum. =nil; taps into the power of horizontal scaling in two ways: 

• First, =nil; is a modular blockchain that uses the strong consensus and data availability guarantees of Ethereum thus distributing tasks across multiple full nodes. 
• Second, =nil; is a sharded blockchain thus distributing portions of state across many full nodes.

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

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

The End Game for Ethereum Scalability

Neither horizontal nor vertical scaling is restricted to the modular or monolithic architecture. This is why the horizontal vs. vertical scaling framework provides more space to explore new solutions that make modular blockchains even more scalable.

For example, one option is to vertically scale one of the layers of the modular stack. A popular means to do so is implementing a parallelized VM, thus scaling execution throughput. As mentioned above, Eclipse is taking advantage of the SVM and other rollups, such as Starknet, implement BlockSTM to enable parallelization. 

But, vertical scaling is always restricted by the limits of a single machine and we cannot break the laws of physics.

One solution might be to opt for horizontal scaling through sharding. 

Current modular designs only begin to touch on the full potential of horizontal scaling. With sharding, we can tap into the power of an arbitrarily large number of machines (as opposed to 2-3 machines split by tasks). 

In other words, many machines can run the same type of task in parallel. This is what Ethereum and Celestia hope to achieve with Danksharding and data-sharding, respectively. But, sharding isn’t inherently limited to data availability layers - it can also be coupled with execution (as in the case of the =nil; L2). 

If we combine the horizontal scaling achieved through a modular stack with the horizontal scaling sharding affords, we get a massive increase in available computational power.

But we can do even better…

The end game for blockchain scalability will merge both horizontal and vertical scaling, resulting in sharded blockchains with parallelized VMs.

At =nil; Foundation, we’re methodically working towards this end state design. The =nil; L2 takes an aggressive scaling roadmap by leveraging modularity, a horizontally scalable architecture (zkSharding), and a vertically scaled validator implementation (intra-shard parallelization). 

The =nil; design therefore results in global scale without sacrificing state, liquidity, or user fragmentation.

Curious about horizontal scaling and zkSharding? Check out our Discord and Twitter to join the conversation.