status

Scalability as Cardano's path to global adoption

Published 16.5.2023

You want to get from A to B. You can buy an expensive ticket and travel for an hour, or buy a cheaper one and be there in 2 minutes. People behave rationally and most will choose the more affordable and faster option. Therefore, they will never be willing to pay for expensive transactions on the blockchain.

Public and decentralized blockchain networks usually need to scale better. This means they are unable to process all incoming user transactions in a timely manner. Think of it like a bus that runs regularly every 10 minutes from a stop. Only 100 people can fit on the bus, but there are regularly 200 or even 300 people at the bus stop. People need to take the bus, so they start offering a higher fare. Some people are still willing to pay The fare rises from 0.50 USD to 50 USD. The competition will emerge. A modern high-speed train that runs every 30 seconds, the fare is only 0.10 USD, and it can fit 1,000 people. In a week, no one will use the bus.

In blockchain terminology, we would say that a high-speed train scales better than a bus. The number of transactions handled by a system per second is referred to as throughput. Think of it as the number of people the bus takes every second. In our case, it is 0.16 people, because we divide 100 people by 600 seconds.

Cardano has ambitions to become a global financial and social operating system. To do this, it needs to scale better. Much better. In this article, we discuss why it is difficult to achieve scalability at the first layer and why we need second layers. We'll talk a little bit about Hydra, a bit about rollups, and a bit about Milkomeda.

Remember that a single Cardano transaction can contain multiple assets and multiple recipients. We won't repeat this too much in the article, but a single Cardano transaction can be the same as 10 or even 100 transactions on another blockchain network.

TLDR

Worldwide, over 16,000 digital financial transactions take place per second. It is difficult for decentralized blockchains to approach such high throughput. State channels, sidechains, and rollups are all second layers that we will be using in the Cardano ecosystem in the near future.

Why does not blockchain scale well?

Blockchain is a distributed network composed of nodes. One of the requirements for blockchain is decentralization, which basically means being able to run your own full node relatively cheaply. Nodes have 4 bottlenecks: processing power, memory, storage, and bandwidth (the maximum amount of data a node can download or send at a given time).

Nodes in the Cardano network communicate with each other and forward all transactions that users submit. Each node validates the transaction. This may require Plutus script validation, which requires more computational power. All received transactions must be temporarily stored. Valid transactions that make it into the block must be stored permanently.

Cardano currently processes roughly 50,000 transactions per 24 hours. Many transactions contain multiple recipients, so Cardano is used by roughly 1 to 5 people every second.

Now imagine what kind of computer you would have to have if 1000x more people were using Cardano. Or 10,000 times more people. The computing power, memory, storage, and bandwidth requirements would be extreme. Only entrepreneurs could run a full node, which would lead to centralization. The idea of "Do not trust, verify" would be unattainable.

According to one report provided by Capgemini a BNP Paribas in 2021, there were 522 billion financial digital transactions worldwide in 2020. That's 1.4 billion per day, or approximately 16,000 transactions every second. The real number may be even higher as the team did not have access to all companies' data.

Higher demands on computer performance lead to network centralization. If a decentralized network is to scale better, the team faces a major technology challenge.

In order to settle a transaction, the nodes must first agree on its validity. If the system has a large number of nodes, this agreement may take some time. Higher decentralization makes agreement between nodes more difficult. Each individual node has to consume its own computing resources to obtain, verify and store the transactions. This is desirable from a decentralization perspective, but very inefficient from a scalability perspective. Clearly, if the ecosystem (blockchain and second layers) is to scale better, nodes cannot verify all transactions between users.

The task of the second layers is to alleviate the bottlenecks of the first layers. The goal is to parallelize the processing of transactions in different layers, thus saving the computing resources of the first layer. There must always be some mechanism to transfer assets from the first layer to the second and back.

The second layer has its own nodes (computer resources) and its own rules for achieving consensus among users. Decentralization and security assumptions can be significantly different from the first layer. Some people mistakenly believe that if a second layer is created on top of a particular blockchain, it automatically inherits its properties. This is not the case. The point of second layers is to take over responsibility for assets from the first layer. The first layer is only involved in the transfer of assets between layers but does not validate the transactions and execution of smart contracts taking place in the second layer. The second layers are usually a completely different infrastructure, including nodes (which can have bugs), wallets, consensus (the second layer can be just a centralized server or consists only of a few nodes operated by a single entity), etc.

Note that verifying transactions is about working with data. In order to verify data, it must be available. In practice, this means that the node must download it or have someone send it to it (bandwidth), and the node must store it (memory, storage) and validate it (processing power). The problem is that a normal computer cannot handle a huge volume of data. People are complaining that the Cardano blockchain is too big and growing fast. The second layers reduce the computing resource requirements of the first layers, as it is assumed that the data (transactions) that originated in the second layer will be stored elsewhere, or simply deleted after some time.

You probably know that Cardano is the first layer. The second layers are or will be Milkomeda, Hydra, Midnight, and others. Let's take a look at the differences between the solutions. There are 3 basic concepts of the second layers: sidechains, state channels, and rollups. We won't dwell too much on the differences between the concepts. We will focus on how they work in principle.

Hydra

Hydra is a state channel solution.

Hydra is used as follows. Several users agree (off-chain) to open a so-called Hydra Head together. This basically means that they use a smart contract that transfers a chosen amount of their assets from the Cardano blockchain to Hydra. An on-chain transaction is required to transfer the state from Cardano to Hydra. After the transfer, the users share the off-chain state with each other. They can do any number of transactions quickly and cheaply. The final changes are transferred back to the Cardano blockchain through an on-chain transaction.

Hydra is similar to Lightning Network (LN). Hydra Head can be opened by multiple users while LN will only allow a channel to be opened between 2 users. Hydra will allow users to use tokens and can also execute smart contracts.

Hydra is useful when multiple users want to send multiple transactions to each other. Each user has to use a Hydra node and be online at all times to make sure that no attempt is made to close Hydra Head prematurely. If so, it is necessary to check the final state and challenge it if necessary (in case of a fraud attempt).

Hydra is useful when participants know in advance when Hydra Head will be closed.

Hydra has its own consensus mechanism that takes place only between participants. The Cardano blockchain knows nothing about what transactions are taking place in Hydra Head.

It can be said that Hydra Head transactions are private. However, the final state is written into the blockchain.

Future work will be done on Hydra Tail to allow users to be temporarily offline. Hydra will operate from a mobile phone. Another planned improvement will be the ability to connect Hydra Heads with each other. The interconnection of Hydra Heads paves the way for larger networks of participants, effectively turning local Heads into a global network.

Milkomeda

Milkomeda C1 is a EVM-compatible sidechain solution.

Milkomeda enables the execution of Ethereum applications in the Cardano ecosystem. To use Milkomeda, you need an EVM-compatible wallet, such as Metamask. You connect the wallet to the Milkomeda sidechain. Then you need to send assets from the Cardano network to Milkomeda via a bridge. The ADA will become MilkADA (a kind of wrapped ADA). MilkADA is used for paying fees.

Sidechain is usually a separate network with its own validators. In the case of Milkomeda, the validators are run by a group of Cardano SPOs.

The dcSpark team has come up with an innovation called wrapped smart contracts that allows users to stay on the Cardano network but use smart contracts on the sidechain. All users have to do is submit a single Cardano transaction with the data and assets needed to interact with the sidechain dApp. The sidechain bridge layer takes care of the rest. This particular solution actually uses the resources of Cardano nodes but can save computing power.

Commonly, sidechains are used so that assets are transferred across the bridge and all transactions and smart contract execution take place in the second layer. This saves essentially all the computational resources of the first layer (similar to state channel solutions). Users are not forced to run a Layer 2 node and do not have to be online as in the case of the state channel solution. Sidechains usually have their own public ledger in which transactions are traceable.

In general, a sidechain may face similar problems as a blockchain if it were to be decentralized. However, this is not what users expect. The goal of a sidechain is usually to scale better at the cost of less decentralization.

Rollups

IOG and dcSpark teams are working on rollups for Cardano. Rollups can save processing power and memory of the first layer. To a certain extent, so does storage and bandwidth, but its usage can vary from case to case.

Rollups are mostly based on a smart contract that allows users to transfer assets from the blockchain into a rollup network. In a rollup, you can do basically anything with assets. A rollup can be just a fast transaction network, it can execute smart contracts on any virtual machine, or it can be an application.

Rollup maintains the state of the network through a special Merkle tree data structure. Think of it as a pyramid built out of bricks, where each individual brick represents the information (user balance, transactions, etc). A hash (short string) can be created from each piece of information. A hash can also be created from two pieces of information. For every two hashes from the lower layer of the pyramid, one hash is created in the higher layer. If one proceeds in this way towards the top of the pyramid, a single hash, the Merke root (state root), is created that represents all the data in the tree structure.

It is possible to cryptographically prove that piece of the state exists within the Merkle tree as long as you have the piece of state, a few branch nodes (bricks in our analogy), and the Merkle root.

Rollup continuously sends a new state (Merkle root) to the smart contract of the first layer. Blockchain is used to write the rollup state, which cannot be changed. The blockchain also serves as a data availability layer, as the new state of the rollup is distributed along with each new block.

Rollups tend to have data availability problems. If the blockchain only wrote Merkle root, it would know nothing about transactions which is a desired feature. However, if the rollup was offline for an extended period of time, the funds would be stuck, since without the data (or at least part of the data) it is impossible to prove that the user is the owner of the funds.

There are multiple solutions to this problem. Rollup can send data to the blockchain together with Merkle root. Just data allowing to recreate the changes made in the Merkle tree. The blockchain network does not need to process the data, just store it. The data can be compressed.

Some rollups store data on other dedicated networks. This saves storage on full nodes (the size of the blockchain grows slower). Some solutions validate that data is actually available on external networks.

Rollups can use Zero Knowledge (ZK) cryptography. ZK allows a user to create proof that they correctly completed a task without having to give any information about the task.

How does ZK work? Imagine you have a secret code to a door located in a corridor. You want to prove to the other party that you know the code, but you don't want to show them the code? So you walk down the corridor and open the door. Passing through the corridor is your proof that you actually know the code.

ZK rollup can create a ZK proof that it has taken the previous state, processed valid TXs, and correctly produced a new state root. A smart contract executed on the blockchain can verify all evidence and can reject a Merkle tree update if there is an attempt at fraud. ZK rollup does not need to store transaction and signature data on the blockchain because it is not possible to cheat.

As with sidechains, the rollup must have its own way of decentralization, project management, etc. Often the risk is that the smart contract can be updated via admin keys. This way the team retains control over the contract and therefore essentially the user funds. Some projects deal with this by making the new update active with a delay (e.g. 2 weeks).

At the time of writing, it is uncertain how far along the teams are with the development of rollups for Cardano. Our assumption is that we will see the first attempts in 2023. Rollups are used in many projects, and the first attempts are even being made on Bitcoin, which has very limited programmability.

Conclusion

Each second layer will always be dependent on the first. Therefore, the scalability of the first layers must also be significantly improved, otherwise, the blockchain will forever limit the functioning of the second layers. In the case of state channel solutions, channels must be constantly opened and closed. Someone calculated that if everyone on the planet were to onboard the Lightning Network, it would take 70 years. If transactions on the first layer are expensive and slow, many people won't get to the second layer and probably won't even try. Cardano will scale significantly better on the first layer thanks to PoS Leios.

If you use sidechains and rollups, always be aware of how decentralized the networks are and what the risks of using them are.

Cardano has a sidechain on Milkomeda. Hydra Head has already been opened on the main-net. We expect the first rollup to appear later this year and it will be delivered by the dcSpark team. Each individual solution has its own strengths and weaknesses and is suitable for different use cases. All solutions have a chance to succeed.

Featured:

Related articles

Did you enjoy this article? Other great articles by the same author