So far, blockchains as we know them today are classic monoliths. Monolithic architecture choice renders suboptimal in the longer run manifesting into issues such as high complexity, lack of scalability. Lack of scalability is one of the primary reasons why blockchain technology has not reached millions or even billions of users yet.
Monolithic systems are the enemy of scalability
Increasing throughput of blockchains has been a hot research topic since a few years now. To understand this point better, itt would be good to see how blockchains have evolved since the beginning of it all — since Bitcoin.
With the launch of Bitcoin in 2009, it was possible to transact (send + receive crypto) on a decentralized system for the first time. This set the stage for programmable money or smart contracts. In 2015, Ethereum was launched that enabled users to do more than simply send + receive money.
Both Bitcoin and Ethereum blockchains are textbook monolithic chains and as expected, these chains have a scalability problem. As Ethereum’s ecosystem matured, the need for scalability become increasingly apparent. A throughput of 15 tx/sec was not going to cut it.
The principle behind modular blockchain design is to divide the system into functional units. Each unit would be a blockchain in itself specializing in one function. It should be possible for the units to communicate with each other over a secure protocol.
Celestia created four different specializations:
Other blockchains such as Cosmos, Polkadot were trying to solve the scalability problem by opting for a multi-chain architecture. A multi-chain architecture brings together multiple chains that are connected to a parent chain. This architecture replicates hub and spoke model. These chid chains use cross-chain protocols and bridges to interact with each other.
This model might be useful for application specific blockchains. With respect to modularity, a multi-chain architecture off loads execution of transactions to the child chains from the parent chain and parent chain still acts as the “main chain.”
However, the cross chain protocols and bridges are extremely vulnerable to exploits. This security flaw ultimately isolated the child chains from one another resulting in independent chains which was the initial problem to begin with.
Hence, there was a need for more secure scaling technology than multi-chain architecture.
Rollups essentially compress transactions into a blob and pushes it to layer 1 (such as Ethereum). The validity of transactions occurs based on the type of rollup being used. optimistic rollups use fraud proof and zk-rollups use validity proof (such as ZK-SNARKS using PLONK). Since data is ultimately settled and is available on L1, the rollup commands the same level of security as L1.
There are several rollup projects such as zkSync, StarkNet, Loopring, Arbitrum, Optimism, etc which already have significant amount of value locked in them. It is an established fact that Ethereum will follow a rollup-centric growth model.
In the Ethereum L2/scaling wars, zk rollups will beat optimistic rollups in the medium to long term largely due to transaction finality. Transaction finality of optimistic rollups come with significant delay. ZK rollups offer a much faster finality as they mathematically prove correctness of all transactions without relying on any assumptions as in the former case. A typical optimistic rollup might require its user to wait for as long as a week to withdraw their assets from L2 to L1. Whereas a typical ZK rollup user would be able to withdraw their assets from L2 to L1 within minutes.
Currently, optimistic rollups such as Arbitrum and Optimism have better support for EVM, however zkEVMs are also catching up slowly. zkEVMs are significantly much harder to engineer. It is worth mentioning that zkSync is making great strides in that regard.
Rollups are modular innately modular in nature. They act as the execution layer and use L1 as settlement, consensus, and data availability layer which is similar to the multi-chain architecture. In a multi-rollup architecture as well a cross-rollup protocol is necessary to interact between rollups. Like cross-chain bridges are vulnerable to exploits, cross-rollup bridges are also vulnerable to exploits.
The difference between the two architectures i that there is no “parent chain.” L1 is the base layer which provides settlement + consensus + data availability, and the execution is off loaded to the rollups.
The adoption of rollups in the blockchain space is remarkably better compared to other scaling solutions such as plasma, validium, state channels. However, a single rollup is not the solution. In a world with multi-rollup architecture, the users would be able to hop between chains seamlessly (ideally within a single transaction). Consider this cross-chain MEV opportunity.
Another vision into the future could be the multiverse of rollups where a rollup creates its own universe of further rollups, or fractal rollups. zkSync is a Layer 2 scaling solution, they are currently working on Layer 3 solution known as Opportunity. Their aim is to unlock infinite scalability on Ethereum. L3 relates to L2 just as L2 relates to L1.
StarkNet is also working on the concept of hyper scalability with L3s and fractal layering.
Other than fractal rollups, enshrined rollups archetype is also coming into play. Polynya outlined that enshrined rollups. They may seem a bit futuristic but a multi year horizon, highly likely. Enshrined rollups are natively part of the L1. At this point, all the rollups are external. Ethereum doesn’t ship its own rollup. Yet.
The blockchains have evolved architecturally from Bitcoin to Ethereum to Cosmos to rollups. A multi-rollup future seems highly likely. Activity in the realm of ZK-DeFi is increasing with projects like zkSync, StarkNet, Aztec working hard to push the movement forward. It would be pretty cool to have enshrined rollups being shipped within the L1 spec however, we must remember that we should crawl before we walk. The next likely step would be to have fractal rollups. At this point, lots of key pieces such as cross-rollup protocols, bridges are needed to make a multi-rollup architecture possible.