All you need to know about Zilliqa v.6.0.0

Greetings everyone,

We hope you found this week’s technical AMA informative. Further to our explanations and the discussions on Discord yesterday, we would like to summarise the latest on-goings from our Languages and Platform teams for your benefit.

As you already know — Zilliqa version 6.0.0 is now live — marking the last major upgrade of 2019!

In version 6.0.0, the objective was to improve the user experience in three ways:

1. Easier data access
2. Support for smart contracts with multiple messages; and
3. Faster block times.

I. We achieved easier data access through two new features: the pending transaction API and WebSocket.

• Pending transaction API: One of the common pain points when making a transaction on the network has been tracking its whereabouts between the point of creation and the arrival of the next Tx block. Even then, the transaction may also possibly not appear within the first few blocks, or not at all in certain situations. The challenge for the tech team for remedying the lack of available information in this situation has been how to improve visibility into the different components of the mainnet as the transaction goes through the different nodes for processing and confirmation. The end result is the addition of the new GetPendingTxn API that should effectively help users diagnose common issues with their transactions (for instance, incorrect nonce or gas).
• WebSocket support: Another long-standing challenge with accessing data on the mainnet has been the inefficiency it brings to dApp developers, who needed to periodically poll for new data on the chain. By introducing the WebSocket protocol into our API-servicing nodes, developers can now finally subscribe to specific events as a more efficient alternative to the polling scheme. This reduces the frequency of communication required between clients and the API nodes to retrieve the information requested. For now, we support two useful events through WebSockets: new Tx block generation, and event logs generated for a contract address.

II. Multi-message smart contracts: A message in the context of our smart contracts refers to the message field that is outputted by the Scilla interpreter after running a contract. When present, this field can allow the previously executed contract to effect another contract call or payment transaction. The limitation in earlier versions was that only a single such message could be returned by a contract call, allowing chain calls to be simply linear in nature. This forces contract writers to break down more complex contract chains into multiple transactions, which, of course, means that the completion time takes longer than necessary. In version 6.0.0, the mainnet supports multiple-message smart contracts in a depth-first search manner, effectively reducing the number of transactions needed to be created.

III. Faster block times: Until recently, Tx blocks in the mainnet have been generated at a rate no faster than 75 seconds. Heading into the mainnet launch, many of our timing parameters were set to conservative values for reasons such as stability of the network. For instance, with nodes that can be hosted theoretically anywhere in the world, it is prudent to set some communication windows for longer to allow for the successful completion of slower data transfers. This conservative approach of throttling the network has also allowed us to perfect the protocol during this mainnet’s nascent stage. Gradually, as we made all the improvements to the core protocol between version 4.0.1 up to 6.0.0, we decided it was time to push the envelope and start reducing several of these timing parameters.

For the last upgrade, these settings were: the transaction distribution time, the consensus announcement delay period, and the microblock receipt timeout. During team discussions, these were the parameters we felt posed the lowest risks to introducing unintended consequences to the mainnet’s operation. These were also the parameters that could bring potentially the largest benefit. The end result: we can now expect Tx blocks to be generated in as fast as 45 seconds on the current mainnet.

For Scilla, we added contract constraints to the language. Contract constraints are expressions that are evaluated when a contract is deployed, and which can be used to guard against contracts being deployed with illegal or nonsensical parameters.

For example, it makes no sense to deploy a multi-signature wallet which requires that each outgoing transaction requires more owner approvals than the total number of wallet owners. If such a wallet is deployed any funds deposited into the wallet risk being frozen indefinitely. A contract constraint could be used to perform a test at deployment time to ensure that the wallet has enough owners to satisfy the approval requirement.

Contract constraints provide functionality similar to a constructor in Solidity, although constraints in Scilla cannot be used to initialise the state of a contract.

The work on the recently announced Scilla compiled backend is progressing, with the focus now being on the generation of LLVM-IR. We have previously shared updates on the various lowering phases that transform the Scilla AST in stages, to be finally read for LLVM-IR generation. We are now able to translate most Scilla values (literals) to LLVM representation and will moving forward, will proceed with translating more Scilla expressions and statements.

For further information, please contact us on:

• Twitter
• Telegram
• Discord
• Reddit
• Github