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

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.

Author

Jan Hackfeld

Publication

23.08.2018

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

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.

Author

Iker Alustiza

Publication

20.03.2019

LIP0006: Improve transaction processing efficiency

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.

Author

Iker Alustiza

Publication

20.03.2019

LIP0007: Use a consistent and informative versioning scheme

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.

Author

Iker Alustiza

Publication

20.03.2019

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

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.

We also modify the computation of the delegate weights to account for the amount of self-votes cast by the delegates. The proposed system will encourage delegates to maintain a secure and efficient setup as well as have an open communication about their node setup.

This LIP addresses the same issues as the withdrawn LIP 0021 "Change to one vote per account". That LIP and the corresponding forum thread contain valuable information used to create this proposal. We encourage community members to read that LIP in order to understand the similarities and differences between these proposals.

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.03.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.03.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.03.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.03.2020

LIP0031: Introduce Merkle trees and inclusion proofs

The purpose of this LIP is to define 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

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

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

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.