Zilliqa is the first public blockchain designed to implement sharding, allowing for linear scaling as the blockchain grows in size.
To date, scalability has been an issue for existing blockchain technologies.
Right now, Bitcoin can’t process all the demand for its network, and transaction fees have risen accordingly. The same goes for Ethereum where limited throughput means smart contracts can become gas-intensive. For instance, the popularity of Crypto Kitties significantly slowed Ethereum, showing the limits of the network.
Zilliqa fundamentally changes how a blockchain reaches consensus. Their sharding solution scales with the size of the network. Theoretically, there’s no limit to the number of transactions Zilliqa could process per second. Practically, however, depending on the number of nodes on the network, Zilliqa could process tens or hundreds of thousands of transactions per second.
Zilliqa also promises to support smart contracts. Running smart contracts on a sharded network is a major technical challenge for Zilliqa. In this article, we’ll explore how they’re approaching scalability for transactions and smart contracts. We’ll also investigate Zilliqa’s team and roadmap to see if they’re up to the task.
Solving the Scalability Problem
Blockchain has an inherent scalability problem. The more nodes you have on a network, the harder it is to reach consensus.
To illustrate the point, it’s helpful to think of consensus scaling in terms of people:
- With a small group of your close friends, it’s simple to make decisions. You may not always agree, but it’s straightforward to see how everyone feels.
- For a larger group of people, like an auditorium full of people, you could have people raise their hands to quickly vote. But it becomes harder to count, and you can’t be sure everyone is acting honestly.
- With groups of thousands or millions of individuals, you’ll need a more complex voting system that takes more energy. You also can’t be sure people are acting in good faith, and it’s hard to achieve finality – the sense that everyone has voted and there’s a clear answer.
While the analogy isn’t perfect, you can see how consensus gets more complicated the larger your network is. Consensus speed/quality and network size are inversely related. When one goes up, the other goes down.
Other solutions to the blockchain scalability problem focus on moving some information off-chain. Or, they seek to increase the block size, effectively establishing consensus on more transactions with each round of consensus. These solutions may work as a stopgap, but they don’t fundamentally fix the scalability problem.
To fix it, you’d need to change the architecture of the entire system so consensus speed and network size are positively correlated.
Zilliqa’s Scalability Answer
Zilliqa has found a way to process more transactions as more nodes join the network. It involves re-imagining the blockchain from scratch. Their new model implements a hybrid consensus protocol to grow the network’s throughput with every ~600 new nodes that join.
In theory, every 600 new nodes, Zilliqa’s throughput increases by dividing the work. In practice, there are issues with broadcast if the network becomes very big (over 1 million nodes). Still, 1 million nodes is an upper bound that we’re nowhere close to reaching. As of this writing, Bitcoin has ~11,000 nodes in operation. Ethereum, the largest network of full nodes, has almost 25,000.
Bitcoin and Ethereum’s networks of tens of thousands of nodes can still only process 3-15 transactions per second. In contrast, recent tests on private testnet (AWS virtual test) have shown that Zilliqa’s network has a throughput of 1,218 tx/s when 1,800 nodes are operating. Increase the number of nodes to 3,600, and Zilliqa’s network scales to 2,488 tx/s.
Sharding: Dividing Work Across the Network
How does Zilliqa accomplish this scalability?
They use a solution known as sharding. The Zilliqa protocol divides the number of mining nodes on the network into groups of 600 nodes. Each group is known as a shard.
For instance, in the testnet examples above, when operating with 1,800 nodes, the testnet divided itself into 3 shards. When operating with 3,600 nodes, there were 6 shards. As more nodes join the network, Zilliqa can further divide the network, creating more shards.
Those shards each process a fractional portion of the network’s transactions. In simplified terms, if there are 6 shards, each shard would process approximately 1/6 of the network’s transactions. The more shards there are, the more the network divides the consensus load between shards, keeping computing demands relatively stable.
Each shard processes its assigned transactions into a microblock in parallel with the other shards. At the end of the parallel processing period, known as the “DS epoch,” those microblocks get combined into a full block that’s added to the blockchain.
The DS Committee: Managing the Shards
For each DS epoch, several nodes are randomly selected to manage the various shards. This managing committee, known as the “DS committee,” directs the network. They decide which nodes are assigned to which shard. When new transaction requests arrive, the DS committee assigns the transactions to a shard for processing. At the end of the DS epoch, the DS committee assembles the full block from the microblocks the shards created.
Finding Consensus: PoW + BFT
Zilliqa uses a hybrid consensus mechanism. When you first start mining, you’ll have to complete a proof of work hash. PoW requires computing power that guarantees that a machine can only operate one node. As such, PoW helps Zilliqa establish identity. It makes it difficult for one bad actor to create multiple identities to overwhelm the network in what’s known as a Sybil attack. The network does not use proof of work for consensus, however.
After a node has proven its identity, it gets assigned to a shard. Within the shards, Zilliqa uses Practical Byzantine Fault Tolerance consensus. This is a higher-throughput consensus mechanism that has finality. Finality means that most of the nodes in the shard must agree on the miniblock. Once a block is confirmed by the shards and DS committee, it is the only block that can reference the block before it. There is no forking in a consensus mechanism with finality.
Zilliqa isn’t the first distributed ledger to implement BFT. NEO, Tendermint, and Hyperledger use versions of the proven BFT consensus mechanism.
Data Flow Contracts & State Sharding
Sharding transactions is fairly straightforward. You can easily assign transaction verifications to various shards. Each verification stands on its own. There shouldn’t be a need for much communication between shards.
The same is not true for running smart contracts and decentralized apps (dapps) on a sharded blockchain. The issue is smart contract actions often rely on checking other states, variables, and functions. Doing so would require lots of communication between shards. These messages back and forth would require bandwidth and processing power that would negate the benefits of sharding.
As such, Zilliqa’s contracts focus on data flow and functional programming, only. They don’t allow for checking, storing, or changing states. At least, not yet.
The consensus so far is that there isn’t a state sharding scheme that is secure and efficient. If you allow contracts to execute separately in various sharded states, there could be all kinds of potential attacks, challenges to reconciliation, and excessive cross-shard communication.
Ethereum, however, is currently working on a state sharding solution. It’s not clear how far along that initiative has advanced in its development.
That said, Zilliqa can still be used for dApps that require high throughput. Any dApp that needs transaction rates beyond what’s currently possible on other blockchains could find a home on Zilliqa.
A New Programming Language
With the goal of making functional programming more standardized and secure, the Zilliqa team has developed a new programming language known as Scilla.
Scilla separates state and function. It is a functional programming language that draws a distinction between the communication aspects of a contract – transferring funds or calling another contract – and the actual computational work the contract does.
The new language is not Turing-complete. This means it doesn’t support applications that need certain types of loops or conditional statements. However, its incompleteness allows it to be subject to formal logic proofs. This is important for security purposes. Proving contracts lets users know a contract is safe in a verifiable way before using it.
Scilla helps draw the distinction between functional contracts, supported on Zilliqa, and state-dependent contracts that Zilliqa can’t yet support.
The ZIL Token
Zilliqa has a token for its ecosystem. Similar to other dApps platforms like Ethereum or NEO, the ZIL token serves as mining incentive, gas for contract execution, and tender for paying transaction fees.
Initially, ZIL is an ERC-20 token based on the Ethereum blockchain. This is because the Zilliqa public main net has not yet launched. When it does, the ERC-20 token will exchange for Zilliqa-native tokens.
Zilliqa raised the equivalent of $12 million in ETH in a private funding round near the end of 2017. After the private round, the surging price of ETH meant that private funding originally worth $12 million was soon valued at the project’s hard cap of $20 million.
Having hit its hard cap, Zilliqa told its community that a public sale was no longer needed. Due to community interest, however, Zilliqa allocated 4445 ETH to a public sale in January 2018.
The ZIL token is currently on Huobi, EtherDelta, gate.io, and Idex exchanges.
The team behind Zilliqa is largely computer science academics and PhDs.
The CEO, Xinshu Dong, has a PhD in Computer Science from the National University of Singapore. He’s a cybersecurity expert, responsible for several national security projects in Singapore. His research has also appeared at reputable conferences and in journals.
Prateek Saxena is the Chief Scientific Advisor. He has a PhD in Computer Science from University of California, Berkeley. He now a professor of computer science at NUS.
Amrit Kumar is the project’s Crypto Lead. He’s a Research Fellow at NUS. He has a PhD from Université Grenoble-Alpes, France and an Engineer’s diploma from Ecole Polytechnique, France.
The Zilliqa’s advisory board includes the prominent figures in blockchain. They include Loi Luu, Co-founder of Kyber Network; Vincent Zhou, Founding Partner of FBG Capital; Nicolai Oster, Partner at Bitcoin Suisse AG; and Alexander Lipton, Founder and CEO of StrongHold Labs.
Scalability will continue to be a problem for blockchain and distributed ledger technologies. Zilliqa is an important project that’s tackling scalability head-on. The platform itself could prove to be an important development in blockchain. More broadly, however, expect to see Zilliqa’s open source breakthroughs in sharding technology come into use for other blockchain projects in the coming years.