Development Update — Road to Core 1.0 Mainnet: August 9, 2018
Hello Lisk Community,
Over the last week, we mainly focused on testing Lisk Core 1.0.0-rc.2, and as you already know, the final quality assurance round for this release was successful. We announced the migration height and tagged the second release candidate as a Pre-release on GitHub. And lastly, the migration from Lisk Core 1.0.0-rc.1 to 1.0.0-rc.2 on Testnet network occurred today. It went smoothly and successfully! We’re very proud of this achievement, as it brings us very close to the long-awaited Lisk Core 1.0.0 release to Mainnet. The rest of this development update will review our progress over the last week.
Last issues closed in Lisk Core 1.0.0-rc.2
Issue #2283: A few days ago, we released Lisk Elements 1.0.0 — our general-purpose JavaScript library. We are using this library in almost all of our products, including Lisk Core. Lisk Elements is a dependency of Lisk Core, utilized in both test and production environments. To ensure that our products are properly aligned with one another, we’ve upgraded it to the latest version.
Issue #2280: During the most recent QA round, we detected that one of our tests was failing. We have already fixed this in 1.1.0, therefore we just backported the solution.
Issue #2246: This was one of the last steps before the actual release to Testnet. We needed to populate the blockVersions property in the exceptions file with the proper heights range, as the Testnet 1.0.0-rc.2 migration block height was announced.
Progress made on one of our next releases — Lisk Core 1.2.0
Issue #2272: We’re supporting several different types of transactions in our application:
SEND — A simple transfer transaction with optional message (up to 64 bytes long).
SIGNATURE — Register a second passphrase for extra account security.
DELEGATE — By sending a transaction of this type, you can register your account as a delegate.
VOTE — With this, you can cast and remove votes for particular delegates.
MULTI — We have built-in support for multisignature accounts, which is not very common with other blockchains. Executing such a transaction will transform your account into a multisignature one.
DAPP — Allows you to register your own decentralized application (dapp) on the Lisk blockchain.
IN_TRANSFER — Send funds to a dapp.
OUT_TRANSFER — Withdraw funds from a dapp.
The last two are currently disabled in Lisk Core 1.0.0. We’re actively researching a better and long-term approach for providing interconnection between mainchain and sidechains. Despite this, we’re still maintaining those transaction types in our codebase. We noticed that functional tests were missing for the asset fields of OUT_TRANSFER (type 7) transactions. We added tests to make sure that the response from the API returns the right asset data.
Issue #2194: Similar to above, but this time for the IN_TRANSFER (type 6) transaction. The property asset was not included in the API response for this type of transaction. We fixed it and added corresponding tests.
Issue #1788: In some edge cases, our application encounters a critical error that requires the process to shut down, while for some other cases, we intentionally shut down the process (for example, at the end of the snapshot creation). When the application needs to shut down, a special event is triggered — cleanup — to ensure that all pending operations such as block processing, database writes, etc., are completed. Previously, we didn’t distinguish between expected shutdowns and shutdowns caused by errors, returning 1 as the exit code in both cases. We fixed this behavior to return the proper exit codes — 0 for an expected shutdown and 1 for an unintended shutdown.
Issue #2236: We noticed that in some of our tests, expectations are missing assertions. This was due to incorrect usage of .equals(), which resolves directly to boolean (true or false). For example, expectation expect(block.reward.equals(‘0’)); evaluates to expect(true); which unintentionally lets the test always pass. We fixed such cases in the entire test suite to ensure that expectations always have assertions — expect(block.reward.equals(‘0’)).to.be.true;.
Issue #2198: In many areas of our codebase, we used the function name apply, which overrides JavaScript’s defined property Function.prototype.apply(). This is against best practices; it is also difficult to understand and can lead to other issues, therefore we decided to rename all occurrences of apply to applyConfirmed along with renaming undo to undoConfirmed (for consistency).
Next steps
We have already initiated the QA phase for Lisk Core 1.1.0. Although the release may seem minor, it contains significant changes, therefore, we must take every proper measure to ensure that everything will work as expected.
Regarding the Lisk Core 1.2.0 version, we decided to extend its development phase and include several additional issues. We’re progressing very well on this release. There are currently 7 open pull requests that are either ready or pending review. As always, you can track the progress of this release on the corresponding Version 1.2.0 project on GitHub.
Last but not least, we have one last issue remaining for Lisk Core 1.0.0 — #2245. It will be closed after we have determined and announced the expected height of Mainnet migration. If Testnet network remains stable over the weekend and no new issues are detected, we will make an announcement regarding the Mainnet migration height next week.
-The Lisk Team
Is this one of the first posts that you're seeing about Lisk? See more at Lisk.io or Github.