# 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 Ti,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 Ti,n+1 and waits until it's time to generate the (n+1)th block.
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 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:
generationSignaturen = signVRF(VRFn – 100, privateKeyn),
VRFn = verifyVRF(generationSignaturen, VRFn – 100, publicKeyn).
The first 8 bytes of the
VRFn value are reversed and converted to Xi,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
generationSignaturen 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:
- Tmin = 15 000 ms is a constant defining the minimum block interval;
- C1 = 70 is a constant that adjusts the shape of interval distribution;
- C2 = 517 is a constant to adjust
- Xi,n is the hit derived from the
VRFof nth block;
- Xmax = 264 – 1 is the maximum possible hit (8 bytes);
- bi,n is the generating balance of ith account in WAVELETs;
- Λn is the
baseTargetof nth block, that is the adaptive ratio, regulating the average interval between blocks.
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 Tavg for producing the three preceding blocks (n – 3, n – 2, n – 1):
- if Tavg > 90 s, then Λn = Λn-1 + max(1, Λn-1/100);
- if Tavg < 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 264 /
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