Can Quarkchain handle the real world commerce transactions and keep intact the basic principles of blockchain i.e. decentralization and security? — A technical analysis of the system architecture, starting from the basics:
Blockchains like Bitcoin and Etherium are slowly getting mainstream for peer to peer transactions, but still they are in their nascent stage of becoming the go to choice for commerce. Being decentralized system due of its core principle the blockchain lags way behind conventional centralized players. Below image illustrates the current ecosystem.
Lately, there have been lots of attention from the blockchain community to solve scalability issue and keep decentralization and security as a priority.
In a broader technical sense when we talk about scalability, there are two types of techniques that can be applied to an ecosystem i.e. Horizontal scaling and Vertical scaling. To understand these techniques lets just briefly understand in simple language:
Vertical Scaling: In this technique the resources available on servers are increased for example the available processing cores, RAM size etc.
Horizontal Scaling: In this technique, instead of increasing the resources of servers, number of servers are increased, thus the load on current ecosystem gets distributed among all the servers in the network and it increases the performance of the system exponentially.
Beside the technical potential of horizontal scaling, in the blockchain, we are not interested in vertical scaling as it gives more hash power to certain miners and thus is not healthy for the core purpose of blockchain existence.
So are there any horizontal techniques being currently used by blockchain projects? In my current understanding, there are currently two main solutions being explored or implemented i.e.
Lightning Network: The basic principle is to keep intermediate transactions between two parties off-chain and reflect transaction on the blockchain once they have final transaction. This architecture is a good solution, but lacks the transparency factor. Currently, this is being used in Bitcoin network.
Sharding: The term sharding architecture was coined for improving the reliability and speed of database CRUD (Create, Read, Update and Delete) operations. In simple terms the database is sliced into multiple partitions and distributed across the network. Thus, non related operations can be performed in parallel. There is a lot more to it, but this is more than sufficient to understand the concept of sharding. So, if we talk in terms of blockchain you can think about distributing transactions into different shards.
There are multiple projects that are building the blockchain utilizing sharding technique e.g. Zalliqa, EOS, Etherium etc. and now we have another promising project, i.e. Quarkchain that claims to target 100000+ TPS as a first goal. Lets understand the technical aspect of this project and analyze if this is even possible?
Quarkchain is a high capacity peer-to-peer transaction system as stated in the project’s white paper:
Design principles of Quarkchain that outlines the key goals:
1- Improve scalability while keeping the security and de-centralization aspects intact
2- Enable cross shard transaction for user quality of experience(QoE)
3- Simpler account management for clients
4- Open standard to enable development of DApps.
5- Incentive driven ecosystem
Being an technocrat, most of my interest lies in this piece of information. I must admit that I was quite skeptical about potential scaling capabilities of the system claimed by Quarkchain, but it has changed after understanding the system architecture:
The system comprises two layers of blockchain i.e.
Root Chain Layer: The main responsibility of root chain is to confirm the transactions from shards layer and mine the desired block to reach Proof of work. 50% of hash power is allocated to this layer alone.
Elastic Sharding Layer: The responsibility of this layer is to maintain ledger and perform the transaction. This layer contains a list of minor blockchains i.e. shards and each shard by definition process the slice of all transactions independently. The beauty of this layer is that theoretically infinite number of transactions can be processed in parallel with increasing the number of shards. Also, as these shards are independent, thus increasing the shards can be done in realtime for improving the capability of network. Its like if you want transport more people from A to B in parallel, you just need to increase the number of Bus it is as simple as that.
Same as in the case of Database sharding, any transaction done within the shard is simple because all the required information resides within a shard and there is not need of cross shard synchronization for completing the transaction. Quarkchain claims to have efficient cross shard transaction system where transactions can be performed within a minute and the performance of cross shard transaction can be improved linearly by increasing the number of shards.
Everything looks great on paper but what about real product?
This is what bugs me a lot, in my experience almost every good technical person can have great ideas, but what matters is its execution. I am happy to learn that Quarkchain already have a simulation of the network with 18 -nodes and 8- shard. Following are the results for early stage incentive and difficulty algo testing:
Also, not to forget that Quarkchain claims to have clocked 2.2k TPS on testnet.
I am a software engineer by core and I love to the keep my code modular and flexible. This architecture is designed in such a way that it is highly flexible and that is the beauty of highly adaptive coding for e.g.
a- Allocate 100% hash power to root chain and system is converted to conventional single blockchain
b- Revoke all hash power from root chain and system is converted to multiple independent blockchains.
I guess the purpose of this article is accomplished, but there are still lots of details about the project that needs to be explored and shared. Maybe in next article!!! Stay tuned!!!
BTW, I will also play the devil’s advocate and analyze the boundary conditions and exceptions that can cause the system to fail ;-)
My current analysis says that this project has smart and simple tech, but remember folks simple is not easy!!!! Hopes are high as team and advisors seem to know their business….