Zilliqa Project Update #25 — Gearing Up for Mainnet

Published in

Zilliqa — Official Blog

7 min readJan 8, 2019

Happy New Year to everyone in the Zilliqa community! We expect 2019 to be an exciting year for Zilliqa, as we release and refine our platform, continue to push the boundaries of blockchain innovation, and begin to drive adoption. This coming year will be about laying a strong foundation for what we believe will be the future of decentralized applications, games, security tokens, payments, and more.

As we inch closer towards the mainnet, we are wrapping any loose ends found during internal and community testing. Thorough checks of the core protocol design and ancillary components are being been conducted both on paper and in the code. As expected, during this process, we found areas for improvements, some of which have been implemented, while, others will be taken on post mainnet.

For instance, we found that it was possible in a relatively straightforward manner to improve the execution performance of smart contracts by 2x in certain scenarios. Another example is a recently appeared academic paper that found a possible attack on the signature scheme that we employ for the consensus protocol. Even though, the chance of success of the attack will be very low in our setting, we nevertheless decided to update our protocol to ensure that any future attack improving upon the current one can be averted.

We are also delighted to inform our developer community that we are gearing up fast to ensure that they will have all the necessary SDKs to develop applications on Zilliqa. With the help of the community, we will very soon have SDKs in languages such as C#, Python, Java and Go to cater to common industry requirements.

Community members who wish to run services such as explorers will now be able to run what we refer to as seed nodes. These nodes will not be mining on the network and hence the cost of maintaining them should be very low.

Before we jump into other tech and non-tech updates, here is a quick summary of the coming timelines for reference:

End Jan 2019 — Mainnet launch

We will be bootstrapping the mainnet carefully to mitigate attacks when hashpower is low.
Bootstrap phase: Miners will get mining rewards, but no transactions will be processed; bootstrap phase will automatically end when a set amount of hashing power and/or number of blocks is achieved

Q1-Q2 2019 — Token Swap window

Details will be released AFTER mainnet launch in late Q1. This will include the list of exchanges/custodians supporting the swap
We will have the token swap window open for several months to allow for enough time for the swap

As always, please feel free to connect with us in any of our social channels:

Discourse Forum: https://forum.zilliqa.com/
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)

Upcoming Events

We are back on the events trail in 2019, starting later in January:

Jan 19–20 — Singapore — Binance Blockchain Week

Jan 22 — Singapore — LongHash Incubator Event

Jan 23–24 — London, UK — Security Tokens Realised

Tech Updates

Our team continues to implement feature updates and bug fixes as the periodically relaunched Testnetv3 (codenamed Mao Shan Wang) brings us closer to the final configuration for the mainnet.

Updates to Seed Nodes

In the previous tech update, we introduced the concept of the seed node, i.e., a new node layer that accepts transactions from services and forwards to the lookup nodes for eventual submission to a shard for processing. This week’s update involves enabling a new seed node to fetch the latest state / blocks and thereafter join the network. Once it successfully joins, the seed node can begin its main function of accepting and forwarding transactions. Additionally, seed nodes are now able to fetch and verify historical data (e.g., transactions) from our storage on Amazon S3.

Updates to PoW Mining

As you may know by now, Proof-of-Work (PoW) mining in Zilliqa is performed on two levels of difficulty, which results in a node being assigned to a shard or to the DS committee. We have fixed two issues with the PoW mining that were observed during testing.

First, we noticed that the mining for the DS level used a nonce value that made the difficulty unnecessarily higher than it should have been. This was because the timestamp used for determining the difficulty was set to a time after the completion of shard-level mining. By using the same timestamp as the initiation of shard-level mining, the DS-level mining can be done with the same nonce and thus finish faster.

Another mining-related issue observed was for sharding structure validation in the situation where a node somehow made PoW submissions under the same public key but through different IP addresses. This can cause backup DS nodes to reject the proposed sharding structure by the DS leader. To avoid this situation, any node that makes a PoW submission will have its old entries in the DS nodes cleared out, so that only the latest IP address is associated with the node.

Updates to Transaction Processing

There were two recent updates along the transaction processing front. The first one involves the addition of a minimum difficulty threshold before transactions can be processed by the network. The difficulty threshold ensures that a certain level of security is first achieved before transaction processing is allowed to commence.

Additionally, the null address (i.e., 20-byte zero address) has now been reserved for the origin of our coinbase rewards. The amount held by the address is fixed at the bootstrap phase, and it is forbidden to make any transactions involving this address.

Updates to P2P Communication

To prevent against DoS attacks, we have added a couple of security measures to our gossiping code. First, if a node receives a gossiped message larger than some acceptable size, the message is rejected and the sender of the message is blacklisted to prevent it from sending more such packets. Also, we noticed that our cache for gossiped messages was not being cleaned up, and any malicious node could exploit this cache to quickly exhaust a node’s resources. We have now put in place the code to periodically remove entries from the cache that are several minutes old.

Scilla Interpreter

Have you ever wondered whether it is possible to take a transaction on the Ethereum chain and verify its validity on Zilliqa?

Good news! With the recent addition of ECDSA signature scheme to Scilla, we have come a step closer to this goal. The possibility of verifying ECDSA signatures in a Scilla contract will have important consequences in terms of building relay networks. Note that the Schnorr signature scheme (the one that is used in Zilliqa to sign transactions) is already supported in Scilla.

While conducting stress testing of the interpreter recently, we happened to notice that there were avenues to improve the performance of the interpreter. As you may know, the interpreter essentially takes an input state of a contract and a message that contains information on which transition to invoke (and the expected input parameters) and in turn returns a new state as an output. Now, if the interpreter generates a well-typed state (which it does by design), it is not necessary and rather wasteful to type-validate an input state as a part of interpreter evaluation. We instead observed that the interpreter was unnecessarily validating an input state for type safety and this validation was linear in the size of the state.

To this end, we wrote a new JSON parser without validations and with a focus on speed. This parser, for an ERC20-like contract performs two times better (for large input states) than the old parser. We are retaining both the parsers for now, with an option to switch based on a command line flag. The reason behind the retention is to handle the situations where the interpreter is run as a part of an IDE, wherein, it is possible for a malicious end user to supply an invalid state.

We have also finished the first stage of custom ADTs. Custom ADTs will allow smart contract developers to write a union of structs. For instance, the following declaration defines a custom type MyType with three possible constructors: Nothing (takes no parameter), Name (takes a parameter of type String) and AddrAmount (takes two parameters of type ByStr20 and Uint128).

type MyType = | Nothing | Name of String | AddrAmount of ByStr20 Uint128

For those familiar with C enums: enum sign { positive, zero, negative };, the corresponding code in Scilla can be written as: type sign = Positive | Zero | Negative.

The first stage doesn’t allow polymorphism or induction (hence no recursive data structure such as trees). The next step is to allow inductive ADTs. From a typechecking perspective it’s fairly straightforward, but we haven’t yet settled on an induction principle for such ADTs. We also need to estimate gas cost when using recursion over inductive ADTs.

Dev tools and libraries

With the new year and mainnet just around the corner, we’ve stabilised the JavaScript library’s core APIs and made a couple of security tweaks in preparation for the token swap:

Modified usage of Web 3 Secret Storage Definition. Zilliqa now uses hmac-sha256 for generating the mac, instead of plain sha256. Further, we additionally include IV and the cipher identifier in the computation of the mac, as opposed to the Definition’s DK[16..31] ++ <ciphertext>.
Modified address checksum that uses the 6 * i-th bit to branch instead of Ethereum’s 4 * i-th. This is primarily to prevent confusion/inadvertent mistakes by users of wallet applications.

On the same note, we have started the process of porting the JavaScript library to other popular languages, including Java, C#, and Python. This is to provide better support to exchanges and other dApp developers who may not be comfortable with a JavaScript API. Additionally, we intend to develop a simple daemon capable of managing private keys locally and signing payloads over RPC (socket or HTTP) in the coming weeks.