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.
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.
- 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.
- 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
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`.
- 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.
- 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.
- lisk core:logs — 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.
This month we would like to recognize development contributions from Sayler8182, Corbifex, TonyT908, Endro, Lemii and Hirish. Always use third party tools with caution.
- Max announced yesterday on Twitter that the Lisk SDK Gitter channel is now live. Please join Gitter for developer focused discussions during the SDK release.
- Shoutout to Sayler8182 who released a Lisk Core API wrapper for Swift. RxLisk Swift 5 Library is a Swift 5 library for Lisk that allows developers to interact with the Lisk Core API for retrieval of collections and single records of data.
- Thanks to Corbifex for creating Lisk Genesis, a genesis block creator that gives developers the possibility to customize their own genesis block for blockchain app prototypes during the Lisk Alpha SDK phase.
- Community builder TonyT908 has built 14 tools for the Lisk ecosystem. Check them out on his GitHub repository and don’t forget to star his repos.
- We were thrilled to learn that longtime community member Endrorecently announced his intention to work full-time for the development of Lisk Discovery.
- Community-built Lisk Ledger App, by delegate Hirish, is compatible with the new version of the Ledger Nano X even before this hardware wallet’s public release.
- Thank you to community member JesusTheHun for sharing feedback with our UI team. His idea to use the quick action menu to improve the privacy through discreet mode is being implemented.
- Have you built a community tool for Lisk? Please make sure that your tool is listed in our Community Tools Spreadsheet so that everyone can benefit from it. We have over 80 community tools in the spreadsheet and counting.
- Community Tool of the Month — each month we will feature a community tool for you to learn about and try.
- ScanBlocks: Need to file your taxes? Calculate and get reports on your income with real time fiat value at the time of block generation for staking rewards.
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:
- Send LSK tokens
- Vote for delegates
- Register a delegate
- Register a second passphrase
Improved UX/UI for Hub’s delegates page
We are continually gathering community feedback in order to improve your experience using Lisk Hub. More recently, we focused our improvements on the delegates page which now follows our new design language and allows guest users to search and view all delegate information. Guest users are currently restricted from voting for delegates.
Lisk Hub 1.18.0 introduces a new onboarding module
We have also introduced an onboarding module in Lisk Hub 1.18.0, which helps new account holders get acquainted with new concepts, making it easier to start using Lisk Hub to its full potential. The onboarding will include:
- Our DPoS consensus algorithm
- How to understand the delegate page
- How and why to vote for delegates?
- Where to get more help if you have questions
Lisk Hub 1.18.0 fixes bugs from the previous Ledger S hardware integration
Edge cases from our Ledger S hardware integration have been addressed. In order to access the seeds stored in Ledger S, this hardware wallet requires you to open the Lisk application using the buttons on the hardware wallet. Lisk Hub then notifies you when you connect the Ledger, and unlocks, but didn’t open the Lisk app on Ledger.
Refactoring Redux store and React components for multicoin support
There are further changes which are not visible, but rather prepares the foundation for upcoming features. In Lisk Hub 1.17.0 and 1.18.0 we have prepared the groundwork for integrating BTC tokens. This involves refactoring our Redux store, as well as almost all of our React components to enable them to store and present any number of additional tokens, starting with BTC. This is a huge amount of work because every single file in the project is affected. The integration of BTC was originally planned for 1.18.0, but some obstacles made us decide to postpone it to 1.19.0 with higher confidence in the quality of the feature we deliver to you.
Lisk Hub 1.19.0 will include BTC integration
As promised, this feature will allow you to store BTC tokens and make transactions using Lisk Hub. This release will contain the final step to migrating to the final design language.
In the past month, we have released two versions of Lisk Mobile, with the third version in the final stages of completion. Here we’ll explain the changes shipped in these releases.
Lisk Mobile 1.1.0 was released with improvements to BTC integration UX
We released the BTC integration in Lisk Mobile 1.0.0. However, we received feedback from community members stating that the new feature wasn’t visible enough. Therefore, we decided to add a welcome message to introduce the BTC integration in Lisk Mobile 1.1.0 so that all Lisk Mobile account holders are aware that the feature exists.
With Lisk Mobile 1.1.0, you can shake your phone to activate discreet mode
We made another improvement on the features that was already released, Users could use the settings page to activate the discreet mode. This feature was also available in the home page via the icon next to the section title. From now on, users can toggle the discreet mode by simply shaking their phones. Shake your phone once, the discreet mode is activated. Shake it again, and it gets deactivated. The modal views suffered performance issues on Android. In Lisk Mobile 1.1.0, we have fixed this issue so Android users feel the same smooth behaviour as iOS users do. There are many other improvements to animations used in different parts of the application that you’ll notice them when you use the app.
Lisk Mobile 1.1.1 was released to fix bugs from 1.1.0
After releasing Lisk Mobile 1.1.0, we noticed a couple of bugs that potentially blocked the experience of some users. One of the issues was caused because of a change in xCode build mode which depreciated some methods that React Native used internally. We’ll fix this by updating to the latest version of React Native in the near future. 1.1.1 was released two days later to ensure all the features in Lisk Mobile are available for all users.
Lisk Mobile 1.2.0 adds the new design language
The upcoming version of Lisk Mobile has finished development and is now in the QA phase. 1.2.0 implements the new design language Lisk Hub. We hope you’ll enjoy the new illustrations, nicely designed pages, improved registration page and much more.
Thanks for keeping up with the latest developments here at Lightcurve. The next month will see us progress further through various objectives on the roadmap as well as produce multiple releases across our product suite.
Lightcurve Development Team