For the best viewing experience, please turn your phone to portrait mode.

Last update

Development Roadmap

Explore the road to the groundbreaking Lisk SDK

  • Objective defined: Objective has been defined on the development roadmap.

  • In research: Objective is currently being researched and discussion around the topic has started or has been completed.

  • LIP drafted: One or more LIPs tackling this objective are published on the LIPs GitHub repository for further review.

  • In development: The alpha reference implementation (proof-of-concept) for a LIP related to this objective is currently being developed.

  • LIP proposed: The LIP beta/release implementation has been proposed to the Lisk Testnet.

  • Completed: The Lisk Mainnet accepted the proposal and the objective has been completed.

Inception

This phase represents progress already made towards our proposed Blockchain Application Platform, between Lisk Core versions 0.1.0 to 1.0.0.

Product

Status

Objective

Protocol
Introduce block rewards for delegates

Introduce a block reward mechanism to the Lisk protocol which adds an milestone based LSK incentive for every block an active delegate forges.

Protocol
Add data field support to balance transfers

Add support for a 64 byte data field to the type 0 transaction type so that custom identifiers, hashes and other pieces of metadata can be optionally attached to every balance transfer on the network.

Protocol
Introduce fork recovery mechanism

Significantly reduce the probability of fork or chain splits and introduce a consistent way for the Lisk protocol to react to forks through valid block determination and windowed rollback.

Protocol
Introduce block versioning mechanism

Introduce a mechanism for version controlled block generation when a distinct change is made to the Lisk protocol.

Core
Introduce new API

Introduce a new API to Lisk Core which conforms to RESTful design principles and integrates Swagger as a tool for designing, building, documenting, testing, and standardising the API across the entire application architecture.

Core
Change database system

Change the database engine used by Lisk Core from SQLite to PostgreSQL, introducing the use of PG-Promise as its primary interface for reading and writing to the database system.

Core
Rewrite database module

Rewrite the database module of Lisk Core so that it supports a repository design pattern as recommended by PG-Promise.

Core
Add database migration system

Add database migration system for version controlled atomic schema changes between Lisk Core releases.

Core
Ensure atomic block persistence

Ensure blocks are persisted atomically and that data corruption never can occur when the Lisk Core application is interrupted or processing fails.

Core
Add support for verified database snapshots

Add support to Lisk Core for creating verified blockchain snapshots of the existing blockchain and the ability to restore them on demand.

Core
Add transaction pool system

Add a transaction pool system to Lisk Core for receiving and processing transactions from peers in a more controlled, efficient and scalable manner.

Core
Add broadcasting mechanism

Add a broadcasting mechanism to Lisk Core for propagating blocks, transactions and multi-signatures in a more controlled, efficient and scalable manner.

Core
Rewrite P2P module

Rewrite the P2P module of Lisk Core so that it utilises the SocketCluster.io framework for maintaining data connections, broadcasts and receipts between peers on the network.

Core
Complete multi-signature group and transaction solution

Complete the multi-signature solution provided by Lisk Core, so that transactions initiated by a multi-signature group owner can be reliably created, pooled and included into the blockchain when all required accounts have signed a transaction.

Core
Add delegate passphrase encryption

Add delegate passphrase encryption so that plain text passphrases are never propagated or stored when managing a Lisk Core delegate node.

Core
Add minimum version support

Add support for setting a minimum application version accepted by new Lisk Core release proposals made to the network.

Quality and Performance

This phase includes a number of key improvements to API & vote verification performance, developer tooling, and adds benchmarking of nodes.

Product

Status

Objective

Core
Facilitate single installation for all networks

Allow node operators to connect with different networks (devnet, testnet or mainnet) using a single Lisk Core installation.

Core
Add configuration migration system

Add configuration migration system for easy tracking of configuration changes between Lisk Core releases and migrating existing configurations to the latest release.

Core
Move build system directly into Lisk Core

Replace Lisk Build with an inbuilt system for building Lisk Core.

Core
Move docker integration directly into Lisk Core

Replace Lisk Docker with an inbuilt integration for running Lisk Core using Docker.

Core
Add application benchmarking

Add Lisk Core application benchmarking using NewRelic (https://newrelic.com/), helping to identify API bottlenecks, database query performance problems and potential stack overflows.

Core
Improve API & vote verification performance

Improve performance in Lisk Core for
1) Poor performing API endpoints and
2) Vote transaction verification.

Elements
Setup mono repository structure

Change the repository structure of Lisk Elements to conform with the "mono" repository ideal. Reference: https://ai.google/research/pubs/pub45424.

Elements
Add sodium-native support

Add optional support to Lisk Elements for the sodium-native (https://github.com/sodium-friends/sodium-native) cryptography library, as a backend alternative to TweetNaCl (https://tweetnacl.js.org/#/).

Elements
Implement consistent error handling

Implement consistent handling of error message propagation throughout the entire Lisk Elements library.

Elements
Migrate elements to TypeScript

Add static type checking to Lisk Elements by migrating the codebase to: https://www.typescriptlang.org/.

Elements
Create transactions element

Extract logic from Lisk Core to Lisk Elements with the code rewritten in TypeScript. In support of:
1) Migrate elements to TypeScript and
2) Improve transaction processing efficiency.

Elements
Create transaction pool element

Extract logic from Lisk Core to Lisk Elements with the code rewritten in TypeScript. In support of:
1) Migrate elements to TypeScript and
2) Improve transaction processing efficiency.

Commander
Change application framework

Change the application framework used to create Lisk Commander from https://github.com/dthree/vorpal to https://github.com/oclif/oclif.

Commander
Migrate commander to TypeScript

Add static type checking to Lisk Commander by migrating the codebase to: https://www.typescriptlang.org/.

Commander
Add multi-signature transaction fetch & sign commands

Add new commands to Lisk Commander for:
1) Fetching a pending multi-signature transaction and
2) Signing a pending multi-signature transaction. In support of the existing multi-signature transaction broadcast command. This will complete the fetch, sign and broadcast workflow.

Commander
Add vote/voter listing commands

Add new commands to Lisk Commander for:
1) Listing votes placed by an account and
2) Listing votes placed for a delegate.

Architecture and Design

This phase implements a new modular and resilient architecture for Lisk Core.

Product

Status

Objective

Core
Use a consistent and informative versioning scheme

Introduce two distinct versioning schemes, one for the Lisk Core application and one for the Lisk protocol. This will allow, for instance, a better overview when updating to a new Lisk Core release is optional or mandatory.

Core
Introduce new flexible, resilient and modular architecture for Lisk Core

Introduce a new application architecture for Lisk Core, one which provides:
1) Looser coupling between modules through functional isolation
2) Optional elastic scaling for modules over multiple cores, threads or machines
3) Easier extensibility through the use of a plugin pattern and a supporting API
4) Increased resilience to individual module processing failure. The new architecture will form the framework which new Lisk applications will inherit from.

Core
Implement extensible data persistence model

Implement a design pattern for the database component outlined by the new Lisk Core application architecture proposal. The database component will provide an abstraction layer for Lisk applications for reading and persisting objects.

Core
Implement design pattern for protocol change

Implement a design pattern for elegant handling of protocol change in the Lisk Core codebase. One which provides a consistent and straight-forward approach to dealing with protocol changes on an existing blockchain.

Core
Improve transaction processing efficiency

Consolidate transaction processing so that the majority of operations are performed in-memory and expensive database operations are minimised. This will bring significant efficiency improvements to transaction processing in Lisk Core.

Elements
Create p2p element

Extract logic from Lisk Core to Lisk Elements with the code rewritten in TypeScript.

Commander
Add node dependency/management/configuration commands

Add new commands to Lisk Commander for:
1) Ensuring node dependencies are met
2) Managing node processes and
3) Configuring code parameters.

Commander
Add node migration/upgrade commands

Add new commands to Lisk Commander for:
1) Performing network migrations (forks) and
2) Upgrade node installations.

Alpha SDK

After completion of the Architecture & Design phase, the architecture used to create new applications will be finalised, allowing developers to start development of proof-of-concept applications that are aligned with the future SDK. The ability to conduct rapid application development via our SDK (Core, Elements, Commander) will only have preliminary support at this stage. Developer caution should therefore be assumed.

Security and Reliability

This phase mitigates transaction replays, scalable peer connections and implements a guarantee that blocks are finalized after 150 confirmations.

Product

Status

Objective

Protocol
Introduce robust peer selection and banning mechanism

Introduce a robust peer selection with periodic shuffling together with a banning mechanism. Further refine the gossip-based flooding mechanism for blocks, transactions and signatures in order to improve information propagation. The changes are intended to make the Lisk peer-to-peer network ready to scale to a large number of nodes and further increase the robustness of the network.

Protocol
Improve blocks verification

Change the consensus algorithm in order to add block finality guarantees based on classic Byzantine fault tolerance (BFT) research, i.e. guarantees that a block is never reverted. Block finality and a robust consensus are one of the key requirements for introducing sidechains and communication between different chains in Lisk.

Protocol
Improve blocks transmission efficiency

Change the way blocks are presented to each peer throughout the network to a structure which is more efficient than now.

Protocol
Mitigate transaction replay on different chains

Bind each transaction to a specific chain by using unique chain identifiers. In general, this will prevent that transactions get replayed on other chains. For instance, a transaction from the testnet cannot be replayed on the mainnet. Also, a transaction on a specific sidechain cannot be replayed on another sidechain.

Protocol
Remove redundant fields in transactions

Remove redundant fields in transactions that are not needed for certain transaction types.

Elements
Create fee estimation element

Create a new fee estimation element. In support of: Implement fee estimation algorithm for dynamic fee system.

Network Economics

This phase implements Dynamic Fees in Lisk Core.

Product

Status

Objective

Protocol
Change to byte based block size limit

Remove the limit on the number of transactions per block, and introduce a limit on the overall size of the block. This will increase the maximum rate of transactions per second for most transaction types while keeping the growth of the blockchain at a reasonable level.

Protocol
Replace static fees with dynamic fee system

Introduce a dynamic fee system as a free fee market where the fixed fee for all transaction types will be removed and a minimum fee will be set in the protocol. This minimum fee will be given in terms of LSK per byte used by transactions and any transactions broadcast with a fee below that value will be rejected. For each transaction, it will be up to each user to choose the fee.

Protocol
Implement fee estimation algorithm for dynamic fee system

Implement an algorithm that recommends a fee for a transaction depending on the preceding network usage demand and the desired maximum time for the transaction to be included into a block.

Protocol
Improve multi-signature solution

Change the multisignature process so that nodes can handle a sufficient number of pending multisignatures.

Elements
Create chain element

Extract logic from Lisk Core to Lisk Elements with the code rewritten in TypeScript. In support of: Introduce decentralised re-genesis.

Commander
Add node snapshot/restore commands

Add new commands to Lisk Commander for:
1) Performing blockchain snapshots and
2) Restoring blockchain snapshots.

Network Longevity

This phase focuses on replacing address, block and transaction ID systems to secure the immutability of the Lisk blockchain.

Product

Status

Objective

Protocol
Replace address system

Change the address system such that:
1) registrations are not needed
2) the address space is sufficiently large to avoid collisions of addresses
3) sending money to a black hole due to user failure (mistyping an address) is mitigated.

Protocol
Replace block ID system

Increase the length of the block IDs to secure the immutability of the blockchain also for next decade(s).

Protocol
Replace transaction ID system

Increase the length of transaction IDs to avoid collisions. Moreover, introduce a transaction invalidation mechanism along with this change that will improve the usability of the dynamic fee system.

Protocol
Remove pre-hashing for block and transaction signatures

Remove the pre-hashing step from the block and transaction signature processes. This will simplify the protocol since hashing a message (transaction or block header) before signing the resulting hash digest is a redundant step.

Protocol
Introduce decentralized re-genesis

Introduce a decentralized way of writing the account states to the blockchain in order to avoid the maintenance of all past versions of the protocol by Lisk Core. This re-genesis will allow nodes to synchronize from a new genesis checkpoint while only requiring compatibility with the latest protocol version.

Core
Migrate core to TypeScript

Upon completion of the logic extraction from Lisk Core to Lisk Elements. Rewrite the remaining Lisk Core in TypeScript.

Elements
Create consensus element

Extract logic from Lisk Core to Lisk Elements with the code rewritten in TypeScript. In support of:
1) Perform uniform ordering of delegates list
2) Change vote system
3) Incentivise standby delegates and
4) Punish delegates who double forge. Existing logic has been extracted to Lisk Elements, leaving Lisk Core as a reusable framework.

Delegated Proof of Stake

This phase implements improvements to our consensus mechanism. After the completion of this phase, we will enter the Beta SDK stage - where developers will be able to conduct rapid application development.

Product

Status

Objective

Protocol
Uniform ordering of delegates list

Improve the current delegate scheduling process in the block generation rounds. Scheduling a delegate round will be done by hashing each delegate’s unique ID together with a unique ID for the round. Then, the delegates will be unequivocally ordered according to these hash values.

Protocol
Change voting system

Change the voting system in accordance with the Lisk values of accessibility, simplicity and decentralization. A simple voting system encourages a high participation of all stakeholders of the ecosystem. Moreover, this new voting system is expected to encourage decentralization and a healthy competition for active delegate slots.

Protocol
Incentivise standby delegates

Allow standby delegates to participate in the block forging depending on their delegate weight. This way there will be an incentive for standby delegates to also run Lisk nodes.

Protocol
Punish protocol violations by delegates

Add the possibility of punishing delegates for protocol violations such as forging multiple conflicting blocks in the same time slot or not forging for an extended period of time.

Protocol
Prevent change of delegate during round on virgin network

Prevent change of delegate during round on virgin network where no votes have been placed.

Elements
Create application bootstrap element

Create a new application bootstrap element. This will allow the Lisk Core framework and existing elements to be initialised as skeleton applications.

Elements
Create genesis block element

Create a new genesis block element. In support of: Create genesis block from ICO proof.

Commander
Add application bootstrap commands

Add new commands to Lisk Commander for: Bootstrapping new applications.

Commander
Add ICO transaction commands

Add new commands to Lisk Commander for: Creating ICO transactions for new applications.

Commander
Add genesis block commands

Add new commands to Lisk Commander for: Creating a genesis block for new applications.

Commander
Add custom token commands

Add new commands to Lisk Commander for:
1) Registering custom tokens and
2) transferring custom tokens.

Beta SDK

After completion of the Delegated-Proof-of-Stake phase, a variety of important objectives will have been completed. These include the provision of: improved blockchain security, dynamic fees, a new ID system, an evolved DPoS, the complete migration of Core and Elements to TypeScript, and the ability to conduct rapid application development via our SDK (Core, Elements, Commander). Our proposed custom token system, ICO mechanism, and sidechain interoperability solution will not be supported at this stage.

ICOs and Custom Tokens

This phase provides the functionality to conduct ICOs, and register & transfer custom tokens on the Lisk mainchain. With this phase, we will reach the Release Candidate SDK stage - where developers will be able to fully bootstrap and develop new applications, albeit without sidechain communication.

Product

Status

Objective

Protocol
Add ICO transaction type

Add a transaction type to the Lisk protocol that will allow ICOs to be conducted on the Lisk mainchain.

Protocol
Create genesis block from ICO proof

Implement a mechanism that will create a genesis block derived from an ICO previously.

Protocol
Add custom token system

Implement a custom token system that will allow to registration and transfer of custom tokens on the Lisk main chain. It is yet to be decided if the permanent usage of custom tokens will be allowed, or only a temporary usage, e.g. until a genesis block based on an ICO is created.

Elements
Create sidechain element

Create a new sidechain element. In support of:
1) Establish bond between mainchain and sidechains and
2) Facilitate decentralised and trust-less token transfers.

RC SDK

After completion of the ICO & Custom Tokens phase, developers will be able to fully bootstrap and develop new applications using our SDK (Core, Elements, Commander), register & transfer custom tokens, and conduct ICOs for applications on the Lisk mainchain. Our proposed sidechain interoperability solution will not yet be supported at this stage. The ability for connecting applications as sidechains to the mainchain will be added in the next phase.

The Blockchain Application Platform

This phase enables communication between Lisk Core and application sidechains. The Blockchain Application Platform is delivered.

Product

Status

Objective

Protocol
Establish bond between mainchain and sidechains

Establish a bond between mainchain and sidechains in order to form an authenticated network of Lisk applications.

Protocol
Facilitate decentralised and trust-less token transfers

Implement a decentralized and trust-less way to transfer tokens between chains. Allowing the transfer of LSK between the Lisk mainchain and sidechains. If custom tokens are to be transferable is not decided yet.

Production SDK

After completion of the Blockchain Application Platform stage, we have completed all the phases necessary to be able to deliver a fully functioning SDK with scalable interoperability between sidechains and the mainchain, as well as trust-less token transfers.

Roadmap / LIPs FAQ

The statements made herein and via other means of communication in relation to the Lisk roadmap are not guarantees but express current intention and describe potential. Use of the information available in this document or otherwise related to the Lisk roadmap as well as any use of the Lisk products is subject to the terms of use of the Lisk website including the Lisk privacy policy as well as all applicable laws. The information contained herein is for informational purposes only and should not be construed as investment, financial, or other advice.