Shout out to my new team member CryptoRaider for his technical due diligence and editorial support on this article. If you are a researcher or writer and would like to join the team please reach out to me at [email protected]
MultiVAC is a new entrant in the public blockchain space. Using sharding (similar to Zilliqa, Quarkchain, and Emotiq) MultiVAC aims to produce high TPS to enable decentralized applications (dApps). Differentiating itself from Zilliqa and Emotiq (built off of OmniLedger), MultiVAC adopts Verifiable Random Functions (VRF) for its consensus mechanism and shard selection. Projects such as Dfinity and Ontology introduce similar randomized methods to elect block creators. MultiVAC's accounting method uses UXO, similar to Bitcoin. Developers will have the ability to flex between the tradeoffs within the CAP Theorem, namely consistency, availability, and partition tolerance. If you're unfamiliar with CAP please see the Education Series article titled Blockchain: A Game of Tradeoffs. In short, decentralized computing at scale is currently an unsolved problem in computer science. Decentralized networks can maximize along two corners of the triangle with consistency, availability, and partition representing the edges. MultiVAC is well aware of these tradeoffs and allows developers to choose the settings they need to suppose their use cases.
The Web 3.0 stack of technologies hope to compete and overtake the existing internet with scalable distributed networks. Public blockchains such as Ethereum are working on layer 2 solutions to achieve scalability. Sharded networks such as Zilliqa make some security concessions in favor of higher scalability. EOS, which recently launched its mainnet, opted for "sufficient" decentralization with its 21 block producers to create a high throughput network.
VRFs are pseudorandom functions in which the user of the function can generate a proof in which all verifiers can quickly validate without the user revealing the overall function itself. Shards are simply subgroups of the entire network. For example, if the entire network had two shards, say A and B, then when nodes join the network they would need to choose between the two. In MultiVAC's network, a VRF is used to assign a node to one of MultiVAC's shards. The underlying mechanic is a random number is generated on the main chain and then encrypted (hashed, see our hash function Education Series article) with the unassigned node's private key. The end result is a pseudorandom number and is then assigned to a shard according to a probabilistic table. If that's too complicated, just imagine the sorting hat from Harry Potter is placed on a node's head and decides which house (shard) the node is assigned to. End of story.
Consensus Within a Shard
Consensus enables agreement about the state of the distributed ledger (blockchain) without a third party needing to get involved. Depending on the algorithm employed, different thresholds of network reliability are needed for consensus success. There are a multitude of different consensus schemas and variations of said schemas to consider. Zilliqa (ZIL), another sharded protocol, uses PBFT where each node wishing to join the network is tested to solve a Proof-of-Work (POW) problem. Existing nodes in the ZIL network validate the PoW and authorize the node to join the network. PoW serves as an entry ticket to the network. Only nodes holding valid tickets can join the network.
For consensus to work, the percentage of honest nodes within a shard needs to be greater or equal to the ratio of the margin of safety. Additionally, the overall state of how synchronous the network is needs to be taken into account. It's natural for nodes to fall into an asynchronous state for benevolent or malicious (under DDOS attack for example) purposes. Think of a DDOS attack as someone walking out the door to the get to a polling station to send in their vote, but instead find thousands of people coming at you to prevent you from reaching your destination. Consensus thresholds need to take both the margin of safety and the proportion of synced nodes into consideration.
MultiVAC prioritizes consensus algorithms that prevent forks. In its whitepaper each shard may employ one of the following algorithsm: PBFT (Zilliqa), asynchronous BFT or BA⋆ (Algorand).
Syncing Across Shards is Hard
All sharding implementations today face the same challenge of syncing not just intra-shard transactions (across nodes within the same shard), but also across other shards within the MultiVAC network. One solution, employed by Zilliqa, is to use a global ledger that is shared by every shard. This will result in a secure (Zilliqa shards require around 600 nodes to reach its margin of safety) and synchronous ledger but at the cost of burdening the network with coordination costs. Another approach is taken by OmniLedger and any protocol building on it (Harmony, Emotiq) where its Atomix protocol processes transactions across shards. The Atomix protocol is new so will have the opportunity to be battle tested as Emotiq and Harmony go live. MultiVAC opted for a simpler solution. Its UTXO accounting comes into effect only when an account spends. The transaction will reside on the ledger within the shard the account is part of. This is different from Atomix where transactions are processed across shards. On a programming level, MultiVAC is simplifying its approach to reduce security risks and boost scalability.
Preventing Shard Spamming Attacks
One can think of shards as a subset of the overall network. The strength of a distributed network is its ability to absorb DDOS or 51% attacks given enough nodes. Shards will have much fewer nodes so inherently have a higher risk of these attacks. To avoid this, MultiVAC will employ dynamic shard adjustment where miners are randomly assigned to different shards. The mechanism for random assignment must also be secure to prevent attackers from coordinating.
MultiVAC Virtual Machine (MVM)
The MVM allows smarts contracts to run on the network without needing smart contracts to comprehensively run on every machine. MultiVAC's machine aims to achieve trustworthy computations on fewer machines than other smart contract platforms. MultiVAC introduces its Blockchain Instruction Set Computer (BISC) and its PoIE consensus. Currently the MVM supports the C programming language but has plans to enable higher level languages such as Java and Go.
Blockchain Instruction Set Computer (BISC)
BISC is a blockchain enabled version of RISC-V with 256-bit instruction processing, signature, and hashing instructions for blockchains. RISC-V, the predecessor to BISC, is an open source instruction set architecture (ISA). Okay what is an ISA? There's a lot of acronyms here! An Instruction Set Architectures (ISA) is just a way for software to communicate with the underlying computer processor. It's the guide to bridge software and hardware. If you're familiar with Intel's x86 chips then you no doubt have used the x86 ISA. MultiVAC is paving the way for modern computer chipsets to perfectly align with their network. Instead of a virtual Virtual Machine, the blockchain network's software can work with the nodes on the network equipped with BISC.
Proof of Instruction Execution (PoIE)
PoIE is MultiVAC's Virtual Machine consensus algorithm to verify honest computation of smart contracts. MultiVAC's design focuses on ensuring every node running a smart contract is expensive in terms of computation. Malicious actors wishing to cheat the system would essentially put their own skin in the game by expending energy due to their node needing to run an "expensive" computer resource.
Let's start over and try to simplify what I just said above. In computers, memory can be stored either on the CPU memory (also known as the computer's cache memory) or the computer's Random Access Memory (RAM). Cache is used to store program instructions and data meant for repeated use. Think of this as the computer's muscle memory. It should be quickly accessible. RAM can be thought of as the computer's primary store for memory. In cognitive terms this would be the place where humans access long term memories. Reading and writing to RAM takes longer and is therefore computationally more expensive.
PoIE forces miners to not only perform hashing but to also randomly and frequently read large amounts of data from memory. This encumbrance creates a bottleneck for specialized miners such as ASICs. If you recall from our Education Series on mining ASICs are highly specialized computers designed to execute one or a very narrow series of tasks. By introducing a speed bump in the mining process, specialized ASIC mining and malicious miners would incur a heavier cost.
dApp Developers Have Options
Decentralized Apps (dApp) come in many shapes and sizes. Some require high levels of security while others require high speed. Blockchains, to date, have tradeoffs to consider and none have met all the needs of every dApp. Ethereum has opted for platform grade censorship by optimizing for decentralization and security, making the tradeoff of speed. EOS traded away some centralization in favor of high speed. MultiVAC works within these known boundaries by having dApp developers submit their requirements. For use cases needing security the dApp would opt to choose a shard with a large number of nodes. For use cases needing higher throughput they can work with a less decentralized shard (fewer nodes).
At this stage, I am hopeful of this project. There is a lot here to unpack from a design perspective, at least from what I see in their whitepaper. I am in conversations with the team and hope to learn more about the project. Where they are with their development and what their roadmap looks like. I joined their Telegram channel as member number 18 and within 24 hours the group had swelled to over 3,000. At the time of this writing the channel is approaching 14,000 members. Clearly the team has not started a coordinated approach to their marketing but yet there is clearly hype for it.
I would like to see this project round into shape in a few areas. Token metrics obviously need to be released. I suspect advisory firms, token funds, and VCs are all clamoring for an audience with the team. This project will clearly grab the attention of these groups and for good reason, the project's whitepaper tells a compelling story. At the end of the day, these blockchain protocols all suffer from the same go-to-market issues. How will they attract developers to build on their ecosystem. Will the team commit to not only building this protocol but also maintaining it going forward. I see a lot of promise here but if they have any product to show it's well hidden behind closed doors for now. Unfortunately I cannot provide a final verdict but I believe this project will catch everyone's attention over the coming months. Stay tuned.
Quantalysus publishes blockchain research and analysis for the crypto community. Please follow on Twitter, Steem (please follow and upvote if you can – thanks!), Telegram channel (New!), and Medium to stay up to date.
My ICO rankings (anything above a 60 by the way I would seriously considering investing in… call me a harsh grader)
If you learned something:
