Zilliqa Project Update #20 — Progress in Core Tech Features, Scilla Safety Features

Published in

Zilliqa — Official Blog

8 min readOct 30, 2018

The tech team continues to make good progress as we move towards our mainnet launch, slated for Dec/Jan. This includes ramping up the testing phase of our platform and finishing up development on core features for blockchain functionality. On Scilla, we have been improving our development tools and are actively working on a new safety feature called “Cashflow Analysis” that can detect unaccounted funds in a contract, and hence detect any potential leakage of funds. We continue to work towards making Scilla a secure standard for smart contract development.

On the business front, we have been actively attending events around the world this month and spending a lot of time working closely with developers to get feedback. We were in Tokyo last week to run Scilla workshops with developers from DMM.com, LayerX, and Infoteria.

As we approach mainnet, we know that many of you are keen to learn more about our technical progress and marketing plans. Thus, we will be holding a live AMA on our Telegram channel on Nov 15 3pm SGT (7am UTC). We will share more details on our social media channels soon.

As always, to learn more about Zilliqa or to discuss technical aspects of the project, feel free to connect with us through any of our official channels below:

Telegram: https://t.me/zilliqachat
Slack: https://invite.zilliqa.com/
Twitter: https://twitter.com/zilliqa
Reddit: https://www.reddit.com/r/zilliqa/
Github: https://github.com/Zilliqa/zilliqa
Gitter: https://gitter.im/Zilliqa/ (Dev-related topics including the Ecosystem Grant)

Previous Events

October was a very busy month for us with events and workshops around the world. We rounded out the last few weeks of the month by attending and speaking at events in Barcelona, Tokyo, Frankfurt, and Jakarta. Notably, we conducted Scilla workshops in Tokyo with the developers from DMM.com, LayerX, and Infoteria.

*We worked directly with developers from LayerX and DMM.com to discuss the structure and benefits of building smart contract applications in Scilla.*

*Ong En Hui, Head of BD, speaking at Blockchain Jam in Tokyo.*

*Max Kantelia speaking at Crypto Economy World 2018 in Barcelona.*

*Juzar Motiwalla, Zilliqa’s Chairman, as a panelist at Tech in Asia Jakarta 2018.*

Upcoming Events

November will be a quieter month for us as we double-down on key technical developments and partnerships for our mainnet launch.

7–9 Nov — Hong Kong
Digital Media Asia 2018

9 Nov — Beijing, China
Zilliqa Meets Tsinghua — Scaling Public Blockchain and Mass Adoption in Gaming

12–13 Nov — Singapore
Blockchain and Cybersecurity Workshop
(Register here to attend our free Zilliqa Workshop on Secure Smart Contracts on Nov 13)

Tech Updates

While the core development team has now started dedicating some effort to further enhancements and to ramping up testing, we are primarily focused on finishing work on the key features essential to the blockchain operation. For this tech update, we will share about three of those new features, as well as one notable enhancement.

GPU Selection for PoW Mining

We continue to make enhancements based on requests from the developer community. One such request was to support GPU selection to allow the use of one or multiple GPU units together for the purpose of resource-intensive PoW mining. For instance, a user with 6 available GPUs can choose to configure one Zilliqa node to employ any combination of the 6 GPUs, or even launch multiple Zilliqa nodes with each node assigned to a specific GPU.

Gas Rewards

Another feature essential to a public blockchain is the distribution of rewards to miners from gas fees. In the version we have implemented, gas fees generated by processing transactions in the transaction epoch are accumulated into the total coinbase rewards. The rewards are then issued during the last transaction epoch — which we refer to as the vacuous epoch, as we forego processing of transactions at this epoch — just before the next round of PoW submissions begins. To support this feature, a new field representing the total gas fees for the shard has been added to the transaction Micro Block. The DS committee is then able to sum up the fees from all the micro blocks and perform the rewards distribution when initiating the coinbase rewards. For security reasons, a similar field has also been added to the transaction Final Block. This way, the gas fees for each epoch become part of the consensus over the Final Block.

PoW Ordering Verification

The DS Block consensus message announced by the DS committee leader contains the proposed sharding structure for the next DS epoch. If this structure is not vetted thoroughly by the backup DS nodes, it’s possible for a malicious node to pretend to be the leader and announce an invalid sharding structure. Since all DS nodes must recognize all shard nodes from their validated PoW submissions, it makes sense to use these submissions as the basis for generating and validating the sharding structure. The structure generation now follows a strict ordering based on the hash of the concatenation of the last transaction block and each node’s PoW result.

Fallback Mechanism

We have introduced a fallback mechanism to improve the robustness of the network and ensure that it always makes progress in spite of unforeseen stalls. When the entire system enters a stall for a significant period of time, the first shard in the system is tasked with reviving the network by assuming the responsibilities of the Directory Service (DS) committee. If, after this, the system still fails to make progress, the second shard proceeds to take over. This fallback mechanism is actualized by the candidate fallback shard performing consensus over a new block type — the Fallback Block — designed for this mechanism. Once consensus is achieved, the block is broadcasted to the rest of the network, and a new round of proof-of-work (PoW) submissions begins thereafter.

Scilla Interpreter

Cashflow analysis: Scilla was designed with safety in mind, and to this end we have been working on a new safety feature that can detect unaccounted funds in a contract and hence potentially detect leakage of funds. In more concrete terms, we are currently implementing a static analyzer of Scilla contracts that tracks the flow of money through the contract. We call it cashflow analysis.

The underlying idea of cashflow analysis is that some contracts use a `field` (a mutable state variable) to track what the contract’s money is to be used for. For instance, a kickstarter contract may want to keep track of how much money each contributor has put in, so that the money can be paid back if the target is not met. If the money tracked by the contract does not correspond to the balance of the contract (as tracked by the blockchain), something may be wrong, and the idea is to issue a warning to the contract developer if such a discrepancy is found.

Not all contracts track money in this way, so if a contract is found to violate the analysis, this will only give rise to a warning. Indeed, some contracts may want to keep track of more money than the current balance. For instance, a multi-signature wallet contract will keep track of all the transactions that have not been signed off, regardless of whether there is enough money in the contract to pay them all out.

The first prototype of the analysis is slated to be ready within the next couple of days. This prototype will however not be able to handle library functions, and will have limited support for `ADT`s. The full language will be supported later on by building on top of this prototype. To support cashflow analysis, we had to first implement the underlying infrastructure that will report warnings.

Performance experiments: During the last several weeks, we have been conducting extensive experiments to understand the performance of the interpreter and detect any performance bottlenecks. We are happy to report that the experiments have now been concluded. On the final leg of these experiments, we conducted a few more fine-grained ones to determine gas costs for arithmetic and hash operations. We also did a performance testing of Scilla libraries.

New map operators: We have added new in-place map operators that allow modifying and querying the map in a much simpler way. Note that in-place updates are only for `Map` fields. Also, pure expression treatment for `Map`s are still available via `builtin` map operations. In other words, all previous semantics for maps still exist including `put`, `get`, `remove` and `contains`. The new operators supported are given below:

`m[k1][k2][…] := v` : In-place update. If intermediate keys don’t exist, they are created.
`delete m[k1][k2][…]`: In-place removal of key. If intermediate key(s) doesn’t exist, no action.
`v <- m[k1][k2][…]`: In-place fetch. Returns `Some value` after indexing with keys, else `None` if any of the keys doesn’t exist.
`b <- exists m[k1][k2][…]`: In-place existence check. Do all keys have a value mapped?

Dev Tools

As always, in the run up to our mainnet, we’ve experimented with and made considerable changes on both the blockchain and client side, in addition to adding more features to the now-stable JS client. Some of the changes are listed below:

Exponential backoff for transaction confirmation polling, to prevent unnecessarily aggressive network usage in bandwidth-constrained client environments.
(WIP) Conversion of manual encode/decode functions to their Protobuf equivalents, as Zilliqa core is moving to gRPC/Protobuf as the main wire format.
Implementation of BIP-0032, BIP-0039, and BIP-0044 so that client developers can rely on `zilliqa-js` for all crypto-related functions instead of rolling their own. Note that `coin_type` is still undecided, and therefore uses a placeholder value for now.
Initial internal specification for basic smart contract log filtering, potentially through an additional RPC API, `GetLogs` (tentative).
Default encode/decode middleware for `HTTPProvider`.
And plenty of tests!

We aim to publish `0.2.0` of `zilliqa-js` this week, while continuing to push daily updates to the dist-tag `@zilliqa/zilliqa-js-*@next`, so that community developers can always get the bleeding edge if they wish. A further announcement will be made on Gitter when we publish on NPM.

Last but not the least, for Emacs fans, we have added a Scilla flycheck mode for Emacs. This integrates Emacs with `scilla-checker`, thus enabling error highlighting on the fly. Enjoy coding in Scilla!

Zilliqa in the News

A technical analysis of Zilliqa, our approach towards sharding, Scilla, and comparing that with Ethereum: https://medium.com/on-the-origin-of-smart-contract-platforms/on-the-origin-of-zilliqa-1b1afc344aa7

An article about formal verification in smart contracts highlighting Zilliqa and Scilla: https://blockonomi.com/formal-verification-smart-contracts/

Various other crypto articles about Zilliqa: