halibobo1205 / tips Goto Github PK

tip: 635
title: Optimize Reward Withdrawal To Improve TPS
author:  [email protected]
discussions-to: https://github.com/tronprotocol/tips/issues/635
status: Draft
type: Standards Track 
category: Core
created: 2023-12-21

Simple Summary

This TIP aims to optimize the algorithm of the voting reward withdrawal in Phase 1 (after TIP-53 before TIP-465) to improve performance for increasing the TPS of such transactions.

Abstract

There are currently two phases of the TRON protocol voting reward:

• Phase 1: After TIP-53 before TIP-465, The voting reward withdrawal is calculated cumulatively, and the time complexity is o(n).
• Phase 2: After TIP-465, its voting reward withdrawal adopts an efficient calculation method, and the time complexity is o(1).

Due to the poor performance of the current Phase 1 voting reward withdrawal algorithm, when a user has both Phase 1 and Phase 2 rewards, the current Phase 1 reward withdrawal algorithm will slow down the overall performance of the transaction.

This TIP proposes an optimization plan that optimizes the relevant calculation complexity to o(1) for Phase 1 without modifying the reward calculation method, greatly optimizing the calculation performance of Phase 1 reward, and thereby improving network TPS.

Motivation

Performance

According to statistics, there are currently about 16W users on the TRON main network who have Phase 1 rewards to be withdrawn. By comparing the performance of the Phase 1 reward algorithm before and after optimization in the test environment, it is expected that this optimization plan can improve performance by >20 times.

User Income

The current Phase 1 voting reward withdrawal uses truncation at the end of the decimal, resulting in the current actual result being slightly smaller than the theoretical value. The optimized algorithm will adopt higher calculation accuracy, and the calculation results will be closer to the theoretical values. At the same time, the difference in results before and after optimization will be controlled within 1 TRX, which will have almost no impact on the TRX inflation of the entire network and users.

Specification

Glossary

In Phase 1 and Phase 2, the calculation logic of voting reward for a single SR vote is as follows:

• Phase1.algorithm1: 
  userReward(s) = for i range [startCycle, newRewardCycle) { userReward(s) += userVote( s)/totalVote(i, s) * totalReward(i,s)}

• Phase2.algorithm:
  userReward(s) = voteCount * (accumulateRewardPerVote[newRewardCycle-1,s]- accumulateRewardPerVote[endCycle-1,s])

Phase1.algorithm1 uses an iterative method to distribute calculations for each maintenance period and then accumulates them. The algorithm complexity is o(n). Phase2.algorithm directly multiplies the number of votes and the cumulative reward value of the corresponding interval to obtain the total reward amount, and the algorithm complexity is o(1). Please refer to TIP-465 for more information.

The optimized Phase1.algorithm2 will use the same algorithm as Phase2.algorithm. Based on the previous analysis, this optimization will be divided into the following steps:

1. Precalculate the cumulative reward of a single vote for all SRs in Phase 1 in each maintenance period, and store it persistently. At this time, all Phase 1 reward-related transactions continue to use the algorithm1 algorithm.

2. Use the proposal to control whether the optimized algorithm2 algorithm should be adopted for Phase 1 rewards.

3. After the proposal is passed, Phase 1's voting rewards will use the algorithm2 algorithm, which will use the intermediate data persisted locally by the node to calculate the result with O(1) performance. The difference between the calculation result and the original Phase1.algorithm1 algorithm is within 1 TRX.

Note: The TRON protocol's voting reward can be triggered by a variety of transactions. Any address will automatically trigger voting reward collection when executing the following transactions:

• VoteWitnessContract

• UnfreezeBalanceContract

• UnfreezeBalanceV2Contract

• WithdrawBalanceContract

Rationale

Switching Impacts on Ecology

• For the total amount of TRX: the core calculation logic of the optimized Phase 1 reward algorithm is consistent with the current Phase 2 reward algorithm. This optimization aims to improve the performance of the current algorithm. At the same time, the new algorithm improves the calculation accuracy while maintaining the same core calculation logic. This optimization plan has almost no impact on the circulation and inflation of the entire TRX.

• Regarding user benefits: since higher precision is used, user benefits will be closer to the theoretical value. When each user receives Phase 1 earnings, the losses caused by the tail-removal algorithm used previously will be reduced. However, since there is not much difference in the calculation results before and after optimization, this optimization has little impact on users.

Data Consistency

The most critical feature of the blockchain is the consistent ledger. This solution optimizes the voting reward calculation logic and affects consensus. Therefore, proposals are needed to control the switch to ensure data consistency on the chain.

Pre-calculation of voting reward for each maintenance period before TIP-465

In order to minimize the impact on node performance, precalculation is performed asynchronously. Asynchronous tasks often have some state synchronization problems, so the execution logic of precalculation tasks needs to be described in detail here.

1. Monitor service: When the node starts, it will start a monitor service, which will be detected every 3S. This service is responsible for detecting whether the TIP-465 proposal is enabled.

• if enabled: execute precalculation asynchronously

  • Determine whether precalculation has been completed based on finishFlag.
    • If completed, perform data consistency verification, monitor service stops, return
    • If not Unfinished: Start precalculating task, monitor service stops, return

• Not enabled: enter the next detection

2. Precalculation tasks:

   1. calculate SR single vote accumulated reward value during the maintenance period between TIP-53 to TIP-465
   2. store the calculation results in the new database RewardViStore, the data composition is consistent with TIP-465
   3. write finishFlag
   4. perform a data consistency check

Transaction Execution

Check if there is any Phase1 voting reward

• If there is: check whether the new proposal is effective

  • effective: Check whether the precalculation task is completed

    • completed: transaction adopts new execution logic
    • not completed: blocked waiting for the precalculation task to be completed, and the transaction adopts new execution logic

  • not effective: the transaction maintains the original execution logic

• if there is not: the transaction maintains the original execution logic

Backwards Compatibility

According to the previous explanation, this solution has no compatibility issues with on-chain functions.
Please note that if any application party implements a similar voting reward estimation algorithm outside the chain, please adapt the changes promptly.

Implementation