Integrate mobile rewards v2 #843
Merged
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
HIP-119 introduces a new set of tables for location trust scores based on `(radio_type, distance_to_asserted)`. This also allows for a new minimum trust score multiplier of `0x`.
This value is now contained within the function `asserted_distance_to_trust_multiplier` in the coverage point calculator.
All location trust scores used to be 1.0 or 0.25. HIP-119 adds 0.00 as a multiplier possibility based on distance.
Location Trust Scores are no longer reduced based on the presence of a boosted hex. However, having an average distance from an asserted location past 50m can cause a radio to be ineligible for boosted rewards.
Both constants have to do with service provider boosting in regards to a radios location trust scores. Namespacing allows for not needing to shove all possible context into a top level name.
It didn't feel quite correct to have half the service provider boosting code in lib.rs and the other in location.rs. The constants have to with location trust scores, but they do not get used there.
The distance to asserted no longer changes trust scores in the presence of a boosted hex. Service provider boosting eligibility is determined from the distance to asserted, that is tested at the top level of this crate.
The only difference was the location distance from asserted and assigned location trust multipliers. Refactoring heartbeat seeding further is left as an exercise to the next person who has a need to change these tests.
…osting HIP-119 removes the part of calculating coverage points that degrades a trust score when a radio covers a boosted hex and is more than 50m away from their asserted location. Now, being +50m away from an asserted location makes a radio not eligible for receiving service provider boosted rewards. They continue to receive the full force of their location trust score. Being an Indoor radio 100m away from an asserted location is enough to keep a location trust multiplier of 1.0x, but not receive boosted rewards.
Adding links to multiple places so you don't have to know a secret location where they exist.
andymck
approved these changes
Jul 16, 2024
Both were answered yes
CBRS is always trusted for location. The location trust score is intercepted earlier when validating heartbeats. If for some reason CBRS radios do make it to this function, they will receive a good trust score anyways.
Assignment used to be a nested message inside the oracle_boosting_hex_assignment message. It's being referenced in mobile_rewards_v2, so it's been pulled out.
use `as_bps()` instead of `into_inner()` for the symmetry with `as_mbps()` and to prevent compulsory use of `into_inner()` and wanting a different type.
Put the cumbersome transformations in a helper crate to help keep transforming from a calculator CoveragePoints to proto a little neater.
Both will live in the proto for a while until we fully move over to v2. To still be done is using the v2 reward for test assertions before we can fully move over.
Until RadioReward v1 stop being output, we can compare the poc_reward fields of both version, they should be the same always. (maybe off by a bone, but that would be a special case indeed.)
Because `beacon` is in the helium-proto repo, when you want to test a different branch you need to update both entries. It is a convenience that they are moved closer together.
A blank v2 looked confusing in the diff.
michaeldjeffrey
force-pushed
the
mj/integrate-mobile-rewards-v2
branch
from
3847545 to
0cf5a3b
Compare
HIP-119 added average distance to asserted further than threshold reason for a radio to not receive boosted rewards.
Both `mobile_reward` and `mobile_reward_v2` will be written out for 90 days. Within that 90 days, Indexer will switch to using `mobile_reward_v2` as the source of reward values, then `mobile_reward`s will stop being written. If both messages were used radios would be double rewarded.
michaeldjeffrey
force-pushed
the
mj/integrate-mobile-rewards-v2
branch
from
2735b4e to
6cc51cb
Compare
bbalser
approved these changes
Jul 16, 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.
Proto PR: helium/proto#407
Reward::RadioRewardandReward::RadioRewardV2will be written out for 90 days.poc_rewardmatch between the two.poc_mobile::oracle_boosting_hex_assignment::Assignmenthas been moved a top level enum atpoc_mobile::OracleBoostingAssignmentbecause Assignments are listed in the v2 radio reward.