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:
-
Making Fast Finality rewards governable while maintaining the basic block transaction fee allocation ratio.
-
Ensuring a more balanced distribution of Fast Finality rewards between epochs.
-
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:
-
Validators collect transaction fees from within the block.
-
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.
-
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:
-
Validators collect transaction fees from within the block and deposit all into the ValidatorContract.
-
Deposit finalityRewardRatio of transaction fees into the SystemRewardContract, where finalityRewardRatio is governable, with an initial value of 1/16.
-
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.