This is the first of many subsequent articles discussing scalability limitations of current Blockchain technology and maybe more interestingly, solutions to overcome those limitations. While this article provides some theoretical introduction, the next one will show concrete benchmark results comparing the use case of running a simple market mechanism on the Ethereum Blockchain protocol and a technology so called “Payment channels”.
The Blockchain can be considered as a protocol to save transaction data chronologically and distributively in a peer-to-peer network. However, as in many cases, it is only as strong as its weakest link, the ordinary miner. In order to take this weakness into consideration the public Ethereum Blockchain sets a limit to the block size. By doing so, it limits the number of transactions that can be stored in each block. This in turn limits the throughput of transactions the Blockchain can handle per let’s say a second.
Technically the block size restriction is realised through a so-called block gas limit. Each operation executed in Ethereum costs gas. For instance, a simple matching mechanism for trading stocks costs roughly 200,000 gas per call. The Ethereum Blockchain has currently a block gas limit of 4.3 million gas. Assuming that all traffic is handled by a simple matching function, this restriction leads to 21.5 transactions per block. Due to the 12 second block creation time, this in turn enforces an upper limit of 1.8 transactions per second. To put these numbers in perspective, the Shanghai stock exchange has a peak of over 80000 transactions per second and USA’s biggest clearing house performs 1200 transactions per second. Thus, if the Blockchain should represent a sensible alternative, it needs to be far more scalable.
Unfortunately, the block creation time cannot be made lower in order to process more blocks overall because Ethereum’s verification algorithm itself has a minimum execution time of 12 seconds. However, there are efforts to further optimize the verification algorithm and thus reduce block creation time down to 3 seconds. However, this direction on improving is out-of-scope in this article. Several other solutions have been proposed to solve the scalability issue. A naive approach would be to constrain the complexity of code and thus limiting the gas needed per operation allowing for more transactions to be processed per block. This approach has obviously many drawbacks.
Another, potentially more promising approach to cope with it are so called Payment channels, which are currently under active development. Payment channels allow users to carry out transactions rapidly by processing the majority of transactions off-chain, whereby the Blockchain is solely used for settling transactions. Such transactions originate from an ongoing interaction between any two users. The original purpose of this technology is to enable Micropayments.
Let’s take an example: Alice and Bob put some coins into a multi signature transaction and publish it. By doing so, the coins are locked away and can only be spent in the form of transactions that are signed by both of them. On the basis of the locked coins Alice and Bob can now send themselves coins without using the Blockchain. First, they both sign a transaction that sends all the locked coins back to them under the condition that it can only be incorporated into the Blockchain after a specific period of time is passed, let’s say 30 days. Alice can now create a new signed transaction which can be brought to the Blockchain one day earlier, committing some of the locked coins to Bob. It is passed to Bob without hitting the Blockchain. Bob can now sign and publish it, so that it gets into the Blockchain after 29 days. However, Bob knows that Alice does not have access to the coins for the next thirty days, thus he is not afraid that she double spends his coins and therefore does not sign anything in order to keep the channel open for further transactions. Hence, Bob and Alice are now capable of shifting funds back and forth in an instant, by handing out unilaterally signed transactions which have not yet been in contact with the Blockchain.
In the context of Blockchain-powered exchanges, payment channels could be used to let the matching happen locally on the exchange’s hardware. All parties would lock some coins and tokens in a multi signature transaction and then exchange unilaterally signed messages that modify the token and coin balance according to the users’ orders and the exchange’s matching logic. Users could now accept the transactions, bring them onto the chain and close the channel at any time or keep it open in order to allow further rapid interaction with the exchange. By doing so, the matching could happen as fast as on traditional exchanges, but still in a trustworthy way.