QuarkChain Code Review - Deep Dive

Share this article

Today I’m doing a deep dive with my QuarkChain code review – the findings here were factored into the QuarkChain ICO review that we just published yesterday. We’ll be doing this more and more, to give you more of a sense of why our ICO reviews are rated the way they are, since the code review is an important metric in our analysis.

QuarkChain, the high capacity, peer-to-peer, transactional system. Buzzwords for blockchain, but we won’t hold that against them. Promising 1 million TPS… So, if any of you have read any of my previous work, you know how I feel about 1 million TPS. I just don’t understand the obsession and more so I don’t understand this target number.

Can we all, as a community, please take a step back and look at our current ecosystem. Right now our highest production blockchains are maxing out at around 2k TPS, so can we please make our target a production level 10k TPS? And then can we focus on 50k TPS?

We still have a lot of targets to reach before 1m TPS, you know what I want to see? I want to see the 13,431 TPS blockchain promise. I want to go on a website, and see “we can achieve 13,431 TPS” that I’ll believe. If you tell me you do 1 million TPS, I automatically flag you as a scam.

That out of the way let’s look at some of the tech.

Two-layered blockchains, elastic sharding blockchains (shards) in layer one and a root chain in layer two. Consider Ethereum is the root chain, you have a lot of Ethereum side chains, we have POA, we have dAppChains (from Loom Network), each of these side chains is rooted in Ethereum. This is a rudimentary explanation of this two layered approach.

Right now Ethereum uses their ERC20 token (this gives us tokens such as EOS, TRX, etc), now instead of Ethereum having had each one as an ERC20 token, instead they had each one as a side chain. This starts giving you an idea of elastic sharding blockchains, a new token gets added we add a new blockchain, but each one is still confirmed within the Ethereum mainchain.

So keep the picture, of lots of side chains all rooted in Ethereum mainchain, in mind when we talk about the two layered approach.

The rest are actually all features off of the two-layered blockchain, we will jump into each concept as we go through them in the code review, the one that deserves mention however is Cross-shard transactions.

In my quick Two-layered blockchain example above, we spoke of side chains for example POA and Loom Networks dAppChain, the problem however is that these two can’t natively communicate with one another. Not unless you implement some form of a cross-chain bridge. In QuarkChain these are designed as first class citizens.

Basically we are saying they are inherently part of the system, the difference between sending an on-chain transaction versus a cross shard chain transaction is as easy as changing the destination address.

So with these two high level concepts in mind, let’s look at the code.

So, we start of with pyquarkchain, my immediate assumption, they just cloned pyethereum. I know I shouldn’t be so pessimistic, but with the sheer amount of projects I have looked at, cloning seems to be the norm.

And what a pleasant surprise. I even tried digging into a few files that I was sure would have been copies, all custom. We do have a few imports for EVM and P2P from Ethereum, but these are just raw imports.

Some stats on the repo, 268 commits, 4 branches, 4 contributors. I like the contributor ratio, branches management is used, commits while small contain a lot of substance. Off to a good start.

Pull requests and issue management is actually being used. Good to see.

Quick comparison of the two code bases (pyquarkchain & pyethereum).

Good comments. Let’s jump into some of the actual functionality.

Testnet is currently running on 8 shards (this is configurable). Chains are mining in Proof-of-Work. Each individual shard is running between 100–200 TPS, overall TPS currently at around 1.1k.

So, we need to get these guys a designer, I liked bootstrap back in 2011 when it came out, but we need to get these guys onto material. Wallet is straight forward, I have my usual reservation and comment about it not being HTTPS, a certificate takes 10 minutes, come on guys.

Wallet uses ethereumjs-util.

We see some getNodes and selectNode functions, let’s have a look.

They are protected, so guess no breaking for us today.

Let’s chat about some of the functionality. So remember earlier when we described the sidechains, that’s a form of isolated sharding, splitting the whole into smaller parts. I don’t actually want to call what QuarkChain is doing sharding, the interesting thing here is one of their features they mentioned earlier Simple account management. Let me copy.

“There is only one account needed for all shards. All cryptocurrencies from different shards are stored in one smart wallet”, the thing about a bunch of Ethereum clones (WanChain, POA, dAppChains, etc) is that they all share the same private/public key architecture. This means if you own a private/public key pair on Ethereum, you also own that same private/public key pair on WanChain, POA, and every other clone.

So in the Two-layered example we mentioned above, you would own this key in each side chain as well. But this would cause conflicts? Since now, how do I send my 10 WAN to my POA address? Well, you can’t. In QuarkChain you can? So how does that work?

So first, we need to look at why our (my) original assumption on the side chain two-layered architecture was wrong. We can call that approach namespace sharding (each sidechain/token would have its own name).

What QuarkChain does is create a kind of parallel sharding. So unlike the sidechain example, this is more like parallel Ethereums all running next to each other. If Ethereum A starts getting busy, you move your funds to Ethereum B. For this reason I struggle to call it true sharding, since each shard is actually not a piece of the whole, but a copy of the whole, all running concurrently, yet isolated.

So when I own a key, I own that key in Ethereum A, Ethereum B, Ethereum C and so forth, and I can move my funds between any one of these, but won’t that cause a conflict again? So your public key has the addition of which shard it is in, so it can be seen as key + shard ID, so if you own base address 0x1, you have 0x1a, 0x1b, 0x1c and so on. So when you want to move your funds from 0x1a to 0x1b you simply use the address you want to send to. This is how they allow single key ownership while maintaining cross shard interaction.

Here though, the two parallel chains can’t reach consensus, so they need to rely on the root-chain for their consensus, so the root chain’s primary function are these cross chain transactions. Where in a normal Ethereum transaction you have address A sending to address B, now you have blockchain A sending to blockchain B, same concept, but the from and to parties in question are of a different scale.

So since these are parallel chains, what happens if everyone simply transactss on Ethereum A, and no one uses Ethereum B or C? Well, then Ethereum A becomes congested and it will start suffering throughput. This will cause fees to go up, so now, if you wanted to have a cheap transaction, you could simply process your transaction on Ethereum B, and if both A and B have an equal load share, then you could move to C.

This concept is the market driven collaborative mining, thanks to the reward structure the load is shared across the shards. The problem though, you have all your funds in Ethereum A and you want to now participate to the ICO on Ethereum C, but A is congested and you have to pay high fees to make your transfer from A to C, and not only do you have to pay the high fees, but you have to wait for the root chain to finalize your transactions, adding more overhead.

I’m not sure how they will tackle this problem, but I see it as an issue. Also the micromanagement that users have to do between their own shards will create a bad user experience. I think these are 2 key issues that need solving. 

So already we see the practical TPS is less, considering the congestion can occur on one parallel chain and we have to consider the overhead of the root chain.

So, let’s look at the theoretical side of the TPS first.

Current shards are running at, let’s go with 150 TPS, so 1m/150 means 6667 shards required, sharding supports up to 2 billion shards. So, theoretically sure, are you going to micromanage 6667 shards by moving your funds around? So let’s practically go with around 10 shards for around 1.5k TPS.

Next up is CPU, I’ve managed around 5k TPS on a single core (dedicated only to TPS), so let’s say practically 1k. If we look at some of the monster machines in AWS, m5.24xlarge, let’s say 72 cores, so 72k TPS (assuming there were enough transactions to be done in parallel and you didn’t have to do them synchronous, remember, the reason we do transactions synchronous is because transaction 0x2 might be influenced by transaction 0x1. If I have 10 QKC and I send 10 to A and 10 to B and they are processed in parallel, both could succeed, so we have to process them synchronous. But let’s assume we have 72 shards so we can run each shard on a CPU, so let’s say 72k TPS is possible.

We said practically we will look at around 10 shards, so let’s instead say 10k TPS is possible (highly possible)

Even at 20 shards, which is still reasonable, we quickly start looking at 20k TPS. I’m still very much against the 1 million TPS claim, but these guys are looking realistically close to a potential 10–50k TPS system.

And now we haven’t even started talking about clustering yet, which I think I will leave for another article since at this point you must be bored.

QuarkChain Code Review Conclusion

If you made it this far, congratulations, this is probably the most I have written on any ICO so far, and why? Because they have more here than any ICO I have written about, there are things I disagree with, but I am honestly impressed. I think they should throw away the 1 million TPS claim and just say 50k TPS, and I really think they have a realistic shot at it (and we need to get them a UI/UX expert)

I think their implementation is novel, well executed, and I am definitely going to be playing around a lot more in their testnet. It annoys me that I haven’t been able to break it yet.

Full QuarkChain ICO Review is here.

Disclaimer: Crypto Briefing code reviews are performed by auditing what is on display in the master branch of the repo’s made available. This was performed as an educational review and any comments in the article are the opinion of the writer. It is normal for code to change rapidly, hence we timestamp our code reviews so that they present a snapshot at a moment in time. Information contained herein should not be used as any comment or advice on the project as a whole.

QuarkChain Code Review Timestamp: April 16th, 2018 at 17:42 GMT

Share this article