Zilliqa Technical Update — 2 July 2019
The core team released Zilliqa version 4.6.3 two weeks ago, which introduces changes made specifically for Lookup and Seed nodes.
Core Tech Updates
The core team released Zilliqa version 4.6.3 two weeks ago, which introduces changes made specifically for Lookup and Seed nodes. In this release, we have improved on the JSON response for GetTxBlock and GetLatestTxBlock by adding a BlockHash field, which is basically the hash of the returned transaction block. Another improvement is the ability to re-configure the location of the persistent storage from the previously fixed location (i.e., the current Zilliqa execution path).
Finally, this release also fixes one bug which involved the Lookup incorrectly processing block requests while its blockchain was not completely populated. This can happen in multiple scenarios, such as when the Lookup is still syncing up or recovering.
We are also close to completing Zilliqa version 4.7.0, which will contain all the new developments from the past month since version 4.6.1 was released. One recent improvement is a retry mechanism to allow miners to re-attempt submitting their proof-of-work result to the remote mining proxy, which can be helpful in the event of unstable network connections.
A slew of functional bugs will also be addressed in this release. For example, one interesting observation we recently discovered is that in some situations (e.g., poor network connections) a Directory Service (DS) node may fail to successfully propagate a change in its IP address to the entire DS committee. In the event of a view change where this node is identified as a faulty leader, the committee may fail to agree on the view change block to be mined since a fragment of the DS nodes are not aware of the IP change. The fix for this involves removing the dependence on IP changes for view change consensus by limiting the check to the public key of the faulty leader.
Stay tuned to our usual developer channels for the availability of this new Zilliqa release in the coming weeks.
Scilla Updates
On the Scilla side, as part of routine maintenance work, we have fixed a couple of bugs as well as added a new built-in to compute the address from a public key. After requests from contract authors for the support of exceptions in Scilla, we plan to implement exceptions in the coming weeks. While currently, there is no straightforward way for a contract to explicitly raise an error, having constructs to throw exceptions will provide a means for this.
Lowering I/O requirements: The Scilla interpreter currently executes as a standalone entity that, given a Scilla contract with input states, executes a transition to produce an output state. The input and output states are provided and read by the blockchain by means of JSON files. This mechanism has the drawback that, even when the semantics of a transition requires only certain parts of the state to be accessed (fetched / updated), the entire state of the contract is passed around in the JSON files. A simple example where this can go bad is contracts that can have large maps as their states, but only access a single key during a transition execution. The entire large map, which is mostly unchanged (and unread) is part of the state JSON files. We have identified, experimentally, that this can indeed be a performance bottleneck in such situations.
To overcome this problem with communication of large states, we have designed a closer coupling of the blockchain with the Scilla interpreter. Given that the interpreter runs as a separate process, and that we require to communicate only parts of the state that is needed (for reading or updation), and more importantly that these parts of the state that is needed can be known only at execution time, we have chosen the simplest solution of establishing an IPC (inter-process communication) channel b/w the Scilla interpreter and the blockchain processes.
Establishing a serialization mechanism for simple fields (such as integers or strings) is straight forward. While simple maps (i.e., maps with depth 1) can also be similarly handled, complications arise when dealing with nested maps. This is because Scilla allows entire map to be treated as immutable values, requiring an entire map or submap to be fetched or updated from the backend database. This requirement also necessitates a rehaul of our database schema to support efficient fetch and updates of nested maps. While fetching or updated entire maps (or submaps) will be expensive (in terms of gas), the schema is designed to be efficient for in-place map accesses.
We have now designed a serialization mechanism, with protobuf as the underlying container and have begun implementations to support this IPC base state accesses both on the Scilla side, as well as on the core blockchain side. In the Scilla interpreter, we have refactored the core evaluator to separate out a module for providing state access support. This state service module can be configured to use the current JSON file based accesses (which is useful for use in the IDE as well as for our internal testing) and also the upcoming IPC based accesses. In the coming weeks, we will setup an IPC channel and implement the protobuf based serialization and deserialization.
For further information, connect with us on one of our social channels: