Product

Status

Objective

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.

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.

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.LIP draft on GitHub

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.LIP draft on GitHub

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.LIP draft on GitHub

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.

Enable developers to write custom transaction types using a standardised interface, making it easy to extend the default set of transaction types provided by the Lisk Protocol with new network functionalities.

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.LIP draft on GitHub

Protocol

Change consensus protocol to add block finality

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.

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.LIP draft on GitHub

Protocol

Remove redundant properties in transactions

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

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.LIP draft on GitHub

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.

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).

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.LIP draft on GitHub

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.

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.

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.LIP draft on GitHub

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.

Elements

Create DPoS element

Extract logic from Lisk Core to Lisk Elements with the code rewritten in TypeScript. In support of:

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 genesis block commands

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

Core

Migrate core to TypeScript

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

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.

Commander

Add ICO transaction commands

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

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.

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.

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.

Learn

About

When accessing our website, we obtain and process your personal data. We also use cookies to improve your experience on our site. To find out more about our use of your data, read our updated privacy policy To continue using our website, click „I accept“.