The scalability problem in the blockchain space is one of the barriers preventing this technology from mass adoption. According to the blockchain trilemma, one must sacrifice decentralization or security to solve the scaling issue. One of the examples is the Ethereum blockchain, which can handle no more than 15 transactions per second, leading to a skyrocketing transaction fee. Still, it is well known for its decentralization and security. For a blockchain to handle a million users and maintain its characteristics, we need a way to scale blockchains while implicating decentralization and security as little as possible.

One well-known solution this problem is to use layer-2 solutions (rollup, state channel, and plasma) to scale the blockchain. Layer-2 platforms shift dApp computations off-chain. Layer-2 chains handle executions for a base chain (layer-1) and must settle their data on the base chain to inherit its decentralization and security.

When a block is proposed in a blockchain, each node must re-execute all the transactions in that block to verify that it is valid. This task is quite computationally intensive, and if you want faster verification time, each node needs to have higher hardware requirements. But doing so will reduce the decentralization aspect of that blockchain, as only a small group of node operators can afford a high-end computer.

Aside from increasing hardware requirements, one can upgrade a layer-1 blockchain to increase the chain’s throughput. For example, Polkadot split their computation onto several chains that can run many executions in parallel. However, this causes a heavy change in the layer-1 protocol architecture design, which requires a lot of time to develop. This is where layer-2 solutions come in to solve these pain points and why many developers are choosing to build a dapp on layer-2.

The concept of layer-2 scaling is to push computations off the base chain (layer-1) and make them more scalable without the need to change the layer-1 protocol. While the executions are handled off-chain by layer-2, their security and decentralization are still derived from the base chain by sending the transaction data back to the layer-1 chain. Currently, there are two main approaches to layer-2 scaling solutions: zero-knowledge (ZK) rollups, and optimistic rollups.

A fraud-proof mechanism is used here for optimistic rollups. Generally, a layer-2-based optimistic rollup collects transactions on their chain and batches (rollups) the transactions into a batch before executing them on layer-1. The name “optimistic” comes from the fact that those transactions are assumed to be valid until they are proved invalid (within a time window or challenge period). Therefore, the transactions can be executed without the need for the layer-1 blockchain to re-execute them again. The transaction data must be posted or made available on layer-1 chain to construct a fraud proof if the block producers misbehave.

ZK rollups use validity proofs to guarantee that a transaction is valid, which is different from what optimistic rollups did. After the transactions are batched, the layer-2 then produces proofs to attest to the validity of the chain. The proof and the data need to be sent together to the layer-1 chain so that the chain can execute the proof and check if it is valid. The proof is designed to be executed using much fewer resources, compared to re-executing all the transactions. One only needs to verify a proof to ensure the block’s validity, no transaction data is required. However, knowing the correctness of the block doesn’t tell us anything about the state of the L2. Thus, the transaction data must be available (data availability) so that users can perceive the L2’s state and interact with the chain normally.

Even though the gas cost of the rolled-up data is cheaper than the layer-1 chain in both cases, the scalability is still limited by the block size of the layer-1 chain. As a result, certain rollups may allow centralized entities to keep user transaction data off-chain. By doing so, one can have a more scalable layer-2 by trading off decentralization and security.

Before you go and build a dApp on layer-2, it’s worth looking at some of the solutions to the blockchain trilemma that are developing among layer-1 protocols. Recently, we have seen the emergence of several alternative layer-1 blockchains such as Solana, BSC, Avalanche, and so forth. They have paved the way for the next generation of blockchains with the hope of being superior to the old blockchains, like Ethereum. All these chains are either trying to be better than Ethereum in terms of better scalability, faster finality, higher transaction throughput, and lower gas cost. Each of them is designed to have its own unique advantages and technology to provide attractive use cases and a suitable environment for their users and developers. However, since most blockchains are closed systems to begin with, having several blockchains can cause fragmented users and assets in an ecosystem.

Imagine you have your money in a bank, and let’s also assume that there is no interaction or information exchange between other banks. How complicated would it be if you wanted to do online shopping?

The same problem occurs with blockchains today. Currently, all of these layer-1 and layer-2 chains isolate users and assets within their own silos, preventing them from interacting with one another. Although spinning up a new blockchain can help solve scalability, it does bring a new problem to the space. There is limited interaction for both users and resources among different chains. Therefore, we need a way to connect blockchains together, allowing the flow of resources and information. This is where the concept of interoperability comes in. The ability to build in the environment best suited to a developer’s product while allowing interaction with different chains. This can be made possible via the help of cross-chain platforms like the Axelar network. The cross-chain ability can lead us to the next era of blockchain, called the internet of blockchains.

We can solve the scalability problem through interoperability, yet it is very hard to achieve. There are a lot of challenges in making blockchains interoperable. The cross-chain protocol needs to ensure that interoperability can be done in a decentralized and secure manner. Liveliness and trust assumption are also important aspects to consider as well. There are several approaches to building an interoperable bridge. For example, using a traditional multisig bridge to connect two chains together in a pairwise manner (Horizon bridge, Ronin bridge, etc.), using a PoS chain to facilitate cross-chain communication (Axelar network), utilizing atomic swap (Connext), or using the concept of an optimistic bridge (Nomad). Different methods rely on different trust assumptions. We will discuss more about trust assumptions in the next article.

Both layer-1 and layer-2 scaling approaches have different advantages and disadvantages. Layer-2 scaling allows apps and users to transact more cheaply and efficiently, while inheriting some of the security of the underlying chains. Still, the scalability will eventually be bounded by the capabilities of the base chain. Also, developers who build a dApp on layer-2 are limited in sovereignty by constraints that may be applied at the base layer-1. Scaling via new layer-1 chains provides a variety of environments for the developers and users to choose whatever they want. At the same time, they can use cross-chain platforms to break the barrier of communication between chains.

On either path, solutions to scalability lead to new information silo problems where each chain is worked on independently. To connect or design an interoperability protocol, one needs to carefully design so that the chains can be securely connected in a decentralized manner. Many of today’s cross-chain platforms rely on a traditional multisig approach, so new trust and liveliness assumptions must be introduced. These are the problems we are now facing. In the next article, we will discuss the liveness assumption and trust model of different interoperability protocols.

Image source: Photo by Vernice Karbe, CC BY-SA 4.0