Shermin Voshmgir
The “scalability trilemma” describes the trade-off in distributed consensus between decentralization, security, and scalability. Decentralization is the premise of a distributed network, security is the most important aspect when the network involves a set of untrusted actors, and scalability refers to the number of transactions a system can process per second. In order to allow for a high degree of inclusion of computationally weaker nodes, the block size in a Proof-of-Work network is limited and blocks are created with a delay. Otherwise, since larger blocks are harder to process, network latency would prevent weaker nodes from participating in the block creation process. Such limitations, however, reduce the amount of transactions that can be validated in a given timeframe, and as a result, Proof-of-Work mechanisms are safe but don’t scale well. In the early days of blockchain networks, scalability was hardly addressed by the developer community, as the traffic in those networks was still low. Today, scalability of public blockchain networks is one of the major bottlenecks of mass adoption and also one of the most worked on R&D questions.
Blockchain scalability is comparable to the early days of the Internet, where we used to pull phone cables through our apartments in order to connect our computers with the Internet. As for the connection, bandwidth was low and communication was slow; one had to wait for pages to build up pixel by pixel. The introduction of 56k modems was considered a major improvement to the 28k modem, but video streaming was considered a distant dream. While data throughput was an issue, these issues were eventually resolved, and it certainly did not stop the Internet from evolving into what it is today. In the context of blockchain networks, many solutions have been proposed to make transactions faster and cheaper, while maintaining security and a certain level of decentralization. Scalability solutions can address these issues on (i) protocol level, or on (ii) second-layer level.
When they are addressed on protocol level, it often leads to centralization. More transaction volume per second often requires granting more powers to certain nodes, thus increasing the level of centralization. Alternative consensus mechanisms try to resolve the scalability issue by introducing some kind of permission layer to guarantee trust. The chapter “Bitcoin, Blockchain & Other Distributed Ledgers” that is featured in the first part of this book, has a whole subchapter dedicated to a list of alternative distributed ledger solutions and consensus protocols that try — among others — resolve the questions of throughput. Most popular solutions for achieving higher levels of throughput are alternative consensus protocols such as delegated Proof of Stake (dPoS), practical Byzantine fault tolerance (pBFT), or permissioned networks. Sharding of the ledger or alternative cryptographic algorithms are other means to address the scalability problem on the protocol level and will be described in this chapter.
As an alternative, various efforts have been made to move scalability solutions to a second layer, such as “side chains” or “state channels.” In both cases, user interactions are shifted from the blockchain layer onto a second layer, while guaranteeing risk-free P2P transactions between participants.
State Channels
In the context of blockchains, many solutions have been proposed to make transactions faster and cheaper, paving the way for mass adoption of this new technology. There is ample debate whether this should be resolved on a protocol level, often making concessions to decentralization. In order to allow for more transaction volume, it would require granting more power to certain participants, thus increasing the level of centralization. One main protocol level alternative consensus mechanisms try to resolve the scalability issue is by introducing some kind of permission layer to guarantee trust. Sharding of the ledger, which refers to partitioning the ledger into several smaller parts, or alternative cryptographic algorithms are other means to address the scalability problem on the protocol level. As an alternative, various efforts have been made to move scalability solutions to a second layer, like sidechains or state channels. In these cases, user interaction is moved out of the blockchain, onto a second layer, while still allowing risk-free P2P transactions between participants.
Keeping transactions off-chain and exclusively between both parties is not only cheaper and faster, but also more privacy preserving. Everything happens within a channel, rather than being publicly broadcasted over the whole network. The only transactions that are registered on-chain and visible to the public are the opening and closing transactions. The downside of this process: state channels need full availability of all participants involved. Otherwise, if the final closing of the channel, and therefore the final submission of state, were to be submitted by a bad actor, tokens could be at risk. To dispute malicious attacks, the locked tokens can be withheld by the smart contract to penalize the malicious actor. This requires monitoring and could be outsourced to service providers, so-called judge contracts, in exchange for a fee. State channels are therefore only useful in cases where participants exchange many state updates over a long period of time, to mitigate the initial cost of creating a channel and deploying a judge contract.
The smart contract used to lock the state must know the participants of a given channel in advance. State channels work well with a defined set of participants, but adding and removing participants requires a change in the smart contract, or the creation of a new channel. Projects such as Lightning Network (Bitcoin) or Raiden Network (Ethereum) have come up with solutions based on a mesh of participants, creating a network out of all the channels such that one doesn’t have to create a new channel for every new participant. Transactions can now be routed over other people’s channels, but only as long as there is some direct channel connection over the network. Here is a selected list of state channel solutions for various blockchain networks with different degrees of maturity and success: “Celer,” “Counterfactual,” “Fun Fair,” “Liquidity,” “Lightning” “Machinomy,” “Perun,” “Raiden,” “Spankchain,” or “Trinity.” Most solutions are specialized on one blockchain network — such as Bitcoin, Ethereum or Neo — others are network agnostic.
Sidechains
Sidechains are separate blockchain networks, compatible with the mainchain. Sidechains have their own consensus mechanism, their own level of security, and their own tokens. The sidechain doesn’t necessarily need to be public and can also be a privately managed ledger. If the security of a sidechain network is compromised, the damage will not affect the mainchain or other sidechains. Both networks are linked to each other via a “two-way peg” and can transfer any state. This way, tokens can be exchanged at a predetermined rate between the mainchain and the sidechain. The mainchain guarantees overall security and dispute resolution, and the transactions that are outsourced to the sidechain can sacrifice decentralization in return for scalability.
As opposed to state channels, transactions that occur on a sidechain are not private between the participants of a transaction. They are published on the sidechain network and thus visible to anyone who has access to the ledger. Alice and Bob don’t have to be available all the time, and there are no extra administrative costs in adding or removing participants. Setting up a sidechain, however, is a big effort, as it means building a whole infrastructure from scratch.
The sidechain interacts with the computation layer on the mainchain and requires tokens to be locked to facilitate disputes. A group of servers (federation) mediates between a mainchain and its sidechains and determines when the tokens a user has used are locked up and released. This adds another security layer between the mainchain and the sidechain. The federation is selected by the sidechain developers. However, such a federation adds another layer between the mainchain and the sidechain and could introduce more attack vectors. Here is a selected list of sidechain solutions for various blockchain networks with different degrees of maturity and success: “Bitcoin Codex,” “Bitcoin Extended,” “Elements Projects,” “Hivemind,” “Loom,” “Liquid,” “Mimblewimble,” “Plasma,” “Poa Network,” or “Rootstock.”
Blockchain Interoperability
The number of blockchain networks and other distributed ledgers is growing. However, all these distributed ledger systems are, for the most part, isolated systems and work as a silo. Networks have no knowledge of the state of tokens managed in other networks. They also have no idea about whether other networks have idle capacities to settle transactions. Sidechains could be seen as a first step toward full blockchain interoperability and scalability. A more effective and global solution could be provided by interoperability networks, such as “Cosmos,” “Polkadot,” or “Wanchain,” that could resolve the scalability problem for multiple networks simultaneously.
Interoperability, in the context of distributed ledgers, refers to the ability to freely share tokens and related data across different networks. In a fully interoperable environment, a user from network A could send tokens to another user on network B without the need for an intermediary, like a centralized exchange. Blockchain interoperability is a contrary idea to what some propose might happen: a winner-takes-all situation where, due to network effects, only one blockchain network will survive in the long run. The idea of “one chain to rule them all” is contrary to the core idea of decentralization. The future of the Web3 might, therefore, depend on the ability of blockchain networks to interact with one another.
Sharding
Some developers propose that sharding the network state could be a solution to the scalability problem of blockchain networks. Sharding is a concept adopted from distributed databases, which has not been tested on a global scale in the context of blockchain networks yet. Sharding could address the scalability constraints of current consensus protocols, where each node has to update their ledger regularly and maintain the full history, from the genesis block until the present day. It is suggested that the ledger history could be split into separate pieces, each of which would have their own “shard” of the network state. Multiple shards maintained by different network nodes parallel to each other, thus improving overall network scalability. Shards would be “sub-states” as part of the whole network state. The network as a whole should still operate under one single state, but each shard would have to be consistent in itself. Cross-shard communication would be handled through protocol rules. In such a process, blockchain addresses, balances, and general state would be contained on shards. Shards provide proofs to the mainchain and can communicate with other shards over the sharding protocol. Sample projects working on sharding solutions: “Prysmatic Labs,” “Drops of Diamond,” “Status,” and “PegaSys.”
Alternative Cryptographic Algorithms
One of the biggest challenges of the Bitcoin network and similar networks is the management of unspent transactions. These unspent transactions contribute to the exponential growth of the ledger. In Bitcoin, for example, they are referred to as UTXOs, and contribute to a higher payload, more expensive transactions, and less throughput per second. When a new raw transaction gets created and is later validated, before signing, the inputs can only come from unspent outputs of former transactions. Therefore, for transaction creation validating and signing, unspent transactions are more important than spent transactions (outputs). For the consistency of the ledger, unspent transactions are of importance for things like time-stamping, proof of existence, data storage, and also block creation and mining. Transaction-oriented blockchain networks are all about the unspent transactions. This is why bloat of the ledger is so heavily related to them. Managing the payload-size of the UTXO, the amount of UTXOs on the ledger, and the degree up to which it becomes possible to keep them off-the-chain remedies the bloat of the chain as such. In fact, everything that keeps the payload smaller tackles bloat.
Alternative cryptographic algorithms used in collective signatures, like multi-signatures, ring signatures, threshold signatures, or Schnorr signatures, could resolve certain scalability problems, for example, by reducing information added to the ledger, or eliminating that information with multi-signatures, and redeem scripts. With multi-signature transactions, for example, receiver addresses are aggregated into one multisig receiver address and cause the accompanying redeem script to be stored offline. It also reduces the number of outputs and script size inside the transaction. The same is true for ring signatures, threshold signatures, and collective signatures.
Multi-signatures are divided into a funding transaction, which turns into a UTXO and a spending transaction, and results in a spent transaction. For the UTXO-relevant funding transactions, the aggregation of several receivers into one receiving address and the usage of less outputs, plus off-chaining the redeem-script, normally results in a smaller payload. Alternative signature schemes belong to the anti-bloat toolset, but compared to the average non-multisig transaction, payload reduction is not always the case and depends on the specific use case. “Mimblewimble,” for example, is a proposal for Bitcoin to use a different approach to transaction construction. It removes most historic blockchain data, including spent transaction outputs, while still allowing users to fully verify the chain. It also allows for more privacy than current Bitcoin implementations. “Dfinity” and “Hyperledger Fabric” use threshold signatures to achieve the same goal.
Source: https://blockchainhub.net/blog/blog/blockchain-scalability-statchannels-sidechains/
