update doc about burn ratio in BEP-319

BEPs/BEP-319.md

@@ -63,16 +63,10 @@ Due to the deposition of the SystemRewardContract being in the client, requiring
 
 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, 9.375% of the deposited amount is burned directly, and the remainder serves as potential earnings for validators and stakers.
+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 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.
+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:
 ```