Zilliqa Project Update #14

— Enterprise Partnerships, Scilla Made Open Source

The Zilliqa team is committed to building a secure, scalable and decentralized blockchain platform. Over the past few weeks, we have been making several enhancements to our protocol as presented in our whitepaper (released back in August 2017). For instance, we have merged the two PoWs (as outlined in the whitepaper) into a single PoW (more details to follow in this post). We have also replaced raw transaction data sharing with state-change sharing.

In light of the enhancements, we have made lately, the team had extensive discussions to review our mainnet timeline. We have come to the conclusion that we will need more time to ensure that the code gets properly tested by the core team, the community and last but not the least, established auditing firms. We will also be leveraging the additional time to:

  • Conduct thorough security audits
  • Prepare for and execute the token swap
  • Integrate with wallets
  • Develop toolchains
  • Bring more dapps onboard

We will be updating the community about the mainnet timeline along the way. At this stage, we are targeting end of this year or January 2019. We believe that it is in the best interest of the long-term future of the project and would like to seek your support and understanding.

On the business development as well as technology front, we continue to make steady progress. We have announced a partnership with leading middleware software provider Infoteria which will provide the ZIlliqa platform access to the Japanese enterprise market.

In addition, on the smart contracts front, we have open sourced Scilla, the secure-by-design smart contract language that ZIlliqa will be using at https://github.com/Zilliqa/scilla. We would like to take the opportunity to invite community members to experiment with Scilla and also help us further improve it.

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)

We are receiving more applications for our Ecosystem grant and look forward to sharing some of the selected applicants with all of you soon. If you have an interesting idea or wish to explore how you can implement your idea on Zilliqa, do reach out to us on Gitter https://gitter.im/Zilliqa/ .

Infoteria Partnership

On 2 August we announced a partnership with Infoteria, a leading enterprise software company in Japan (Listed on Tokyo Stock Exchange Section1: 3853). The partnership will enable enterprise systems to easily utilize Zilliqa’s next-generation high-throughput blockchain platform to power enterprise usage and adoption of Decentralized Applications (DApps).

Both Infoteria and Zilliqa will promote the Zilliqa platform on ASTERIA — Infoteria’s middleware product that currently has more than 6,500 enterprise customers and 41% market share in Japan. We will also be launching a series of initiatives to support the development of enterprise DApps based on the Zilliqa blockchain and ASTERIA later this year. Zilliqa will also develop a special connectivity adapter for ASTERIA so that enterprises can easily utilise the Zilliqa platform as below.

Xinshu with Pina, CEO of Infoteria

Community Updates

Past Events

Singapore Minister of Education Ong Ye Kung visited the Zilliqa office.

We held a Chinese name contest a while ago and the winning entry was 晶砺. We hosted the winner of our contest at our office.

Upcoming Events

Zilliqa will be participating in Consensus Singapore on 19–20 September so do drop by to visit our booth.

Tech Updates

For the past two weeks, our tech team has been working on various features, e.g., merging of PoW1/PoW2, GPU-support mining, improvement of stability, refactoring the current protocol to support our sharding-friendly smart-contract design.

In the previous implementation, we had two rounds of proof of work (PoW) to elect new DS nodes and new shard nodes. To reduce the complexity and unify the interfaces of the system, we have combined the two rounds of PoW into one round.

There is still a minimum-difficulty bar for all the candidate nodes to pass to be selected as shard nodes. At the same time, with the same set of randomness but having a larger number of 0s in the PoW submission will give a node a higher probability to be elected as a DS node.

Presently, every node can submit its PoW solution to the current DS shard. We let current DS nodes propose DS block and sharding structure to all the nodes. The new DS leader will join the DS committee and the oldest DS node joins one of the shards.

On the mining side, we’ve developed a library using OpenCL to support GPU mining for our Ethash-based PoW. Previously, we only had support for CPU mining for our testnet. With this new feature, miners can start to leverage their GPUs to mine test ZILs. In our current implementation which is mainly based on Zilliqa’s PoW class, we customize Ethminer’s mining algorithm, and use a wrapper function to wrap the mining part of Ethminer. We now support OpenCL-enabled GPUs, and soon will roll out support for CUDA-powered GPUs.

For stability, with every stability improvement pushed to Github, we immediately rolled out a new testnet to make sure those changes work well in large scale testing. Last two weeks, we also identified several memory and concurrency issues using the powerful runtime error detection tools, i.e., AddressSanitizer and ThreadSanitizer, and fixed potential security vulnerabilities. In the coming weeks, we will re-enable the recovery feature so that any data (testing tokens, user created transactions and smart contracts, etc.) will still be accessible across testnet restarts.

While we are pushing hard on the code quality, the refinement on building and testing facilities are also in progress. After reviewing the CI/CD workflow, we’ve removed the time-consuming parts and cleared the caching issues on Travis, making each automatic build more swift than before. This enables faster deployment by our developers after their code being built and tested, and reduces backlogs on Travis.

Towards the full support for our sharding-friendly smart contract design, we’ve implemented a bunch of new and dependent features. First, we developed an algorithm to order received transactions in terms of their gas fees and nonces.

Second, we brought forward the forwarding of transactions and state delta to the moment that the microblock consensus is done, to shorten the time needed to wait for forwarding messages at each node.

Third, we attached the state delta to the Microblock message when shard nodes send it to the DS committee. Then DS nodes aggregate all the state delta and generate a final state delta for each epoch. DS nodes attach the final delta to the Final block message, which will be broadcast to every shard node who updates its AccountStore.

More features and adjustments will be made to support the new sharding-friendly smart-contract design. Meanwhile, we’ll have a blog post to elaborate our design. A summary of the other enhancements is given below.

  • Fixed microblock’s DS block number.
  • Implemented missing transaction retrieval.
  • Fixed unprintable ascii characters (“block type” and “difficulty”) in log message.
  • Handled various view change corner cases.
  • Improved code documentation for view change.


We recently released the first version of a node.js based RPC server for testing and development of Scilla contracts on Zilliqa. We nickname it Kaya. For those who are Solidity developers, Kaya is similar to TestRPC or Ganache.

Kaya makes development of decentralised applications faster and easier. Instead of waiting for block confirmation on the chain through the Blockchain IDE, Kaya provides near-instantaneous response to developers, greatly expediting the development process.

Furthermore, developers have an option to enable the “debug mode”. The debug mode provides greater verbosity and provides logs to enable developers to debug their smart contract code from non-Scilla related errors (e.g., malformed JSON request, incorrect nonce, insufficient gas, invalid address, etc).

As Kaya runs locally, developers can now keep their code development process private and reveal their contract code to the public once it is ready for staging or production through the public blockchain or testnet.

Kaya supports a list of functions specified in Zilliqa Javascript Library. It does not replace any of the existing tools that we provide; instead it complements our existing set of tools to enable developers to create applications on our platform.

You may try our Kaya by cloning https://github.com/Zilliqa/kaya.

Scilla Interpreter

We have finished implementing the first version of typechecker for Scilla contracts. You may now try to typecheck your Scilla contract using the binary scilla-checker to be found in the bin folder of the Scilla project repository. We will soon be adding the typechecker to the IDEs.

We have also implemented checks for non-exhaustive pattern matches, which ensures at run-time that a pattern-match expression will not fail (unless a subexpression fails). The checks also include checking for unreachable patterns. These do not cause the contract to fail, but they do indicate that the programmer has made a mistake, since the pattern can never successfully match the value being matched against. The check is performed while building a decision tree describing the pattern match. The check is currently embedded in the typechecker, but will be moved to a separate phase at a later stage.

Some other minor changes done to the interpreter are given below:

  1. Removed lower-case-only restriction for hex values (addresses / hashes) in Scilla. Since the internal representation for hex values are strings, having both upper and lower case may lead to different results when the values are hashed. Hence, the change involved normalizing (in our case, converting to lower-case) internal representations after parsing (from either Scilla source or JSON).
  2. Made defining an in-contract library optional. Previously, the parser mandated that a library section be declared in a contract (even if empty).
  3. Improved verification of ADT literals (including type consistency) in JSON parsing. With this, many more errors will be caught during JSON parsing, and tests have been added to demonstrate this.
  4. Added structural type verification for literals. This traverses Maps and ADT literals recursively and verifies that they are properly formed types.
  5. We have also migrated the Scilla build system from jbuilder to dune.


We are pleased to announce a new member to the Zilliqa team: Ian Tan. Ian has an interesting academic profile. He has an LLB Law (Honours, First Class) degree from University of Bristol. While studying law, he decided to double-down on software and programming.

Ian is now a full stack engineer with a keen interest in developer tooling and smart contracts. With a background in law, he is particularly fascinated by the immense potential of smart contracts and blockchain technology in the realms of trade finance and international commerce.

Join Zilliqa!

We are actively interviewing and seeking to bring on high quality members to help Zilliqa achieve its maximum potential. We’re looking for programmers with deep C++ experience, compiler engineers, and associates and executives in business development. Please reach out if you feel you can bring value to the growing Zilliqa ecosystem!

Zilliqa in the News

The Infoteria partnership was widely covered in the Japanese media.