-
Notifications
You must be signed in to change notification settings - Fork 21
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
HIP-122 restrict boosting from poc bucket (#836)
* Store coverage points received by boosting separately This is preparing for being able to make sure boosted rewards do not take more than 10% of the reward shares. base_coverage_points will always be recieved, but boosted_coverage_points may receive less rewards per share depending on how many there are in a reward epoch. Note that boosted_coverage_points _do not_ contain base_coverage_points. * Add struct for containing allocated Rewards for Data transfer and POC If boosted rewards are above the allowed 10% of total emissions, the rewards per share needs to be recalculated _not including_ leftover DC from Data Transfer rewards. To make this easier, we store data transfer allocated rewards and resulting unallocated rewards separately from the 10% buckets for poc and boosting. * Move calucating reward shares for poc to coverage point calculator * Correct points for share calculation alway includes multipliers Points considered when doing math for shares for a radio should always include speedtest and location multipliers. * Use the AllocatedRewardShare struct for calculating unallocated data transfer rewards * Add caller to timeout message for file sink during debugging * Fix first hex_boosting intregration test - Add a way for receiving rewards from the mock sink to determine if it needs to await for an unallocated msg. - Derive the expected rewards from math outside the oracles repo * Fix second hex_boosting integration test This test really illustrates the preference for coverage over boosting. A hotspot covering 2 hexes can far surpass a hotspot covering a single hex with a strong boost multiplier. * Fix third hex_boosting integration test This tests math looks different because it's the first time we're dealing with different coverage point values from radios because of degraded location trust scores. * Fix fourth hex_boosting integration test This test almost exactly the same as `test_poc_with_multi_coverage_boosted_hexes` but the last radio is CBRS instead of a WIFI with a degraded location score. Interestingly, the coverage points work out to the same values between the differences. * Overview all changed tests - Break out getting the poc allocation bucket sizes. - Make sure math in comments checks out. - Try to make the math for rewards look similar enough to feel good. * Move reward share calculation where it belongs - coverage_point_calculator -> reward_shares as it has to do directly with reward shares, and is not about calculating coverage points. - AllocatedRewardShares -> DataTransferAndPocAllocatedRewardBuckets * Add doc for CoveragePoints::coverage_points * remove whitespace * Unwrap calculating expected rewards in tests * Update formatting of comment for Doc.rs readability * Fix broken doclink - `HexPoints` to public so the doc comment can be seem * fully expose `HexPoints` members bumper rails retracting * remove public from helper member * rename points -> shares for poc rewards There will soon be a mobile rewards v2 proto. In which we better define what a "point" means. It was considered that Location Trust was part of a "coverage", that will no longer be the case. Points are the base value provided from covering a Hex, a "coverage point" if you will. Combining those points with location and speedtest multipliers, both things having to with the radio directly, we arrive at "shares". * coverage_points() -> coverage_points_v1() to call out location difference coverage points including the location trust multiplier, but not the speedtest multiplier has been a source of confusion. Shortly, that will no longer be the case. This method has been renamed to raise an eyebrow as to why it needs a v1 specifier. * Round POC rewards individually Despite talking about POC rewards as a combined number, this HIP pulls them from seperate buckets. Because the sources of rewards are seperate, the end values should be treated as discretely. * Round POC rewards individually Despite talking about POC rewards as a combined number, this HIP pulls them from seperate buckets. Because the sources of rewards are seperate, the end values should be treated as discretely. - make sure we wrap the math to be unambiguous that we're rounding the result to u64.
- Loading branch information
1 parent
13233e0
commit 5606471
Showing
8 changed files
with
808 additions
and
433 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.