Hello Lisk Community!
Over the past week, the Lightcurve Development team has mainly been working on QA (quality assurance) for Lisk Core 1.0.0-rc.2. This is the most crucial process prior to the release to Mainnet, therefore we are making sure to take our time to ensure with utmost precision the stability of the product. We are also still communicating with many exchanges that will need to properly migrate to Lisk Core 1.0.0.
Lisk Core 1.0.0-rc.2:
We have continued testing the second release candidate for Lisk Core 1.0.0, performing several intensive rounds of QA. In the process, we have been able to identify several issues that required fixing before the actual release.
Issue #2199 — The logic of the isValid function that is responsible for validating the blocks’ version property was not correct. The function was returning an invalid result when the blockVersions object in the exceptions file contained only one entry. We had to rewrite the entire logic of that function. We also added more test cases that have proven that the above mentioned function works as expected now.
Issue #2249 — As mentioned in last week’s Development Update, this issue is very important for the security of the network and to ensure a smooth migration process. During the migration tests, we noticed some incorrect behavior — after the node restart at the migration height, the last block of the blockchain was detected as invalid, therefore deleted from the database. After extensive debugging, we identified that the cause of the misbehavior was the additional sorting of transactions performed during the loading of the last block from the database. Because the order of the transactions was different than the one from the time at which the block was created and signed, the block verification function generated a different payloadHash, resulting in an error. We carefully investigated why this sorting mechanism was added (which was introduced in 0.4.0 release) and finally decided to remove it. We also added more tests and additional logging in various places to guarantee appropriate behavior.
Issue #2269 — In our application, we’re using the Domain class, which encapsulates the functionality of routing errors and uncaught exceptions, to the active Domain object. We’ve noticed that when the Domain catches an error, it forces the application to exit with the error code 0. This is incorrect and causes the wrong behavior of PM2 (process manager for Node.js). We updated the Domain error handler to instead emit a graceful cleanup event.
Next steps
While part of our development team is still working on the Lisk Core 1.2.0 version, we’ve allocated the majority of our available resources to identifying and fixing the root causes of issues spotted during the last round of QA for Lisk Core 1.0.0-rc.2. Because of this, we have been able to quickly stabilize the state of the second release candidate. We are progressing tremendously and are currently in the seventh round of the quality assurance process. This round is all-inclusive, which means that we’re executing all of the extensive test scenarios against both Testnet (1.0.0-rc.1 to 1.0.0-rc.2) and Mainnet (0.9.16 to 1.0.0-rc.2) migrations at the same time. Thanks to this strategy, we will be able to reduce the waiting time between the actual testnet and mainnet release of Lisk Core 1.0.0.
Lisk Core 1.0.0-rc.2 is our best release candidate to date; it has successfully passed all of the hurdles created on Alphanet. As we are incredibly close to finishing the full QA cycle, we expect to announce the block height at which to perform the Testnet Migration within the next few days.
As always, thank you again for the continued support!
-The Lisk Team
Posted by us also on
Is this one of the first posts that you're seeing about Lisk? See more at Lisk.io or Github.