Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
The CalculateOwnerRewards function is currently the most performance intensive part of DeFiChain, this function calculates the coinbase, loan, commission and custom pool rewards for a liquidity owner from when their address was last used to the current usage which triggers this call. When calculating rewards, every single block since between the last usage and now is checked with the coinbase, loan, commission and custom pool rewards calculated for the address' liquidity against the total liquidity. This is heavy, especially if the address has not been used for a long time and has liquidity in multiple pools.
This PR greatly simplifies this process by avoiding working through each block a time. On each block we workout the coinbase, loan, commission and custom pool reward for each liquidity share in the pool and save this against a running total stored with the current height. When an address is used we get this total from the last time the address was used and the current total, deducting the last usage total from the current we can see the reward per liquidity share for this period and use that to reward the address for however many liquidity shares it has.
Rather than work through each block and run calculations for each reward type, we get the two totals from the last usage block to the current block for each reward type and calculate the rewards. There is additional work storing these totals on each block, but this can be considered negligible and a reasonable trade off.
Implications
Storage
Consensus