Zilliqa Technical Update 21 May

— Smart Contracts Coming, Ledger Support for Native ZILs underway

Greetings everyone,

Earlier this week, we announced that smart contracts will be enabled on 10 June. With this, the company has delivered on one of our key technology objectives. What does this mean? Using smart contracts, customers building on us and facilitating transactions and communications in a more efficient, direct and accountable way — without the use of middlemen that might slow down or compromise the process. Given that the benefits of smart contracts that have been recorded frequently within the industry, we are committed to understanding business needs and develop our smart contracts platform accordingly. This milestone keeps us on track to getting financial services, gaming and media entertainment industries onboard to build on the Zilliqa platform.

To learn more, ask questions, and to join the Zilliqa community connect with us on one of our social channels:

Discourse Forum

Telegram

Twitter

Reddit

Github

Gitter

Core Tech

It has been quite an active month for the core tech team, who released three new versions of Zilliqa in this time. For now, we are keeping the mainnet on the current stable version 4.6.1 while the team is busy building up the content for the next version.

Apart from working on new improvements to our current feature set, we have also been performing more exhaustive testing and maintenance work as token swaps continue to take place on the mainnet and the date for supporting smart contracts draws closer. Additionally, we are taking this time to do some housekeeping and cleanup of existing code. Here is a quick rundown of what we have completed thus far for the next version:

• Should a Lookup node crash for any reason, we have a utility running as a daemon process that automatically restarts and resyncs the Zilliqa process in that crashed node. Continuing the trend of improving the Lookup nodes in the previous version, we have updated this utility so that external parties hosting their own Lookup nodes can also make use of it. This should effectively help reduce downtimes for any such community-hosted nodes
• Still on the topic of Lookup nodes, we have also re-coded our mechanism for indicating when an epoch has conclusively been completed. For a Lookup node, the completion should include the reception of all the microblocks and updated states. In the absence of this, there were potential timing-related issues that could impact some aspects of the protocol such as resyncing for other nodes
• Zilliqa maintains a connection counter for each peer that it interacts with in the network, and a maximum number of connections to each peer is enforced. In some instances such as consecutive failed connections, a node may blacklist another node to prevent abuse. Once blacklisted, a connection request to the peer is thereon refused. We noticed, however, that in these blacklisted cases the peer connection counter was incremented but not decremented after checking the blacklist. While a node can be removed from the blacklist in the next epoch, the incorrect counter management could mean the node can continue to be refused connection at some point. We have since corrected this code, and the fix should be available in the next release
• We have also introduced several changes in the code and build environment as part of our housekeeping efforts. We ran a static code check too — cppcheck — over the entire code base and fixed several issues found. We standardized and automated the addition of preprocessor guards inside our header files. The addition of the pedantic flag to CMake in our code compilation showed some additional syntax issues which we quickly resolved as well. Finally, we have moved our automated Travis builds from Docker containers to native Ubuntu 16.04, which is now supported by Travis. Expect more such work in the future as we continue to improve the quality of our code to meet industry standards and practices

Scilla Interpreter

Transitions in Scilla are currently able to share code through library functions, but library functions are restricted to being pure, i.e., they cannot access the contract state.

We have therefore started working on Procedures, which will allow transitions to share code that can access a contract’s state. This is especially useful when dealing with Maps, since using Maps in the pure part of Scilla involves a great deal of copying, whereas procedures will allow access to Maps in-place without first making a copy of the map.

Work on adding procedures to Scilla is ongoing. The design is now pretty much settled, so all that remains is implementation and testing. We are currently able to parse user-defined procedures, but any attempt at performing a procedure call will result in an error.

The main obstacle that has been overcome so far is how procedures should handle arguments of type Map. If they are handled in the same way as map arguments to library functions, then we incur the same performance penalties (because of copying), which is obviously undesirable. However, handling them on a call-by-reference basis (essentially passing a pointer to a map object rather than the object itself) causes difficulties in terms of verification.

We have settled on simply disallowing map arguments to procedures, since they are effectively unnecessary as long as procedures are restricted to being local to a specific contract. We may at a later stage introduce the possibility of procedure libraries, in which case we will also introduce a more sophisticated call-by-reference calling convention not just for map arguments.

Ledger App Development

One of our community developers has been working to enable Ledger support for native ZILs. Zilliqa’s core tech team provided their inputs and support as well. Last Friday, we were able to sign a transaction from Ledger Nano S and send it to the Zilliqa testnet. The transaction was accepted by the network, thereby bringing us a step closer to Ledger support for native ZILs.

The goal of this experiment was to conduct an end-to-end testing of the Ledger Nano application. With this, we were able to sign the first transaction using Schnorr signature scheme via a Ledger. Take a moment to appreciate the feat achieved. The ledger Nano S app development required support from the Ledger team too and we are very thankful to them for adding Zilliqa’s Schnorr signature scheme in the Ledger firmware.

We are now providing final touches to the app before we submit it to Ledger Manager for review. Post review, the app should become available for use in the developer mode.