MultiVAC Code Review: All Dimensional Sharding

Share this article

Nothing makes me more intrigued than exciting marketing buzzwords – you know, instead of real code and an actual basis for a blockchain project. JK. What I really mean, is that when I read “All-Dimensional Sharding” I actually feel I’m going to suffer a stroke. But for once, I’m happy to report this turned out much better than I expected.

So, let’s look at this high-throughput and flexible blockchain platform based on trusted sharding computing.

“All-Dimensional Sharding — world’s first fully sharded blockchain” Dammit, there it is again.

“Trilemma Flexibility — allowing DApp developers the flexibility to trade off between the the impossible triangle of decentralization, scalability and security”. Uh huh. At least they acknowledge the trade off rather than promise something that can’t currently be done, like, solving it.

Initial thoughts, fairly realistic statements, looks like a well designed ecosystem, strong focus on separation of storage, mining, and compute functionality. A very important distinction nowadays.

The whitepaper was, interesting, in that I understood maybe 10% of it. The core of it is all the random generation though. Random generation in blockchain solutions are incredibly difficult because it can easily be manipulated. In a traditional proof of work solution you know the answer, and you try to prove that you got to the answer. If you did this with random functions, you could simply say you got the random value. So the concept of Verifiable Random Functions become incredibly important, since it can prove that the generated value is indeed random. This concept is then used to create shards, consensus, leaders, everything.

The repo’s are active, lots of contributors, everything private, but we can excuse that for now.

Lot’s of interesting repo’s to dig into, I see btcd, so we have a bitcoin fork at its core, but let’s dig into that a bit later.

One of the oldest repo’s is called consensus, since the VRF (Verifiable Random Functions) are key to the whole system, I wanted to start with this proof of concept (I assume it’s proof of concept since it hasn’t been updated since 8 months ago)

VRF, cryptographic sortition, byzantine agreement, and a quick and dirty block structure. Let’s have a look;

VRF is a stub for now, moving on.

Another stub, leader’s and committees. This is interesting though, because it shows how important the Random number generation is. If the last few digits of the random number match the general value, then the committee is selected, and leader, and shard, etc. So this function is going to be critical.

So, the consensus repo is more a skeleton draft of what they want to build, no real detail, so moving on to the other repos.

Multivac skeleton is a bit more recent, so it’s interesting to dive into. To be fair, I’m just looking at the other repo’s because the core Multivac repo is a btc fork, which means a lot of code, and it’s difficult to go through, so hopefully we see the secret sauce in one of these template / skeleton folders.

With Golang projects you start at /cmd/, so we jump into /cmd/main and we see it initializes a node. Over to node;

Just a stub, p2p and rpc.

Shard, RPC, p2p, just stubs, I’m going to have to go through the big repo it seems. I did get excited by the consensus directory, but just stubs. The repo did literally say it’s a skeleton, so it is very aptly named. Sigh. Guess we are doing the real work, not allowed to be lazy today.

Trying to guess where the important parts are, I would assume consensus, chain, shard, storagenode, vrf. Now we do a quick diff on btc vs multivac repo’s, so I can see where the big changes are;

Left btcd, right multivac, looks like I guessed correctly 🙂

/consensus/ binary byzantine votes, practical bft, sortition. These are all great concepts to see in a single repo. They really did cherry pick some of the best technological implementations out there currently. I want to start with the VRF’s though, so let’s jump into /vrf/

I’m quite excited about this.

Same stub as we saw in the original consensus repo, good to see they are building off of the original architecture ideas.

Read random bytes from input reader, create private key from random input. So what stops you from just providing the same Reader with the same input everytime? Like a reader for a file with the same 32 bytes? Don’t know, let’s keep looking;

Verify, standard verification, nothing specific here.

VRF just signs a message with the private key. Now I’m a little bit confused, where is the random being verified? Going to head into the whitepaper again, think I’m missing something, this isn’t a VRF.

Looking at the brief intro in the whitepaper we expect;

VRF = Generate, which produces a public key and secret (private) key, and verify that proves it was randomly generated.

Doing a deep dive, but I still don’t see it. The random can be manipulated. Isn’t this just ed25519? Good code, high level quality, but I’m missing something, I don’t see the random generation or verification. Going to move on a bit for now and see how it is used in other areas;

Sortition should use it, so let’s go have a look at it.

Not VRF, pity.

BFT is broadcast voting. Practical BFT, so leader proposes a value, committee acknowledges receipt of proposal, committee votes, leader collects votes, leader broadcasts votes, committee acknowledges receipt. Standard 3 phase commit broadcast.

The consensus part is a bit pBFT 101, each chain is a shard, shard are just descriptors essentially.

MultiVAC Code Review Conclusion:

Little bit disappointed, but only because I think very highly of this team, I consider them one of the good ones. I don’t see the core implementations of their whitepaper yet, I see good code clean, very well documented code, but it’s lacking it’s core value differentiation.

I think I’ll look at this again in a few weeks/months time and see how it evolves, but I’m currently left a bit wanting.

You can chat about MultiVAC in our Telegram group.

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.

MultiVAC Review Timestamp: March 13th, 2019

Share this article