In recent years it has become in for new Layer-1 blockchains to heavily advertise their scalability in the form of TPS = Transactions Per Second. But is that really all scalability is about, and how do networks try to scale on the base layer? Read on to find out.
What is scalability anyway?
Scalability isn’t limited to blockchains. More broadly, it describes the capability of any system to adapt to increased workload and demand quickly. While most of us will think of scalability only in terms of scaling up, it can also apply to a situation in which demand drops sharply. You’d want a system to cope with that without becoming hugely inefficient.
We’d call a firm scalable when it benefits from economies of scale. That means that it can, without much further expenditure, provide supply. A great example of businesses benefitting from such effects are Software-as-a-Service firms. While they initially have to spend a vast amount of capital and labor on building their products, eventually, they will be able to easily accommodate 100, 1000, or even one million customers.
Scalability also applies to organizational capabilities. When a business scales, it often increases its headcount, which can be chaotic if it’s not well thought through and managed. Businesses doing well during the transition from startup to big corporate usually have a company culture of trust and a well-functioning leadership team.
Now we know that scalability encompasses various aspects, but still…
What about blockchain scalability?
In the world of blockchain, it seems to be common to express scalability with a straightforward measure: hello again Transactions Per Second (TPS). It’s easy to put a number to it and easy to compare networks using that one number.
However, it tells us little about how well a blockchain can adapt to changing demand. We experienced downtimes for blockchains like Solana and Polygon in recent months — limiting scalability to tps might not be sufficient.
If we want blockchain to support payments and transactions by millions of people, scalability is a requirement. Yet, existing blockchains are struggling with it.
A centralized entity like Visa can easily manage 24,000 TPS because it doesn’t require thousands of nodes to verify that these transactions are valid.
But why can’t a blockchain have it all?
The blockchain trilemma
The trilemma is an idea first conceived by Vitalik Buterin. He concluded that any given blockchain can only achieve two out of the three properties:
- decentralization
- security
- scalability
These days, we’re seeing new Layer-1 blockchains launch that are making clear sacrifices on the decentralization side to accommodate scalability. And it works — until it doesn’t.
A few of the things blockchain protocol developers need to think about as a chain scales are:
- cost: what does it cost to verify and send transactions?
- blockchain size: is there a storage cap or does it just grow infinitely?
- latency: how long does it take for the state of the chain to propagate to the entire/a majority of nodes as more nodes exist?
- network load: how many transactions can the network handle? how many can be stored in the mempools and what happens when those are full?
- energy: how much energy will the network consume as it scales?
All these are questions blockchain developers need to consider when addressing the scalability question. There are various approaches to increase scalability. In the following we will focus on solutions that directly affect the base layer of the chain, also called L1 scalability solutions.
Let’s start with the most obvious — and easy-to-understand one.
Bigger blocks
What limits how many transactions a blockchain can verify per second? It’s closely related to how many transactions fit into a block and can be validated at a time.
Initially, Nakamoto when creating Bitcoin added a 1 MB limit to block size which resulted in 3–7 transactions per second. The bitcoin community was torn between increasing the block size to accommodate more transactions and making changes to what is stored in blocks which would result in increased transactions (SegWit, more on that below).
Ultimately, the camp advocating to increase block size hard forked the protocol and created Bitcoin Cash. Bitcoin Cash took bitcoin’s code and increased the block size limit to initially 8 MB and later further to 32 MB allowing it to handle up to 116 transactions per second.💨
Bigger blocks = better?
Unfortunately, scaling isn’t that easy. The downside of that approach is that now running a full node for Bitcoin Cash requires a lot of computing power and storage capacity from node runners. As a result, Bitcoin Cash is primarily mined by big mining pool operators these days.
It might do alright in transactions it processes per second, but its big blocks aren’t even full. The average block size is 0.22 MB, leaving more than 30MB empty in blocks. It scaled at the cost of decentralization and massive inefficiency in the form of empty block space.
What about the other camp of Bitcoiners advocating SegWit?
SegWit
When Bitcoin was created, every transaction included digital signatures. These signatures required a lot of space to accommodate and were responsible for the transaction malleability hack bug.
The malleability bug is a direct result of how hashing works. When you use SHA 256 to encrypt a text, even one small change in the original text (low cap instead of high) will create an entirely different hash. (You can try it yourself here).
The vulnerability resulting from that would allow receivers of a transaction to alter the sender’s signature and overwrite the existing transaction.
The introduction of SegWit (short for Segregated Witness, because signature information was also known as witness information) fixed the malleability bug that previously prevented second-layer protocol development on bitcoin.
While the intention was to remove a bug, by removing signatures from transactions, they became smaller. Consequently, more transactions could be added to one block even without changes to the block size; increasing scalability.
Thanks to SegWit other features could be added to the network including Schnorr signatures and the lightning network.
SegWit is limited to Bitcoin so doesn’t apply to other L1s. This is why a lot of them these days are looking at parallel processing via Sharding.
Sharding
Sharding is a database partitioning technique. What does that mean? It means that the database is split into partitions that process only parts of the database, and not the entire database.
The concept is in use since the 1990s in traditional databases worldwide.
For blockchains, it means that all nodes are split into different groups (called shards) that are assigned a specific section of the network. Instead of all nodes processing every transaction, they are spread across all shards enabling parallel processing of transactions without requiring nodes to do any more workload than previously.
Therefore, sharding can increase the speed of transactions, and help keep costs down, as the network scales. Too good to be true?
There is one catch, the 1% attack.
For sharding to work, shards need to communicate with each other. If we assume a network that is split into 100 shards, where each shard holds 1% of the hash power, an attacker would need only 1% of the total hashrate to take over a shard.
On that shard, they’d then have free reign to double-spend or delete data of legit transactions.
We speak about hashrate of the network, because the 1% attack is possible only on sharded PoW networks. All currently existing blockchains that implemented sharding use Proof-of-Stake, or a form of BFT in combination with PoS, including Zilliqa and NEAR.
Is Proof-of-Stake with Sharding the answer to the Blockchain trilemma?
Short answer: No because Proof-of-Stake doesn’t enable true decentralization.
Longer answer: Proof-of-Stake might be energy-efficient, but when tying security and construction of a chain to one’s wealth, it tends to favor the rich. If we want to achieve decentralization, security, and scalability giving up on decentralization isn’t an option
As soon as you give up on decentralization you sacrifice censorship resistance and create vectors of attack. You might also run into problems with availability as downtimes with networks like Polygon have shown this year.
We outlined why we believe the only algorithm making decentralization possible is PoW here.
And does that scale?
The blockchain trilemma is referring to Layer-1 blockchains. But Layer-1 doesn’t scale. And it doesn’t have to. As long as you have scalable Layer-2 solutions.
Blockchains like Bitcoin have shown that it’s possible to create a highly scalable payments network (Lightning) on top of a not-so-scalable Layer-1 and even Ethereum maxis are now advocating for the development of further rollups and other scaling solutions to enhance scalability.
When combining a truly decentralized Layer-1 with Layer-2 Scaling solutions, you can get all three properties: decentralization, security, and scalability.
But not all Layer-2 scaling solutions are created equal. Watch out for our next post to learn more on Layer-2 scaling, and on how Minima will scale.
To learn more about Minima, check out our website, join our Discord server and discuss the protocol with us!