Blockchain Scalability Solutions - Token-Economy-Book/EnglishOriginal GitHub Wiki

One of the greatest challenges of a distributed consensus like Proof-of-Work is that, while it makes the network safe, it does not scale well. This is due to the trade-off between decentralization, security, and scalability.

Disclaimer: Research and development around scalability solutions is subject to current events. This chapter will give a general overview, but is by far not complete in outlining all possible solutions and/or their tradeoffs.

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

State channels offer a second layer on top of a blockchain network, allowing transactions that could occur on-chain to get settled off-chain, while maintaining the security of all network participants. In this process, transaction settlements are outsourced to a private state channel, which could be described as a two-way pathway between two users. These state channels are formalized and processed by a smart contract. “State channels” allow for the transfer of any state for any type of decentralized application. “Payment channels” only allow for the transfer of payments. They are useful if two parties, Alice and Bob, have an ongoing business relationship with continuous back-and-forth payments.

Tokens are temporarily locked as a security mechanism in case of disputes: (i) Tokens can be sent from Alice to Bob and vice versa using state channels where they are locked up via a multi-signature scheme or a smart contract for a pre-defined period of time. (ii) Both Alice and Bob sign each transaction with their private key, but the transactions are kept private and are not broadcasted to the blockchain network. (iii) After the period has passed, the balance of all bilateral transactions is broadcasted to the blockchain network, which closes the state channel.

Let’s assume that Alice has 200 ETH and Bob has 100 ETH. Within a certain period of time, Alice sends ten payments of 10 ETH and Bob sends Alice two payments of 25 ETH. If all transactions would be settled on the Ethereum network directly, twelve individual transactions would be registered by all nodes in the network. Not only would this bloat the number of transactions and slow the network, it would also be more expensive for both Alice and Bob, since each single transaction would incur a transaction fee. Using a state channel to settle such bilateral transactions, only the balance of all transactions needs to be settled on the blockchain directly once the pre-defined time has passed. This means that only two transactions will be registered by the network: the opening and closing transactions of the channel.

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.

State Channels

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.”

Sidechains

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.

Chapter References & Further Reading