Lisk Research – Quick Overview of LIPs 2 and 3

In today’s article we give a quick overview of Lisk’s LIPs 2 and 3.  The first one proposes to change the model for the block size limit and the latter suggests a new way of ordering the delegate list.

The LIP 2 proposal came from Iker Alustiza and Nazar Hussain and it consists in the replacement of the literal 25 transactions per block size limit with a byte based block size limit. They argue that, since the Lisk protocol is evolving and becoming more and more popular, a significant activity and usage of the network is expected. In order to fulfill this request, a more flexible and higher productivity throughput would be needed.
The actual system is also in conflict with the varying byte size of each transaction type that can be managed in relation with any given block.

For this reason they propose a byte based block size limit. Specifically, the size is set to 15 kilobytes in order to maintain the yearly blockchain growth below 50 gigabyte (precisely 47.3 gigabyte per year).

Below we have a table of the space used from each transaction type, according to the transaction sizes given in the protocol documentation:

Below you can see a table with the comparison of the number of transactions per day before and after:

The LIP 3 proposal came from Iker Alustiza and it resolves two issues affecting the delegate list uniformity revealed in occasion of the implementation of the Lisk protocol. He has developed a way to homogeneously order the delegates list by hashing each delegate’s unique identifier together with a unique identifier for a round.

He explained that currently there is a bug in the way that the order of the delegates list is generated for every round. Specifically, delegates that hold the positions  from 1 to 54 have 50% more chance to be chosen in the loop process than the others.

The solution proposed by Iker will ensure that every delegate’s position in the list is recalculated every round, so every delegate has the same probability to end up in any position for all possible solutions.

According to the proposal, each delegate’s unique identifier must be hashed together with a unique identifier for the round. Iker suggests two possible ways: 1) The delegate’s unique identifier can be his public key or ID ; 2) The round’s unique identifier can be the height of the block in which the new round starts or the height of the round itself. Regarding the first way, Iker thinks that it is better to use the public key since the ID system might be changed in the future, even though this choice must be made during reference implementation. Anyway, he specifies that both options generate randomness in equal way.

———————————————-
Lisk Magazine is a project supported by Lisk Italian Group and EliteX.
Support our work, vote for Lisk Magazine.