Defined

The objective has been defined on the protocol roadmap

In research

The objective is currently being researched and discussion around the topic has started or has been completed

Drafted

One or more LIPs tackling the objective are published on the LIPs GitHub repository for further review

In development

The reference implementation for the objective is currently being developed

Proposed

The reference implementation for the objective has been proposed to the Lisk Betanet or Testnet

Completed

The Lisk Mainnet accepted the proposal and the objective has been completed

Security and Reliability

Stage 5
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.

Stage 5
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.

Author

Jan Hackfeld

Publication

28.03.19

Stage 5
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.

Author

Manu Nelamane Siddalingegowda & Iker Alustiza

Publication

16.10.18

Stage 5
Remove redundant properties in transactions

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

Author

Andrea Kendziorra

Publication

18.12.18

Network Economics

Stage 4
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.

Author

Iker Alustiza

Publication

13.02.19

Author

Iker Alustiza

Publication

19.12.19

Stage 4
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.

Stage 4
Improve multi-signature solution

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

Stage 4
Enable transaction invalidation

Introduce a transaction invalidation mechanism that will improve the usability of the dynamic fee system.

Stage 4
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.

Stage 4
Simplify transaction validity rules within blocks

Specify a general rule for the validity of transactions within a block in order to improve transaction pool performance and to simplify transaction logic.

Network Consensus

Stage 4
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.

Stage 4
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.

Stage 4
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.

Author

Maxime Gagnebin

Publication

30.09.19

Stage 4
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.

Author

Iker Alustiza

Publication

17.08.18

Network Longevity

Stage 4
Replace transaction ID system

Increase the length of transaction IDs to avoid collisions.

Stage 4
Introduce an authenticated data structure

Authenticated data structures, such as Merkle trees, allow to verify the presence of a subset of data in a trustless way and without knowing the whole data set. This can be beneficial to several parts of the Lisk protocol: Using an authenticated data structure for transactions in a block allows to verify the inclusion of a transaction without knowing the whole transaction payload. Moreover, when creating a snapshot of the blockchain, an authenticated data structure allows for trustless queries for subsets of data without requiring to store or request the full snapshot.

Author

Alessandro Ricottone

Publication

18.03.20

Author

Alessandro Ricottone

Publication

18.03.20

Stage 4
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.

Author

Andreas Kendziorra

Publication

16.10.18

Stage 4
Introduce universal serialization method

Introduce a serialization method that is generic, deterministic, size efficient and deserializable. This method should be used to serialize and deserialize any data of the Lisk blockchain and SDK, in particular, (custom) transactions and blocks. It should be used for storing and transmitting data as well as hashing and signing data.

Author

Maxime Gagnebin, Andrea Kendziorra

Publication

18.03.20

Author

Alessandro Ricottone

Publication

18.03.20

Author

Alessandro Ricottone

Publication

18.03.20

Stage 4
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.

Author

Jan Hackfeld

Publication

08.04.20

Stage 4
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.

Stage 4
Replace block ID system

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

Author

Andreas Kendziorra

Publication

06.09.19

Blockchain Interoperability

Stage 2
Establish inter-blockchain communication

Define and implement a protocol for decentralized and trust-less communication between chains in the Lisk ecosystem.

Stage 2
Facilitate inter-blockchain token transfer

Using inter-blockchain communication, implement a decentralized and trust-less way to transfer tokens between the Lisk mainchain and sidechains.

Previously completed objectives

Inception

Stage 6
Add database migration system
Stage 6
Introduce fork recovery mechanism
Stage 6
Complete multi-signature group and transaction solution
Stage 6
Ensure atomic block persistence
Stage 6
Introduce block versioning mechanism
Stage 6
Add delegate passphrase encryption
Stage 6
Add support for verified database snapshots
Stage 6
Introduce new api
Stage 6
Add application benchmarking
Stage 6
Add minimum version support
Stage 6
Add transaction pool system
Stage 6
Change database system
Stage 6
Introduce block rewards for delegates
Stage 6
Add broadcasting mechanism
Stage 6
Rewrite database module
Stage 6
Add data field support to balance transfers
Stage 6
Rewrite P2P module

Quality and Performance

Stage 6
Add sodium-native support
Stage 6
Move build system directly into Lisk Core
Stage 6
Add vote/voter listing commands
Stage 6
Implement consistent error handling
Stage 6
Move docker integration directly into Lisk Core
Stage 6
Migrate elements to TypeScript
Stage 6
Change application framework
Stage 6
Improve API & vote verification performance
Stage 6
Facilitate single installation for all networks
Stage 6
Migrate commander to TypeScript
Stage 6
Setup mono repository structure
Stage 6
Add configuration migration system
Stage 6
Add multi-signature transaction fetch & sign commands

Architecture and design

Stage 6
Improve transaction processing efficiency
Stage 6
Create transactions element
Stage 6
Use a consistent and informative versioning scheme
Stage 6
Create transaction pool element
Stage 6
Introduce new flexible, resilient and modular architecture for Lisk Core
Stage 6
Add node dependency/management/configuration commands
Stage 6
Implement extensible data persistence model
Stage 6
Enable custom transaction support
Stage 6
Implement design pattern for protocol change