Despite starting out in the financial industry, we believe that blockchain technology can be applicable and useful to almost any field. QuarkChain is working on developing the most effective and useful enterprise blockchain solution. We did lots of research to understand what kind of blockchain solutions are really needed by enterprises. The first thing I believe is flexibility. In fact, it is a relatively missing feature in most existing projects.
What does flexibility refer to? With many enterprise business scenarios and geographical differences, can we address all the scenarios with just one public chain? In my opinion, this solution is not viable. The ideal solution should be scenario-based: based on the specifications of the scenario, customize a public chain as a solution. In other words, the solution that addresses all scenarios should be multiple blockchains.
Another question arises: if each business scenario requires its own blockchain to be relatively independent, then how can we make the interactions between these blockchains seamless? How can we ensure a high level of security while crossing chains?
Thirdly, if the business needs to expand, how can we maintain a high level of scalability with few major improvements? As we all know, the biggest problem the existing blockchain solution faces is that, once it is written, it is extremely cumbersome to upgrade. For example, when Ethereum is upgraded from 1.0 to 2.0, it is not something we understand in the traditional sense that the project is modifying the infrastructure from version 1.0 to 2.0. ETH 1.0 and 2.0 are two separate projects which show the whole blockchain ecosystem indeed lacks scalability.
Now we have another question, what kind of roles do public chains and alliance chains play in the ecosystem? We know that alliance chains offer more friendly monitoring capabilities and are easier to satisfy business demands. Public chains are more open and are better for cross-border or some international business scenarios. Based on our understanding and observations of clients, we see that we are trending towards a comprehensive solution that provides both public chains and alliance chains when needed. To be able to satisfy any demands at any time is something that enterprises are looking for. How can one satisfy the varying types of demands? The simple answer is heterogenous sharding.
Let me introduce more about the heterogeneous sharding, the cutting edge technology of QuarkChain. There are three key concepts related to heterogeneous sharding namely single chain, shards, and heterogenous sharding. What is a single chain? It is analogous to a single-lane highway. ETH 1.0, EOS, NEO, hyperledger, public chains, alliance chains, and so on are all single chains. As for sharding, it is like a multi-lane highway. The advantage of a multi-lane highway is that the time needed for a huge amount of traffic to pass through is lesser than that of passing through a single-lane highway.
At the same time, sharding can be based on the current traffic to dynamically adjust the number of lanes. If one has three lanes for now, when traffic increases, one can add one, or two, or three more lanes to expand the capacity to allow more traffic to pass through. One thing to note is that, for each lane, one needs to have identical lanes with identical specifications. Such constraint requires us to consider in the first place how wide the lane should be. What kind of materials should be used? Sandstone or granite? Should we plant any greens on both sides? All these specifications are needed during the design phase. After the design, every time when we add lanes, we follow this blueprint to add identical lanes.
In the area of sharding, ETH 2.0, Zilliqa, Harmony, Near are all good examples. If so, then what is heterogenous sharding? Heterogenous sharding, like sharding, has a multi-lane highway but each lane can be designed differently. As the highway in the previous examples requires the same width and the same materials and such, the heterogenous sharding highway allows each lane to be designed differently. In the area of heterogeneous sharding, QuarkChain and Polkadot are the leading examples.
We mentioned earlier that heterogenous sharding allows customized configuration but in terms of what areas? Before addressing this question, let us first establish a few baseline understandings of blockchain. Currently, all the structure of blockchain infrastructure includes all the tokens and public chains we heard of, such as Bitcoin, and Ethereum, anonymous tokens, ZCash, Grin, EOS, and all public chains consist of four important components.
The first component is transaction mode, which also can be referred to as a virtual machine (VM). The second component is called the consensus mechanism. The third component is the ledger model and the fourth component is token economics, which is more related to public chains. Do not be intimidated if you do not understand these four terms. As long as you understand that any blockchain platform must include these four components, then we can proceed to the main discussion.
For example, for ETH1.0, it uses EVM as virtual machine, POW as consensus mechanism, account base as ledger, and inflationary expansion as token economic. ETH is also used for paying transaction fees. For Bitcoin, its token economics is a fixed 21-million token supply of which it just halved its production rate a few days ago. Its ledger model is UXTO and consensus mechanism is POW with its own unique transaction mode called bitcoin type transaction mode. So as you can imagine any blockchain platform must contain these four elements.
However, for each platform, it has a fixed combination of ABCD. Once defined, users cannot modify or customize based on their needs. If the platform defines A as the consensus mechanism, then all users need to follow suit and adopt A as the consensus mechanism. It is similar to our analogy where once the width of the highway lane is defined then everyone has to abide by the specification.
In contrast, heterogenous sharding allows each new blockchain to be configured completely anew. For each shard on QuarkChain, one can add a new VM. For example, one shard can use EVM while the other one uses Wasm. One shard can use POW as a consensus mechanism while the other uses POS. The same logic can be applied to the ledger model and token economics. With that logic in mind, each lane can look completely different based on the needs of each lane.
Each shard chain in the blockchain can be added based on demand. The maximum number of shards can be added is about 20000. There are four shards in this diagram. Shard 1 uses EVM as a virtual machine, POW as consensus. This shard in fact is similar to ETH and in fact, has incorporated all the ETH functionalities. The second shard is similar to the first shard except that it uses DPos instead of POW as a consensus mechanism, which is used by EOS and Tron.
The third shard uses XVM as a virtual machine, which is a new type of virtual machine. If one day, I would like to have a chain using the latest VM technology, I can implement it quickly on a shard instead of hard forking the existing project. This example demonstrates that out of all the possible VMs or consensus mechanisms, one can choose what it prefers to configure a shard based on business requirements or domains.
In fact, heterogeneous sharding shares many similarities with cross-chains. What I meant by cross-chain is not interactions between ETH and EOS or between EOS to Tron, but interactions based on the same infrastructure. For example, Cosmos has a strategy: users can leverage its HUB API to launch a new chain easily but one would need to take its own risk in protecting the chain from attacks. Users are welcome to customize the configuration of each of the four components.
For Polkadot, it has a relay chain, which is the main chain that allows users to release a new chain easily. Among the released chains, one can cross the chains for communications. However, a new chain does not enjoy complete freedom in picking the four components: at this stage, each chain can pick its consensus mechanism out of the three limited grandpa options that Polkadot provides. In the future, it will add more options for consensus mechanisms. For protection, Polkadot’s hub will provide hashing power from its relay chain to protect the chains launched under the hub.
ETH2.0 shares many resemblances with Polkadot and Cosmos as well. It has one root chain and many shards. However, its shards have to be identical, lacking diversification. Lastly, for QuarkChain, it can launch shard chains with one click like that of Cosmos. What is even better is that each shard supports many types of consensus and allows cross-chains.
To summarize all the questions above, a single chain only allows the building of dApp with no customization. All the four components cannot be modified once the chain is launched. Polkadot and Cosmo support launching a chain with one click and can build a public chain and parallel chain and allow cross-chains. As for QuarkChain, we also support launching one chain with one click. Our solution can customize for public chains as well as alliance chains and allows cross-chains. It can provide a comprehensive solution for public chains and alliance chains, which is something that will satisfy the future demand in enterprises.
I am going to share two actual business cases now. One case is a solution we customized for a major multi-industry business client. This client covers various industries and currently based on three different areas, it has built three different independent single-chain public blockchains, one on hyperledger, one on alliance chain, and one on ETH. The problem they are facing is that for future businesses, if it would like to allow those resources to be moved onto blockchains in the future, how should we design to allow scalability? If it would like to exchange data between different industries, how would it be carried out? Since the different businesses all belong to the same company, it would make sense to share the data across verticals. However, to cross chains between hyperledger, alliance chain, and ETH with three different infrastructure layers are indeed challenging at this moment.
In the future, should we launch the 4th, 5th, 6th chains and so on and enable cross-chains among them? Or is it better to create a new chain that integrates all businesses? Both solutions are not optimal in my opinion. In the end, our solution was using QuarkChain’s infrastructure layer that implements heterogeneous sharding. The root chain acts as the executive level of the parent company that possesses the right to all business data and guarantee security. For each shard chain, the company can customize it based on business needs.
In terms of customization, the four components that make up blockchains can be tuned to fit what the client is looking for. One certain combination can be identical to hyperledger, the other can be the same as alliance chain, and the other for ETH. So one can pick a combination it prefers and add to the root chain. Since different shards are built on the same infrastructure layer, the solution allows cross-chain interactions. In the future, if the client would like to move some businesses onto the chain, it can add shards onto the chain. Such a solution allows scalability and avoids creating a public chain anew.
The second case is for a client who is a large-scale business. The client is looking to build a blockchain-based platform for resource management. Currently, it would like to start small with some test points. Next step, it plans to expand the testing area to more cities and more types of resources. So at the beginning stage, the client wants to start with a few areas and a single type of resource and later on integrate more resources and more cities. The traditional solution would be to create one chain for the particular resource and connect the related areas altogether. In the next stage, when the client decides to expand to more businesses, then it can launch a new blockchain that adds more users and more types of resources, which is like changing from project version 1.0 to project version 2.0.
Our QuarkChain solution provides a well-planned solution that uses heterogeneous sharding to avoid the need to relaunch a new chain for each expansion. It can have multiple layers and add shards on each layer. To go into more details, for instance the first layer is the state or equal scale executive level, which is the root chain that controls all the access rights for all data; the second layer is the lower administrative level like the city-level executives, which can use different resources that they have to customize different shards and allow cross-chains among shards. The first layer has a higher level of access rights compared to that of the second layer. In the future, if the project spans across more resources and even rolls up to the national level, we can add a third or even fourth layer whereby each layer enjoys different administrative rights and controls appropriately.
As a leading blockchain technology company, QuarkChain is exploring to use heterogeneous sharding technology to achieve the most innovative ways enterprises are incorporating blockchain to revolutionize their industry. In 2020, QuarkChain plans to expand the enterprise solution into the smart city and large-scale resource management system, bringing high storage capacity, high processing efficiency, safe and reliable enterprise blockchain solutions.
Website
Telegram
https://twitter.com/Quark_Chain
Medium
https://www.reddit.com/r/quarkchainio/
Discord