Skip to content
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
merged 23 commits into from
Jul 9, 2024

Conversation

michaeldjeffrey
Copy link
Contributor

Reference: HIP-122

DataTransferAndPocAllocatedRewardBuckets and CalculatedPocRewardShares

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 of DataTransferAndPocAllocatedRewardBuckets 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 and HexPoints

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 receives 4,000 coverage points.
But they are stored { base: 400, boosted: 3,600 }, because the radio receives 3,600 additional points thanks to Service Provider Boosting.

hex_boosting.rs test file

Tests 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

  • 3 IndoorWifi radios
  • 2 boosted hexes at 20x and 10x
Old Expected Reward New Expected Reward
20x boosted 31,729,243,786,356 19,223,263,075,722
10x boosted 15,864,621,893,178 16,295,862,607,338
No boost 1,586,462,189,317 13,661,202,185,792

The boosts contributed significantly less than before.

test_poc_with_multi_coverage_boosted_hexes

  • 3 Indoor Wifi Radios
  • 2 boosted hexes at 10x, 1 at 20x
Old Expected Reward New Expected Reward
1 at 20x boosted 23,990,403,838,464 14,455,028,799,291
2 at 10x boosted 23,990,403,838,464 24,479,397,430,217
No boost 1,199,520,191,923 10,245,901,639,344

Covering more hexes is much more valuable than a strong boosted hex.

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
- `HexPoints` to public so the doc comment can be seem
bumper rails retracting
@michaeldjeffrey michaeldjeffrey force-pushed the mj/hip-122-restrict-boosting-from-poc-bucket branch from 4c65a4d to d9ae734 Compare July 3, 2024 21:03
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.
@michaeldjeffrey michaeldjeffrey merged commit 5606471 into main Jul 9, 2024
19 checks passed
@michaeldjeffrey michaeldjeffrey deleted the mj/hip-122-restrict-boosting-from-poc-bucket branch July 9, 2024 18:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants