The Three S’s of Zilliqa
With several completed Zilliqa projects under my belt, now I feel comfortable calling myself a Zilliqa developer. From that vantage point I can see that that the time is right for an independent take on Zilliqa. From my experience, there are three main features that makes Zilliqa stand out from the pack of other crypto projects I’ve worked with.
They are: Sharding, Schnorr Signatures and Scilla. Each has something transformative to offer Dapp developers. Together they make for a system that is specialized in the secure execution of smart contracts, and I consider it finally ready for business.
I have to commend the work the Zilliqa team has done, but it is not that unexpected - the project was conceived in academia and they moved into the crypto industry, bringing with them an appetite for rigor that already sorts them into minority group within crypto. They consistently follow standards and produce maintainable code, engage with the academics and publish on related subjects around their discipline and ultimately they keep pretty close to their roadmap. This is in stark contrast to the most common status among other next-gen smart contract platforms, which often have show-stopping caveats that forces developers to wait for the core protocol to catch up to outstanding promises before you can confidently ship Dapps in production.
To date I’ve worked on four Dapps, two of which are in the final steps to production. Over that time the tooling has improved dramatically, and is at a point where generalist devs can be up and running with the chain via a familiar JSON-RPC interface on day one. The recent release of Zil-3 and the corresponding Zilliqa 7 mainnet upgrade take care of many of my final complaints before recommending Zilliqa for new dapps, and now I feel comfortable recommending the platform for certain projects. In order to prepare you to understand why this milestone is so exciting, I will spend the rest of this post diving into what I think separates Zilliqa from the pack in the first place.
Sharding
Sharding is Zilliqa’s bread and butter. The team behind Zilliqa have a claim to being the first to successfully apply the principles of database sharding to a permissionless blockchain. Certainly since their launch there have been challengers sprouting up, but a quick survey of the likes of Quarkchain, Harmony and Elrond does little to convince me they are anywhere close to delivering on their promises.
Zilliqa’s unique approach to sharding is to break apart the two major motivations of reaching for consensus on a ledger; ordering of events and sybil resistance and selecting a new cast to fill these requirements. pBFT and PoW are not new concepts in cryptocurrency applications, but relying on a Beacon chain and a set of seed nodes to distribute the execution of chaincodes to consumer hardware by only running PoW once an Epoch is an ingenious way to tie together several problems with one brushstroke remiscient of TrueBit. This is only meant to be an overview, so I invite you to dive deeper into this in their whitepaper and the Zil-3 writeup for understanding the recent seed node development.
Schnorr Signatures
Schnorr signatures are in truth what prompted this post, they are astonishing and we are only beginning to understand what they mean for cryptocurrencies because the patent expired after Bitcoin’s initial design. Bitcoin did implement Schnorr signatures a while ago to fix their transaction malleability problem, but they have far more to offer than just than that. Compared with the transaction and block signing method relied upon by Ethereum and many others, Schnorr signatures are very friendly to the concept of a multisignature. If the blockchain is the most over-hyped tool to reach notoriety due to Bitcoin, Schnorr signatures are probably its least-appreciated (note that neither originated with the Bitcoin project).
For example, Schnorr signatures allow for aggregate signatures that don’t increase in size, making certain kinds of wallet-based voting finally practical. Beyond that can form the basis for novel BNS and BLS signing implementations that share in Schnorr’s efficiency gain. The addition of Schnorr to Bitcoin is how Taproot is able to function — it relies on MuSig to act as nodes off the mainchain that resolve a state summary on-chain.
Scilla
Finally we have reached the third course of this meal — The Smart Contract Intermediate-Level LAnguage, or Scilla for short. Scilla is what truly ties all this together. In order to have execution of smart contract chaincode across the shards, Scilla constrains developers so that the intitial effort to create the contract is higher, but once complete the contract can be relied upon with far more certainty than a Solidity contract, for example. The Scilla language is a typed variant of OCaml stripped of much of the imperative and OOP features, forcing developers to work within the Functional paradigm, and relay their intentions more clearly to the type-checker. The result is I believe we will see a far lower rate of incorrect contracts and ‘hacks’ compared to the competition. This is important to all participants in the network because buggy contracts reduce confidence across the ecosystem, and can cause congestion on-chain as we’ve seen many times on the Ethereum network.
Of course, this is only relevant when the ecosystem has more dapps and smart contracts running. For an up-to-date look at this evolution in process, you can refer to the Zilliqa Reference Contracts. As far as token standards, at the time of writing there is a Fungible (ERC20) contract, one for NFTs (ERC721), an accepted draft for Metatransactions (written by yours truly) and the beginnings of an ERC-1155 multitoken standard.
My experience translating Solidity to Scilla will be the topic of another upcoming blog post. For now I hope you enjoyed this celebration of all the hard work that the Zilliqa team and the community has done to put Zilliqa forward as a top-tier alternative for new dapps and those disappointed with the scalability or security offered by their current platforms.
