Consensus mechanisms like Proof-of-Work (PoW) are critical to the performance, and indeed, the existence of blockchains. However, they usually end up slowing down the systems. And while it is essential for mass adoption of the technology, scalability has to be balanced with the other two critical aspects of blockchain; decentralization and security.
Having data in blocks makes the decentralization of blockchain networks possible. Meanwhile, the size of those blocks is limited so that the system knows when to move on to the next block. It is important to point out that most blockchains maintain small blocks. In the case of Bitcoin, for example, Satoshi Nakamoto capped the block size at 1MB. The reason for keeping the blocks small is so that even people with small hardware, software and data resources could effectively participate in the network. Also, having larger blocks would increase latency on the network to levels that impact user experience negatively.
However, the small block size has ended up creating another problem, which was not very apparent early on, by the way. It limits the number of transactions that a blockchain network can confirm in a second. For example, the Bitcoin network, in its original form, could hardly do 10 transactions per second. Meanwhile, Ethereum had a capacity of about 16. This is insufficient capacity, especially when you consider centralized systems can do. Visa and MasterCard can handle up to hundreds of thousands of transactions per second.
It has been apparent to many that for blockchains to effectively meet potentially existing demand, they have to scale massively. However, scaling blockchain is not something easy to do. In particular, there is a scalability trilemma to overcome. And that is the balance between the three critical attributes of blockchain: (I) decentralization; (II) security; and (III) scalability. If the right balance is not struck, the system will fail to become what we’ve all envisioned it to be
There is no question that decentralization is what makes a blockchain. The system exists because independent computers on a peer-to-peer network form consensus on the essential functions. If one or a few collaborating entities can dictate how the entire system works, then we will not be sure whether what we have is an actual blockchain.
Meanwhile, security assures all stakeholders they are not going to be victims of selfish actions others on the network. In part, security on the blockchain is assured through decentralization. And then there is scalability, the number of transactions a system can process and confirm in second. The more users a blockchain gets the more demand for scaling.
Indeed, given that blockchain is getting more use cases with time, it is necessary to confront the problem of scalability. And while doing this, it is critical to strike the right balance in regard to security and decentralization. Interestingly, the issue of blockchain scalability is akin to the scalability of the Internet. In the early Internet days, bandwidth capacity was really an issue. Users had to pull phone cables to connect computers. Meanwhile, the first modems had a capacity of 28 kilobytes, and it was a real development when they were upgraded to 56kilobytes, even though still surfers had to wait for minutes for pages to load. Today, we are talking terabytes, and internet scalability has ceased to be a major challenge.
The best way to scale blockchain is a question that developers, entrepreneurs and enthusiasts are still actively debating. One point of contention is whether the scaling should be implemented at the core protocol, or it should be done through second-layer solutions built on top of the blockchain. The main reason why some do not support scaling right at the core of the protocol is that it might mean making concessions on decentralization and security. Indeed, the belief is that it might mean granting more powers to particular participants and thus centralize the network.
Nevertheless, some of the proposals to scale blockchain right at the core protocol level do not necessarily point to a situation where security and decentralization will have to be compromised. Examples of such proposals include Sharding and alternative cryptographic algorithms, both of which we explore more below.
Meanwhile, there is much effort to develop second-layer scaling solutions. Examples of such solutions include sidechains and state channels (Lightning Networks). We also look at these two in more detail below.
State channels is a scaling solution that is implemented through projects like Lightning Network (for Bitcoin) and Raident (for Ethereum). In essence, the solution facilitates two or more individuals or entities to create a state channel. This is basically a line they will use to send each other funds as many times as they need to, and those transactions are not submitted to the blockchain. Meanwhile, the state channel will record only two transactions on the blockchain; the one that creates it and the one that closes it. The closing transacting will record the net balances for each participant. A robust smart contract manages the activities on the state channel.
To open a state channel, participants must commit funds on the blockchain. It is from these funds that they settle debts back and forth. Also, in the event of a dispute, the smart contract will use these funds to settle it on the blockchain. As part of opening a state channel, the smart contract creates a multi-sig. This is a pair of private keys from which each participant gets a copy. They can only use this key to send each other money through the state channel. The state channel can exist as long as the participants need it. At the point that they no longer need it, they submit a request to the blockchain close it. Then each participant gets a net balance.
Let’s say Alice and John have a business relation, and they often send each other money. They can simplify their financial interactions by launching a state channel on the blockchain. Alice can, for example, deposit 200 ETH into the smart contract that manages the state channel. On his part, John can deposit, say, 100 ETH. Let’s assume in a particular month, Alice sends John ten payments each worth 10 ETH each. On his part, John sends Alice two payments, each worth 20 ETH.
Without using a state channel, each of these 12 transactions would be recorded on the Ethereum blockchain. Meanwhile, through a state channel, they all are settled as two transactions. Besides reducing the number of transactions that are recorded on the blockchain, the state channel also helps Alice and John cut the transaction fees they have to pay to the network. Instead of paying transaction fees for each of the 12 transactions, they end up paying for only two – the state channel opening and closing transactions.
Furthermore, the state channel adds more privacy to the financial interactions of participants. Most of the activity happens in the state channel, and that is accessible only to the participants. Of course, we should expect that disputes will arise. One party can attempt to cheat the other. The protocol has been designed with this fact carefully considered. And like the core protocol of blockchain, its game theory rewards those who play by the rules and penalizes those who seek to cheat. With the smart contract keeping track of transactions, it is not easy to cheat the system anyway.
Usually, participants of a state channel must be part of it from the point of its creation. Adding or removing participants will necessitate closing the channel and creating a new one. However, projects like Lightning Network (for Bitcoin) and Raiden Network (for Ethereum) are testing upgrades that will make it possible to remove or add participants without having to close down the state channel. This opens up the possibility of meshing state channels so that transactions can be routed through several channels. This will remove pressure from blockchains as more transactions are processed on the second layer.
The following is a list of implementations of state channel:
Sidechains are blockchains that are linked through a two-way peg, a protocol that facilitates the transfer of digital assets between them. To transfer assets or tokens from one blockchain to the other, a user sends the tokens in the source chain to an address that locks them. The source blockchain then alerts the recipient blockchain about the transaction. The recipient blockchain proceeds to create and release equivalent tokens to the user to spend. If the user wants to move their value back to the initial blockchain, they have to go through a similar process. A group of servers known as a federation is responsible for the mediation between two or more sidechains. The federation, in particular, determines when tokens are locked up and released. Developers of a sidechain that links to a mainchain are the ones to set up a federation.
It is important to point out that a public blockchain can link up with a private blockchain and vice versa. Also, each of the sidechains can have its own consensus mechanism. That means two blockchains do not need to be using the same consensus mechanism for them to be compatible. However, sidechains that share the same consensus mechanism can participate in merge mining. That means the same miners can support the two networks using the same resources.
Although value can be transferred from one blockchain to another, they remain independent of each other. In case one of the blockchains does not have enough mining power behind it and it is attacked and compromised, the vulnerability does not affect the sidechains (or mainchains) that are linked to it.
Unlike in the case of state channels, transactions processed on sidechains are on a public ledger, unless the sidechain is a private blockchain. They are accessible to anyone who wants to look at the public ledger. Of course, they are recorded using pseudo-anonymous identities, which offers some levels of privacy. Also, sidechains are more permanent compared to state channels. They are not created to be closed at some point. With that in mind, it is way more costly to set up and run sidechains. In essence, all sidechains are blockchains that need skill and talent to build as well as enough miners to maintain the network. Furthermore, the federation component becomes an extra cost item and also a possible single point of failure.
The sidechain can operate more efficiently, even when some decentralization is sacrificed. The mainchain can guarantee overall security and stability. Meanwhile, users can get a higher transaction throughput on the sidechain, even with it being managed by a centralized authority.
The following is a list of sidechain solutions:
The number of blockchains is on the rise, but almost all of them are still isolated. They do not talk to one another. If they did, they could share the capacity they collectively own. So that an idle blockchain can take up and process some of the transactions on another that is getting clogged. In essence, that is how interoperability can help with scalability. It is important to point out that sidechains could be the initial step toward more extensive blockchain interoperability. Indeed, already protocols are being created to help put all blockchains out there into a mega-network. The protocols being designed for this purpose include Cosmos, Polkadot and Wanchain.
Interoperability will make it possible that a user can send another assets without considering what blockchain the recipient is on. It will be like bringing the email experience to the blockchain technology. Of course, we never concern ourselves with what protocol or platform the person we are about to send an email is using. And that is because of interoperability. And contrary to what some believe, interoperability will not lead to one blockchain pushing the others out of operation. In particular, because different blockchains may end up serving different specific niches. Indeed, interoperability is most likely to usher in the future of blockchain Web3. However, as things stand now, we might be very far from seeing an interoperabilitized blockchain network become a reality.
Sharding is a concept that has mostly been used in distributed databases. While it has not been widely tested on blockchains, some propose it as a solution to the blockchain scalability problem. In the current blockchain architecture, every node on the network holds and maintains the same ledger. With Sharding, the ledger could be split into sections known as shards. Then the nodes on the network could be put into different groups that are tasked to maintain different shards. That means that the entire network does not concentrate on updating the same transactions. This could scale network capacity significantly. It is important to emphasize that the blockchain as a whole would still operate under a single state. The shards will just be sub-states.
The shards will contain the addresses, balances and transaction states. Also, it is the shards that will provide proofs of transactions to, what you may call, the mainchain. The shards are also able to communicate with one another using a special protocol so that they do not end up duplicating work on the network. Examples of projects exploring Sharding as a blockchain scaling solution include Prysmatic Labs, Drops of Diamond, PegaSys and Status.
Management of unspent transactions demands many resources on blockchains. Indeed, it is thanks to unspent transactions that the ledger often bloats exponentially. For example, on the Bitcoin blockchain, where they are known as UTXOs, they contribute to a higher payload, high fees and, as a result, a reduced amount of transactions that can be confirmed per second. However, every new transaction comes from unspent outputs of previous transactions. That makes unspent transactions critical. Furthermore, they are necessary for time-stamping, proof of existence, data storage, block creation and mining.
Indeed, a blockchain that offers payment services is basically about the unspent transactions. However, finding a way to reduce the amount of data that comes from UTXOs can help remove bloat from a blockchain.
Indeed, a few alternative cryptographic algorithms are trying to do precisely that. Solutions like Multisignatures, Ring signatures, Threshold signatures and Schnorr signatures are designed to reduce the amount of data that goes onto a blockchain from each transaction. For example, multi-signature aggregates receiver addresses into a single multisig receiver address. It also stores the accompanying redeem script offline. In other words, this protocol significantly reduces the outputs and script that come from a transaction and thus creates room for more transactions. Mimblewimble is another example of a solution that removes a lot of historical data, such as spent transaction outputs from the Bitcoin blockchain, while not compromising the ability to verify transactions. It also improves the privacy of users. Ring signatures, Collective signature and Threshold signatures do the same thing. Hyperledger Fabric and Dfinity” blockchains use threshold signatures for the same purpose.