Lisk Core's New Database Layer & 1.5.0-rc.2 in Testnet QA

Lisk Core 1.5.0 was released to Testnet and introduces a completely new database layer. A couple of API issues spotted during the Testnet phase resulted in a patch fix which is currently in the QA process. Lisk Elements 2.1.0.alpha.2, its third release, continues work on the integration of Elements’ libraries into Core. Lisk Hub 1.11.0 features a redesigned dashboard, as well as the wallet page. Lisk Mobile, on the other hand, announces the major release of 1.0.0 featuring a Bitcoin integration!

Want to know more?

By Lisk

28 Feb 2019

Generic-3@2x_0.png

Lisk Core

1.5.0 includes a brand new database layer — a 2nd release candidate for the Testnet fix is in QA.

1.5.0 was released to Testnet on Monday February 25th. Since then, we’ve fixed a few regressions spotted on the API level. Some of them were reported by community members on Lisk.Chat’s Network channel. We would like to thank the community for their fast response and help in identifying these bugs, in particular korben3, sexor and przemer. A patch for those issues, 1.5.0-rc.2, is currently in the Quality Assurance stage and is set for release on Friday, March 1st.

This release featured a considerable amount of changes, including acompletely new database layer. Given this, the API issues we have encountered posed a very minimal challenge for our development team in the controlled environment of our Testnet. Additionally, we found no problems with crucial network factors including block validation, or the forging process. In the future, we will create more automated tests in order to identify similar issues during development.

We can confirm that the API performance problem, which has delayed 1.5.0’s move to Mainnet, is now fixed. In order to properly solve the issue, we decided to take the longer route, which meant removing dependent transactions tables from databases and storing the transaction-related data directly in the transactions table in the new “asset” column. There are three key advantages to this approach:

  1. Performance gains while gathering transaction asset data — no more joins on other tables while querying on the data relevant to transactions; the view `full_blocks_list` was joining eight dependent tables (delegates, votes, signatures, multisignatures, dapps, intransfer, outtransfer, transfer) and is now completely removed.
  2. Database table clearance and a simplified relationship. The old structure required a pre-knowledge of the database. From now on, the dependant tables have been removed and their data was migrated to the same ‘asset’ field inside the transactions table.
  3. A unified way of storing transaction-relevant information. These will be consistently stored in the ‘asset’ column of the transactions table. A unified way of storing transaction-relevant information is extremely important for the future SDK development as custom transactions can have a different structure, depending on the additional information they require.

The described implementation of storing transaction-related data directly to the transaction table was originally scheduled to be completed as part of Lisk Core 1.6.0, however, we brought it forward as it also solved the API performance issue we encountered in 1.5’s QA phase two weeks ago.

1.6.0 is in the final stage of development and will vastly improve overall application performance.

During the last two weeks, we have significantly progressed with work on the new application architecture. Many of the steps of the Roadmap objective “Introduce a new flexible, resilient and modular architecture for Lisk Core”have been already finalized. The remaining steps are in the advanced development stage.

Storage Component now contains a minimal set of entities for a blockchain application, they are called ‘block’, ‘transaction’ and ‘account.’ All three entities contain only getters, which protects against unauthorized modifications of the blockchain storage logic by other modules.

HTTP module the second module after ‘chain’ is now extracted. The HTTP module isolates the business logic responsible for the public API only. It’s a big code refactor which makes the chain logic much thinner, but also will make it possible to run the public API module on a separate process. This will significantly improve overall application performance.

Before the development of 1.6.0 finishes, we need to conclude work on the new framework test suite, modules parameters validation. Additionally, the ability to run modules on multiple processes needs to be integrated from the Lisk Modular repository, as well as preparing the documentation for the new framework. We don’t foresee any major obstacles there.

1.7.0’s integration of Lisk Elements increases transaction processing efficiency.

In the Chain module of Lisk Core, we have started to use new transaction library developed in Lisk Elements. We are in the middle of integrating this specific module to put transaction processing in memory, which will significantly increase efficiency. Once integration of the ‘lisk-transactions’ library is done, we will start to integrate the transaction pool module from Lisk Elements to sum up the milestone “Improve transaction processing efficiency

Network module the third module after ‘HTTP’ we have begun to create. This module will be a thin wrapper of ‘lisk-p2p’ library, which is developed in Lisk Elements. We are finishing up the development of this Network module, and then starting to integrate into Lisk Core.

Lisk Elements & Lisk Commander

Lisk Elements 2.1.0 continues its integration into Lisk Core.

2.1.0-alpha.2 is the third alpha version of the new Lisk Elements release. This release includes minor bug fixes. As per the previous Lisk Dev Update, we are gradually integrating Elements’ libraries into Lisk Core.

Lisk Commander 2.2.0 completed work on a major node functionality.

As mentioned in our last Dev Update, 2.2.0 will bring enhanced node management functionality to Lisk Commander and addresses two main roadmap objectives:

In these objectives, we are going to implement various commands to easily manage a Lisk Core node straight from our Command Line Interface. These will include simple functions such as “node:install”, “node:start”, and “node:status”. Pull request for the “node:install” functionality has already been merged, which lays the groundwork for the second objective outlined above.

Lisk Hub

1.11.0 includes a new dashboard, and wallet page design.

1.11.0 was released on Wednesday, February 20th. This version continues the gradual rollout of our new UX/UI with a completely redesigned wallet page and a design update to the Dashboard page.

1.12.0 introduces a transaction filter and continues design rollout.

1.12.0 development is finished and will be released in early March. With 1.12.0, we will be introducing a new transaction filter. It allows you to filter your transaction by the transaction message. We will also continue the rollout of the new UI/UX design with a new ‘Request LSK’ page.

1.13.0 will lay down the foundations for the new custom extension module system.

1.13.0’s development is currently in progress. Apart from extending filtering by date and amount, this release will present an MVP for the custom extension system. This feature will allow developers to create their own modules for the Hub and have them included for additional functionality.

Lisk Mobile

P.S: Participate in a short 13 question survey to help us improve Lisk Mobile!

0.11.0 includes German language localization.

This version of Lisk Mobile was released today on February 28th. You can read about our decision to include this language option in the previous Lisk Dev Update.

After receiving online feedback, we have identified a release-wide issue which blocks some of our users from accessing the settings page of the new Lisk Mobile release. This issue affects only the users whose iPhone uses a language other than German or English. A fix was already submitted to the App Store and should be approved for download soon.

1.0.0 will feature a Bitcoin implementation.

For the second major release of our mobile wallet, we are refactoring most of the core functionality to facilitate multi-currency support, starting with Bitcoin. This will allow us to easily communicate with other blockchains, retrieve the accounts and transactions information and store them locally in order to present them to the user. The Bitcoin Integration in Lisk Mobile will allow users to manage their Bitcoin assets from inside the application by using the addresses derived by their mnemonic passphrase.

There were multiple reasons for implementing this feature starting with comprehensive research, including competitor analysis, and community feedback/requests to include multi-currency support. Additionally, Bitcoin is the most widely used cryptocurrency in the industry — by integrating it into our mobile application, we are inviting a much larger userbase into the Lisk ecosystem.

Thanks for keeping up with the latest developments here at Lightcurve. The next two weeks will see us progress further through various objectives on the roadmap as well as produce multiple releases across our product suite.