Proposal: Enable new reward calculation algorithm

[bladehan1]

Simple Summary

This proposal aims to activate the #67 network parameter to use a new reward calculation algorithm, speed up the execution of reward calculations related transactions, and improve the performance of the TRON network, for the new reward calculation algorithm, please refer to: TIP-465.

Motivation

The current reward algorithm time complexity is O (maintenance period * vote witness number), which increases linearly with the number of maintenance period rounds. As a result, it sometimes takes more than 1s to extract rewards-related transactions, which reduces the transaction volume of production blocks. The above problems can be resolved by recording the accumulated reward per ticket of each witness in the maintenance period, simplifying the cross-cycle calculation, and reducing the time complexity to O (number of vote witnesses).

Timeline

Any opinions or discussions about this proposal are welcomed.

The estimated timeline

• Creation time of the voting request: January 17, 2023
• The effective time of voting request: January 20, 2023

How to Initialize the Voting Request

• Open the new reward calculation algorithm proposal.
  • createProposal 67 1

Performance Analyze

In order to quickly calculate the multi-maintenance period rewards, the cumulative per-ticket rewards are introduced to record the accumulated rewards per ticket during a maintenance period. The reward per ticket during the current maintenance period equals the witness reward during the maintenance period divided by the number of tickets, and the cumulative reward per ticket is the prefix sum of the reward per ticket during the maintenance period.

The interval per-ticket reward equals the sum of per-ticket rewards at the end of the maintenance period minus the sum of per-ticket rewards at the start of the maintenance period. The reward for a per witness equals the interval per ticket reward multiplied by the number of votes, so the calculation complexity of the reward is O (the number of voting witnesses).

[crayfishbang]

100% agree!

[txoh1603]

It is also helpful for explorer and DAPPs which provide stake and voting function. they need to query the voting reward more frequently, and this high efficient algorithm help to improve these product's performance.

[Jackmrshen]

With the increase of voters on TRON and the implementation of Stake 2.0, the calculation of workload during maintenance period is heavy. Optimization of algorithm is necessary to keep the maintenance period stable. Please go ahead and check more minor problems brought by Stake 2.0 to fix in advance.

[jernganl]

The new algorithm reduces the maintenance time, which is a great idea.

[Bellgin]

It sometimes takes several secs to get it through when claiming my rewards, I was expecting failed transaction somehow. Hope this new method will help and make it fast and stable.

[SevenPie-R58zz]

So excited about the potential of reducing time complexity, can't wait to see how this will speed up the reward related transaction.

[ethan1844]

Thanks to everyone's contribution to this proposal.

This issue will be closed as it is already going to effect, check detail at: https://tronscan.org/#/proposal/82

[bladehan1]

At present, this proposal has been effective for 10 days, comparison of average execution time of unstake related transaction before and after the proposal is shown as follows:

The Number of Maintenance Periods	Average Execution Time Before the Proposal Takes Effect	Average Execution Time After the Proposal Takes Effect
1000	1 - 1000 ms	0.08 ms
3000	1000 - 5000 ms	0.09 ms

The result meets expectation, and I will continue to follow up performance of this proposal.