Hey Liskers,

Another fortnight has passed and Lightcurve development teams have a number of updates to share with the Lisk community. Lisk Core 1.5.0 was released on Mainnet and includes a brand new database layer while 1.6.0 is in the final stages of development. Lisk Elements 2.1.0 is finalizing integration of three libraries into Core 1.7.0. Lisk Commander 2.2.0 has implemented the majority of new node functionalities. Hub 1.12.0 continues the rollout of its new design and introduces extra passphrase length option for additional security. Mobile continues work on its second major release of 1.0.0 which will begin multi-currency support, starting with Bitcoin. Want to know more? Read on.

Lisk Core

1.5.0 was released to Mainnet on March 6th and includes a brand new database layer.

After the second release candidate to Testnet — 1.5.0-rc.2, we have spotted no further regressions, therefore we released 1.5.0 to Mainnet. This means that the following objectives from the “Architecture and Design” phase of our Development Roadmap are now completed:

“Use a consistent and informative versioning scheme” — its purpose was to create a versioning scheme that differentiates the protocol version from the software version. Peers now have a new header attribute called `protocolVersion` additionally to the previously existing `version` attribute. The `version` attribute now only represents the software version keeping `MAJOR.MINOR.PATCH` notation defined by the Semverspecification. The `protocolVersion` attribute represents the protocol version and follows the `H.S` notation proposed by the LIP0007, where `H` represents the number of hard forks and `S` represents the number of soft forks since the last hard fork.

“Implement extensible data persistence model” — this objective’s purpose was to create a flexible and extendable data persistence model that could be used across the whole application using the same predefined interfaces. To achieve this, a new storage layer was implemented exposing a common interface for every entity and making it extendable by adding new functionalities when required. That means now the storage layer is decoupled from the application and can be easily replaced if the same interfaces are implemented. Each entity implements the CRUD operations and has a list of filters auto-generated based on the field types. The filters are very flexible and allow to mix `AND` and `OR` combinators by using objects and an array of objects. You can read more about this here.

1.6.0 is in the final stages of development, continues work on the new modular architecture.

Over the last two weeks, we focused on cleaning the code after the vast changes from “Introducing a new flexible, resilient and modular architecture for Lisk Core” roadmap objective, which has resulted in 20 issues closed. Adapting dependent projects to the new modular structure has already been finished.

After the Storage Component was isolated to only contain getter operations, we decided to export all the storage functionalities by centralizing the interface to provide modules with all the Storage utilities and avoid them to access the component files directly. This way modules can extend and utilize Entities, Adapters, Error messages and Utilities already implemented by the Storage component.

More refactoring was done in both `Chain` and `HttpApi` modules seeking for a better separation of concerns and decoupling the code when possible. With the new modular architecture, each module should have a clear responsibility and only communicate with other modules through messages using channels.

Improvements on how packaged scripts and configurations are used were also finalized. Some of the scripts and configuration files under the `packaged` directory in the LiskHQ/lisk-scripts repository were directly related and used in Lisk Core to manage binary builds and configure dependencies. These included Redis but needed to be downloaded during the build process. Now they were moved to the Lisk Core repository under the folder `build/target/` keeping it in the same place as it is used. The other scripts in LiskHQ/lisk-scripts will still stay separated from Lisk Core repository as they are used to bootstrap a Lisk Core installation and are (mostly) version independent.

Work on the three remaining steps for “Introduce a new flexible, resilient and modular architecture for Lisk Core” continues and is expected to finish within the next week. Those three steps are:

1.7.0 development is in progress, will conclude integration of Element’s libraries.

The work on the configuration with the overall aim to make Lisk Framework extensible, accessible and easy to use by external developers is moved to Lisk Core 1.7.0.

Within it, a GitHub milestone “Improve transaction efficiency” is still in progress. We have mostly finished implementing this feature by using Lisk Elements libraries, and now are fixing the tests and adding the missing feature back to Elements. A parent issue “Integrate @liskhq/lisk-p2p module in chain module” is currently being worked on. We have created a new network module which wraps the @liskhq/lisk-p2p library, and are currently replacing network usages in the application.

We are also preparing a significant change regarding the structuring of 1.7.0 and the following releases. We are planning to announce the change in the next Lisk Dev Update.

Lisk Elements & Commander

Lisk Elements 2.1.0 is finalizing integration of three libraries into Core 1.7.0.

As stated above, we continue to focus on the integration of three libraries into Lisk Core 1.7.0. We have fixed several bugs and added improvements including minor interface changes with the feedback gathered during Lisk Core 1.7.0’s integration so far. This work will continue until the integration to Lisk Core 1.7.0 is completed. The following libraries will now be used in Lisk Core:

Transaction extends the functionality for Core to be able to process transactions and lays down the basis of custom transactions for the future SDK.

extends the functionality for Core to be able to process transactions and lays down the basis of custom transactions for the future SDK. Transaction-pool where transactions are held prior to being written to the block.

where transactions are held prior to being written to the block. P2P lays down the basis for LIP-0004 by creating the initial version of the library that is compatible with the current Core.

Lisk Commander 2.2.0 is nearly finished implementing new node functionalities.

This upcoming version of Commander has been making great progress for Roadmap objectives “Add node dependency/management/configuration commands” and “Add node migration/upgrade commands”. We have finished implementing main features including “node:install”, “node:uninstall”, “node:start”, “node:stop”, “node:status” and “node:list”. Now we are working on finishing the last two commands — “node:upgrade” and “node:migrate”. Once we finish the work on the last two commands, we will go back and improve the UI/UX of the commands. The production version of 2.2.0 is planned to be released with Lisk Core 1.7.0.

Lisk Hub

1.12.0 introduces a transaction filter, new passphrase length option and continues design rollout.

1.12.0 was released as planned on Wednesday, March 6th. With this version of our network dashboard and blockchain wallet, we have introduced the following changes: