Proposal: Optimize calculation performance of vote reward withdrawal in Phase1

[halibobo1205]

Simple Summary

This proposal aims to activate the #79 network parameter to optimize the calculation performance of vote reward in Phase1 (since TIP-53, to TIP-465, speeding up the calculation execution of vote reward withdrawal related transactions, and improve the performance of the TRON network, for more details, please refer to TIP-635.

Motivation

The Phase1 (since TIP-53, to TIP-465) reward algorithm time complexity is O (maintenance period * vote witness number), which increases linearly with the number of maintenance period rounds. As a result, executing the rewards-related transactions sometimes takes more than 1s, which reduces the transaction volume of blocks. The above problems can be optimized by using the TIP-635 proposal.

How to Initialize the Voting Request

• Open the new vote reward calculation algorithm proposal.
  • createProposal 79 1

Performance Analyze

Since TIP-465 was already in effect, the performance improvement of the corresponding proposal is shown below:

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

For the expected performance improvement of this proposal, according to statistics, about 160k users on the TRON mainnet currently have Phase1 rewards to be withdrawn. By comparing the performance of the Phase1 reward calculation before and after optimization in the test environment, this optimization plan is expected to improve performance by >20 times.

[KrisdiaPaul]

As discussed in Tip-635, the calculation only improve the withdrawal speed of vote reward in phase 1 without influencing the reward value, this proposal should be introduced.

[WalterBrooks]

The performance improvement is obvious, this proposal will definitely strengthen the network, expect to see the actual effect.

[Danyalkasiri]

#649

[ExOCeo]

So the change is about system performance, stakers have nothing to worry about as it is seamless from the user side. The most affected voting reward could accumulate as many as more than 4000 periods. Currently, it takes more than half a second to execute when withdrawing, which may lead to transaction expiration or worse, I hold the optimization is quite necessary.

[SevenPie-R58zz]

20 times faster will greatly improve the reward withdraw experience, and it has no impact on the inflatation of TRX or whatsoever, great work. How about the compatibility or stability after the upgrade, also wondering if the phase 1 has any impact on network security. Based on TIP 635, only off-chain third-party implement should worry about the compatibility issue. Again, great work for reducing the time complexity to O(n).

[brooklynn1212]

Though the vote reward generated before tip465 no longer increase, the calculation still becomes heavier as time goes by. Before it takes to much resource and time, it is necessary to make this proposal effect. The developer is able to detect this potential risk and use a way that has least impact to solve it, good job.

[Ademillery]

Yes, if several of the 160k users' vote reward withdrawal transaction take place in short time, it may cause the chain choked, and the risk is growing due to the previous calculation complexity O(maintenance period * vote witness number). Glad to have this proposal approved before it is too late.

[jernganl]

The proposal is not only improve the speed of calculation, and also is higher precision.
User rewards will be closer to the expected value without multiple decimal truncations.

[ikirudoughnuts]

The vote reward for now is already calculated in low complexity method, and this proposal will make the calculation method of vote reward before about 2023 consistent with now. That makes sense, and users will benefit from this proposal without changing api calling. I see no harm, agreed.

[laurenceja]

This proposal enables a full implementation of TIP-465 which makes all withdraw reward transactions can be finished within a time complexity of O(1). The calculation performance has been greatly improved.

[hitlxy]

From the performance analyze, if the number of maintenance period is 3000, the execution time before the proposal takes effect may reach 5 seconds, that is exceed the block time (3 seconds), so it's nessaray to enable the proposal as soon as possible.

[CooperDepp]

It's kind of performance optimization proposal, and should be approved with no doubt. A new algorithm is introduced only to speed up the calculation process rather than changing the result, users' reward remain the same just more faster when executing withdrawal transactions.

[brooklynn1212]

20 times faster will greatly improve the reward withdraw experience, and it has no impact on the inflatation of TRX or whatsoever, great work. How about the compatibility or stability after the upgrade, also wondering if the phase 1 has any impact on network security. Based on TIP 635, only off-chain third-party implement should worry about the compatibility issue. Again, great work for reducing the time complexity to O(n).

The new proposal will not have any impact on network security in phase 1 as explained here: https://github.com/tronprotocol/tips/blob/master/tip-635.md#data-consistency

[souppopnix]

The vote reward withdrawal transaction will become faster, and moreover the block would be able to contain more transactions, so the throughput of network is also expected to increase. Keeping optimizing such transactions is indeed a way to improve TPS.

[halibobo1205]

The optimized results are as follows:

transaction	avg(TP99)	max(TP99)
UnfreezeBalanceContract	8.29 ms(before 418 ms)	49.5 ms(before 9.95 s)
WithdrawBalanceContract	23.7 ms(before 252 ms)	148 ms(before 8.13 s)
VoteWitnessContract	15 ms(before 88.8 ms)	435 ms(before 3.75 s)