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 nth 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 nth 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 nth block is calculated using the following formula:

where

• T_min = 15 000 ms is a constant defining the minimum block interval;
• C₁ = 70 is a constant that adjusts the shape of interval distribution;
• C₂ = 5¹⁷ is a constant to adjust baseTtarget;
• X_i,n is the hit derived from the VRF of nth block;
• X_max = 2⁶⁴ – 1 is the maximum possible hit (8 bytes);
• b_i,n is the generating balance of ith account in WAVELETs;
• Λ_n is the baseTarget of nth 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 nth block, and depends on the average time T_avg for producing the three preceding blocks (n – 3, n – 2, n – 1):

• if T_avg > 90 s, then Λ_n = Λ_n-1 + max(1, Λ_n-1/100);
• if T_avg < 30 s and Λ_n-1 > 1, then Λ_n = max(1, Λ_n-1 – max(1, Λ_n-1/100));
• Λ_n = Λ_n-1 otherwise.

Choosing the Primary Chain

The primary chain of blocks is selected based on the score parameter. The score of a block is 2⁶⁴ / 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