Beating Bitcoin Series (2) - Pay Attention to Projects That Solve Problems Currently Keeping Blockchains from Mass Adoption Such as Zilliqa

In 2017, I wrote a seven part series titled the “Ideal Digital Currency” highlighting seven important unsolved issues with cryptocurrencies that needs to be solved before they can gain mass adoption. The third part of the series focused on scalability. Public decentralized cryptographically enabled digital currencies can currently not handle sufficient number of transactions per second for them to be used on a global scale of the type Visa or Mastercard currently handle. While the Visa network can handle over 40,000 transactions per seconds (tps), the Bitcoin network can only handle about 7 tps. The Ethereum network is slightly faster at about 25 tps. And no matter how many nodes join the network to process transactions, this throughput does not increase. This is what is referred to as non-scalable in that throwing more resources at the network does not increase the load it can handle.

The Blockchain Scalability Problem in a Nutshell

The reason behind the non-scalability of public decentralized blockchains is due to the very formulation of blockchains from the original paper by Satoshi. In that formulation, every node competes to write the next block and thus are all replicating the same work and also maintaining the same copy of the ledger. And only one block can be written during each interval. And then the competition to write the next block begins; which is written referencing or chained to the prior block. This is to prevent the possibility of double spending which could occur if more than one set of different blocks can be admitted as representing the state of the ledger at any time. In such a case, a transaction could then conceivably be written in one but not the other. Thus the more nodes join the network, the number of transactions it can handle will not increase. The blockchain process is basically intrinsically serial since only one block can be written at any time and must be related to the prior block, and on.

A few Approaches to Solving the Scalability Problem

There are several potential methods that have been proffered for solving this problem. They include increasing the size of blocks that can be written so it can handle more transactions. This is the approach taken by Bitcoin Cash. They also include processing transactions off the blockchain and then writing it on the blockchain over longer intervals. Those methods are termed as creating side chains and include approaches such as that utilized by the Lightning network. However, both methods involve some sacrifice. Increasing block sizes will limit the size of applications and devices that can serve as clients for the network or make it slower for them to sync and receive blockchain data. For side chains, users must commit to opening channels to those side chains, which require committing resources to open the channels. There is also the chance that hubs could set up side chains and fund it but result in centralized pockets on the side chains. These are very recent developments and practical applications are new or just emerging. For instance, a form of the Lightning network just went into beta about a month ago. It is not yet fully certain if those sacrifices are significant enough to significantly negate those as the future solutions for the scalability issue for public decentralized blockchains.

Parallelizing the Blockchain is the Holy Grail of Scalability Solutions

What if the blockchain was completely reformulated such that it is no longer serial but can actually process transactions in parallel? That would enable all the advantages of the decentralized blockchain to be retained while being able to process several times more transactions at the same time. This is the approach a few emerging blockchains are taking. This approach is sometimes referred to as “sharding” and in its original meaning applies to the process of splitting up a database into sub-parts. I have in the past insisted on using the term parallelization because the activity goes beyond simply splitting up the database (in this case the blockchain as a database). Ethereum has been mentioning sharding as a planned scalability solution for more than a year now, but have projected it would likely be ready in a couple of years or so.

However, a new network has now actually implemented a form of sharding and has actually demonstrated it live in beta for several weeks now. So sharding, or more correctly the parallel processing of blockchain transactions, is now pretty much a reality now for blockchains. This network is named Zilliqa. I was first encouraged to review the network late last year, and mentioned it in a 2018 outlook article, but could not find the time for a full review until now after reviewing ongoing results of the beta test. As can be expected, as word gets out and it becomes clearer that this network has indeed a solution to on-chain scalability, the value of the network will increase; and that has been the case thus far. Its market price has slowly crept up on net even during the earlier downturn of 2018. A basic projection of current trend combined with the prospects of a main network live release by the third quarter could potentially see the value grow several times still, provided the global cryptocurrency market trend itself holds up roughly at its current pace.

Parallelization as Accomplished by Zilliqa

The Zilliqa process divides the network into 2 layers as shown in the figure below. The first layer includes a sharded network that splits the network into several groups with each group responsible for processing a subset of all transactions that are submitted during each block creation interval. The decision on which transaction each shard processes is based on the rightmost bits of the account that originated the transaction. For instance, assuming numerical account numbers, and a shard of 5, then any transaction generated from accounts ending with 0 or 1 would be handles by shard 1. And any transaction originating from accounts ending with 2 or 3 would be handled by shard 2. And on.

Traditional Serial Block Creation Structure
Source: author

Parallel Block Creation as Described by Zilliqa
Source: author

The second layer termed the directory services (DS) layer aggregates the sharded blocks from the first layer into one block. This layer also helps organize the nodes of the first layer into shards. To ensure security of shards potentially consisting of fewer nodes than they would in the traditional blockchain network, Zilliqa implements a series of randomized procedures to shard the network so that groups of adversary nodes can not easily congregate within a shard and thus compromise the network. Finally, Zilliqa is also introducing a blockchain programming language for its sharded network that though not Turing complete would be able to take advantage of the parallel nature of the network in processing contracts.

How is Zilliqa Working During the Beta Test Phase?

There is sufficient review of the network operations and scaling capacity already available from the weeks long Zilliqa test network to demonstrate likely success of the sharded Zilliqa network in accomplishing scaling of blockchain transactions. Some parameters of the test network can be viewed here. The beta tests already show the number of transactions per seconds at over a hundred. The main network would at least likely process transactions in hundreds if not thousands, compared to the handful the earlier decentralized blockchains can handle. It would be interesting to see the frequency of final block creations go up during this tests phase. There are also still some other blockchain issues still being addressed including on network pruning and addressing state sharding or essentially splitting of the final blocks itself. Also, sharded processing of contracts are yet to be tested publicly at the time of writing but the success of transaction sharding alone would likely assure Zilliqa comparative notice and likely growth in value when the full network goes live as promised by the third quarter of 2018.

References

1. Nov 5 2007, Ken A. “The Ideal Digital Currency Needs Scaling Solutions,” http://www.trustnodes.com/2017/11/05/ideal-digital-currency-needs-scaling-solutions, Accessed November 30 2017.
2. Vitalik Buterin et al, “On Sharding Blockchains,” https://github.com/ethereum/wiki/wiki/Sharding-FAQ, Accessed October 31 2017.
3. Dec 2017, Ken A. "2018 Blockchain and Cryptocurrency Outlook: Expert Blog", https://cointelegraph.com/news/2018-blockchain-and-cryptocurrency-outlook-expert-blog.
4. August 10 2017, The Zilliqa Team. “The Zilliqa Technical Whitepaper,” https://docs.zilliqa.com/whitepaper.pdf. Accessed Dec 2017.
5. Mar 20 2018, Yaoqi Jia. “The Many Faces of Sharding for Blockshain Scalability,” https://bitcoinmagazine.com/articles/op-ed-many-faces-sharding-blockchain-scalability/. Accessed May 11 2018.
6. May 10 2018. “The Zilliqa Test Network,” https://explorer.zilliqa.com. Accessed May 11 2018.
7. Nov 11 2017, Ken A. "The Ideal Digital Currency (Part 3 of 7):
   Digital Currencies Need Scaling Solutions", https://medium.com/@alabs.ken/the-ideal-digital-currency-part-3-of-7-digital-currencies-need-scaling-solutions-d45c41bad8c8.

   ---

   About the Author Ken has a doctorate in Engineering, and a master’s in Computer Aided Engineering, An IT professional, programmer and published researcher with over thirty publications in various fields of technology, including several peer reviewed journals and publications.
   

   Legal Disclaimer: I am not a financial adviser and this is not financial advice. The information provided in this post and any other posts that I make and any accompanying material is for informational and educational purposes only. It should not be considered financial or investment advice at all. You should consult with a financial or investment professional to determine what may be best for your individual needs.
   This is only opinion. It is not advice nor recommendation to either buy or sell anything! It's only meant for use as informative, educational, or entertainment purposes.

   Upvote/Resteem/Comment. All comments are upvoted. Everyone that resteems gets a 100% upvote on comment here or their own blog. Let's start a conversation.