by Zebra Crossing
Update: This is our reply to Quarkchain Team.
https://steemit.com/quarkchain/@bitcoinstartrek/zebracrossing-response-to-quarkchain
This article attempts to analyze Quarkchain[1] architecture from various sources. Do note that Quarkchain White paper does not have sufficient details about its architecture. The following is derived from its Whitepaper[2], live private testnet demo[7], AMA, admin answer from its official Telegram group[3] and its latest quiz answer[6].
Figure 1: Official admin answer
Each shard in Quarkchain resembles a mini Ethereum chain. And there will be many shards and the theoretical maximum number of shards is 2147483648, see Figure 2. All these shards are connected via a root chain. For example, if you have a wallet in shard ID 1, and you want to send 1000 tokens to another wallet in shard ID 1, then the process will be very fast because the TX is within the same shard, and thus no need to go thru the root chain, Figure 1.
However, if you want to send 1000 tokens from a wallet in shard ID 1, to another wallet in shard ID 5, then since the source and destination address is in different shard, the transaction need to go thru the root chain, and it is called cross-shard transaction, see official answer, Figure 1, Question 5.
The root chain function is like a bridge, linking all the mini Ethereum chains together (shards). The root chain also does the job of recording the checksum/hash of the shards but it doesn’t keep record of the global ledger. Each shard has its own ledger and the ledger is local to its own shard and never share and duplicate across shard. The root chain also do not store the ledger(s).
By using this method, the TPS will increase tremendously if more shards are there. Say we have 1 million shards, and each shard can process 1000 tps, then the total TPS is 1000 x 1 million shards = 1 billion TPS.
Before we judge who is better, let’s us delve deeper on what is the difference between state sharding and transaction sharding. A state sharding[4] is to divide the entire storage into pieces and let different shards store different parts; thus every node is only responsible for hosting its own shard’s data instead of the complete blockchain state. In another words, each shard in state sharding do not have a complete global ledger, while a transaction sharding, each shard store a complete global ledger. If one of the shard in state sharding is compromised, then the tokens stored in that shard might be lost forever and could not be recovered. This is called a single shard takeover attack and the same has been discussed in Ethereum FAQ. In transaction sharding, recover is possible since each shard store a complete global ledger.
It is also unclear how reshuffling can happen in state sharding, and will that temporarily makes the network unusable? These questions were asked in Quarkchain main channel and no answers were given by their admin. It seems like the team at Quarkchain has no idea how to tackle the problems in state sharding and yet dare to claim it will use state sharding to achieve 1 m tps!
Do note the team from Quarkchain are comprised from Phd and Professors from the field of Electrical and Electronics Engineering, not from blockchain related field and has zero blockchain experience prior to this. It is questionable that the team can achieve what they claim of 1 m tps while still maintaining sufficient security and up time.
It is also said that a 25% hashpower attack will compromise the whole network of Quarkchain. This is a major red flag and shows how insecure the architecture of the Quarkchain is, see Figure 5.
It is also said that the address of each wallet last few digits are shard ID, from live test video [7]. This will give an easy target for hackers to target those wallets with large amount of tokens and knowing that which shard the hacker need to compromise. Thus the design of Quarkchain architecture is simply a big warning.
Which means a Cross-shard transaction will be solely confirmed by a root chain at the end of each block (which is 15 times slower than the shard chain) [6]. This is an interesting side-effect of the sharding that you might be unlucky to have your transaction pending for 15x time than someone else because you are doing a cross-shard transaction [5].
Assumption is the number of wallets is the same in each shard.
If we have only 2 shards, then the probability of same shard is 50%. And cross-shard probability is 50%.
If we have only 10 shards, then the probability of same shard is 10%. And cross-shard probability is 90%
If we have 100 shards, the probability of same shard reduces to 1% only. And cross-shard probability is 99%
And if we have 1 milllion shards? The probability of same shard is only 1/1000000 = 0.000001%. And cross-shard is 99.999999%.
What happen if not in the same shard? Then the throughput will reduce significantly, 15x slower as [5] shows. It first needs to be confirmed by the source shard, then send through the root chain, then from root chain, sent to the destination shard. This actually makes it much slower than Ethereum network.
By looking at the scenario above, it is easy to see that the more shards that are available, the probability of cross-shard transaction is a lot higher, and thus it will actually slow down the throughput of the blockchain!
It is inconvenient for the requirement for users to move their tokens to Shard 1. Why can’t they just use any wallet that they have on any shard??
Project X identified the problem of inconvenience and low throughput, and decided to launch the smart contract on ALL shards. Thus, now you don’t need to create wallet at shard 1 and move your tokens to shard 1. You can participate in the project X crowdsale at any shard. And also now the TPS is much higher, at 5x the speed, which is 5000 TPS due to 5 shards in total.
Problem to this approach:
In other to keep track of the total of tokens sold, few approaches can be used.
A) Cross-shard communication. Each smart contract from each shard will update each other if a token is sold. If there is one million shards, that means if one token is sold, 1 million of communications via the root chain is needed! It means It is VERY RIDICULOUS SLOW! OR
B) A special smart contract say in Shard 5 is used specially to keep track of the tokens sold. So, whenever a shard sold a token, it need to update special smart contract in Shard 5, much faster but still a lot of overhead, the problem of 5 times more fees still haven’t solved. OR
C) Divide the total tokens by number of shards. 1 m tokens here divide by 5 shards, so each max tokens available for sold in a shard is limited to 200,000 tokens only. This method will eliminate cross-shard communication and most efficient, but remain costly to launch so many smart contracts at the same time. But it will at the expense of user inconvenience. If shard 1 has a lot of participants, then it sold out way faster than shard 2 which is unfair to participants in Shard1.
In another words, Quarkchain architecture does not provide cheaper and faster for smart contracts execution. It is actually make smart contracts execution more slower and more expensive than Ethereum!
Say if a high speed Dapp need to deploy on Quarkchain, then if the Dapp execute only on Shard 1, the TPS is only 1000 TPS! Which is SLOW. To increase the speed of the Dapp, then the Dapp need to execute on all the shards. Say Quarkchain has 1 million shards, and thus it need to pay 1 million times the fees! How ridiculous is this approach!
Creating islands of mini Ethereum networks and linking them DO NOT work as they thought.
