Sometimes, all it takes is cp and rsync. See the image below for an example.
Quarkchain is interesting. I still have my reservations on cross-shard transactions and the implication on finality, and I still dislike the horizontal scalability claim.
But in the QuarkChain code review I definitely see some things that I like, too.
Testnet is up and running, hitting 10,000+ peak TPS. Curious what this is per shard, since I assume the value is cumulative. Overall TPS can be a bit of a confusing metric since each shards TPS should be measured individually. And does the overall TPS take root chain finality into consideration?
All that aside, let’s have a look at the code, and see what they have been up to since last I looked at it.
Quite a lot to go through. Layout is a bit weird. Key classes are in root it seems, and then we have directories for testnet, cluster, genesis_data? Might make more sense when we are deeper into the code.
Starting with utils, mostly wrappers, good comments, good attribution to libraries used.
Interesting abstraction. Seems a bit needless.
Protocol is the network layer. RPC and connection data.
Very curious to get into EvmState. Will get there soon. Looking at genesis_state currently. For now just a commit to the EVM state. So at this point balances and addresses live in the EVM, so a bit of a decoupled architecture design (consensus => EVM). I like the design.
ETH difficulty calculations. Starting to feel a bit like Ethereum with sharding.
RocksDB used for key value pair storage.
Currently ecsda, future versions will have secp256k1 it seems.
Core is mostly quality of life functions.
Interesting naming standards for testnet. Where is lambo and micra?
Interesting default config values. Lots of testing utility built into the config.
Accounts is as expected. Keystores, creation, etc. Great commenting.
adjust_difficulty is in p2p folder. Weird.
Jumping to cluster (which is their version of node)
Master / Slave setup, not unpermissioned clusters.
Monitoring kafka rest address? Is transaction data for clusters managed with kafka?
Real meat is in cluster/master.py, it’s good. Clusters are built the same way the shards are. The leader is essentially the root chain for each cluster.
QuarkChain Code Review Conclusion:
It’s good code. Because I hold Quark to a very high standard I did want more, although what I wanted more I don’t know. It’s very good, but I can’t help but feel there is something more here. For now, it’s shards processing transactions, and transactions being committed to the EVM. QKC is living in the EVM. It’s a scaling solution for EVM that allows parallelized processing via the shards.
All in all, they build exactly what they said they were going to. I don’t think this will see higher than 25k TPS though, but it’s niche allows for concurrent smart contract execution which is really great. Good code, good progress. Will continue to keep an eye on them.
Disclaimer: 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 opinion. It is normal for code to change rapidly, hence timestamped code reviews such 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.
After formalities and introductions; this is how the conversation proceeded. Obfuscated due to NDAs and Confidentiality agreements.
Me - something polite akin to "You are breached."
Them - something akin to "We are PCI compliant. We are not breached."
What I want to ask - Are you sure about that?