Protocol Roadmap

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.

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

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.

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

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

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.

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

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.

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.

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.

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.

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.

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.

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

Increase the length of transaction IDs to avoid collisions.

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.

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.

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.

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

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