Development Update — Road to Core 1.0 Mainnet: July 19, 2018

Hello Lisk Community!

Over the last week, the Lightcurve development team has been incredibly productive in our journey toward the release of Lisk Core 1.0.0 to Mainnet. On Wednesday, we released the Lisk Hub 1.0.0 release candidate, the first release candidate for version 1.0.0 which is compatible with the Lisk Core 1.0.0 API. We’ve also been successfully reaching out to a number of exchanges to inform them of the progress regarding the Lisk Core 1.0.0 release.

We also took many more progressive and necessary measures to ensure a smooth and secure migration of Lisk Core 1.0.0 to Mainnet. We’ve been working on a number of improvements and changes, which we have detailed below.

Lisk Core 1.0.0-rc.2:

Issue #2199: It is possible that after migration from Lisk Core 0.9.16 to 1.0.0, the legacy chain will still move faster than the newly migrated chain. This can happen if enough delegates continue to forge on the old chain after migration. There is also the possibility of someone performing a migration on that chain and revealing the chain to the already-running 1.0.0 network (which has a shorter chain). In order to prevent this, we decided to bump the block property version, which is also included in the process of generating a block’s signatures, so that it cannot be altered for existing blocks. After an in-depth discussion amongst our developers, we specified what should be the requirements for the block version property. And here are the results:

• Block property version is the key indicator to identify any changes in the block structure from here on forward and will be bumped each time hard forks are introduced.
• It is also directly connected with the protocol version that our software is implementing.
• The block version is a protocol-specific attribute, therefore should not be added to network specific configurations.

Following our findings, we decided to implement the following solution:

• We’re bumping the block version in Lisk Core 1.0.0 from 0 to 1.
• For this reason, only 1.0.0 and any upcoming releases can only process version 1 blocks.
• Therefore, all previous blocks (which are valid, and part of the blockchain) are now considered invalid by the 1.0.0 release, as they contain version 0.

In order to handle the historical tracks of those blocks and allow them to be accepted by the Lisk Core 1.0.0 release during the synchronization and snapshotting process, we will take the following steps:

• We will add an exception for blocks with version 0 for specific networks (Mainnet and Testnet).
• This exception will inform the software from up to which height blocks with version 0 are valid and should be accepted.
• The height will be the same as the height of the actual migration.
• The change with the block version property is considered to be a hard fork for both networks.

Issue #2154: The issue regarding disabling SSL support for P2P layer was already described in a previous development update. However, we decided it is important to include them in the Lisk Core 1.0.0 version because it can help to avoid issues for node operators that have their SSL option enabled.

Issue #2226: We updated our documentation to include guidelines for enabling and disabling forging on a node.

Issue #2227: During the configuration migration, we noticed that at times, an empty string was set as the configuration database username. We eliminated this issue by setting the database username to a default username lisk when left blank.

Issue #2208: Previously, the migration script was saving passwords provided by users for encryption of delegate passphrases as defaultPassword in the configuration (config.json) file. This feature is only used for development purposes and cannot be utilized in production as it compromises the entire encryption passphrase mechanism. For this reason, we’re no longer saving these passwords to the configuration file during migration.

Lisk Core 1.1.0:

Issue #1992: Logging related to peers being added/removed was inconsistent as they each maintained a different log level. We fixed this to ensure that logs related to peers have the same log level.

Issue #2148: The lack of a standard led to our logs being outputted in text format. This made it difficult to automate the process of analyzing the logs. We then decided to rewrite our logging mechanism to introduce new way of storing the logs:

• For the console output, we will use the text format due to ease of readability.
• Logs which are saved to the file will be in the JSON format making it easier to search for specific logs, collect information for debugging and use automated tools to analyze the logs. Example log entry:

{
“name”:”logs/lisk.log”,
“hostname”:”my.local”,
“pid”:48673,
“module”:”peers”,
“level”:20,
“msg”:”Broadhash consensus: 0 %”,
“time”:”2018–06–29T09:48:13.966Z”,
“src”:{
“file”:”/lisk/modules/peers.js”,
“line”:879,
“func”:”calculateConsensus”
},
“v”:0
}

• We will also use a standardized format and keys for more optimal searchability.

The logging version format change will break the compatibility for tools based on logs.

Next Steps

Now that the development phase is ready for Lisk Core 1.0.0-rc.2, this release will move on to the most important next step — the QA phase. The migration will be tested in the same manner as before the 1.0.0-rc.1 release. The 1.0.0-rc.2 Testnet release will be a hard fork due to the block version change described above. The date of the release will be announced when the QA round of this release is completed. The Mainnet migration process will remain the same as initially planned.

The first QA round for the 1.1.0 release was successful. However, we decided to adjust the distribution of the issues between both 1.1.0 and 1.2.0 versions. Completed issues from Lisk Core 1.2.0 were merged to the 1.1.0 branch and will be released and tested together. The current division for projects 1.1.0 and 1.2.0 under our GitHub projects clarifies which issues will be included within which release. With regards to the QA round for that release, we’re still waiting until the issues are completed on lisk-build and lisk-script following the significant configuration file change took place.

We look forward to updating you again next week!

As always, thank you again for the continued support!

-The Lisk Team