Another month has passed and Lightcurve development teams have a number of important updates to share with the Lisk community. Here are the main takeaways from this month:

Majority of QA testing is finished for Lisk Core 2.0.0 and Lisk SDK 2.0.0.

Lisk SDK will be deployed in 3 releases (2.0.0, 2.1.0, and 2.2.0) with 2.1.0 allowing custom transactions.

Lisk SDK 2.2.0 includes an extra step to minimize a huge chunk of technical debt which will improve dev speed and bug detection.

First tests of the new transaction processing efficiency show an increase in throughput with blocks including a bigger number of transactions. More tests and performance optimizations are needed.

Implementation of Byzantine Fault Tolerance for Lisk began, and is expected to be included in 3.0.0.

Lisk Commander 2.2.0 will introduce five new commands to help with deployment and management of new nodes.

Three new P2P features from LIP-0004 have been implemented.

We’ve added an extra segment called Lisk Builders to include all of the tools and solutions built by community devs for the Lisk ecosystem.

Lisk SDK Gitter channel is live, join the dev discussion today.

Sayler8182 released a Lisk Core API wrapper for Swift.

Corbifex created a genesis block creator for the Lisk Alpha SDK phase.

TonyT908 has built 14 tools for the Lisk ecosystem.

Endro went full time working on Lisk Discovery, a platform for viewing community-built tools, or collaborating/connecting with other builders.

Lemii went full time working on ScanBlocks, a passive income rewards reporting for the Lisk Ecosystem.

Lisk Hub 1.17.0 was released, includes performance and UX improvements.

We have decided to stop bi-weekly releases for UI products in order to focus on bigger user-facing features such as BTC support, or Trezor T integration.

Lisk Hub 1.18.0 beta includes Trezor T support.

Lisk Mobile 1.1.0 includes a welcome screen to introduce the BTC integration in UI and shake-to-activate discreet mode.

Want to know more? Read on.

Lisk SDK

Majority of QA testing is finished for Lisk Core 2.0.0 and Lisk SDK 2.0.0

A big chunk of work related to the syncing and verification process of the blockchain with Testnet and Mainnet has been completed. QA for Lisk Core 2.0.0-alpha.11 and Lisk SDK 2.0.0-alpha.10 is currently in progress. Partial roadblocks identified in those releases described in issue #3687 have now been fixed. The outstanding issues including the low consensus issue are being investigated by our development team.

Alpha SDK’s main features will be deployed over 3 consecutive releases

As pointed out in this Twitter thread by Max on May 27th, the Alpha SDK will be rolled out over three releases. These will include:

Lisk SDK 2.0.0 — the official release of the Lisk SDK on GitHub. This version will be used internally to create Lisk Core 2.0.0. You can use it to generate a blockchain without custom transactions.

— the official release of the Lisk SDK on GitHub. This version will be used internally to create Lisk Core 2.0.0. You can use it to generate a blockchain without custom transactions. Lisk SDK 2.1.0 — this version will enable custom transaction support. Even though it’s the second release of the Lisk SDK, it represents the launch of the Alpha phase.

— this version will enable custom transaction support. Even though it’s the second release of the Lisk SDK, it represents the launch of the Alpha phase. Lisk SDK 2.2.0 — this release will include efforts to reduce technical debt, including removing circular dependency, usage of callbacks in favor of async/await and third party libraries.

Below you can find more information about Lisk SDK 2.1.0 and 2.2.0.

Lisk SDK 2.1.0 enables you to create custom transaction types

The version SDK 2.1.0 contains issues that enable the creation of new transaction types and enhance the developer experience. These changes to the Alpha SDK interface do not interfere with the QA phase of Lisk Core 2.0.0, which means that both can be completed faster and should be released in short succession.

With Lisk SDK 2.1.0, developers will be able to create proof of concept blockchain applications

As part of the initial Alpha SDK release — Lisk SDK 2.1.0, developers will be able to create proof of concept blockchain applications implementing new use-cases by creating and registering new transaction types through a single NPM package — `lisk-sdk`. Lisk SDK 2.1.0 exposes the interfaces to do so in an organized way and hides the underlying blockchain complexity.

Alongside polishing the developer experience of Alpha SDK, we took the effort to explain the functionalities of the Alpha SDK. We are working on the documentation and example applications showcasing the use of Alpha SDK for simple use-cases. You can track our progress with the documentation atLiskHQ/lisk-docs.

Adding and tackling a technical debt objective to the roadmap will improve dev speed and bug detection in Lisk SDK 2.2.0

We have been developing the Lisk project for a while. This means we have accumulated some technical debt as any company developing software. In normal circumstances we prefer to return those debts bit by bit. This time though we decided to focus on solving a big part of the debt by adding a new objective to the current roadmap phase and target to release included in Lisk SDK 2.2.0.

In order to reduce technical debt, our three main goals are to:

Remove circular dependency Remove usage of callbacks, and use async/await Reduce usage of 3rd party libraries

Completion of this objective will increase the speed of the development, will make the code easier to understand, and will allow us to detect bugs even before the QA phase. Also, after this objective, we are planning to consistently reduce and control the technical debt.

Network stress tests being conducted to benchmark TPS for Lisk Core 2.0.0

Stress testing for `type 0` transactions was performed comparing Lisk Core 1.5.0 vs. Lisk Core 2.0.0 on a single node running devnet configuration, not taking into account network latency.

In general, both versions performed very similar with 100 transactions per block or less. The recent improvements related to the transaction processing efficiency in 2.0.0 allowed bigger blocks to be filled with up to 500 transactions. However, increasing the amount of transactions included in a block resulted in missing more slots.

Mind that benchmarking transactions per second is not yet complete as we need to gather more data and run more tests to be able to come up with consistent and measurable conclusions. You can find more info about this issue #3627.

Everything except multisig transactions behaved as expected during QA phase

As part of the ongoing QA phase of Lisk Core 2.0.0, we stress tested the network for all transaction types. All but multisignature transactions behaved as expected. The tests revealed that the delegates forged with non-full blocks, with maximum 17 transactions for multisignature registration transactions. After executing the same scenario against the older version of Lisk, we found that this bug is persistent in version 1.6 of Lisk as well.

Our research showed that transactions and signature propagation in the network are sub-optimal for multi-signature transactions. This issue can be tackled in a future minor release. So, we have created an independent issue to tackle this problem after more research.

Byzantine Fault Tolerance (BFT) implementation began on May 16

Work has started on the implementation of our BFT functionality. We’ve started planning for implementation details of critical functionalities like the interface design for the new BFT class or PriorityQueue holding the BlockHeaders. Also, internal research for deciding on the design flow of the Fast Chain Switching mechanism was kickstarted on Wednesday May 29th.

We have begun to draft PRs including #3722 for adding `maxHeightPreviouslyForged` and `prevotedConfirmedUptoHeight` which forms the basis for blockheaders and BFT in general. Work has also been started on implementing the fork choice rules with PR #3725 that will help Lisk Core determine how to choose between the `Fast Chain Switching Mechanism` or `Block Synchronization Mechanism`. You can read more about the benefits of implementing BFT for our blockchain here.

Lisk Commander 2.2.0 will introduce 5 new commands to easily manage node installation

Lisk Commander 2.2.0 now comes with a new set of commands to deploy and manage a new node installation. We expect this version of Commander to be included with the Lisk SDK 2.0.0 release. You can find more info about this in issue #3516

The new node commands are:

lisk core — help — Retrieves the overview of all possible commands for `lisk core`.

— Retrieves the overview of all possible commands for `lisk core`. lisk core:install — Allows you to install Lisk Core, download the snapshot, insert the snapshot in the database, and start the freshly installed node. By default, this will fetch the latest public release of Lisk Core and download the `mainnet` snapshot. Extra options are provided to install a custom build of Lisk Core or specify a different network like `testnet`. At last, it is possible to install multiple versions or networks on the same machine with the `install` command.

— Allows you to install Lisk Core, download the snapshot, insert the snapshot in the database, and start the freshly installed node. By default, this will fetch the latest public release of Lisk Core and download the `mainnet` snapshot. Extra options are provided to install a custom build of Lisk Core or specify a different network like `testnet`. At last, it is possible to install multiple versions or networks on the same machine with the `install` command. lisk core:start & lisk core:stop — By default, `lisk core:install` will start the application. However, it is possible to start and stop the application.

— By default, `lisk core:install` will start the application. However, it is possible to start and stop the application. lisk core:logs — Of course, monitoring the logs of a node is an important feature that needs to be part of this command set.

— Of course, monitoring the logs of a node is an important feature that needs to be part of this command set. lisk core:uninstall — We don’t like to see you uninstalling Lisk Core, however, we were nice enough to provide the option to remove an active installation.

We hope to see more adoption by bringing this `node generation kit/set of functions` and doing so, reducing the knowledge barrier for running your own node. Basically, a user must be able to download Lisk Commander, unzip & install, and run the commands from its terminal.

Three new P2P features from LIP-0004 have been implemented

Several features specified by LIP-0004 have been implemented. Namely:

Feature 1: Single websocket connection for every pair of peers, as opposed to separate inbound and outbound connections.

There’s one source of truth about the peers websocket connections stored in the memory.

It’s easier to control connect/disconnect peers actions handling.

Decreased resources used by P2P websocket connection. Instead of creating two websocket connections for each peer, now it’s only one for each, which is categorized as ‘Outbound’ or ‘Inbound’.

Logic ensuring the existence of only 1 websocket connection per-peer

Feature 2: Peer targeting implemented to allow for communicating with specific peers (for advanced use-cases only).

The new BFT consensus will make it necessary to be able to respond to the specific peer who sends a block advertisement. Peer targeting is needed in this case. In BFT Consensus mechanism, a new block can be sent unsolicited from a peer, or requested from a peer after that peer announced a new block. In order to to request a block from a peer, the node needs knowledge of which specific peer the announcement came from. In this case peer targeting is required.

Feature 3: Banning mechanism implemented that will apply penalties to peers for bad behavior.

The banning mechanism is not in effect right now, but it will be a new feature after LIP-0004 is fully implemented.

There will be a reputation score for all peers that is initially set to 100 (on a scale of 0 to 100).

The score of a peer will decrease each time invalid information is sent or if too many messages are sent within a 30 second window (of type: getSignatures, postBlock, getBlocks and getBlocksCommon). For invalid information, you can view the table on GitHub which lists the penalties under the section “Banning Mechanism”. For sending too many messages, we are still conducting internal tests before it is decided how many is too many messages. For now, we have finished implementing the logic.

If the reputation score reaches 0, a peer is banned temporarily for a period of 24 hours. The default value of banTime can be changed by the user in the configuration.

The reputation score will not be publicly exposed on any of our user interfaces. It is strictly for the P2P library and only to be used for banning bad peers.

The banning mechanism does not extend beyond 24 hours. After that, the banned peer can be re-discovered by the node and added back. However a user can permanently blacklist specific peers if they want to.

Jon Gros-Dubois recently jumped on to answer some questions about the new P2P network module/layer of the upcoming SDK. View the recap.

Lisk Builders

This month we would like to recognize development contributions from Sayler8182, Corbifex, TonyT908, Endro, Lemii and Hirish. Always use third party tools with caution.

UI

Lisk Hub 1.17.0 was released on May 27th, includes performance and UX improvements

Lisk Hub 1.17.0 includes performance improvements and also fixes some UX issues such as the error in the account initialization button.

Future releases will focus on delivering more consequential features, starting with Trezor T integration for 1.18.0

With the goal of delivering updates/improvements/design rollout in a timely manner, historically we scheduled bi-weekly releases for Lisk Hub with everything developed in the previous sprint. Regular releases helped us deliver and quickly improve upon the rollout of the new design. Now that we will be wrapping up the new design in version 1.19.0, we have come to the conclusion that bi-weekly releases don’t always make sense based on the complexity of new features in the pipeline that take longer than 2 weeks to develop. The BTC integration we are working on right now is a perfect example of this. After Lisk Hub 1.17.0, we’ll only release a new version on a bi-weekly basis IF there’s a prominent feature that you can easily use. The only exception to this rule, is if there is a critical bug from the previous version that needs immediate fixing.

Lisk Hub 1.18.0 beta was released on June 5th with Trezor T support

If you are a hardware wallet enthusiast then you will be happy to learn about the latest feature that we developed in 1.18.0. We have integrated Trezor T hardware wallet into Lisk Hub. The Trezor T integration into Lisk Hub will enable you to perform all of the following actions, all from inside Trezor T’s interface: