The objective has been defined on the protocol roadmap
The objective is currently being researched and discussion around the topic has started or has been completed
One or more LIPs tackling the objective are published on the LIPs GitHub repository for further review
The reference implementation for the objective is currently being developed
The reference implementation for the objective has been proposed to the Lisk Betanet or Testnet
The Lisk Mainnet accepted the proposal and the objective has been completed
Security and Reliability
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.
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.
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.
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.
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.
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.
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.
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.
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.
Make the Lisk-BFT consensus protocol more flexible by introducing the possibility to set different validator weights for finalizing blocks and allowing these finality weights to change over time. For interoperability, Lisk-BFT also has to generate compact proofs for a finalized state that can be used on other chains.