Following our earlier update on the upgrades being planned to enhance mainnet and smart contracts functionality, we would like to share a bit more about what the teams are working on implementing by 15 September.
Core Tech Updates
Shortly after the previous core tech update, the team upgraded the mainnet to the new Zilliqa version
4.8.0. This time, the focus has been on transaction processing — more specifically, smart contracts. This version, as alluded to the other week, contains some new mitigatory features to help keep the network in good condition when smart contract processing overloads the nodes.
The most significant of these features is the exponential back-off for the gas limit, which was covered in detail in the previous tech update. Every time a view change occurs as a result of non-consensus over the Directory Service (DS) microblock, the DS nodes halve the transaction gas limit. This allows the committee to gradually reach a state where a sufficient portion of the nodes is able to process the same number of transactions, thereby ensuring the success of the next round of consensus.
This version includes another important feature- the temporary backing up of processed transactions into each shard’s local storage. This is done by the shard leader for a limited number of transaction epochs to ensure we have copies of these transactions available in the worst case scenario, such as if the shard nodes are somehow unable to send these transactions back to the lookup nodes at the end of the transaction epoch. Alongside this feature, we have also configured the shard leader to upload those same transactions to our cloud-based AWS S3 storage, to add yet another guarantee of full data availability in all situations.
In addition, there are other improvements in version
4.8.0 not directly aimed at addressing the incident described in the previous update. For one, we have moved up the storing of smart contract states earlier within the contract creation, as opposed to when the contract is first called. This way, any user can already begin to check the transaction’s states immediately after the created contract is stored in the chain. Also, nonce and gas limit checks are now enforced earlier at the point of transaction creation within the lookup nodes, so that invalid transactions are more effectively filtered out before they even get dispatched to the shards.
With these newly deployed features, the core tech team will turn their attention to preparing for the major Scilla upgrade. We will, of course, take that opportunity to also push more improvements and fixes already in the pipe, so stay tuned for more developments on this next upgrade in the coming weeks.
On the Scilla side, we have been aggressively testing the Scilla inter-process communication (IPC) protocol scheduled to be released next month via a network upgrade. Since the IPC protocol is crucial for any smart contract to run on the Zilliqa infrastructure, we have designed tests to be as comprehensive as possible:
- To this end, we first started with basic unit testing of each communicating component of the IPC protocol run on a single local machine
- Following this, we designed test vectors to specially capture corner cases and also tested the IPC protocol with a testsuite of sample contracts that includes a crowdfunding contract, a fungible token contract, a non-fungible token contract, an auction contract, a simple dex contract etc
- After local testing, we moved to network-level testing where we created a private testnet and ran all the aforementioned tests on it.
As expected, the testing revealed a few bugs that needed to be fixed. For the last phase of testing, we are currently trying to replay every single transaction that ever happened on the Ziliqa mainnet on a fresh private testnet with the objective of comparing the final state of each account on the mainnet with the one on the testnet. The two states should match.
Given that the Scilla IPC will also require changing the way each node stores the account states, we also have to test the code that will be used for data migration from the old format to the new format. This test is underway.
To sum up, we’re well on track for the next network upgrade scheduled for September.
Last but not the least, amid the heavy testing, we also ran a performance test to understand what to expect post-network upgrade. As discussed in the last biweekly post, in the current network we observe a linear degradation of a contract’s performance as the size of its state grows. Our performance and profiling experiments show that with IPC, there is no linear degradation. This is illustrated in the following figure:
The Ledger team has begun the second round of review of the Ledger app to support mainnet ZILs. All feedback received so far has been promptly addressed by us, and verified by the Ledger team. Stay tuned for an update on this once the second round of review is fully complete!
For further information, connect with us on one of our social channels: