Development Update — Road to Core 1.0 Mainnet: August 16, 2018

Hello Lisk Community,

As you may already know, we recently announced the block height for the Lisk Core 1.0.0 migration on Mainnet. In case you missed it, the height is 6,901,027 and the actual migration will happen on Wednesday, August 29, no sooner than 11:00 AM CEST.

Together with the imminent Mainnet release, our development team recently reached another great milestone — merging more than 1,000 pull requests! We’re very excited about this and look forward to many, many more.

In regards to the Lisk Core 1.1.0 quality assurance (QA) phase — it is almost complete. Scenarios were executed successfully without the detection of any issues. We’re currently only awaiting snapshotting and syncing from scratch tests, as those take longest to complete.

Over the last week, the development team made significant progress on one of the next releases — Lisk Core 1.2.0. Here is a brief overview of the work we’ve done:

Issue #2278: Lisk Core uses config.json as the main configuration file. The structure of this file can change in every release, as we’re constantly adding new features and improving the codebase. However, users need to have this file customized and because of this, we’re maintaining the update_config.js script, which performs an automated migration of config.json, preserving all the users’ custom changes. This script was not flexible, as it was only able to perform the migration from one version to another. In order to solve this inconvenience, the update_config.js script was rewritten to support the migration between any versions. This masterpiece was designed and implemented by one of our talented backend developers, Nazar Hussain. Now it is very easy to migrate your configuration. For example, you can do it from version 0.9.16 to version 1.2.0 by running the following command:

node scripts/update_config.js ../config.json 0.9.16 1.2.0

Issue #2261: One of our dedicated community members, Simon Warta, reported an issue regarding inconsistent data returned between the P2P layer endpoint rpc.status and API endpoint api/node/status. Some data, such as height and broadhash were not updated in the rpc.status response. This happened when the node was in the synchronization process. We fixed this issue by updating the node’s headers after every block, regardless of whether or not the node is in the synchronization process.

Issue #1733: We extended the API node/status endpoint by adding two useful properties:

• currentTime, which returns the current time of the node in milliseconds (unix timestamp)
• secondsSinceEpoch, which returns the number of seconds that have elapsed since the Lisk Epoch (2016–05–24T17:00:00.000Z)

Issue #2237: To extend Lisk Core’s flexibility and compatibility with platforms not natively supported by us, we’re utilizing Docker. We have a special repository — lisk-docker — in which we keep configuration files for Docker. But because we’re supporting multiple networks with one installation from Lisk Core 1.1.0, we decided to move all Docker-related files into the lisk repository and following that, archive lisk-docker. This pull request resolved the last step of this process — moving docker-compose.yml file.

Issue #1822: Behavior of the checkConfirmed function from logic/transactions module wasn’t following best practices and resulted in confusion. The function returned an error when the transaction was confirmed (it exists in the database). We refactored it to return the actual result (true or false) and an error only when database query fails.

Issue #2274: We removed the following tests out of our integration test suite:

• stress tests — this involves sending a massive number of transactions (of various types)
• sync only — testing block propagation with disabled block broadcasting
• broadcast only — which tests block propagation with a disabled syncing mechanism

The reasoning behind these removals is that we already have these tests as part of our QA process, and they are already automatically executed during nightly builds.

Issue #2273: To keep our test suite reliable, we renamed some of the test directories, realizing that their original names did not accurately reflect their functionalities. The following changes were made:

• integration to network
• system to integration

Issue #2225: Previously, we were supporting only a subset of configuration options to be set through the ENV (environment) variables. This approach was not flexible; for example, they were not enough to run the Docker image. For that reason, we greatly extended support for ENV variables. You can check which variables are supported in Lisk Core 1.2.0 by reading the Command Line Options section of the corresponding README.md file.

Issue #2254: We had another issue reported by community member Corsaro. He discovered a bug in the processing of signatures for transactions sent from multisignature accounts. In some cases, like for example an overloaded node, this bug resulted in duplicated signatures added to transaction object in the transaction pool. After investigating, we discovered that the problem lies in the processSignature function of the multisignatures module and it was caused by the execution of only a part of its logic via balancesSequence (tasks queue responsible for synchronous processing of balances-related operations). We rewrote the processSignature function, also adding a complete test coverage for it. We’re proud of our native support for multisignature accounts, as this is not very common with other blockchains. In the future, we’re going to further improve the implementation and fix issues related to the propagation of signatures.

Next steps

While we wait for the Lisk Core 1.0.0 migration on Mainnet, we will continue to work hard on the upcoming releases. There are plenty of issues left for Version 1.2.0 and as always, you can track the progress of this release on GitHub. Both Lisk Core 1.1.0 and 1.2.0 versions, while minor, are still very important, as they bring about many bug fixes and great improvements. Having a stable and reliable network is not only fundamental but mandatory for achieving our goals.

-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.