Skip to content

Latest commit

 

History

History
93 lines (77 loc) · 5.82 KB

BEP-319.md

File metadata and controls

93 lines (77 loc) · 5.82 KB
Raw
  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

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

The existing allocation steps are as follows:
  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

Due to the deposition of the SystemRewardContract being in the client, requiring hard forks for each change, and for ease of governance, it is moved to the smart contract. The adjusted allocation logic is as follows:
  1. Validators collect transaction fees from within the block and deposit all into the ValidatorContract.
  2. Deposit systemRewardRatio of transaction fees into the SystemRewardContract, where systemRewardRatio is governable, with an initial value of 1/16.
  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.3 Maintain Burn Ratio

The real-time burning mechanism constitutes a pivotal element within the BNB deflationary strategy. With the inception of the burn mechanism in BEP-95, a fractional segment of the SystemRewardContract balance was earmarked for relayer incentive fees, while the burn ratio was calibrated to approximate 10% of the collected block transaction fees. The present BEP adheres to the consistency established in BEP-95, upholding a burn ratio of 10%.

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.