Zilliqa Project Update #16 — Sharding-Friendly Smart Contracts and Target DApps
Last week, we published our solution to one of the most challenging and exciting research problems in blockchains today — how to run smart contracts in a sharded network. We have addressed sharding (in a bitcoin-type payment model) and smart contracts separately in our whitepaper and other materials so far. Our newly-published solution marries both aspects of sharding and smart contracts and explains how this is done efficiently.
Previously, the Zilliqa testnet codebase only handled payment transactions and we had a separate testnet that supported smart contracts on a non-sharded architecture. In the last few weeks, we have finished implementing all the core features for handling smart contracts on our sharded architecture and will begin implementing that into our core architecture after comprehensive testing.
The explanation is highly technical, but we would strongly recommended it for anyone interested in how Zilliqa will be built. You can read the full blogpost here.
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)
Community Updates
Target Dapps for the Zilliqa Ecosystem
We have started featuring some of the #BuildonZIL Ecosystem Grant awardees on our Twitter.
Check out KZen Networks, who are working on a wallet based on applying Secure Multi-party Computation to distribute key generation and transaction signing to multiple parties with no change to the Zilliqa protocol.
Also check out Appbery, who are working on a Chrome extension for Zilliqa. They are a team of blockchain enthusiasts and developers based in Australia whose interests are programming (Dapp games, plugins and SDK development) and gaming (World of warcraft and FIFA).
We are always looking for great developers and teams to apply for our #BuildonZIL Ecosystem Programme and are specifically looking for teams developing Games as well as Financial Applications such as DEXes. If you have an interesting idea or are looking to develop DApps in these areas, do reach out to us on Gitter https://gitter.im/Zilliqa/.
Upcoming Events
September is going to be an event-filled month and we will be at several events across the globe.
1. Cluj, Romania
Date: 4 Sep 2018 10am-6pm
Event: Scilla Full-day Workshop — Learning how to programme in Scilla
2. Berlin, Germany
Date: 6 Sep 2018
Event: Dezentral
3. Beijing, China
Date: 5 Sep 2018
Event: PublicChain Odaily Developer Conference
https://www.odaily.com/post/5133227
4. Beijing, China
Date: 7–9 Sep 2018
Event: BlockChain Cases Center Conference
5. Hanoi, Vietnam
Date: 15–16 Sep 2018
Event: Cryptocurrencies and Digital Assets Dialogue
https://www.vietnamcryptodialogue.com/
6. Singapore
Date: 19–20 Sep 2018
Event: Consensus: Singapore 2018
https://www.coindesk.com/events/consensus-singapore-2018/
7. Singapore
Date: 19 Sep 2018 7–9pm
Event: Zilliqa x DMM.com x LayerX: Tools, Use Cases and New Initiatives for Blockchain Adoption
https://www.meetup.com/Ethereum-Singapore/events/253942745/
New Zilliqa Team Members
Han Wen Chua joins as Developer Relations Lead.
Han Wen is an idealistic libertarian seeking to help build a community of active developers on Zilliqa. He was an active member in the mining community during the early days. He previously worked in the Aerospace industry designing drones and passenger-to-freighter solutions. His other interests include 3D printing, geopolitics and pro-gaming.
Tech Updates
For the past two weeks, our tech team has been working on the implementation of event log/transaction receipt, valid transaction generator and difficulty adjustment of PoW and adding several features to Scilla.
Core Blockchain
Event/Log Transaction Receipt. A client (or an end user) can call a transition in a smart contract by issuing a transaction with appropriate parameters. Once the transaction reaches the network, nodes running the contract commit to the updated mutable state in their local database and the blockchain. However, as clients are external to the blockchain network and do not run contracts themselves, they cannot directly obtain the values returned by a transition. The purpose of events is to solve this problem. A smart contract may emit events that get recorded in each node’s local storage in the form of logs. By reading the logs, it becomes possible for clients to listen to events and obtain values returned by a contract.
We’ve designed events and transaction receipts for our system, as well as implemented the logic for supporting these two new features on the blockchain backend. Now it can interface with the output of Scilla interpreter and generate the JSON messages to the RPC server.
Valid Transaction Generator. On the transaction generation side, we have changed the way that the test transactions are generated and dispatched to the lookup node. The lookup node now is able to load pre-generated testing transactions and dispatch them to different shards at a controlled rate. In order to support the aforementioned change, we utilize persistent volume in Kubernetes that allows read-and-write from multiple pods and shares the volume between the lookup node and the transaction generator.
In the stress-testing scenario, the interface between transaction generator and lookup nodes is the transaction files containing serialized valid transactions generated. Lookup nodes will keep monitoring a directory of transactions files and fetch transactions from any unread files. The transactions are sent from genesis accounts to random-yet-valid wallet addresses. To maximize the benefits of using a transaction generator, the transaction — if from the same genesis account — are ordered according to their nonce, so that the generated transactions are less likely to be ignored by transaction ordering mechanism after being dispatched to non-lookup nodes. Lookup nodes use per-genesis-account counters to keep track of the nonce value of the last dispatched transaction from each genesis account. These values can be set when lookup nodes are started. It also has a set of parameters to control the sending rate in each tx epoch.
Difficulty Adjustment of PoW. We have also implemented the first version of difficulty adjustment for PoW. When we bootstrap the system, every node reads the difficulty parameter from the constant file. After that, every node will update the difficulty level at the start of the first transaction epoch of each DS epoch. At the beginning of each Directory Service (DS) epoch, every DS node will receive PoW submissions and record them. When a DS leader proposes a DS block, it will call CalcNewDifficulty to generate a difficulty that will replace the field in DS block and announce it to every DS backup node in the final block consensus protocol. Once DS generates the DS block with a new difficulty, the DS will broadcast it to shards. Every shard node will accept the new difficulty and use it to calculate PoW for the next DS epoch.
A summary of other enhancements on the core protocol side is given below:
- Maintenance of Persistence Storage Recovery Mechanism.
- Refactored serialization/deserialization of state delta for contract accounts to reduce the message size and save bandwidth consumption.
- Redesigned the transaction order verifier on shard backup nodes to guarantee the correctness of the order composed from the shard leader.
Scilla Interpreter
We have been continuing our refactoring work on multi-staging of scilla-checker that parses and typechecks Scilla contracts. The overall structure is now in place, and the remaining work is to separate parsing and typechecking of recursion principles for built-in datatypes and handling caching for libraries. Note that the goal of this refactoring is to ensure that each intermediate phase of scilla-checker works independently of each other, which will allow for user-defined checks to be implemented as separate phases and plugged in wherever the user wants them.
Apart from code refactoring, we have also been working on adding several features to the language. To start with, we have added support for Events at the language-level. Events in Scilla work similar to messages and can be created using the event construct. Events created during the execution of a transition are communicated to the interpreter invoker through output.json.
Another very important and useful feature that has been added to the language is the ability to sign and verify messages within a contract. The signature scheme that Scilla supports is Schnorr — the native scheme to sign transactions and consensus messages in the core Zilliqa protocol. The implementation interfaces our C++ Schnorr implementation with our OCaml Scilla interpreter.
With this, we now provide Scilla built-ins for generating key pairs, signing a message and verifying a signature. Support for Schnorr now enables several interesting contracts such as multi-sig wallet contract, contract implementing a state-channel among others.
In order to support signing messages of arbitrary size, we have now added support for a new data type ByStrX, which represents a hexadecimal string of X bytes. ByStrX now generalizes existing Address and Hash data types. For instance, Hash is now ByStr32, while Address is ByStr20. Support for Address and Hash data types have been removed from the language.
We have also released a Scilla contract that implements a non-fungible token à la ERC-721. Non-Fungible tokens are unique in nature and can be distinguished from one another. As such, they can be used to represent a unique digital asset on the blockchain. For example, collectible items such as CryptoKitties. The non-fungible token contract has transitions to facilitate token minting, transfer, and approval functions. Do try out the non-fungible contract in your application and let us know your feedback.
Last but not the least, we have also added support for integer division and modulo operations in Scilla.
Scilla Development Tools
In parallel to the core improvements to the Scilla codebase, we have also been working on development tools around Scilla. More on the Kaya RPC Server and an improved Scilla IDE is presented below:
Kaya RPC Server
We have modularized components within the Kaya RPC server. Modularization is necessary as it allows us to test different components in isolation and support future enhancements. With the modularization, we also introduced more automated test cases for Kaya RPC. According to the test coverage by Jest, 53.65% of lines in Kaya RPC are now covered under automated tests. We aim to increase coverage to about 80% before including test coverage as a criteria for branch merging.
Scilla IDE
We are working on revamping the Scilla IDE. The revamped IDE is being developed from the ground up, in order to improve developer experience and drive greater interest.
This new IDE is being rebuilt so that interested developers can dip their toes in Scilla on the web with minimal friction. For example, the new IDE will have several important Quality-of-Life improvements:
- A pseudo-file system backed by IndexedDB that allows developers to start off right where they stopped from a previous visit to the app.
- Automated state management, allowing developers to call transitions as though they were doing so on the actual blockchain, but with instantaneous feedback.
- Type checking is now available, and error messages are much more descriptive.
- A state tree viewer that allows browsing of a contract’s state in native JS types, with the option to view the raw Scilla-encoded types.
We are close to a release, which can be expected in a week or so. Stay tuned!
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, as well as full-stack and application developers. Please reach out if you feel you can bring value to the growing Zilliqa ecosystem!
Zilliqa in the News
Entrepreneur talks about how blockchains face the issue of scalability and mentions Zilliqa as one possible solution: https://www.entrepreneur.com/article/319014
Xinshu talking about blockchain scaling and Zilliqa on the CCN podcast: https://www.ccn.com/interview-zillaqa-ceo-xinshu-dong-talks-blockchain-scaling/
An older interview with the Arthur Falls was just published last week: https://soundcloud.com/arthurfalls/the-third-web-5-zilliqa
