# Waves Finality

The initial proposal is available at [this document](https://docs.google.com/document/d/1qYFlbTJrmMRfYeBHKr_-_QzDR1i9FlUF5hut0VoDcKM/edit?pli=1&tab=t.0).

To enhance finality on the Waves blockchain, the following additions to the existing PoS protocol are proposed:

1. Explicit Generators Set:
The set of generators is formed dynamically based on commitments made by participants. Generators must post information on the blockchain about their active periods, ensuring transparency and accountability during block generation and validation.
2. Block Endorsement by Generator Set:
Blocks are signed not only by their generator but also by other generators in the set who approve the block.
3. Dynamic Finality Calculation:
Finality is determined based on the collected endorsements and the cumulative balance of supporting validators.

By implementing these improvements, the finality on the Waves blockchain can be reduced to just 1–2 blocks, significantly enhancing transaction confirmation speed and security.

## Current State of Waves Finality

Waves operates as a classic Proof-of-Stake (PoS) blockchain, where blocks are considered final once the cumulative balance of generators confirming them exceeds 51% of the total balance of all generators. At this point, no set of validators can create an alternative chain of blocks without surpassing this majority threshold.

Block confirmation occurs when other generators append their blocks on top of a given block, effectively endorsing it.

However, under the current Waves consensus, only the total supply of Waves is known. It is possible to calculate the cumulative balance of accounts exceeding the minimum threshold required to become a generator. Nevertheless, it is impossible to predict the exact cumulative balance of the generators actively competing to produce a block at any given moment.

As a result, the finality of the Waves blockchain has a probabilistic nature. There is always a possibility for a hidden group of generators, with a cumulative balance larger than that of the active generators, to form. Such a group could potentially create an alternative chain. Upon presenting this chain, existing generators would be forced to accept it, leading to a reorganization of the blockchain.

To mitigate this, we propose forming an Explicit Set of Generators.

## Explicit Generators Set

To establish an Explicit Generators Set, a new transaction type called the `Generation Commitment Transaction` will be introduced. Every generator committing to participate in block generation for the next `N` blocks must submit this transaction from their account. The transaction does not have a recipient and serves solely to register the generator’s commitment to the block generation process.

The `Generation Commitment Transaction` will contain the following fields in addition to the required ones:
• Starting height of the participation period
• Length of the participation period (in blocks)

This mechanism allows generators to commit to future participation periods by submitting transactions in advance. To ensure active participation, the length of the participation period may be limited, encouraging generators to maintain regular activity in the set formation process.

Additionally, the cost of the `Generation Commitment Transaction` may be relatively high to promote a conscious and deliberate commitment from participants.

Generators without an active `Generation Commitment Transaction` will not be permitted to generate blocks.

The cumulative balance of all generators will be dynamically calculated at any given moment by summing the generation balances of all accounts with an active `Generation Commitment Transaction`.

### Generation Commitment Transacton activation

Following the activation of the new feature introducing the Generation Commitment Transaction, a transitional period should be provided for generators to submit their initial transactions from their accounts.

Only after this period concludes should the presence of a commitment transaction be considered a requirement for block generation.

## Block endorsment by Generator Set

The second part of this proposal introduces additional endorsements from other generators for each produced block. Every active generator, upon receiving and validating a key-block, must send back a signature of the parent block to the generator of the key-block.

The key-block generator should validate the received signatures against its copy of the parent block. If the signatures are valid, the generator must include the collected signatures in a designated field of the next micro-block.

Upon receiving such a micro-block, other generators must validate the collected signatures, excluding their own. The current generator may stop accepting endorsement signatures once the cumulative balance of endorsing generators reaches 51% of the total generator balance. To achieve this efficiently, the generator can sort supporters in descending order based on their generation balance and prioritize including those with the highest balances first.

If there are no transactions available in the transaction pool, the generator should produce an empty micro-block containing only endorsement signatures.

## Dinamic Finality Calculation

The final part of this proposal introduces a mechanism for every validation node to maintain the Finality Stake for the most recent blocks. If the Finality Stake of a block reaches the Quorum Balance, defined as 2/3 of the cumulative generator balance, the block is considered final, meaning:
* Blockchain reorganization beyond this block is prohibited.
* The block cannot be excluded from the chain.
* Transactions within the block become irreversible.

The Finality Stake of a block is calculated as the sum of its generator’s balance and all endorsement balances recorded in the block. If a single block does not accumulate enough Finality Stake to reach the Quorum Balance, its stake is carried forward and added to the Finality Stake of its parent block. This accumulation process continues up the chain until the required quorum is met, at which point the parent block achieves finality.

## Detecting Alternative Block Endorsements and Punishing Malicious Behavior

A well-behaved supporting generator should refrain from signing multiple conflicting blocks that reference the same parent block.
However, malicious actors may attempt to endorse multiple alternative blocks and distribute their endorsements to different generators.
Due to the peer-to-peer nature of blockchain communication, such behavior may initially go undetected.

To detect and prevent such malicious behavior, the block endorsement structure includes the following fields:

* Supporter's public key
* Endorsing block height
* Endorsing block hash
* Signature (generated by signing the previous two fields)

By signing the combination of block height and hash, any attempt to endorse an alternative block can be detected after the alternative block fails to be included in the main chain.
While the hash of an alternative block might not be known, the inclusion of the block height in the endorsement makes it impossible for the supporter to deny the signature when it is later presented to other generators.

To report attempts to endorse conflicting blocks, a new transaction type called the `Violation Report Transaction` is introduced. This transaction contains the fraudulent endorsement and can be submitted by any network participant.

Upon receiving and validating a `Violation Report Transaction`, the generators must enforce the following penalties on the reported generator:
* Exclusion from the Generators Set:
The reported generator’s `Generation Commitment Transaction` is annulled. An annulled transaction cannot be replaced by a new one, meaning the malicious generator is excluded from the Generators Set until the end of
the participation period specified in the annulled transaction.

### Mitigating Slander with Economic Penalties

To discourage false reporting, the `Violation Report Transaction` should incur a high fee (e.g., 1 Waves). Transaction validation rules should ensure that the transaction is always accepted,
regardless of whether the report is valid or slanderous. However, any second attempt to report the same violation should fail and be rejected from inclusion in the blockchain.

Additionally, the fee for the `Generation Commitment Transaction` can be set ten times higher than the `Violation Report Transaction` fee. This fee should be refundable as a reward to well-behaving generators and serve as a reward to the reporter of the violation.

### Delayed Recommitment Penalty

It may be beneficial to deny the posting of a new Generation Commitment Transaction for a certain period after the violation. Without this measure,
a malicious generator could attempt to violate the rule closer to the end of their commitment period, minimizing the impact of the penalty.

## Surviving Long-Term Network Splits

In the event of a network split that divides the generator set into two nearly equal halves in terms of balance, neither part will be able to achieve finality for the blocks
produced during the split due to the lack of quorum in both partitions. This behavior is beneficial for network recovery, as it allows for block reorganization upon reconnection,
enabling finality to resume for newly generated blocks after the network is reunited.

However, the absence of finality for a long fork presents a challenge. Without a mechanism to address this, the new chain might never restore finality for blocks produced after the split.
Fortunately, Waves Finality accounts for this scenario through the expiration of Generator Commitments.
During a split, generators from each disconnected part of the network are unable to broadcast their Generation Commitment Transactions to the other part.
As a result, their commitments begin to expire over time due to a lack of updates. Once the commitments expire, the disconnected generators are removed from the Generators Set,
allowing the network to gradually restore the ability to finalize blocks.
To handle this situation effectively, we need to define both a minimum and maximum commitment length. This should be calibrated to ensure that finality can be restored after approximately
one to two weeks in the event of a prolonged split.

## Details to consider

### Supporters’ Signatures List

To optimize blockchain storage and reduce the space required by the signatures list, the following approaches should be considered:
* BLS Aggregated Signatures:
Utilizing BLS signature aggregation can significantly reduce the size of the signature list by combining multiple signatures into a single compact representation.
* Threshold-Based Signature Collection:
Once the 51% threshold of the supporting generators’ cumulative balance is reached, additional signatures can be omitted. Supporters should also cease sending their signatures once they have collected the required number from other generators, preventing unnecessary network congestion and resource usage.