This post is an excerpt from the book Token Economy, Shermin Voshmgir, 2019.
One of the greatest challenges of a distributed consensus like “Proof-of-Work” is that it makes the network safe, but slow. This is due to the trade-off between all dominant attributes of blockchains: decentralization, security, and scalability. Scalability is a big issue when it comes to evaluating the feasibility of tokenized use cases and the future of a token economy.
In order to allow for a high degree of decentralization in a public and global network, blocks in “Proof-of-Work” blockchains are limited in size and are created with some delay. This intentional process allows members of the network that are computationally weaker to participate, since larger blocks are harder to process and network latency would prohibit them from receiving blocks. This, in turn, introduces a limit on transactions that can be included in a block, as well as a limit on how many blocks can be validated in a given timeframe. One of the greatest challenges of a distributed consensus like Proof-of-Work is therefore that it makes the network safe, but slow.
Blockchains face a so-called “scalability trilemma,” which refers to the trade-off between all dominant attributes of blockchains: (I) decentralization; (II) security; and (III) scalability. Security is the most important aspect in a distributed network of untrusted actors. Decentralization is the premise of distributed networks. Scalability refers to the number of transactions a system can process per second. As a result of this tradeoff, the attribute of scalability wasn’t a core feature in the early years of blockchain development. Demand of the technology was still marginal.
Balancing scalability, decentralization, and network security might be the holy grail of decentralization. However, it might be resolved over time as the technology matures. It is comparable to the early days of the Internet, where bandwith was still little and communication lines were slow, and we used to pull phone cables through our apartments to connect our computers with the Internet. Back then, the Internet had little throughput. The 56k modem was already a major upgrade to the 28k modem, and we still had to wait for pages to build up pixel by pixel. Over time, however, this issue was resolved, and it certainly didn’t stop the WWW from evolving into what it is today.
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.
State channels offer a second layer on top of the blockchain, allowing transactions that could occur on-chain to get conducted off-chain, without significantly increasing the risk to any participant. Transactions get outsourced to a second layer, a private state channel, a two-way pathway, opened between two users, using a smart contract.
State channels allow for the transfer of any state for any type of decentralized application; payment channels allow for the transfer of payments only. Both solutions require funds to be deposited to facilitate disputes. Each participant in the channel signs these transactions with their private key to ensure that they are undeniably true and authorized. This is a three-step process: (I) Parts of the blockchain state, such as funds, are locked via multisignature or a smart contract. They can send funds to the other in channel alone. To update state on-chain, they need bilateral agreement, or to have a dispute; (II) These two parties update the state amongst themselves by constructing and signing transactions that would usually be submitted to the blockchain, but instead are merely held onto for now; (III) After a certain period, both parties submit the state back to the blockchain, which closes the state channel, until it is opened again.
If two people have a business relation, they have ongoing back and forth payments to each other within a certain time period. Let’s assume that Alice has 200 ETH and Bob has 100 ETH. Within a month, Alice sends ten payments of 10 ETH each and Bob sends Alice two payments of 20 ETH each. On an Ethereum blockchain, these transactions would each count as an individual transaction, twelve in total, which would clog the Ethereum Network bandwidth, thus making it slower. Furthermore, each single transaction would incur transaction fees. With a state channel, only the balance of transactions, after one month, needs to be settled on the blockchain, as two transactions only – the opening and closing of the channel.
Keeping transactions off-chain and exclusively between both parties is also more privacy preserving. Everything happens within a channel, rather than being publicly broadcasted over the whole network and recorded on-chain. Only opening and closing transactions are known to the public. However, state channels need full availability of all participants involved. As the final closing of the channel, and therefore the final submission of state, could be submitted by one party maliciously, there is risk of funds involved if one doesn’t look out for closing transactions. If such an attempt is caught, one can dispute the attack and have the other party penalized. Such an action can be outsourced to service providers looking out for such malicious attempts in exchange for a fee. Participants can use representatives acting on their behalf, but the possibility of the representative getting attacked or bribed makes it a security risk. State channels are useful for use cases where participants exchange many state updates over a long period of time, since there is an initial cost to create a channel and deploy the so-called judge contract. Once it is deployed, the cost per state update inside that channel is extremely low.
The smart contract used to lock the state must know the participants of a given channel in advance. State channels, therefore, 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 to add a new participant. Projects such as Lightning Network (Bitcoin) or Raiden Network (Ethereum) have come up with solutions based on a mesh of participants, so one does not have to create a new channel for every new participant to interact with. By creating a network out of all the channels, users’ transactions can 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:
Lightning (Bitcoin) payment channel, live on Bitcoin Mainnet since 2018
Raiden (Ethereum) payment channel, not live
Trinity (Neo) payment channel, not live
SpankChain (Ethereum) state channel for payments & smart contracts, live
Perun (Ethereum) state channel for payments & smart contracts, not live Counterfactual (Ethereum) state channel for payments & smart contracts, not live
Celer (Blockchain agnostic) roll out in 2019
Machinomy (Ethereum) payment channel, live
FunFair (Ethereum) state channel for payments & smart contracts, beta
Liquidity (Ethereum) payment channel, live
Sidechains also allow for the transfer of any state. They are separate blockchains, compatible with the mainchain, linked to the mainchain using a two-way peg. A two-way peg enables interchangeability of assets at a predetermined rate between the mainchain and the sidechain. A user first has to send their tokens from the mainchain to an address, where the tokens become locked so the user is unable to spend them. Once the transaction has been completed, a confirmation is communicated across both networks. After a waiting period, the same number of tokens is released on the sidechain, allowing the user to access and spend them there. The reverse happens when moving back from a sidechain to the mainchain. 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.
A sidechain needs to interact with the computation layer on the mainchain and requires tokens to be locked to facilitate disputes. The sidechain doesn’t need to be public; they can be privately managed. One can, therefore, move assets to the sidechain and then back to mainchain. Sidechains have their own consensus mechanism, and thus their own level of security. Sidechains therefore need their own miners, often incentivized through merged mining. This means that two separate tokens, based on the same algorithm, are mined simultaneously. Without enough mining power to secure a sidechain, it could be attacked. If a sidechain is compromised, the damage will be contained within that network and won’t affect the mainchain or other sidechains.
As opposed to state channels, transactions on a sidechain are not private. They are published on the sidechain and thus visible to every participant on the sidechain. On the flip side, with sidechains, one does not have to be available all the time, and there are no extra administrative costs in adding or removing participants. However, sidechains need a lot of initial investment. They need to have enough miners so that the network is safe from attackers. Furthermore, the federation adds another layer between the mainchain and the sidechain and could introduce more attack vectors.
Such sidechain solutions can operate more efficiently, as some decentralization can be sacrificed for scalability. As the mainchain guarantees overall security and dispute resolution, transactions conducted on a sidechain can sacrifice decentralization in return for scalability. Not everyone needs to agree and validate this consensus; only those directly operating on the sidechain need to be involved. Here is a selected list of sidechain solutions:
Plasma (Ethereum), not live
Rootstock RSK (Bitcoin Mainnet), not live
Alpha Elements (Bitcoin Testnet)
POA Network (Ethereum)
Bitcoin Extended (Bitcoin)
Bitcoin Codex (Bitcoin re-design of Namecoin)
While the number of blockchains and tokens managed on these blockchains and other DLTs are growing at a rapid pace, these distributed ledgers remain isolated. Most blockchains and other DLTs work as a silo. This means that a blockchain has no knowledge of what happens in other blockchains or ledgers. On many networks, capacity might be idle while other networks are clogged with transactions. Sidechains could be seen as a first step toward full blockchain interoperability. Scaling, however, could happen on a much larger scale than with dedicated sidechains, if and when standards like Cosmos, Polkadot, or Wanchain might be operational and adopted.
Interoperability in this context refers to the ability to freely share tokens and related data across blockchain systems. In a fully interoperable environment a user from blockchain A can send another user on blockchain B a token. 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 will survive. 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.
Interoperability can also enable different blockchains to easily communicate among one another without the need for an intermediary, like a centralized exchange. However, we might be far from being able to make the theory work. It is hard to predict when such interoperability will be feasible.
Some developers propose that sharding could be a solution to the scalability problem of blockchains. Sharding is a concept adopted from distributed databases but has not been tested on a global scale in the context of blockchains. Sharding could address the scalability constraints of current consensus protocols, where each node holds the ledger, maintaining the full history of the state of the blockchain, from the genesis block until the present day. Sharding suggests that the blockchain history could be split into pieces called shards, and each of which would have their own shard of the state. Multiple shards of the blockchain could run parallel to each other, thus improving network scalability. Note that the blockchain as a whole should still operate under one state. Shards would be sub-states as part of the whole state that together form the state of the chain.
Addresses, balances, and general state are contained on shards. Shards provide proofs to the mainchain and can communicate with other shards over the sharding protocol. Each shard has to be consistent in itself. Cross-shard communication is handled through protocol rules. The mainchain can coordinate a consistent general state of the network. Sample projects working on sharding solutions: “Prysmatic Labs,” “Drops of Diamond,” “Status,” and “PegaSys.” However, all these solutions are highly experimental.
Alternative Cryptographic Algorithms
One of the biggest challenges in state-of-the-art blockchains 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 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 still of importance for things like time-stamping, proof of existence, data storage, and also block creation and mining.
Transaction-oriented blockchain services 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 multisignatures, 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 multisignatures, and redeem scripts. With multisignature transactions, for example, receiver addresses get 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.
Multisignatures 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, definitely, but compared to the average non-multisig transaction, payload reduction is not always the case. It 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.
References & Further Reading
- Stathakopoulou, C.; Cachin, C.: “Threshold Signatures for Blockchain Systems “, IBM Research, Published in: RZ3910 in 2017: https://domino.research.ibm.com/library/cyberdig.nsf/papers/CA80E201DE9C8A0A852580FA004D412F/$File/rz3910.pdf
- Tual, Stephan: “What are State Channels?”, Jan 4, 2017: https://blog.stephantual.com/what-are-state-channels-32a81f7accab
- Vasa: “Difference Between SideChains and State Channels”, Hackernoon, June 26 2018: https://hackernoon.com/difference-between-sidechains-and-state-channels-2f5dfbd10707
- Vasa: “10 State Channel Projects Every Blockchain Developer Should Know About”, Hackernoon, Jun 25, 2018: https://hackernoon.com/10-state-channel-projects-every-blockchain-developer-should-know-about-293514a516fd
- Alpha Elements: https://elementsproject.org/
- Counterfactual: https://www.counterfactual.com/
- Celer Network: https://www.celer.network/
- Drops of Diamond: https://github.com/Drops-of-Diamond/diamond_drops
- FunFair: https://funfair.io/
- Hivemind: http://bitcoinhivemind.com/
- Loom: https://loomx.io/
- Liquid: https://blockstream.com/liquid/
- Liquidity Network: https://liquidity.network/
- Machinomy: https://machinomy.com/
- Lightning Network: https://lightning.network/
- PegaSys: https://medium.com/@pegasyseng
- Perun Network: https://www.perun.network/
- Plasma: https://plasma.io/
- POA Network: https://poa.network/
- Prysmatic Labs: https://prysmaticlabs.com/
- Raiden Network: https://raiden.network/
- Rootstock RSK: https://www.rsk.co/
- SpankChain: https://spankchain.com/
- Status: https://email@example.com
- Trinity Network: https://trinity.tech/
About the Author
Shermin Voshmgir is the Author of the Book “Token Economy“. She is the director of the Research Institute for Cryptoconomics at the Vienna University of Economics, and the founder of BlockchainHub Berlin. In the past, she was a curator of TheDAO, and advisor to various startups like Jolocom, Wunder and the Estonian E-residency program. In addition to her studies at the Vienna University of Economics, she studied film and drama in Madrid. Her past work experience ranges from Internet startups, research & art. She is Austrian, with Iranian roots, and lives between Vienna and Berlin.