The Ideal Digital Currency (Part 3 of 7):
Digital Currencies Need Scaling Solutions
This is part of a series looking at issues that need to be solved in the next few months and years for digital currencies to grow to reasonable size compared to the tiny segment of the global economic system that they currently occupy. This segment focuses on scaling issues. This one is probably one of the more obvious issues. As this article is being written, for instance, we are in a countdown to another potential split of the Bitcoin network. Scaling issues were put forward as the rationale for the changes necessitating the split. At the very least, there is consensus that solving the scaling problem is necessary; although approaches vary. Several of these are reviewed here, with a focus on which solutions could actually end up driving the future.
First, let’s start off with a top-level listing of the characteristics of an ideal digital currency, independent of any currently proposed scaling solution.
√ The ideal digital currency should in some way be able to support between 20,000 to 50,000 transactions per seconds; while maintaining the security of those transactions.
√ Payments should be confirmed within at least ten seconds, or that currency will not be viable for live, in-person transactions.
√ The size of the data and software that needs to be downloaded to operate the digital wallets of the currency should be small enough that it can be used in most mobile devices and small clients.
Currently, there is no single digital currency, in wide spread use, that satisfies these three conditions, but there are proposals and ongoing work to deliver this.
General Definition of Blockchains or Distributed Ledger Technology
Let us consider blockchains to have characteristics that include: (1) a ledger of accounts; (2) transactions that move values between those accounts; (3) cryptographic signatures that ensures that only transactions correctly signed by authorized owners of the accounts are accommodated; (4) evolution of the state of those accounts in time, explicitly or implicitly as those transactions are applied, (5) procedure for ensuring that the ledger maintains its integrity as it propagates in time as blocks, with the group of transactions applied to a block resulting in the next block that is cryptographically and immutably linked to its prior block.
The above definition does not presume that the blocks are written in parallel or in series; as most blockchain implementations currently operate; so that we are not looking at solutions in the narrowest sense. Also, the definition can limit the groups of transactions applied to transition a block to the next block to one transaction per block state change, which accommodates technology such as the directed acyclic graph used in IOTA’s tangle, Byteball, or Hashgraph.
Finally, at this point in the article, we will not limit consideration of the ideal digital currencies to perfectly decentralized models, and thus the network topography is not assumed in this definition. Consequently, implementations such as permissioned node networks as used in Ripple are included. Virtually all current blockchain networks fit into this general definition, from bitcoins and other networks built on similar technology, to networks based on directed acrylic graph block topology.
Why Blockchains have Difficulty Scaling
The reason is due to the nature of the formulation of the earliest blockchains. They were developed based on an innovative decentralized peer-to-peer network architecture that needed a means of ensuring agreement or consensus between all the nodes of the network. Essentially, we have one single ledger but multiple transaction processing nodes. The copy of the ledger across all the nodes must effectively be in agreement for the ledger to be consistent.
This consensus requirement is solved in Bitcoins, for instance, by imposing a computational assignment on the nodes to ensure that it is difficult and time consuming for them to update the ledger, or write the next block. This is known as a proof-of-work consensus mechanism. It secures the network since no node can go back and alter a prior version of the ledger that has been agreed to. To do so the node would also need to rewrite all subsequent blocks up to its current version, since the blocks are cryptographically signed and changes to a prior block would break its signature in blocks written after. This would be computationally prohibitive. Based on this design, as a matter of fact, the Bitcoin formulation has proven significantly resilient and secure over the past nine years and has demonstrated greater on chain transaction security than anything that exists in fiat currency financial industry.
However, since all processing nodes maintain the same ledger and only one of them can update the ledger, transaction processing is a serial process. If we have over 5,000 processing nodes as currently exists for the largest blockchain networks, the speed of the network remains about the same since only one of them can write blocks during each update. This will remain the same if the number of nodes were 10,000 or even 50,000 processing nodes. The network inherently does not scale with addition of processing resources.
Secondly, that time consuming computational assignment that nodes must complete before writing new blocks imposes a limit on how frequently blocks can be written. In addition, usually several blocks need to be written on top of a block before it is considered immutable. For some blockchains, this can take several minutes, which effectively rules out in-person store use. It also accounts for why the operations of blockchain networks is resource intensive in terms of the electricity consumed.
Thirdly, blockchains are inherently dependent on the history of blocks that have been written. For instance, for Bitcoins the block sizes are currently 1MB, and there has been about 493,000 blocks written since its inception. For a client to download all the blocks to ensure it has the history of all transactions, means about 493 GB of data needs to be downloaded. This imposes initial bandwidth and space demands on clients that operate wallets for digital currencies.
Current Solutions to Blockchain Scaling Issues
Some of the proposed, and applied solutions have been incremental. This is due to the difficulty of making changes to a decentralized network involving multiple nodes with no central authority. Getting all the nodes to make a major change at the same time can be challenging. Some of the solutions are more far reaching. These are described below.
Minor and Incremental Changes to Blockchain Networks to Enhance Scaling
Incremental changes include solutions such as Segwit. In Segwit, the transactions signatures are referenced in the block rather than included within it; hence the term segregated witness. This reduces the size of blocks by a small percentage. Another incremental change is to increase the block size. While more transactions can be included within each block in this way, the time limit for confirming transactions remains the same, and the space and bandwidth requirement for clients that need to download those blocks would actually increase. Significantly, the nature of the blockchain remains one of serial duplicated processing.
A third type of improvement to blockchain networks that addresses the time taken in writing a block is in improvements to the consensus mechanism. Besides proof-of-work mentioned earlier there are other methods of obtaining consensus that allows faster transactions and reduces the electrical resources requirements. This includes several Byzantine algorithms that involves voting among nodes to determine which node gets to write the next block. This also includes proof-of-stake algorithms where nodes that have deposited and locked into the network their own personal resources have greater privileges in being selected or voted to write blocks. The rationale behind proof-of-stake is that nodes that are invested in the network are more trusted as they have something to lose if they compromise the network by processing bad transactions. While improvements to the consensus algorithm can significantly improve block times, they do not change the serial nature of the overall blockchain and will not on their own solve the earlier listed three dimensions of scaling issues facing blockchains.
Scaling Through Side Chains
Side chains have existed ever since the first Exchange opened to sell bitcoins. Centralized exchanges are basically side chains. Buying and selling of digital currencies on exchanges are instant and do not write to the parent blockchain on every transaction. A side chain or channel can be established between two users; where one user deposits an amount in an account on the blockchain potentially to the benefit of the other user. The first user can then make payments to the second user outside of the blockchain and have it recorded between them, obtaining the necessary signatures for each transaction. At the end of some time period, only one transaction is needed to be posted on the blockchain, representing the final balance of how much the first user has spent on the payment channel they opened on the blockchain.
The Lightning network works in this manner, but extends this concept over bidirectional channels between the users, and over multiply connected network of channels. The network allows users who do not have a channel between them to link over existing channels of other users to find a connection. A Lightning network is currently being implemented for the Bitcoin network. The Raiden network also works in a similar manner, and is being implemented for the Ethereum network. Plasma also being implemented in Ethereum works via side chains as well, but makes greater use of smart contracts to enable the network. The use of masternodes to approve transactions instantly is also a form of transaction processing off chain in the transient, reconciling the transaction with the blockchain in the next block. In general, transactions on sidechain networks are fast, instant, and are relatively cheaper than if they were completed on the serial processing blockchain network.
A very important development also are debit card networks that allow an account in a digital currency to be instantaneously exchanged for fiat currency and spent on prepaid or debit cards, at locations that accept fiat currencies; or used at regular ATMs to withdraw fiat currencies. These networks are basically sidechains as well. The digital currency being spent is moved off the blockchain to a sidechain managed by the operator. When the debit card is swiped at a store or at an ATM, since a balance is already moved off the blockchain, a portion of it is converted to local fiat currency with an online exchange and spent instantly. These side chains essentially open the entire world of commerce in fiat currencies to digital currencies.
Scaling Through Parallelization of Blockchain Networks
The most comprehensive solution to the blockchain scaling issue would be to fully parallelize their operations. Blockchain networks derive their security from their serial nature, which does slightly complicate approaches to parallelizing the networks. However, there are several proposals, and actual implementations of parallelized blockchain networks.
Sharding is one such proposal, and is part of Ethereum’s roadmap. Sharding is fundamentally a process of partitioning a database into smaller parts. Performing similar blockchain transactions in each shard effectively constitutes a single program multiple data (SPMD) parallelization of the blockchain.
There are also several fine-grained implementations of parallelized blockchain transactions. Transaction-wise, the lowest level of fine-grained parallelization is to have each processing node process one transaction in parallel with other nodes. This is fundamentally what is done in some blockchains based on the directed acyclic graphs such as IOTA, ByteBall, and Hashgraph; even though there are slight differences between all three in how blockchain transaction security is maintained. In all three implementations, each node processes only one transaction, and transaction processing is not duplicated by other nodes. The implementation is parallel because nodes can be processing different transactions at the same time as other nodes. Measurements have shown some of these networks to be quite fast, although they are not yet as tested as some of the earlier, reliable blockchains.
Which Scaling Solutions Will Rule the Future?
The incremental solutions applied via synchronized changes to current blockchains, known as network forks, will in the short term stretch the capacity of existing networks. We already see the impact of the recent Segwit implementation in the greater number of transactions packed into recent ~1MB Bitcoin blocks. However, in the medium term (next few months to a couple of years), side chain networks will become layered on the more popular networks and drive increases in capacity of the network. The side chains will be distributed, and centralized due to the reasons mathematically laid out by Jonald Fyookball in this article. To paraphrase the work there, for every channel opened by users with accounts on the blockchain, they need to tie up or move balances into those accounts to open the channels. For instance, for Alice to transact off the blockchain with Carol, with whom she does not have an open channel, the transaction would need to be connected through her channel with some other user, say Bob, with whom she has a channel, and who also has a channel with Carol; or via an even more extended tree of other channels.
To make this more obvious consider Alice and Bob having an account with a bank. Transactions between them simply takes place on the bank’s ledger and is instant. However, transactions between Alice and Carol with an account in a different bank would need to go through the clearing or other instruments such as wire transfers (which notably takes about a couple of days compared to the minutes it takes to confirm transactions even on the slowest blockchain network.) For there to be a Bob with an account in the same bank as Alice and also with Carol, would mean Bob would need to be maintaining a balance in both banks; potentially splitting up or tying up Bob’s funds. Therefore, it is more likely that liquidity providers would set up these channels, and they would essentially function in a centralized but distributed manner off the decentralized blockchain. They would sort of play the role with digital currency that banks play in the fiat currency system. They take deposits after all, and will begin to offer familiar conveniences to users including insurance of funds, and yes (sigh) mediation of transactions between merchants and users that utilize their networks.
Which brings us back to the previously mentioned side chains that operate fiat to digital currency side chains. Due to the fact that the universe of transactions and value in fiat currencies dwarfs that of digital currencies currently, networks that seamlessly allow digital currency to fiat, can be potentially larger in value than most digital currencies at this stage. The value moving between fiat and digital currency can exceed the total value of most digital currencies. It can be expected that widespread digital currency debit card use will be next step within a year or two. Suddenly, the question of how many merchants are accepting digital currency becomes mute. Same for questions about where the next bitcoin ATM is. Since the digital currency debit cards work at regular fiat ATMs, the nearest digital currency ATM for converting to fiat would essentially just be the nearest fiat ATM.
However, in the long run, as the size of the digital currency ecosystem continues to increase, the proportion of transactions that are digital currency to digital currency begins to grow relative to digital to fiat currency. Blockchains with a greater degree of parallelization would then begin to gain in performance and cost advantages compared to less efficient ones. Let’s note that sidechains themselves are a de-facto form of parallelization where the transaction processing task of the entire blockchain network is split up and large parts of it are assigned to several sidechains. Therefore, they do bring increased efficiency to the overall blockchain as well. To that extent, the landscape in terms of adoption in that slightly more distant future would depend on the dynamics between the cost economics of potentially more efficient natively parallelized blockchains and more established blockchains operating with sidechains. The comparative advantages of scale, and vested implementations that would be part of the features of the more established blockchains would then determine how that future looks like in terms of adoption in comparison to the more efficient chains.
The views here are provided freely and could be freely used in whole or part, hopefully with a kind reference to the article. It is not intended as investment advice and should not be used in that capacity.
References:
1. Ken Alabs, Oct 25 2007. “The Ideal Digital Currency,” http://www.trustnodes.com/2017/10/24/ideal-digital-currency, Accessed October 31 2017.
2. Satoshi Nakamoto, “Bitcoin, a Peer-to-Peer Electronic Cash System,” https://bitcoin.org/bitcoin.pdf, Accessed October 31 2017.
3. Vitalik Buterin et al, “On Sharding Blockchains,” https://github.com/ethereum/wiki/wiki/Sharding-FAQ, Accessed October 31 2017.
4. Serguei Popov, “The Tangle”, https://iota.org/IOTA_Whitepaper.pdf, Accessed October 31 2017.
5. Anton Churyomov, “Byteball: A Decentralized System for Storage and Transfer of Value,” https://byteball.org/Byteball.pdf, Accessed October 31 2017.
6. Leemon Baird, May 2016, “The Swirlds Hashgraph Consensus Algorithm: Fair, Fast, Byzantine Fault Tolerance,” http://www.swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf, Accessed October 31 2017.
7. Darema, Frederica; George, David A.; Norton, V. Alan; Pfister, Gregory F. (1988). “A single-program-multiple-data computational model for EPEX/FORTRAN”. Parallel Computing. 7 (1): 11–24. doi:10.1016/0167–8191(88)90094–4.
8. Joseph Pook * Thaddeus Dryja, Jan 14 2016, “The Lightning Network: Scalable Off-chain Instant Payments,” https://lightning.network/lightning-network-paper.pdf, Accessed October 31 2017.
9. “The Raiden Network,” https://raiden.network/, Accessed October 31 2017.
10. Joseph Poon & Vitalik Buterin, “Plasma, Scalable Autonomous Smart Contracts”, http://plasma.io/plasma.pdf, Accessed October 31 2017.
11. Evan Dufffy & Daniel Diaz, June 14 2016,“ Dash: A Privacy-Centric Crypto-Currency“, Dash WhitePaper, https://dashpay.atlassian.net/wiki/display/DOC/Whitepaper, Accessed November 3 2017.
12. Bitcoin Network Statistics, https://blockchain.info. Accessed November 3 2017.
13. Jonald, Fyookball, June 26 2017, “Mathematical Proof That the Lightning Network Cannot Be a Decentralized Bitcoin Scaling Solution,” https://medium.com/@jonaldfyookball/mathematical-proof-that-the-lightning-network-cannot-be-a-decentralized-bitcoin-scaling-solution-1b8147650800, Accessed October 31 2017.
14. “ACH Network: How it Works,” https://www.nacha.org/ach-network, Accessed October 31 2017.
