BEP: 319
  Title: Optimize the incentive mechanism of the Fast Finality feature
  Status: Draft
  Type: Standards
  Created: 2023-11-13
  Discussions(optional): https://forum.bnbchain.org/t/bep-319-make-rewards-for-fast-finality-governable/2174

BEP-319: Optimize the incentive mechanism of the Fast Finality feature

• BEP-319: Optimize the incentive mechanism of the Fast Finality feature
  • 1. Summary
  • 2. Abstract
  • 3. Motivation
  • 4. Specification
    • 4.1 Governable Rewards
      • 4.1.1 Existing Allocation Logic
      • 4.1.2 Allocation Logic Moved to the Contract
      • 4.1.3 Maintain Burn Ratio
  • 4.2 Balancing Rewards
  • 4.3 Extending Submission Deadline for Malicious Voting Evidence
  • 5. License

1. Summary

This BEP proposes three optimizations to the incentive mechanism of the Fast Finality feature in BSC.

2. Abstract

The proposal focuses on three key optimizations for the incentive mechanism of the Fast Finality feature:

1. Making Fast Finality rewards governable while maintaining the basic block transaction fee allocation ratio.
2. Ensuring a more balanced distribution of Fast Finality rewards between epochs.
3. Extending the submission deadline for malicious voting evidence.

3. Motivation

The introduction of the Fast Finality feature in BSC significantly reduces the time required for transaction final confirmation. This feature represents a substantial advantage for BSC compared to other EVM-compatible chains. The purpose of this BEP is to solidify and enhance this advantage.

4. Specification

4.1 Governable Rewards

Currently, the reward is approximately 1/16 of the block transaction fees, leading to a lack of incentive for some validators to participate in voting, thereby reducing the stability expectation of the Fast Finality feature. This BEP makes Fast Finality rewards governable, laying the groundwork for future reward enhancements.

4.1.1 Existing Allocation Logic

1. Validators collect transaction fees from within the block.
2. In the client, if the balance of the SystemRewardContract is less than 100 BNB, 1/16 of the collected transaction fees is allocated as rewards for relayers and Fast Finality voting. The remainder is deposited into the ValidatorContract.
3. Within the ValidatorContract, 10% of the deposited amount is burned directly, and the remainder serves as potential earnings for validators and stakers.

4.1.2 Allocation Logic Moved to the Contract

1. Validators collect transaction fees from within the block and deposit all into the ValidatorContract.
2. Deposit finalityRewardRatio of transaction fees into the SystemRewardContract, where finalityRewardRatio is governable, with an initial value of 1/16.
3. Within the ValidatorContract, 9.375% of the deposited amount is burned directly, and the remainder serves as potential earnings for validators and stakers.

4.1.3 Maintain Burn Ratio

The real-time burning mechanism is an essential part of the BNB deflation plan. In this BEP, the goal is to maintain it essentially unchanged.
Before implementing this BEP, a portion of the balance of the SystemRewardContract will be used as a reward for Fast Finality voting at the end of each epoch, resulting in a balance less than 100 BNB. Therefore, in the majority of blocks, validators will deposit 1/16 of the block transaction fees to the SystemRewardContract.
The oldBurnRatio is 10%. The actual proportion of burned transaction fees to block transaction fees can be calculated approximately as follows:

newBurnRatio = (1 - 1/16) * oldBurnRatio = (1 - 1/16) * 10% = 9.375%

As a result, following the implementation of this BEP, the burn ratio is set to 9.375% directly.

4.2 Balancing Rewards

Fast Finality rewards are unevenly distributed between epochs. Assuming the current balance of the systemReward contract is currentSystemRewardBalance, and the balance after award distribution in the previous epoch is previousSystemRewardBalance, the totalReward calculation formula is as follows:

if currentSystemRewardBalance > 100BNB
  totalReward = currentSystemRewardBalance / 100
else
  totalReward = (currentSystemRewardBalance - previousSystemRewardBalance) * 0.5

This algorithm allocates a portion of the systemReward contract balance increment for each epoch, causing the systemReward contract balance to continuously grow. When it exceeds 100BNB, a reward exceeding 1 BNB is distributed at once, far more than other epochs.
The new formula is as follows:

if currentSystemRewardBalance > 100BNB
  totalReward = currentSystemRewardBalance - 100BNB
else
  totalReward = 0 // this rarely happens because validators keep depositing and relayers consume much less

This formula allocates the entire increment of the systemReward contract balance for each epoch, resulting in a more even distribution.

4.3 Extending Submission Deadline for Malicious Voting Evidence

When rule-violating votes occur, the current requirement is to submit evidence within 256 blocks; otherwise, rewards cannot be obtained, and malicious validators are not penalized.
This BEP proposes making the submission deadline governable, initialized to 3 days, for increased operability.

5. License

The content is licensed under CC0.