A deep dive into Zilliqa’s plans to make blockchain safe, fast, and financially efficient

The Zilliqa team / Photo credit: Zilliqa.

For developers hoping to be part of the Web 3.0 or Dapp (distributed app) revolution, the ability of a chosen blockchain to scale and thereby allow their applications to reach Google-scale is a crucial issue.

Zilliqa is an ambitious startup that’s building a blockchain aimed at solving scalability issues that plague existing implementations. The Singapore-headquartered firm is a spinoff of a technology company Anquan.

A promising mix of established technologies used in novel ways, Zilliqa’s approach has the potential to deliver new possibilities without compromising on safety or developer experience.

Scalable, decentralized, secure

To date, Dapp developers have had to make unpleasant trade-offs. Choosing a Proof-of-Work (PoW)-based platform means enduring limited throughput. On other hand, high throughput blockchains based on Proof-of-Authority or Proof-of-Stake may force the developer to compromise on security and centralization. Zilliqa has demonstrably solved this quandary through its innovative approach to consensus and sharding.

See: The biggest problem with blockchain and how to solve it, illustrated

Efficient consensus

Zilliqa’s solution is unique: by applying an established approach known as Practical Byzantine Fault Tolerance (PBFT) in an innovative way, such trade-offs are unnecessary. First proposed by computer scientists Barbara Liskov and Miguel Castro, the algorithm just requires two-thirds of all nodes in a consensus group to agree on a given change in state before it can be committed across the entire network.

While the originally proposed procedure does away with expensive computations and the centralization problem, it results in a bandwidth bottleneck. To verify the identity of participants, every node in the group must transmit a message to every other node, leading to a quadratic complexity of O(n²).

Zilliqa therefore leverages a EC-Schnorr multisignature scheme – also under active consideration by the Bitcoin core team – that effectively reduces the size of messages by an order of magnitude, dramatically reducing bandwidth cost.

Divide and conquer

While crucial, the consensus algorithm is only part of the equation. As long as consensus and verification take place in series, the time required to add a block to the chain generally remains unchanged or even increases linearly with respect to the number of nodes in the network.

This can have a potentially detrimental effect on a given network. Most importantly, Dapp developers who seek to deploy complex smart contracts will face a significant handicap in the form of transaction fees (aka gas), which can be exorbitant on Ethereum during times of high activity, such as the token sale of a popular token offering.

In this regard, the state-of-the-art solution is sharding. In principle, sharding is simple: divvy up the work and process it in parallel. However, it is notoriously difficult to implement in practice; doubly so with the added constraint on centralization shared by public, permissionless blockchains. In fact, Zilliqa is the only publicly available implementation of a sharded blockchain to date.

Image credit: Joshua Lim

The backbone of Zilliqa’s sharding implementation is known as the Directory Service Committee (DSC). The DSC, which is made up of nodes that form a substantial percentage of the network, acts much like the brain in Zilliqa’s architecture. It assigns transactions to shards (groups of mostly-siloed nodes that process chunks of transactions and computations independently of other shards in the network), then aggregates, verifies, and commits their output (microblocks) in the form of a TX-block. The latter is so labeled because Zilliqa relies on two distinct blockchains: one for transactions, and the other for network leadership.

To avoid bottlenecks inherent in systems that force state changes to be verified in series, it’s important that changes in the Zilliqa blockchain are asynchronously propagated back through the network once the DSC has completed its work. This act eventually brings all shards and their member nodes into a consistent state without requiring nodes to ‘block’ while waiting on others to confirm them.

This approach has clearly paid dividends in practice. Despite a shorter development cycle, Zilliqa was able to deploy a working proof-of-concept, which has performed impressively. During a stress test demonstration by the Zilliqa team, the network was able to sustain a consistent throughput of ~2,000 tx/s with 1,000 nodes (four shards of 250 nodes each), giving an average TX-Block time of approximately one minute (given that a TX epoch on the testnet appears to have a per-block transaction limit of 9,000). The company reports that its platform was previously tested internally with 3,600 nodes and managed ~2,488 tx/s.

Security

Given the significance of DSC, Zilliqa has invested heavily in tightening its implementation. As it is made up of incentivized nodes that have successfully mined a DS-block by solving a ethash-based PoW, the DSC and its state is tracked by its own blockchain (alluded to earlier, and known as the DS chain), and is therefore effectively protected from would-be Sybil attackers. A similar process is used to determine shard membership. It’s also important to note that PoW is used in Zilliqa solely to establish node identity in the DSC and shards, thus leaving transaction throughput (tx/s) largely unaffected.

Additionally, problems of centralization are sidestepped by ensuring that DS-blocks, which encode metadata and guarantees about the DSC and its membership, are mined at a consistent rate. In this way, malicious/Byzantine nodes that make it into the DSC are prevented from holding up or otherwise harming the network for an extended period of time, as the DS chain provides a transparent guarantee to the network that the DSC, and crucially, its leader, is constantly re-elected through a combination of PoW and PBFT processes.

To get a better understanding of this procedure, it can be readily observed in action using the block explorer. At the time of writing, at intervals of approximately 50 TX-blocks, the DS epoch counter is incremented and a new DS-block is added. Its header contains several fields of particular importance: leaderPubKey, minerPubKey and signature.

As the leaderPubKey is invariably identical to the minerPubKey of the previous DS-block, it follows that the DS leader indeed changes at the beginning of each DS epoch. Secondly, since the signature field also differs, it is certain that the DSC’s members, whose signatures are aggregated and used to generate this field, have changed.

The miner of the 80th DS-block became DS leader in the 80th DS-epoch, during which the 81st DS-block was mined (above).

Screenshots from Zilliqa’s Block Explorer.

Thanks to this combination of efficient consensus and effective parallelization, the Zilliqa blockchain displays unparalleled throughput without deal-breaking compromises for most use cases. However, it must be pointed out that since Zilliqa is eventually consistent (as discussed earlier), it is a CP database according to the CAP theorem. As such, while uncommon, the Zilliqa blockchain may be unsuitable for applications that require all nodes to maintain identical state across the board at all times.

Smart Contracts

Scilla: Killer feature?

While Zilliqa leverages established technologies that its competitors are actively developing, its Smart Contract layer – arguably its most captivating feature – uses unique semantics in combination with Scilla, an innovative domain-specific language that promises to enable superior security and developer experience.

Unlike Solidity, Scilla adopts a decidedly functional model and is intended as an Intermediate Representation (IR) – think C/C++ to LLVM – for higher-level languages. Once compiled to Scilla, the program will finally be compiled to EVM-esque bytecode. For now, the Zilliqa team plans to support Solidity, although, in theory, it may be possible to target other languages as well.

In Scilla, Smart Contracts are composed of transitions , which are partially analogous to methods. However, they are guaranteed to terminate and may not manipulate state that is not local to their owning contract, or call other transitions. For this purpose, Scilla provides continuations, which – with some important caveats – can be used to express effective procedures.

This in fact makes Scilla Turing-incomplete, as a transition can only manipulate its owning contract’s state without involving other contracts or third parties. At first glance, such a design may seem odd for a language intended to be used in an inherently stateful environment. Deeper examination, however, reveals that it isn’t so, as the trade-off facilitates several important features that are either impossible or difficult to implement in a Turing-complete language.

Firstly, using an IR paves the way for the Zilliqa team to embed Scilla in Coq – a formal verification language that should, in theory, allow the correctness of Scilla contracts to be ascertained automatically.

Secondly, as previously mentioned, Scilla’s design enforces safety and clarity at the language level by forcing developers to be explicit about the demarcation between pure and effectful procedures. To affect another contract, a transition must explicitly pass a message in the form of a continuation in tail position, which amounts to a CPS-style callback – a pattern that most developers familiar with web frameworks such as Express.js would be intimately acquainted with.

As such, the design of Scilla makes the behavior of contracts more predictable and arguably more robust than Solidity. Since a transition can never invoke a continuation in its body and must pass control to the runtime, Scilla should provide strong protection against DAO-type reentrancy attacks without burdening the developer with adhering to unenforced best practices.

While marginally lacking the expressive power of a Turing-complete language, Scilla makes up for it by providing formal guarantees about smart contracts that should go a long way toward making Zilliqa-based Dapps both safe and computationally (and therefore financially) efficient.

Sharding Contracts

Because of Scilla’s clever design and its state-based execution model, sharding can also be extended to the concurrent execution of custom Smart Contract-based computations.

This area of Zilliqa’s blockchain still needs to be thoroughly fleshed out by the team and is not yet available for testing. But in theory, Scilla’s emphasis on encapsulation, semantic clarity and message-passing should assure developers that a given transition or continuation will always be safe to run, given that any in-scope state can never be affected by any other concurrently executed procedure. This is a huge advantage, as those who have dabbled in any form of concurrent programming will know.

While it may not be immediately obvious, the upshot of this proposed combination of sharding and the language-and runtime-level guarantees by Scilla is – if successfully executed – that extremely computationally heavy Dapps (such as neural networks) can run on the Zilliqa blockchain while maintaining throughput, safety, and speed. It’s a feat unimaginable on any platform currently in production.

Conclusion

Although Zilliqa is not yet production-ready and currently implements a subset of the functionality proposed in its whitepaper, existing results are encouraging, and at least prove that the team’s approach to consensus and sharding is a viable one.

Nevertheless, much work remains to be done. Fully implementing the proposed smart contract layer will require much thought and effort in order to properly handle the intermediate state for distributed parallel computations. Additionally, building a production-ready toolchain for a built-from-scratch compilation target like Scilla will no doubt be a herculean effort.

Crucially, while Zilliqa works on its platform, incumbents like Bitcoin and Ethereum will certainly not be resting on their laurels. However, if the team is able to execute its vision and put its product on the market smoothly and quickly, it might just be enough to join the pantheon of blockchain royalty.

Here’s all our sponsored coverage about Zilliqa.

This post A deep dive into Zilliqa’s plans to make blockchain safe, fast, and financially efficient appeared first on Tech in Asia.

from Tech in Asia https://www.techinasia.com/zilliqa-technical-deep-dive
via IFTTT