Zilliqa Project Update #21 — Details on Jan 31, 2019 Mainnet Launch
We shared an important update last week about the progress of our mainnet launch, which we have fixed for the end of January 2019 — almost exactly one year after our token generation event.
The Zilliqa network will be a large-scale distributed network. This means it is very complicated with many moving parts, and has required us to achieve a level of engineering sophistication that goes way beyond Nakamoto-based protocols, such as Bitcoin and Ethereum. As scientists and engineers, we always aspire to implement as many new features as we can, and test and calibrate as thoroughly as possible. We decided on this deadline after a lot of deliberation to ensure that we were not making any major trade-offs in stability, decentralization, or security in order to deliver on this timeline.
Security of our mainnet launch is at the top of our mind. As discussed in our Telegram community a few weeks back, we need to ensure that our network is protected against attacks during the initial launch period when the hash power is relatively low. This is why Zilliqa will first be launched in a bootstrap phase, to ensure the security of the network. During the bootstrap phase, miners will get mining rewards but transactions will not be processed. This bootstrap phase will automatically end when a set level of hashing power we deem sufficient and/or a set number of blocks is achieved.
Mining on the Zilliqa network will be an important aspect of our system. We will share more details and step by step instructions for mining on Zilliqa towards the end of November, when we release Testnet V.3, which will enable public mining on our testnet.
For those of you passionate about Singaporean food, can you guess the codename of Zilliqa Testnet V.3?
For questions on mainnet and beyond, come join our upcoming AMA on November 15th 3pm SGT with Xinshu, Amrit, and Yiling.
Details and how to submit questions here: https://www.reddit.com/r/zilliqa/comments/9swvn6/ask_us_anything_zilliqa_ama_15th_nov_2018/
As always, please feel free to connect in any of our social channels:
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)
Previous Events
While our engineering team has been heads-down working on delivering our mainnet, the rest of our team has been actively driving blockchain education in events throughout Asia, and working with developers to grow the Zilliqa ecosystem. We are also happy to share that CoinHako, the Singapore-based exchange, has listed the fiat pairs ZIL/MYR, ZIL/IDR and –most importantly — our local ZIL/SGD.
En Hui and Yiling attended and spoke at Digital Media Asia in Hong Kong to help drive broader education of blockchain technology, including a presentation in front of a group of distinguished journalists and media outlets about the blockchain ecosystem as a whole.
Edison (Blockchain Application Developer) and Sophia (Business Development for China) presented on Scaling Public Blockchains and Mass Adoption in Gaming at Tsinghua University in Beijing.
We also held a Townhall (on https://gitter.im/Zilliqa/ecogrant) on the 10th Nov 2018 with our ecosystem grant awardees in the Wallet section. It was a fruitful session that sparked multiple ideas for collaboration. These ideas include the Zilliqa Enhancement Proposal (ZEP) and the consolidation of Zilliqa community-developed projects under a Github organization OpenZesame (https://github.com/OpenZesame). We will be continuing this Townhall bi-weekly to better involve our community developers in our ecosystem building, so look forward to future Townhalls!
Upcoming Events
November will be a quieter month for us as we double-down on key technical developments and partnerships for our mainnet launch.
12–13 Nov — Singapore
Blockchain and Cybersecurity Workshop
(Register here to attend our free Zilliqa Workshop on Secure Smart Contracts on Nov 13)
25 Nov 5pm SGT — Online
2nd Ecosystem Grant Awardee Townhall
(https://gitter.im/Zilliqa/ecogrant)
Tech Updates
As you can see from the roadmap we shared, our team is currently focused on testing, by way of unit test coding and running system-level tests. Meanwhile, we have also made three enhancements to existing features, and finished the first version of one new one.
View Change Mechanism Enhancement
If a round of consensus at the DS committee level stalls for a significant period of time due to an unresponsive DS Leader, the DS Backup nodes trigger a view change to resume the stalled consensus. In our initial implementation of this mechanism, the view change algorithm always selected the first adjacent node as the new candidate DS Leader, and obviously this predictable behavior posed a potential threat that malicious nodes could exploit.
To remedy this, we have now applied some randomization for determining the candidate DS Leader. Additionally, since the view change mechanism only gets activated after some time, the possibility existed that a DS Backup has lagged behind the rest of its peers. Thus, a pre-check needed to be added prior to going into view change. During pre-check, the DS Backup node queries the Lookup node for the latest available DS and Final Blocks. If the blocks indicate that the DS Backup has indeed lagged behind the rest of the network, the DS Backup skips doing view change and instead begins the rejoining process. Finally, as view change can occur in various complicated scenarios, we have made improvements to our unit test cases to induce multiple situations of consensus stalls.
Directory Service Micro Block (DS MB) and Final Block (FB) Consensus Merging
In the previous implementation, after the DS committee receives Micro Block submissions from each shard, two rounds of our consensus protocol occur. For the first round, the committee reaches consensus over its own Micro Block (i.e., the DS MB). Then, with all Micro Blocks now in hand, the second round of consensus is performed over the Final Block. We found that this two-round process could ultimately be merged into one, so we spent the past two weeks doing so. The obvious gain from this merge has been the reduction of the overall execution time for each transaction epoch, but then along the process, we are also able to reduce the storage requirement of the Final Block as well.
Upgrading Mechanism Enhancement
Recall that our upgrading mechanism works by having the node automatically download, decompress, and install our latest released package from GitHub at a targeted DS epoch. Since the initial version, we have slowly added more files into our release package generation, including our configuration constants and the initial list of DS nodes. Moreover, our upgrading mechanism requires a separate daemon program to relaunch the node after upgrading, and until now this program has been designed specifically for our internal Kubernetes-based test environment. For the actual deployment, we have now created a script version of the daemon, as well as a sample script to instruct users on its execution.
Node Recovery
Node recovery is one of the more significant features that we have completed in the past few weeks. If a node was terminated for any reason (such as to complete an upgrade) and then relaunched, it will read the persistent data stored in the machine’s database (data such as the DS committee members, the sharding structure, DS and Final Blocks, etc.) in a bid to recover its last known state and to begin resynchronizing with the rest of the network. The entire process of recovery relies only on the node’s own database (i.e., without unnecessarily querying other nodes) to prevent malicious nodes who repeatedly relaunch themselves from causing traffic in the network. Once all the data has been read out, a pre-check similar to the one described earlier for the view change mechanism is performed by the node. The node queries a Lookup node for the latest available DS/Final Blocks and begins the rejoining process if it discovers it has lagged behind the rest of the network.
Scilla Interpreter
Work continues on the cashflow analysis prototype. We now have support for polymorphism and all builtin ADTs except lists, and most importantly, maps. Also, builtin functions are supported, though library functions are not at the moment. Recall that the cashflow analyzer attempts to determine for each field whether the field is used to represent money in some way in the contract.
As an example, consider the fields goal and backers in the Crowdfunding contract snippet shown below:
contract Crowdfunding
(* Immutable parameters *)
(owner : ByStr20,
max_block : BNum,
goal : Uint128)(* Mutable fields *)
field backers : Map ByStr20 Uint128 = Emp ByStr20 Uint128
field funded : Bool = False
(* Backers can invoke it donate funds *)transition Donate ()end(* Allows the owner to get funds out of the contract *)
transition GetFunds ()end(* Allows backers to claim back money if the campaign is not successful *)
transition ClaimBack ()end
goal(Uint128) represents the target for the crowdfunding contract. This field clearly represents an amount of money, and the analysis is able to correctly identify it. The backers field is a map from addresses (ByStr20) of backers to the amount of money (Uint128) they have contributed. The analysis should also identify it as representing money, which it is also able to do.
In parallel, we have also started working on another tool that we refer to as the resource analyzer.
Note that executing smart contracts requires upfront gas to be paid to the miner. Depending on the transition being executed and the inputs to the transition, the gas consumed for executing it can vary. Resource analysis for Scilla is a static analysis (this means that no transition is actually run, but only the source code is analyzed) that provides an estimate of the gas that may be consumed for a particular transition, as a parameter of the inputs.
As a small (and simplified) example, the analysis can convey that the cost of processing a list of n elements is n * (cost of processing one element of the list). We have finished the design of the analyzer and have started to implement it. Stay tuned for the next update to learn more about our findings.
Dev Tools
As promised, we have finally released v0.2.0 of the Zilliqa JavaScript library, along with documentation. They may be installed via npm/yarn as follows:
- @zilliqa-js/zilliqa
- @zilliqa-js/account
- @zilliqa-js/contract
- @zilliqa-js/core
- @zilliqa-js/crypto
- @zilliqa-js/util
We recommend using the tag next (e.g. npm install @zilliqa-js/zilliqa@next) so that you will always install the latest version (with all fixes), usually published daily.
Note that this version does not work against the current public testnet. Developers looking to test the new version should instead use https://api-scilla.zilliqa.comn and https://explorer-scilla.zilliqa.com.
As always, please reach out to us with your feedback and bug reports on Gitter/Slack!
Zilliqa in the News
Two articles about Zilliqa and Scilla on TechRepublic. Both came from one interview with Amrit and Ilya:
- https://www.techrepublic.com/article/how-scilla-could-speed-up-blockchain-transactions/
- https://www.techrepublic.com/article/these-industries-will-benefit-most-from-optimized-blockchain-tech/
Zilliqa coverage in Japanese:
- https://crypto.watch.impress.co.jp/docs/event/1150479.html
- https://crypto.watch.impress.co.jp/docs/news/1152633.html
Some brief coverage of the upcoming Zilliqa testenet v3 and mainnet announcements: https://www.cryptorecorder.com/2018/11/08/zilliqa-zil-testnet-end-of-november-upbit-btc-market-listing-in-24-hours-its-a-good-day-for-zil-investors/
