New Protocol Features

Network Economics

LIP0002: Change to byte based block size limit

We set a maximum block size of 15KB (kilobytes), replacing the current maximum of 25 transactions per block. This size will maintain the yearly blockchain growth below 50GB, even when blocks are always at full capacity and the active delegates do not miss any blocks. A blockchain created with Lisk SDK 4.0.0 can include over a 100 balance transfer transactions in a block and process up to around 1,000,000 transactions in a day.

LIP0026: Establish block validity by applying transactions sequentially

We change the rule for ordering transactions within a block. Previously, transactions were ordered automatically according to a set of complex rules. After this improvement, the transaction order can be freely chosen by the block producer, and a block is valid if every transaction is valid against the transitory state leading up to it.

LIP0013: Replace static fee system by dynamic fee systems

The new dynamic fee system allows users to freely choose a suitable fee for their transaction as long as this fee equates to the minimum fee required for the transaction type and size. This system supersedes the previous fixed fee rules, resulting in a significantly lower fee for all transaction types except delegate registrations. A part of the transaction fee will go to the delegate who forges the block including the transaction, whereas the other part of the transaction fee is burned.

LIP0016: Implement fee estimation algorithm for dynamic fee system

We introduce a fee estimation algorithm based on an Exponential Moving Average (EMA). The suggested fee depends on the network usage and urgency of the transaction. The algorithm is implemented in a node of the Lisk network, and the wallet queries its output to get the transaction fee estimation for the user.

LIP0025: Introduce minimum balance requirements for accounts

We introduce a new rule for which accounts will also be required to maintain a minimum balance of 0.05 LSK. This prevents spamming of the database by creating many accounts with almost no balance (dust accounts), abusing the greatly reduced transaction fees introduced with the dynamic fee system.

LIP0017: Make multisignature accounts more flexible, prevent spamming and prevent signature mutability

The multisignature system has been enhanced and improved. 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 prevents spamming of the network and the transaction pool. Next, the settings for the account rules become more flexible. For instance, it is now possible to create m-out-of-n multisignature accounts, requiring m signatures from a set of n public keys. 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.

LIP0015: Ensure transaction invalidation by using nonces instead of timestamps

We replace the timestamp property of a transaction by an ordered nonce. This allows invalidating a pending transaction by issuing a new transaction reusing the same nonce, but with a higher fee (thus with a higher chance of getting included in a block first). Furthermore, an invalidation mechanism ensures that a transaction is not included at a later stage, for example in the case of a user transmitting a transaction into the network without receiving any feedback.

Network Consensus

LIP0003: Uniform ordering of delegates list

We change the ordering of delegates forging slots in a round. The delegate slot is calculated by hashing each delegate’s unique ID together with a unique ID for the round, resulting in a uniform shuffling of the active delegates list. Delegates will be uniquely ordered according to these hash values.

LIP0023: Introduce vote locking periods and new weight definition

The voting system for selecting the block forgers has now been improved. Users now have to lock the tokens they want to use for voting, and a LSK token can only be used to vote for one delegate simultaneously. Additionally, the delegate weight computation now takes into account how many tokens delegates have locked in order to vote for themselves. By requiring that the delegate weight must contain at least 10 % of self-votes, we ensure that delegates have a significant amount of tokens at stake which further increases the security of the network.

LIP0022: User Randao-based scheme to include standby delegates and reorder delegate list

With this improvement the forging delegates list will include two standby delegates of each round. The round length is extended from 101 to 103 blocks and the 2 additional blocks slots are assigned to standby delegates using a random selection algorithm proportional to the delegate weight, which ensures both the unpredictability and fairness of the process.

This change is designed in order to incentivize a greater number of online nodes in the Lisk network.

LIP0024: Punish BFT violations

We introduce a new “Proof of Misbehavior” transaction to punish violations of the Lisk BFT consensus protocol, such as forging multiple conflicting blocks in the same time slot. This transaction contains the information necessary to prove the violation. The misbehaving delegate is punished by having their weight set to 0 for 3 months. Furthermore, tokens used to vote the misbehaving delegate are locked for a period of 1 month, to give voters a strong economic incentive to choose their delegates carefully. Delegates that have been punished 5 times are banned and can not forge anymore.

Further Improvements

Convert lisk-elements mocha test to jest

All of the lisk-elements mocha tests have now been migrated to jest. Due to the simplicity of the jest framework, it enables zero configuration, easy to mock, isolated and parallelized test runner with inbuilt code coverage, and furthermore is well documented.

Remove BigNum dependency in favor of BigInt by nodejs

With the introduction of NodeJS 10, native support for BigInt data type is now available. Therefore, it was decided to remove the external forked dependency BigNum and use the native BigInt.

Update to use yarn for monorepo management

It should be noted that although lerna is proficient at managing monorepo, a multitude of problems were encountered with regard to the slow bootstrapping, incorrect package auditing and package-lock conflicts. Therefore yarn will now be used for monrepo management.

Resources for Betanet v4

In the previous Betanet v3 Lisk Desktop was ready to support it, however this time around we had to make a compromise to release the Betanet without a corresponding working UI product to accelerate the release of the final Lisk Core 3.0.0 to the Mainnet. Therefore access will now be via Lisk Commander. A supported Lisk Desktop version will be released after Betanet v5 around the beginning of next year.

The Lisk Faucet was updated to 3.0.0-beta.1 to support the Betanet changes. Furthermore, the Lisk SDK documentation and Lisk Core documentation has been updated to reflect all new changes made.

Known Issues

We have already identified a few issues in Lisk SDK 4.0.0 which have now been rectified in Lisk SDK 5.0.0. To avoid duplicated testing feedback from our community, we have provided a list of known issues below:

1. An error occurred during synchronization #5742
   The synchronizer was designed not to be triggered multiple times, however it was triggered, which created the error.
2. An error failed to restore blocks from the blocks temp table when starting a fresh node #5807
   When there are temporarily saved blocks existing and a node is then started, it should choose to restore the blocks or delete them, however this error occurred.
3. The synchronizer can run twice at the same time #5828
   The synchronizer was designed not to be executed multiple times simultaneously, however it attempts to continue running.
4. Unused payload properties can increase overall parsing of the messages #5212
   Adding additional properties in the P2P communication increases the time to parse the object, which leads to unnecessary resource usages.

The road ahead with Lisk SDK 5.0.0

The development and internal alpha testing for Lisk SDK 5.0.0 have now been successfully completed. At present, the external security audit for Lisk SDK 5.0.0 is in progress. Meanwhile, we are simultaneously working on the Lisk SDK 5.1.0 release goals.

See the Lisk protocol roadmap and our new Lisk Core development schedule for more information on our release procedure.

For further questions and comments regarding the new Lisk Betanet v4, we will host an AMA on Lisk.chat with Shusetsu Toda (Lead Backend Developer), and Manu Nelamane Siddalingegowda (Lead Backend Developer), on Friday 13th November at 3pm CET.

Lisk is on a mission to enable you to create decentralized, efficient, and transparent blockchain applications. Join us:

• Lisk Chat
• Lisk SDK Page
• Research Page
• Lisk Dev forum
• Lisk Research forum
• Twitter