What are LIPs?

Research is structured in the Lisk Improvement Proposal (LIP) process. A LIP is a document that technically defines a change in the Lisk protocol, an implementation or a non-technical process surrounding Lisk. The LIP describes the requirements, rationale and motivation for making a change.

Research - LIPs Process
LIP0001: LIP purpose and guidelines

A Lisk Improvement Proposal (LIP) is a design document providing information to the Lisk community, or describing a new feature for Lisk or its processes or environment. The LIP should provide a concise technical specification of the feature and a rationale for the feature.

We intend LIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Lisk. The LIP author is responsible for building consensus within the community and documenting dissenting opinions.

Because the LIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.

Author

Lisk Foundation

Publication

16.04.2018

LIP0002: Change to byte based block size limit

This LIP proposes to replace the literal 25 transactions per block size limit with a byte based block size limit.

Author

Iker Alustiza & Nazar Hussain

Publication

17.08.2018

LIP0003: Uniform ordering of delegates list

This LIP addresses two issues affecting delegate list uniformity found within the reference implementation of the Lisk protocol. It proposes a way to uniformly order the delegates list by hashing each delegate’s unique identifier together with a unique identifier for the round.

Author

Iker Alustiza

Publication

17.08.2018

LIP0004: Introduce robust peer selection and banning mechanism

This LIP proposes a new implementation of the P2P layer of Lisk introducing a robust peer selection with periodic shuffling and banning mechanism. We further suggest to refine the gossip-based flooding mechanism for blocks, transactions and signatures in order to improve information propagation. Together the proposed changes make the Lisk peer-to-peer network ready to scale to a large number of nodes and further increase the robustness of the network.

Author

Jan Hackfeld

Publication

23.08.2018

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

This LIP proposes a new application architecture for Lisk Core, that is of a flexible and modular design. The goals of the new application architecture are:

  • Looser coupling between modules through functional isolation.
  • Optional elastic scaling for modules over multiple cores, threads or machines.
  • Easier extensibility through the use of a plugin pattern and a supporting API.
  • Increased resilience to individual module processing failure.
Author

Iker Alustiza

Publication

06.09.2018

LIP0006: Improve transaction processing efficiency

This LIP proposes to improve the processing of transactions by optimizing the verification of transactions, applying transactions in memory, and consolidating database queries. Additionally, it suggests improvements for managing transactions in the transaction pool.

Author

Iker Alustiza

Publication

07.09.2018

LIP0007: Use a consistent and informative versioning scheme

This LIP proposes a versioning system for Lisk Core, Lisk SDK and any blockchain application created using the Lisk SDK. One which makes the clear distinction between software implementation and blockchain protocol changes.

Author

Iker Alustiza

Publication

14.09.2018

LIP0008: Remove pre-hashing for block and transaction signatures

This LIP proposes to remove the hash-then-sign paradigm for block and transaction signatures in the Lisk protocol. That means, block or transaction data should be signed instead of the hash digest of block or transaction data. We elaborate on why this paradigm is typically used, and why it provides more disadvantages than advantages in the Lisk protocol, where Ed25519-SHA-512 is used.

Author

Andreas Kendziorra

Publication

16.10.2018

LIP0009: Mitigate transaction replay on different chains

This LIP proposes to mitigate transaction replay on different chains by introducing a network identifier as a constitutive component of the signature of a transaction.

Author

Manu Nelamane Siddalingegowda & Iker Alustiza

Publication

16.10.2018

LIP0010: Use SHA3-256 hash of block header as blockID

This LIP proposes to take the SHA3-256 hash of the block header as the blockID of a block. This implies an increase of the blockID length and the usage of a different hash function. The motivation of the proposal is to increase the security of the Lisk blockchain.

Author

Andreas Kendziorra

Publication

26.10.2018

LIP0012: Remove redundant properties from transaction objects

The current protocol allows for and partially enforces the usage of property-value pairs in transaction objects that are neither required nor used. These property-value pairs are contained in the JSON objects used to transmit transactions and in the input messages for the transaction signature and the transactionID generation. This increases the size of transactions and the complexity of the protocol unnecessarily. Therefore, this LIP proposes to remove these redundant properties of transaction objects.

Author

Andrea Kendziorra

Publication

18.12.2018

LIP0013: Replace static fee system by dynamic fee system

This LIP proposes 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 defined for every transaction. Any transactions received with a fee below that minimum fee will be rejected. For each transaction, it will be up to the issuer to choose an appropriate transaction fee depending on the network load, which has to be at least the minimum transaction fee.

Author

Iker Alustiza

Publication

13.02.2019

LIP0014: Introduce BFT consensus protocol

This LIP proposes to change the consensus algorithm used in Lisk by introducing a mechanism allowing delegates to vote on the correct block at every height and implementing a new fork choice rule. The proposed consensus protocol thereby achieves Byzantine fault tolerance (BFT) and provides block finality guarantees, i.e., guarantees that a block is never reverted.

Author

Jan Hackfeld

Publication

28.03.2019

LIP0015: Enable transaction invalidation by using nonces instead of timestamps

This LIP proposes to replace timestamps by nonces in transaction objects. No constraints on the order of nonces shall be used. Moreover, the requirement that the combination of address, nonce and network identifier has to be unique is added. This will allow to invalidate pending transactions by reusing the nonce.

Author

Andreas Kendziorra

Publication

29.01.2019

LIP0016: Implement fee estimation algorithm for dynamic fee system

This LIP proposes a fee estimation algorithm that suggests a fee depending on the priority of the transaction for the user and the blockchain’s recent history. The algorithm is based on an Exponential Moving Average (EMA). It is implemented in a node of the Lisk network and the wallet queries its output to get the transaction fee estimation for the user.

Author

Iker Alustiza

Publication

04.11.2019

LIP0017: Make multisignature accounts more flexible, prevent spamming, and prevent signature mutability

This LIP proposes some improvements for the multisignature system in Lisk. The first improvement is that only valid transactions from multisignature accounts, i.e. transactions with all required signatures, are accepted and allowed to be forwarded by nodes. This will prevent spamming of the network and the transaction pool. Next, the settings for the account rules become more flexible. This allows, for example, to create accounts that require signatures for m arbitrary public keys from a set of n public keys without making the signature for any public key mandatory. Moreover, the upper bound on the number of participating keys is increased to 64 and the set of signatures of a transaction included in a block becomes immutable. The rules for the existing multisignature accounts do not change with this proposal.

Author

Andreas Kendziorra

Publication

09.08.2019

LIP0018: Use long hash of public key for address and Base32 encoding for UI

This LIP proposes a new format for addresses (also referred to as Lisk ID). On the protocol level, the proposed address format uses 160 bits of the SHA-256 hash of the public key. On the user interface level, a 30-bit checksum generated by the BCH code proposed in BIP 173 is added and a customized Base32 encoding is used. The new address format makes the "registration process" (performing at least one transaction per account to associate a public key to an address) obsolete. Moreover, the collision resistance gets significantly increased, and accidentally sending funds to a wrong address becomes almost impossible due to the checksum.

Author

Andreas Kendziorra

Publication

08.03.2019

LIP0019: Use full SHA-256 hash of transaction header as transactionID

This LIP proposes to use the full SHA-256 hash of a transaction as the transactionID to avoid potential collisions of transactionIDs.

Author

Andreas Kendziorra

Publication

06.09.2019

LIP0020: Use full SHA-256 hash of block header as blockID

This LIP proposes to take the full SHA-256 hash of the block header as the blockID of a block. This implies an increase of the blockID length. The motivation of the proposal is to increase the security of the Lisk blockchain.

Author

Andreas Kendziorra

Publication

06.09.2019

LIP0021: Change to one vote per account (withdrawn)

This LIP proposes a change of the voting system for the election of delegates in Lisk. We suggest to only allow one vote per account with a vote weight given by the balance of that account. The goal is to increase the decentralization of the network by disincentivizing coalitions between active delegates and creating a healthy competition for active delegate slots. Moreover, the proposed voting system is very simple and encourages a high participation of stakeholders.

Author

Jan Hackfeld

Publication

30.10.2018

LIP0022: Use Randao-based scheme to include standby delegates and reorder delegate list

This LIP proposes to include two standby delegates in the forging delegate list of every round to incentivize a greater number of online nodes in the Lisk network. The selection of these standby delegates is done by a Randao-based weighted random selection scheme to ensure the fairness and unpredictability of the process. This scheme is also used to reorder the forging delegates list in every round.

Author

Iker Alustiza

Publication

30.09.2019

LIP0023: Introduce vote locking periods and new vote weight definition

This LIP proposes a change of the voting system used to choose block forgers in Lisk. We suggest to move closer to a proof of stake system by having voters lock their tokens when casting a vote. Consequently, accounts can still vote for multiple delegates, but a given LSK can only be used in a single vote. The goal is to increase the decentralization of the network by creating a healthy competition for active delegate slots.

Author

Maxime Gagnebin

Publication

30.09.2019

LIP0024: Punish BFT violations

This LIP introduces consequences for breaching the BFT protocol. Adding finality and BFT guarantees to Lisk has been discussed in LIP 0014 "Introduce BFT consensus protocol". That LIP introduces the rules for detecting protocol violations, however, it does not define how to record and punish these violations. This LIP introduces a new transaction type called “Proof of Misbehavior”. This transaction allows users to reveal to the network any BFT protocol violation.

This proposal also specifies the consequences of such a breach of protocol. This is done by modifying the delegate weight calculation and the validity of unlock transactions.

Author

Maxime Gagnebin

Publication

30.09.2019

LIP0025: Introduce minimum balance requirement for accounts

This LIP introduces a new rule for the validity of transactions, which implies that the balances of sender and recipient cannot go below a certain constant value, minBalance, defined by the protocol.

Author

Iker Alustiza

Publication

19.12.2019

LIP0026: Establish block validity by applying transactions sequentially

This LIP introduces a procedure to assert the validity of blocks containing multiple interdependent transactions. This is done by defining a general way to order transactions. We then consider a block valid if every transaction is valid against the transitory state leading up to it.

Author

Maxime Gagnebin

Publication

14.01.2020

LIP0027: A generic serialization method

This LIP proposes a serialization method that is generic, deterministic, size efficient and deserializable. This method could be used to serialize arbitrary data for hashing and signing but also for storing and transmitting. This could be applied to (custom) transactions, blocks or account states. Concrete use cases will be defined in separate LIPs.

The encoding is based on protocol buffers proto2, also referred to as protobuf, with a few additional requirements. Instead of providing a .proto file, users will specify the serialization schema as a JSON schema. The encoding is kept compatible with protobuf in the sense that protobuf implementations with the adequate .proto file deserialize binary messages correctly.

Author

Maxime Gagnebin, Andrea Kendziorra

Publication

18.02.2020

LIP0028: Define schema and use generic serialization for transactions

This LIP defines a generic serialization for transactions by specifying the appropriate JSON schema. The proposed serialization method is applied in two steps, first to the asset property, where type-specific properties are defined, and then to the base transaction object. It will be used for signing but also for storing and transmitting transactions in the Lisk protocol. Further, this shall be the default serialization method for custom transactions created via the Lisk SDK.

Author

Iker Alustiza

Publication

18.02.2020

LIP0029: Define schema and use generic serialization for blocks

This LIP defines how the generic serialization defined in LIP 0027 is applied to blocks by specifying the appropriate JSON schema. We restructure the block header and introduce the block asset property, storing properties specific to the corresponding chain. We further specify the block-asset schema for the Lisk mainchain.

Author

Alessandro Ricottone

Publication

18.02.2020

LIP0030: Define schema and use generic serialization for account state

This LIP defines how the generic serialization algorithm will be applied to accounts by specifying the appropriate JSON schema. We specify how the different address format introduced in LIP 0018 will be handled, to ensure that all of the account states are consistent across all Lisk nodes.

Author

Alessandro Ricottone

Publication

18.02.2020

LIP0031: Introduce Merkle trees and inclusion proofs

This LIP defines a generic Merkle Tree structure and a format for proof-of-inclusion that can be used in different parts of the Lisk protocol.

Author

Alessandro Ricottone

Publication

19.02.2020

LIP0032: Replace payload hash with Merkle tree root in block header

This LIP proposes to remove the payloadHash value stored in each block header and replace it with transactionRoot, the root of a Merkle tree built from the transactions included in the payload.

Author

Alessandro Ricottone

Publication

19.02.2020

LIP0033: Introduce numbering scheme for transaction types

This LIP proposes a consistent versioning system for transaction types. This versioning system may also be used in the SDK for custom transaction development.

Author

Nazar Hussain

Publication

26.03.2020

LIP0034: Define new block schema and processing for genesis block

This LIP defines a new block asset schema that allows to specify an initial state of accounts and an initial delegate list valid for a certain bootstrapping period.

Author

Jan Hackfeld

Publication

08.04.2020

LIP0035: Define decentralized snapshot and hardfork process

This LIP defines how a unique snapshot block can be computed from the Lisk mainnet blockchain up to a certain height.

Author

Jan Hackfeld

Publication

08.04.2020

LIP0036: Introduce transaction properties moduleID and assetID

This LIP proposes to replace the type property in transaction objects by two new properties: moduleID and assetID. Both properties moduleID and assetID together must correspond to one unique transaction schema, transaction validation and execution logic.

Author

Shusetsu Toda

Publication

16.09.2020

LIP0037: Use message tags and network identifiers for signatures

This LIP introduces the concept of message tags for signatures. These message tags are prepended to the binary messages before being signed. A unique tag has to be used for each message type (transaction, block header, etc.), and in particular for each schema. This ensures that a signature for one message cannot be a valid signature for another message that serializes to the same binary message.

 

Author

Andreas Kendziorra

Publication

07.04.2021

LIP0038: Introduce BLS signatures

This LIP specifies how to use BLS signatures within Lisk. In particular, it specifies how to create and validate compact aggregate signatures with BLS. The specification consists mainly of a choice of a ciphersuite, i.e., the choice of a concrete BLS variant including the choice of several parameters. Moreover, some guidelines on how to use it within a blockchain created with the Lisk SDK are given.

Author

Andreas Kendziorra

Publication

13.04.2021

LIP0039: Introduce sparse Merkle trees

This LIP specifies the sparse Merkle tree implementation for the Lisk protocol and the format for inclusion proofs. A sparse Merkle tree is an authenticated data structure that allows to validate a key-value dataset with a single hash value, the Merkle root. It differs from a regular Merkle tree in that every element of the dataset occupies a fixed position in the tree, given by its key, and the resulting Merkle root depends only on the final dataset and not on the order of insertion.

Author

Alessandro Ricottone

Publication

22.04.2021

LIP0040: Define state model and state root

This LIP defines the state model of a Lisk blockchain and the construction of the state tree from which the state root is calculated. The state of an interoperable chain in the Lisk ecosystem is organized as a sparse Merkle tree, the state tree, built on top of a generic key-value storage for each module of the chain. This allows to authenticate the whole state with the tree Merkle root, i.e. the state root.

Author

Alessandro Ricottone

Publication

22.05.2021

LIP0041: Introduce Auth module
Publication

08.09.2021

LIP0042: Define state transitions of Reward module
Publication

08.09.2021

LIP0043: Introduce chain registration mechanism

This LIP introduces the concept of chain registration in the Lisk ecosystem. The chain registration is a necessary step to make a sidechain interoperable with the Lisk mainchain. Specifically, for the Lisk mainchain, this LIP specifies a new transaction for the sidechain registration. This transaction creates a sidechain account in the Lisk mainchain with some specific properties given by the user submitting the transaction. Similarly for sidechains, this LIP specifies the mainchain registration transaction.

Author

Iker Alustiza

Publication

22.05.2021

LIP00XX: Add weights to Lisk-BFT consensus protocol

This LIP defines how to generalize the Lisk-BFT consensus protocol to allow for different finality weights of the participating validators. A finality weight defines the amount with which the corresponding validator contributes to finalizing blocks. Additionally, we allow these weights as well as the weight threshold for considering a block final to change over time.

Author

Jan Hackfeld

Publication

06.05.2021

LIP00XX: Define state and state transitions of DPoS module
Publication

08.09.2021

LIP00XX: Define state and state transitions of Random module
Publication

08.09.2021

LIP00XX: Define state and state transitions of Token module

This LIP introduces a token module to be used in the Lisk ecosystem for minting, burning and transferring tokens. This module allows any chain in the ecosystem to handle and transfer tokens in a coherent, secure and controlled manner. In this LIP, the tokens handled are fungible.

Author

Maxime Gagnebin

Publication

22.05.2021

LIP00XX: Introduce a certificate generation mechanism

This LIP defines the schema of certificates, how unsigned certificates can be computed from blocks and how they are signed using BLS signatures. We further specify commit messages, which are messages containing BLS signatures of certificates. We describe how validators create unsigned certificates for blocks they consider final and share the signatures of such certificates by gossiping commit messages via the P2P network. The certificate signatures shared via commit messages are subsequently aggregated and included in blocks. From the aggregate certificate signatures included in blocks, any node in the blockchain network can create signed certificates which can be used in cross-chain update transactions to facilitate interoperability.

Author

Jan Hackfeld

Publication

22.05.2021

LIP00XX: Introduce BFT module
Publication

08.09.2021

LIP00XX: Introduce cross-chain messages

This LIP introduces the cross-chain message schema, the generic message processing and the base error handling. Defining a base cross-chain message allows all chains in the ecosystem to read and understand the base properties of messages.

Author

Maxime Gagnebin

Publication

22.05.2021

LIP00XX: Introduce cross-chain update mechanism

This LIP introduces cross-chain update transactions which are used to post certified information and cross-chain messages in Lisk ecosystem chains.

Cross-chain update transactions are the carriers of the information transmitted between chains. By posting a cross-chain update, the receiving chain gets the information required about the advancement of the sending chain. The transaction can also include cross-chain messages and thus serves as an envelope for messages from one chain to another.

Author

Maxime Gagnebin

Publication

22.05.2021

LIP00XX: Introduce Fee module
Publication

08.09.2021

LIP00XX: Introduce Interoperability module

This LIP defines the interoperability module which provides basic functionalities to transmit information between interoperable chains in the Lisk ecosystem using cross-chain messages. In this LIP the properties, serialization, and initial values of this module are specified. Additionally, this LIP also provides a broad overview of the Lisk interoperability solution, motivating several design choices and presenting the new transactions that are part of the interoperability module.

Author

Alessandro Ricottone

Publication

22.05.2021

LIP00XX: Introduce Legacy module
Publication

08.09.2021

LIP00XX: Introduce NFT module

This LIP introduces an NFT (non-fungible token) module to be used in the Lisk ecosystem for creating, destroying NFTs and transferring them in the ecosystem.

Author

Maxime Gagnebin

Publication

22.05.2021

LIP00XX: Introduce PoA module

This LIP introduces the Lisk Proof-of-Authority (PoA) mechanism for the selection of validators, known as authorities in this context, to generate blocks. In particular, this document specifies the PoA module which contains the schemas and the logic for transactions, blocks and accounts that defines the PoA mechanism for the Lisk protocol.

Author

Iker Alustiza

Publication

29.04.2021

LIP00XX: Introduce sidechain recovery mechanism

This LIP introduces three new transactions to the Lisk ecosystem, the message recovery transaction, the token recovery transaction and the NFT recovery transaction. The first one allows users to recover a cross-chain message that is pending in the outbox of an inactive or terminated sidechain. The second one is used to recover the balance of a token from an inactive or terminated sidechain whereas the latter allows to recover NFTs.

Author

Iker Alustiza

Publication

22.05.2021

LIP00XX: Introduce unlocking condition for incentivizing certificate generation

This LIP introduces an additional incentive for delegates and voters in DPoS for generating certificates by requiring the generation of a certificate for a certain height before tokens previously used for voting can be unlocked.

Author

Jan Hackfeld

Publication

22.05.2021

LIP00XX: Introduce Validators module
Publication

08.09.2021

LIP00XX: Update block schema and block processing

This LIP introduces changes to the block header and block asset schema that are required by several other LIPs.

Author

Andreas Kendziorra

Publication

22.05.2021

LIP00XX: Update genesis block schema and processing
Publication

08.09.2021

Lisk Research Forum

Research Forum

On the Lisk research forum you can participate and contribute towards research for improving the Lisk protocol. The main purpose is to propose and discuss LIPs as part of the process outlined in the LIP process guidelines.