It's in the details
Fundamental crypto research pushes Lisk to the fore-front of the crypto revolution.
How we conduct research
Research is structured through Lisk Improvement Proposals (LIPs), technical research papers suggesting changes and additions to the Lisk protocol.
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.
This LIP proposes to replace the literal 25 transactions per block size limit with a byte based block size limit.
Iker Alustiza & Nazar Hussain
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.
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.
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.
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.
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.
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.
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.
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.
This LIP proposes to use Extended Data Mapper pattern for the database component outlined by the LIP “Introduce new flexible, resilient and modular architecture for Lisk Core”. The proposed model will help to extend and maintain the persistence layer of Lisk Core by being generic, easy to understand and organized.
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.
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.
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.
This LIP proposes to replace timestamps by ordered nonces in transaction objects. This will allow to invalidate pending transactions by reusing the nonce.
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.
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. Lastly, we remove the concept of second signature and convert all accounts with second signatures to multisignature accounts. The rules for existing multisignature accounts do not change with this proposal.
This LIP proposes a new format for addresses (also referred to as Lisk ID). The proposed address format uses 160 bits of the SHA-256 hash of the public key. On the user interface level, addresses are displayed in the Lisk32 representation. This representation uses a customized Base32 encoding and extends addresses with a 30-bit checksum generated by the BCH code proposed in BIP 173.
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.
This LIP proposes to use the full SHA-256 hash of a transaction as the transactionID to avoid potential collisions of transactionIDs.
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.
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.
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 (see LIP 0003).
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.
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.
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.
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.
This LIP also specifies when delegates receive their block rewards and fees.
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.
Maxime Gagnebin & Andreas Kendziorra
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 transaction asset, which contains the custom properties specific to the transaction, and then to the transaction base object, which is the same for all transactions. 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.
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.
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.
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.
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.
This LIP proposes a consistent versioning system for transaction types. This versioning system may also be used in the SDK for custom transaction development.
Nazar Hussain & Iker Alustiza
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. The LIP also specifies how such a block is processed. This can make it easier to create a genesis block, the first block of a new blockchain, with a desired initial state using the Lisk SDK. The block schema is general enough to also define a more complex state computed as a snapshot of an existing blockchain.
Jan Hackfeld & Nazar Hussain
This LIP defines how a unique snapshot block can be computed from the Lisk mainnet blockchain up to a certain height. This block follows the schema introduced in LIP 0034 and, in particular, contains the state of all accounts. This yields a snapshot mechanism that can be used to perform a hardfork on the Lisk mainnet as all Lisk mainnet nodes can independently compute the snapshot block at the same time. The additional benefit of such a snapshot block is that nodes can directly synchronize from this block instead of having to synchronize from the original genesis block of the Lisk blockchain. This enables an implementation that is only partially backwards compatible, i.e., it can apply blocks and transactions following the latest version of the protocol, but cannot apply blocks and transactions from previous protocol versions.
Jan Hackfeld & Nazar Hussain
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.
We introduce 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.
Moreover, we generalize the usage of the chain identifiers (called network identifier in previous LIPs), which are currently used for transaction and block header signatures, to arbitrary signatures. This will prevent replay attacks for arbitrary messages.
This document 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.
This document does not specify any concrete applications of BLS signatures nor does it impose any protocol changes. It is purely informational on how to use them if desired. Specific applications need to be defined in separate LIPs.
In this LIP, we specify 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.
The state of an interoperable chain in the Lisk ecosystem is maintained in a global state store. Entries of the state store are inserted in a sparse Merkle tree, the state tree. The whole state is thus authenticated by the tree Merkle root, the state root. In this LIP, we define the state model of a Lisk blockchain and the construction of the state tree from which the state root is calculated.
The Auth module is responsible for handling and verifying nonces and for transaction signature validation, including transactions from multisignature accounts. In this LIP, we specify the properties of the Auth module, along with their serialization and default values. Furthermore, we specify the state transitions logic defined within this module, i.e. the commands, the protocol logic injected during the block lifecycle, and the functions that can be called from other modules or off-chain services.
Alessandro Ricottone & Ishan Tiwari
The Reward module provides the base reward system for a blockchain developed with the Lisk SDK. In this LIP, we specify the protocol logic that this module injects during the block lifecycle as well as the functions that can be called from off-chain services.
Iker Alustiza & Mehmet Egemen Albayrak
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 command for the sidechain registration. This command 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 command.
The Validators module is responsible for validating the eligibility of a validator for generating a block and the block signature. Furthermore, it maintains information about the registered validators in its module store and provides the generator list. In this LIP, we specify the properties of the Validators module, along with their serialization and default values. Furthermore, we specify the state transitions logic defined within this module, i.e. the protocol logic injected during the block processing and the functions that can be called from other modules or off-chain services.
Alessandro Ricottone, Andreas Kendziorra & Rishi Mittal
The Interoperability module 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 commands that are part of the Interoperability module.
Alessandro Ricottone & Mitsuaki Uchimoto
The Random module handles the validation of the inputs and computation of outputs for the commit and reveal process for a Lisk blockchain. In this LIP, we specify the state transitions logic defined within this module, i.e., the protocol logic injected during the genesis block processing, common block processing, and the functions that can be called from other modules or off-chain services.
Iker Alustiza & Ishan Tiwari
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 with its module store structure and the stored key-value pairs. Furthermore, it specifies the state transitions logic defined within this module, i.e. the commands, the protocol logic injected during the block lifecycle, and the functions that can be called from other modules or off-chain services.
Iker Alustiza & Ishan Tiwari
The Fee module is responsible for handling the fee of transactions. It allows chains to choose the token used to pay the fee and to define a minimum fee for transactions to be valid.
Maxime Gagnebin & Mitsuaki Uchimoto
This proposal 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.
The proposal also introduces three messages used by the Interoperability module, the channel terminated message, the sidechain terminated message and the registration message.
The Legacy module maintains all accounts on the Lisk mainchain that received balance transfers to their address in the old 8-byte format and for which no public key is associated. The Legacy module also implements a command allowing delegates without a BLS key to register one.
In this LIP, we specify the properties of the Legacy module, along with their serialization and default values. Furthermore, we specify the commands and the functions that can be called from off-chain services.
This module is only needed for the Lisk mainchain.
Andreas Kendziorra, Maxime Gagnebin, & Rishi Mittal
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.
This topic introduces an NFT (non-fungible token) module to be used in the Lisk ecosystem for creating, destroying NFTs, and transferring them in the ecosystem.
NFTs are uniquely identified assets. They can be transferred similarly to fungible tokens, but their unique identifiers can never be modified. In this module, NFTs also carry a list of attributes that are used to store information specific to the NFT.
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.
This LIP introduces four new commands to the Lisk ecosystem: the state recovery command, the message recovery command, the state recovery initialization command, and the message recovery initialization command. The state recovery command is used to recover entries from the module store of a terminated sidechain. The message recovery command allows users to recover cross-chain messages that are pending in the outbox of an inactive or terminated sidechain. The state and message recovery initialization commands are used to initialize the state and message recovery process, respectively.
Iker Alustiza & Alessandro Ricottone
This LIP changes the structure of a block, introducing the assets property alongside the block header and transactions. The block header schema is updated to add new properties introduced by several other LIPs. We clarify the mechanism by which modules can include data in the block assets and specify the validation of each block header property. Furthermore, we list the stages that are part of the block processing and generation, and we introduce the concept of failing transactions to the Lisk protocol.
Andreas Kendziorra, Alessandro Ricottone, & Rishi Mittal
This LIP defines how to generalize the Lisk-BFT consensus protocol to allow for different BFT weights of the participating validators, which may also change over time. The BFT weight is the weight attributed to the prevotes and precommits cast by a validator and therefore determines to what extent the validator contributes to finalizing blocks. We specify this generalized computation of consensus votes and associated properties using the new state structure defined in the BFT module.
The DPoS (delegated proof-of-stake) module is responsible for handling delegate registration, votes, and computing the delegate weight. In this LIP, we specify the properties of the DPoS module, along with their serialization and initial values. Furthermore, we specify the state transitions logic defined within this module, i.e. the commands, the protocol logic injected during the block lifecycle, and the functions that can be called from other modules or off-chain services.
Maxime Gagnebin, Nazar Hussain, & Mehmet Egemen Albayrak
This LIP introduces the BFT module, which is responsible for maintaining the consensus participants, their BFT weights and all information related to the consensus votes that have been cast as part of the block headers. In this LIP, we specify how this information is serialized and stored as well as updated as part of the block processing. Additionally, we specify the functions that can be called from other modules and off-chain services.
Jan Hackfeld & Mitsuaki Uchimoto
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.
This LIP adapts the specifications of the genesis block for blockchains created with Lisk SDK introduced in LIP 0034 to the requirements and characteristics of the new state model introduced in LIP 0040. It does so by following the general block format and processing introduced in LIP 0055.
Iker Alustiza & Rishi Mittal
This LIP defines the schema for 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.
This LIP introduces pre-hashing for signatures in Lisk, this includes transactions, block headers and certificate signatures. This allows signing to be performed on memory limited devices such as hardware wallets.
This proposal defines the configuration of Lisk Core v4, including the selection of modules and the choice of some configurable constants. Moreover, it defines the migration process from Lisk Core v3 to Lisk Core v4. As for the previous hard fork, a snapshot block is used that contains a snapshot of the state. This snapshot block is then treated like a genesis block by Lisk Core v4 nodes. In contrast to the previous hard fork, the existing block and transaction history is not discarded.
Andreas Kendziorra & Sergey Shemyakov
This proposal defines a stricter version of Lisk codec - the serialization method introduced in LIP 0027. It is stricter by requiring that every schema property must be marked as required. This simplifies the rules significantly and makes the serialization method much less error-prone without implying any change in the current Lisk SDK implementation.
In this LIP, we introduce a mechanism to emit events from the application domain during the block processing. These events are included in a sparse Merkle tree, whose root, the event root, is added as a new property to block headers. Using the event root, it is possible to provide inclusion or or non-inclusion proofs for events, proving whether an event was emitted during the block processing.
Alessandro Ricottone & Mehmet Egemen Albayrak
This LIP proposes methods for deriving private keys from a single source of entropy. Two methods are proposed, one for Ed25519 key derivation and the other for BLS key derivation. Both methods follow a tree based derivation approach similar to the one used for HD wallets.
We also describe a procedure to discover accounts from a given secret recovery phrase.
We describe a format for encrypted information to be used in the Lisk ecosystem. This could be used in the wallet to encrypt a user's private keys or by the block generator module to store the generator keys.
This LIP defines a new schema to be used to serialize transactions. The main change is to replace module and command identifiers by the corresponding names, which are of type string. This LIP also updates the terminology used for transaction and transaction properties.
Grigorios Koumoutsos & Maxime Gagnebin
The purpose of this LIP is to describe the updated Lisk SDK architecture including the block lifecycle and hooks with related new terminologies.
Join the Lisk Research Forum
Become a crypto researcher yourself, participate in our discussions and actively shape our research direction.