Upgrading to Web 3.0

Scaling permission-less blockchains

After Bitcoin first launched in 2009, people’s excitement and motivation renewed to build a truly decentralised internet which can put in motion a trust-less world economy. The internet today, is the most democratic place and in many ways, it is the most egalitarian institute on this planet. Blockchains provide a way to create a truly decentralised internet. People are already using and building decentralised applications on open blockchains like Ethereum. Bitcoin made it possible to transfer value over the internet in a completely decentralised way. For the first time ever there exists the concept of ownership of something that is digital. For the first time ever there exists a digital “something” that is limited and scarce which is quite insane if you actually think about it.

However, there is a long way to go. For starters, most mainstream blockchains are not scalable. The first direct use case of blockchains is cryptocurrency. But, they lag far behind even as payment processors.

To give you an example, Bitcoin can settle transactions at 7 transactions per second. Ethereum can settle transactions at 15 transactions per second. Compare this to Visa, which can settle transactions at 1800 transactions per second in practice while in theory it claims it can handle up to 56,000 transactions per second. Blockchains like Ethereum and Bitcoin, lag far behind as mainstream payment processors in this regard.

The fundamental reason behind such low performance is that blockchains, in their current forms, are not scalable. Performance in blockchains depends on two factors:

1. Throughput: Maximum number of transactions per second the network can confirm.
2. Latency: The time delay between a user making a transaction and the transaction actually getting confirmed.

Since blockchains are decentralised, we have nodes instead of centralised servers and data centres to clear transactions. In case of open, permission-less blockchains anyone can join the network and run a full node and anyone can leave the network at anytime.

Blockchains don’t scale-out with respect to number of nodes

Transaction verification time increases with increase in number of nodes. The reason is simple. Every node in the network has to independently verify each and every transaction it receives. And since every node does not receive a new transaction at the same time, the node that first receives it, verifies the transaction, if the the transaction is valid it passes the transaction to its neighbours who in turn verify the transaction independently and pass on to their neighbours. This continues till each and every node receives the transaction and has verified it. Due to this, transaction verification time increases with the increase in number of nodes. Also it is more difficult to reach a consensus if the number of nodes is very large. Since in open blockchain networks there is no control as to how many people can join the network and run a full node it is important that we find an efficient scale-out technique.

Scalability is a very important issue to work on if blockchains are to succeed. In this article I will be writing about some important scalability solutions that the blockchain community in general is working on.

1. Sharding

Today, every node in the network processes every transaction. What sharding means is — division of nodes into teams/groups. Each team/group is called a shard. To explain how sharding improves scalability, let us assume that an “unsharded” network can handle only 100 transactions in a given amount of time. Note that the total number of transaction requests can be way more than 100 but the network can handle only 100 transactions at a time. If the network is divided into n shards (teams), then each and every shard can now process at least 100 transactions at a time(or even more) simultaneously. And the reason is simple, as the number of nodes decrease, the network can clear transactions faster because, transaction verification time and the time taken for consensus decreases with decrease in number of nodes verifying the transaction. Hence, theoretically the total number of transactions the network as a whole can handle, now becomes 100 times n.

So, even more simply put — sharding is basically division of work (the work here being processing transactions) among teams (known as shards). Since the network is divided into teams, the number of nodes verifying a set of transaction decreases. So earlier (in our above example) if 1000 nodes were processing the 100 transactions, now after sharding every shard will be processing at least 100 transactions simultaneously. And in a shard, these sets of 100 transactions will be processed by 1000/n number of nodes (n being the number of shards). This is a good thing for performance as it reduces overall transaction verification time and is also more efficient to come to a consensus with lesser number of nodes. Note, that the value of n is decided by the network community and is based on the the degree of decentralisation the network wants to maintain in each shard.

Sharding is not a new technique. It is being used in centralised systems since a long time. Hence, implementing sharding in decentralised systems has its own challenges. There are various ways in which sharding is being proposed to be implemented in decentralised systems and every kind of implementation has its own set of issues.

One way sharding can be implemented is that the network can be divided into shards and they maintain a single, common ledger. The problem with maintaining a common blockchain is — consensus amongst the shards themselves to add the next block. Note that a shard is an open network of nodes working independently from the the other shards. Consensus amongst shards can be tricky in this case. One possible solution might be that, each shard can delegate a “shard leader” and then the shard leaders can come to consensus as to which block to add next to the blockchain.

Another sharding implementation is, each shard maintain its own blockchain. This way there will be no need for inter-shard consensus. But the problem with this solution is that of cross-shard transactions — transactions involving data stored in the blockchains of two or more shards.

The problem of sharding in decentralised systems is an open research problem and lot of different kinds of implementations are being designed and tested.

2. State channels

State channels are specific protocols built on top of the already existing technology to make blockchain transactions scalable. Hence, they are a layer-2 solution for scalability. Let us first try and understand the problem that state channels are trying to solve.

Transactions today on Bitcoin and Ethereum are not exactly very fast. The maximum capacity in terms of the number of transactions these networks can handle in a specific amount of time has already been reached. Hence normal transaction on these networks can take quite some time when compared to mainstream payment methods. This has led to increase in transaction fees as miners prioritise transactions based on the fees they can earn. Hence if a person is ready to pay greater transaction fees his/her transaction is prioritised over others. This leads to transactions becoming expensive and time consuming due to the inefficiencies in performance of these blockchain networks.

What if there was a way using which a number of transactions can be validated without them being recorded on the main blockchain. If all transactions need not be recorded on the blockchain, then not all transactions need to be mined and reach a consensus upon. This kind of payment mechanism can make transactions faster and inexpensive. These kind of transactions, which are not recorded on the main chain are called off-chain transactions.

State channels refer to a set of general rules that define the procedure to carry out such off-chain transactions. State channel is nothing but a special payment method set up between two parties. They can keep exchanging value as long as they want over that channel and can close it by broadcasting the final state to the network so that it can be recorded on the blockchain. To understand this more properly let us take an example. Suppose Alice and Bob want to set up a payment channel. Every payment channel has a limitation as to what maximum value can be transferred over it. That maximum value is equal to the total amount of, say bitcoins, that the two parties are ready to put up as escrow. More simply put, the two parties have to make a deposit of an amount of their choice to initiate a payment channel. This deposit of both the parties needs to be broadcasted to the network so that it can be recorded as a special type of transaction (called a multi-signature transaction) on the main blockchain. Once this transaction is mined, the payment channel is initiated. So, in our example let us say, both Bob and Alice deposit 10 BTC each. Hence the total value of this particular payment channel is 20 BTC. Now if Alice wants to send 1 BTC to Bob, Alice simply needs to send a cryptographically signed message stating so. Hence now Alice’s balance is 9 BTC (10 BTC she had deposited minus the 1 BTC she sends to Bob) and Bob’s 11 BTC. Now let us say that Bob wants to send over 7 BTC. He does it the same way as Alice, signing a special message stating the event. Now Alice’s balance becomes 16 BTC and that of Bob becomes 4 BTC. And say they keep on making transactions like these over the payment channel and finally Alice has 12 BTC and Bob remains with 8 BTC. Note that all these transaction are basically fee-less and instantaneous as none of these transactions are mined and recorded on the blockchain. Now anyone of them can close the channel by simply broadcasting the final state of the channel: Alice-12 BTC & Bob-8 BTC. Once this broadcasted transaction is mined the payment channel is closed. Hence the two parties need to only pay fees when they initiate a payment channel and close the payment channel which is still inexpensive compared to a normal situation in which both the parties would have paid fees for all the intermediary transactions. The power of state channels really shines when these singular channels between two parties becomes a network spread over a large number of payment channels. To give you a simple example, let us suppose instead of two parties, there are now three parties involved — Alice, Bob and Charlie. Say Alice and Bob have a payment channel between them and Bob and Charlie have a payment channel between them but there is no payment channel between Alice and Charlie. Now even though Alice and Charlie don’t have a payment channel linking them directly they can still exchange value via Bob.

Note that these channels can remain live as long as the parties involved want it to be. Even forever if they want. Hence state channels provide a novel 2nd layer scaling solutions to blockchains.

3. Side-chains

Side-chains by far is my favourite scaling solution to blockchains. Just like state channels, even side-chains are a layer-2 scaling solution. Side-chains are basically separate blockchains that operate alongside the main blockchain. These side-chains are two way pegged with the main chain meaning they allow for interoperability of digital assets on the main chain and the side-chains. But why do we need a side-chain and how does it solve the scalability issue?

There are many blockchains that have achieved high transaction speeds at the cost of decentralisation. What this means is that the power/authority to create and add a new block to the blockchain is limited to a small number of nodes in these networks. Generally these nodes are chosen through voting and hence the identity of these nodes are known. While a small number of block producers does improve performance in a significant manner but this is not good as now the network can easily be disrupted if some one or some organisation go after these publicly identifiable block producers and try to shut them down. There is also a great risk that these block producers may collude and cheat the system. Hence “true decentralisation” is very much necessary if transfer of value over the internet is to remain secure.

It is very difficult for a decentralised system to be secure and scalable at the same time. Moreover even if a blockchain were able to handle thousands of transactions per second without compromising decentralisation, it will still not be enough to run all of world’s decentralised applications on that network. Imagine a decentralised version of Facebook, a decentralised version of Twitter, a decentralised of World of Warcraft and hundreds and thousands of various decentralised applications running simultaneously on a single blockchain. No matter how many transactions per second the current form of blockchain can handle, it cannot run all these decentralised applications simultaneously. Hence, while it is important that blockchains have improved scalability at a protocol level it is also very clear that finally for the decentralised internet, scaling has to occur at the second layer — protocols built on top of current technology to improve performance.

So back to the question — How does operating another blockchain alongside the main chain solve the scalability issue? Well, if the main chain has a high degree of decentralisation and is quite secure, then we can have a number of side-chains designed to run various decentralised applications. The side-chains can be designed for high performance at the cost of decentralisation as these side-chains are anyways pegged to a main chain that has a high degree of decentralisation and security. Since digital assets can be easily transferred from the main chain to the side-chain and back to the main chain if required there is easy interoperability. And if the side-chains happen to go rogue it won’t affect your digital assets as you can easily transfer them from the side-chain to the main chain. This opens up a plethora of opportunities as now you can design side-chains for specific use cases, say to run decentralised social media applications or to run certain kinds of games and things like that. And if someone is feeling really crazy then they can even make side-chains to the existing side-chains and side-chains to even those side-chains and so on. With the main chain acting as the backbone, the side-chains will be able to run all of decentralised applications of the world at high performance!

Summary

We saw three main scaling solutions that are currently being researched actively by the blockchain community. Sharding is being actively researched by Ethereum and OmniLedger as a possible scaling solution for decentralised systems. Lightning Network for Bitcoin and Raiden Network for Ethereum are the “state channel” projects being worked upon for the two blockchain networks. Rootstock is designing a side-chain for Bitcoin that can run smart contracts. Loom Network is an exciting community/company that is building its own custom side-chain to run decentralised games. They are soon going to launch a collectible card game called Zombie Battleground on the blockchain.

To summarise the scaling methods we discussed:

1. Sharding: It basically involves dividing the nodes in the network into teams (called shards). Each shard handles a part of the the total transaction requests made to the entire network.
2. State channels: It basically involves setting up a payment channel “off-chain” between two parties. Since transactions happen off-chain they are inexpensive and fast.
3. Side-chains: It basically involves a whole new blockchain operating alongside the main chain and pegged 2-way to it to allow interoperability of digital assets. These side-chains can be designed for specific use cases as they need not have the same degree of decentralisation that the main chain may have.

My name is Miraj and I am a student from India. Thank you very much for reading the post. I intend to write more technical stuff and would love to hear any feedbacks you guys might have. I am also on Patreon and if you feel like contributing go ahead and feel free to checkout my Patreon page here.
https://www.patreon.com/mirajshah
THANK YOU.