-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HIP-122 restrict boosting from poc bucket #836
Merged
michaeldjeffrey
merged 23 commits into
main
from
mj/hip-122-restrict-boosting-from-poc-bucket
Jul 9, 2024
Merged
HIP-122 restrict boosting from poc bucket #836
michaeldjeffrey
merged 23 commits into
main
from
mj/hip-122-restrict-boosting-from-poc-bucket
Jul 9, 2024
Conversation
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 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.
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.
Points considered when doing math for shares for a radio should always include speedtest and location multipliers.
- 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
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.
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.
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.
- 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.
- coverage_point_calculator -> reward_shares as it has to do directly with reward shares, and is not about calculating coverage points. - AllocatedRewardShares -> DataTransferAndPocAllocatedRewardBuckets
maplant
reviewed
Jul 1, 2024
maplant
reviewed
Jul 1, 2024
maplant
reviewed
Jul 1, 2024
maplant
reviewed
Jul 1, 2024
- `HexPoints` to public so the doc comment can be seem
bumper rails retracting
bbalser
reviewed
Jul 2, 2024
michaeldjeffrey
force-pushed
the
mj/hip-122-restrict-boosting-from-poc-bucket
branch
from
July 3, 2024 21:03
4c65a4d
to
d9ae734
Compare
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".
…ence 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.
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.
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.
bbalser
approved these changes
Jul 9, 2024
maplant
approved these changes
Jul 9, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Reference: HIP-122
DataTransferAndPocAllocatedRewardBuckets
andCalculatedPocRewardShares
Data Transfer rewards used to be calculated to fit within the
MAX_DATA_TRANSFER_REWARDS_PERCENT
from the total scheduled tokens for an epoch. This has been moved to the construction ofDataTransferAndPocAllocatedRewardBuckets
so boosted poc rewards can be carved out of the poc allocation as soon as possible.After Data Transfer has been rewarded, the unallocated amount is rolled into the normal POC bucket with
reward_shares.handle_unallocated_data_transfer(dc_unallocated_amount);
.Unallocated Data Transfer rewards are allowed to increase the POC rewards, but not service provider boosted rewards.
(In the case where boosted rewards do not exceed 10%, nothing extra needs to be done.)
CoveragePoints
andHexPoints
To ensure we can do reward calculations with regard to the boosted poc pool, we store the points received from service provider boosting per hex separate from the points received by covering a hex.
Any time boosted points are used in code or comment they do not include base points from covering a hex.
Example:
An IndoorWifi radio with good SignalLevel receives
400
coverage points from a hex.If that hex is boosted
10x
, the radio receives4,000
coverage points.But they are stored
{ base: 400, boosted: 3,600 }
, because the radio receives3,600
additional points thanks to Service Provider Boosting.hex_boosting.rs
test fileTests where boosting did not exceed 10% of rewards were untouched.
For the rest, I attempted to recreate the math that derives the expected rewards for radios.
For a sense of how expected rewards changed with few radios and few hexes, some examples.
(These tests include the 40% data transfer bucket as well)
test_poc_with_boosted_hexes
20x
and10x
The boosts contributed significantly less than before.
test_poc_with_multi_coverage_boosted_hexes
10x
, 1 at20x
Covering more hexes is much more valuable than a strong boosted hex.