# # LPoS — Leased Proof of Stake

Every blockchain network requires a consensus mechanism that enables independent nodes to agree on the present state of the blockchain. In simpler terms, consensus is a process that ensures data integrity by guaranteeing that all nodes have the same copy of the blockchain data and all transactions are valid.

A significant part of the consensus mechanism is an algorithm that selects which network participant is qualified to generate the next block and which chain of blocks in the primary one in case of a fork. The algorithm must be fair to all participants and resistant to attacks.

The Waves protocol uses the Leased Proof of Stake (LPoS) consensus algorithm, which is a variation of Proof of Stake (PoS). Like in other PoS types, the larger the participant's economic stake in the network, the higher its chance of winning the right to generate the next block is. Unlike Proof of Work, Proof of Stake is an eco-friendly algorithm that does not require massive computing power and energy costs. The holders of the system tokens are motivated to maintain the network security and increase the token value.

One unique aspect of the LPoS protocol is that ordinary users can participate in block generation by leasing tokens to generating nodes. Nevertheless, the token owner retains full control of their tokens and can cancel the lease at any time. Generating nodes can pay a part of their rewards to lessors. More about leasing

## # Core Concepts of Waves LPoS

- A node's chance of generating the next block is directly proportional to its economic stake in the network.
- For a node to participate in the block generation process, its generating balance must be at least 1000 WAVES.
- The generating balance is calculated as the lowest balance in WAVES considering leasing in the last 1000 blocks. This rule prevents any attempts to manipulate the block generation process by moving funds between accounts.
- There is no way to predict which account will win the right to generate a block next. This rule is in place to prevent manipulation by attacking the generator or intentionally missing the chance to create a block.
- The targeted average interval between blocks is 60 seconds.

## # Choosing Next Block’s Generator

After receiving the (*n*-1)th block over the network, each generating node *i* calculates a time delay *T _{i,n}* before it can generate the

*n*th block. This time delay is based on node's generating balance, block intervals, and a pseudo-random number, which will be explained in more detail below.

If another generator releases its block earlier and node *i* receives the *n*th block before creating its own, the process restarts. Node *i* calculates a new delay *T _{i,n+1}* and waits until it's time to generate the (

*n*+1)th block.

### # VRF

VRF (Verifiable Random Function) is a pseudo-random function that provides a keyed cryptographic hash. Only the private key holder can calculate the hash, but anyone with the corresponding public key can verify its correctness. The use of VRF ensures that the selection of the block generator is unpredictable, as it requires knowledge of the private key to calculate the hash.

The VRF implementation includes the `signVRF`

function, which calculates the hash of a given message using an account's private key:

*proof = signVRF*(*message, privateKey*).

It also includes the `verifyVRF`

function, which verifies the hash using the message and the public key of the signer, and returns a deterministic VRF value:

*VRF = verifyVRF*(*proof, message, public key*).

### # generationSignature

`generationSignature`

is a block parameter that is calculated using the `VRF`

value from the block of height 100 less and the private key of the block generator:

*generationSignature _{n} = signVRF*(

*VRF*),

_{n – 100}, privateKey_{n}*VRF _{n} = verifyVRF*(

*generationSignature*).

_{n}, VRF_{n – 100}, publicKey_{n}The first 8 bytes of the `VRF`

_{n} value are reversed and converted to *X _{i,n}*, which is known as a hit. This hit is used as a random number to calculate the block delay for generator

*i*. The validity of the hit calculation can be verified using the

`verifyVRF`

function. However, the hit cannot be predicted until `generationSignature`

_{n}is published, as its calculation requires the generator's private key.

### # Block Delay

The time delay, in milliseconds, that account *i* must wait after generating the (*n* – 1)th block before it can generate the *n*th block is calculated using the following formula:

where

*T*= 15 000 ms is a constant defining the minimum block interval;_{min}*C*_{1}= 70 is a constant that adjusts the shape of interval distribution;*C*_{2}= 5^{17}is a constant to adjust`baseTtarget`

;*X*is the hit derived from the_{i,n}`VRF`

of*n*th block;*X*= 2_{max}^{64}– 1 is the maximum possible hit (8 bytes);*b*is the generating balance of_{i,n}*i*th account in WAVELETs;*Λ*is the_{n}`baseTarget`

of*n*th block, that is the adaptive ratio, regulating the average interval between blocks.

### # baseTarget

`baseTarget`

is a block parameter that adjusts the average block interval, bringing it closer to 60 seconds. `baseTarget`

is the same for all generators attempting to create the *n*th block, and depends on the average time T_{avg} for producing the three preceding blocks (*n* – 3, *n* – 2, *n* – 1):

- if
*T*> 90 s, then_{avg}*Λ*(1,_{n}= Λ_{n-1}+ max*Λ*/100);_{n-1} - if
*T*< 30 s and_{avg}*Λ*> 1, then_{n-1}*Λ*(_{n}= max*1, Λ*(1,_{n-1}– max*Λ*/100));_{n-1} *Λ*otherwise._{n}= Λ_{n-1}

## # Choosing the Primary Chain

The primary chain of blocks is selected based on the `score`

parameter. The `score`

of a block is 2^{64} / `baseTarget`

, and the score of a chain is the sum of its blocks' scores. If multiple alternative chains appear (it's called a fork), the chain with the highest `score`

becomes the primary chain.

In more detail, nodes exchange the `score`

of their chains with each other. If node A detects that node B has a higher-scoring chain, it checks whether it can switch to that chain. To accomplish this, node A sends the IDs of the last 100 blocks in its chain to node B.

If node B identifies a block among them that it also possesses, it sends the IDs of the latest common block and all subsequent blocks in its chain to node A.

Node A then removes the blocks on top of the common block, requests new blocks from node B by their IDs, and applies them.

## # Protocol Development History

The Waves network initially utilized the Proof of Stake model proposed by Nxt.

In July 2018, the feature #8 "Fair PoS" adjusted the PoS formulas to ensure that the choice of block generator is fair and resistant to attacks. More information about Fair PoS

In September 2020, the feature #15 "Ride V4, VRF, Protobuf, Failed transactions" introduced a method of calculating a block's `generationSignature`

using VRF to make the choice of block generator unpredictable. Learn more about the transition to VRF