First, QuarkChain Team always appreciates the community’s support and understanding. We treat all these kinds of articles as a learning process to our product and technology. In the following, we respond to the concerns raised in this article.
“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.”
Response: This figure is totally misleading. It does not represent QuarkChain structure at all. We do not know what those black dots are. First, every shard is a blockchain. What does this “star” in every box mean? Second, every shard (or minor chain) is connected to root chain. Every shard can perform many transactions and one cluster/super full node can support many shards. It is not this like this “bus-stop” structure. To clarify this, we put the figure from our white paper here
Fig. 8 from QuarkChain whitepaper
“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.”
Response: We respectfully disagree with the claim here. First, a shard does not mean a node. A shard is a blockchain run by many many nodes from different clusters and each node in a cluster has a copy of the full ledger of that shard. Please see QuarkChain whitepaper Figure 7 (a) and (b) for a detailed example. In addition, Ethereum sharding is also working toward state sharding direction.
“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!”
Response: Reshuffling or resharding is an interesting topic. We will reveal the technical details later. In short, the design is very similar to Google’s BigTable’s resharding -- splitting the state of a shard so that one could have two shards. Based on Google’s pioneer work, this can be done efficiently.
“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.”
Response: Blockchain itself is not a brand brand new topic. In fact, it highly relies on many existing areas, e.g., security, distributed database, distributed network, parallel computing, signal processing, optimization, network theory, big data, etc. In the near future, it also related to hardware circuit designs. QuarkChain team actually accumulated tons of experiences and various expertise in many of these areas from academia to industry. Our core engineers previously worked at Google and Facebook -- two companies that have been successfully using sharding technology in centralized world for years. The responsibility of our core engineers was using sharding to solve the scalability problem of large distributed systems. Thus, our team is very confident about our project.
“Why Quarkchain still using PoW rather than the recently more popular PBFT algorithm? It is because the limitation of PBFT algorithm that the number of nodes that PBFT can support is very limited (not more than 50 nodes). Zilliqa is using PBFT+PoW, a hybrid and improved consensus algorithm. It is clear that what Quarkchain team try to accomplish is rather trivial. They don’t have the technical know how on how to make a robust and secured sharding blockchain. They have no idea how to handle the issues of state sharding. They don’t even realize that by increasing the number of shards, their actual TPS will reduce due to increasing cross-shard transactions as explained below in Cross-Shard Transactions.”
Response: QuarkChain is using PoW for its consensus protocol for shards. “Why not PBFT?” Nobody defined PBFT is more popular. In fact, those representative ones like Bitcoin and Ethereum are all using PoW. “What QuarkChain team try to accomplish is rather trivial” -- Does this mean “scalability is trivial”? We think the majority of blockchain society won’t agree with that. As stated in the previous response, our core developers have years of experience working on solving scalability problems in large scale distributed systems in Google and Facebook. How do the author conclude that “ they have no idea how to handle the issues of state sharding”? About the “TPS will reduce due to increasing cross-shard transactions”, we will response in the following.
“Another issue of the Quarkchain is no minimum and maximum nodes per shard, see Figure 1. This will jeopardize the security of the blockchain. If a shard with low nodes count, it is easy to be targeted by hacker to compromise that shard and lost the tokens. Although the root chain will record each shard hash, it does not record a copy of the shard’s ledger. The ledger is local to each shard only since shard do not share its ledger. The root chain can only identify a genuine shard vs a compromised shard, as Figure 4 shows.”
Response: This comment actually proves the misunderstanding of the author to state sharding technique. Therefore, the plot given by the author does NOT represent the structure of QuarkChain network. QuarkChain supports clusters with multiple nodes which provide security. Please see QuarkChain Whitepaper Section 5.1 and Figure 7 (a) and (b) for a detailed example.
“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.”
Response: All transactions in the QuarkChain Network are protected by 50% of the overall hash power of the network, and a double-spend attack requires at least 25% hash power. This is smaller than single-blockchain’s 50%, but since the QuarkChain Network is more decentralized, a miner will be much harder to collect 51% hash power in our network than that of single-blockchain. More details about decentralization and security, please refer to white paper Section 4.
“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.”
Response: Again, the author still messed up the concepts of shards and nodes. Every cluster would main the full ledger of all shards, hacker must compromise the whole network if a shard is compromised? In addition, all transactions in the QuarkChain Network are protected by 50% of the overall hash power of the network and all shards are supported by clusters. Please refer QuarkChain Whitepaper Sections 4 and 5.
“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].”
Response: It is true that receiving a cross-shard transaction needs root chain’s confirmation (by confirming the transaction’s block header), which takes longer time than in-shard. However, when initiating a transaction, a user could recognize whether they are performing cross-shard transaction or not based on the address info. In term of finality, both in-shard transaction and cross-shard needs the same amount of root chain’s confirmation.
A notable analogy of our sharding approach is like Internet, where sending cryptocurrency from one shard to another shard is like sending IP package from one address to another. Visiting a website in different continent will travel more hops and take longer round-tip time. Similar situation holds for for QuarkChain, i.e., a user should expect a delay after performing cross-shard transaction. Note that 15x is a pessimistic estimate, and we are working on optimizing these parameters using latest blockchain technologies.
“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%.
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!”
“Quarkchain will actually become slower than Ethereum in real life!”
Response: The calculation shows that the author totally misunderstood the purpose of using state sharding technology. First, the purpose of using sharding is to enhance the scalability, i.e., TPS. For example, suppose each shard can perform 1000 TPS. If the application requires 500 TPS, then one shard solves the problem. If the application requires 5000 TPS, then 5 shards can serve the purpose. How can the throughput be slowed down? Once again, the root chain is only for cross-shard transaction CONFIRMATION by confirming the transaction’s block header.
“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.”
“Cost: The Project X need to pay 5 times more fees in creating the smart contract. Do note Quarkchain intends to have millions of shards, so in another words, in reality, Project X might need to pay 1 million times the fees as compared to a similar ICO contract in Ethereum!”
Response: Again, the comment here is a misunderstanding for cross-shard transactions of QuarkChain. We have the answer to this concern in our whitepaper Section 6.2 which we quote here:
“ Since a user can manage all addresses in all shards via a private key, a user will essentially have the same number of addresses as the number of shards. If the number of shards is large (e.g., thousands or tens of thousands), a user may have multiple balances in multiple shards, and thus managing all balance in all shards can be inconvenient. The account management of the QuarkChain Network has been further simplified by defining the following two types of accounts:
Primary account: Primary account is the address of the user in a default shard
Secondary account: Secondary account manages the rest of the addresses of the user in the rest of the shards.
To simplify management, most transactions of a user will be initiated from the primary account, temporarily move to an address in the secondary account if the transaction requires it (e.g., smart contract in different shards), and if there is remaining balance in secondary account after the transaction, the balance will be moved back to the primary account. This ensures that the balance of the user should be in the primary account most of time, and thus the user does not need to manage the balances in the addresses of secondary account. This feature is enabled by smart wallet, which will be provided by QuarkChain team as an open source project. “
“How do the smart contract keep track of the number of total tokens sold? The maximum number of tokens in this case is 1 million tokens. User can buy from any shards.”
“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.”
Response: We feel that the arguments here are all based on the wrong concepts of state sharding and cross-shard transaction. The QuarkChain Network will support smart contracts via Ethereum virtual machine (EVM). To utilize high-scalability feature of the QuarkChain Network, an additional scalability-aware interface will be provided with features such as which shard the contracts being executed and sending smart contract specific data via different shards. Please also refer to our Whitepaper Section 6.4 on how smart wallet supports the smart contract for cross-shard transactions.
“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!”
Response: Based on the aforementioned responses, this claim is not supported.
“What about Dapps running in the future in Quarkchain? A Dapps cannot run on all shards since each shard is like an island of itself, with its own ledger and own smart contract execution independent of each other. The only bridge to connect other shards is via the root chain, but the root chain do not record transaction details and has no copy of the shard’s ledger and definitely will not process smart contract.”
Response: This is a misunderstanding. Based on the author’s plot -- the “star” shape shard, the shard may look like an island. However, that is NOT our definition of shard. Apparently the author got confused about transaction and confirmation. The cross-shard transaction needs root chain to confirm. However, thanks to the sharding technique, the transaction finality of QuarkChain (no matter of cross-shard and in-shard) takes the same time, and the network throughput is still high. User end is barely recognizing the transaction finality difference between cross-shard and in-shard transactions. The QuarkChain Network will support smart contracts via Ethereum virtual machine (EVM). To utilize high-scalability feature of the QuarkChain Network, an additional scalability-aware interface will be provided with planned features such as which shard the contracts being executed and sending smart contract specific data via different shards. Please also refer to our Whitepaper Section 6.4 on how smart wallet supports the smart contract for cross-shard transactions.
“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!”
Response: We are totally confused about the calculation here. The fees are based on transactions, not the shards. One million shards do not mean one million times of the fees. Using the Internet example again, the company does not charge the user for every hops of routers. If the author was talking about the fee for smart contract deployment. Yes you need to pay for each deployment but only if you need that many TPS to support the Dapp. Just like using cloud services to support a mobile app, the more popular the app becomes, the more resources the app needs, and thus the more money you need to pay for buying those resources. No one would pay a million dollars to get a thousand machines when they only need one. The point is we provides a scalable blockchain solution and it is up to the user to decide how much capacity their Dapp needs.
“Quarkchain architecture of scaling is totally flawed! It will not work, it will only become 1,000,000 time more expensive than ethereum and 1,000,000 times more slower than ethereum! It is a flaw architecture designed by a non-blockchain PhDs and Professor, the whole team has zero experience in blockchain, their papers published is only in the field of Electrical and Electronics Engineering. It clearly shows the team lack of understanding what is sharding and how to apply the technology properly.
Creating islands of mini Ethereum networks and linking them DO NOT work as they thought.”
Response: This conclusion is based on the author’s misleading interpretation. About the team qualification, please see our previous response. We feel it is meaningless to argue 1,000,000 times slower or more expensive. Currently our testnet already reaches more than 10,000 TPS and it will be released to public at the end of this month or early next month. We believe once our mainnet comes out, the truth will prove everything.
In summary, we think this article is based on some biased and misinterpreted descriptions on QuarkChain technology, and lack of knowledge of sharding technology. To show the good faith to the community and the media, we wrote this response. We wish this response will clarify and reveal more insights of QuarkChain technology.
QuarkChain Team