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 114: Service Provider Rewards #856

Closed
wants to merge 29 commits into from
Closed

HIP 114: Service Provider Rewards #856

wants to merge 29 commits into from

Conversation

maplant
Copy link
Contributor

@maplant maplant commented Aug 23, 2024

Abstract

This HIP allows for service providers to allocate some percent of their dedicated rewards to promotions, which are received via the ingest bucket.

At reward time, any unallocated rewards left in the service provider bucket will be used to match the promotion rewards, up to 100%. If there is not enough unallocated rewards to match all of the promotion rewards, they will be scaled.

Unallocated Reward Scaling

We scale the unallocated rewards by the amount of total rewards given by the service providers. Therefore, if a service provider rewards their entities a total of half of all promotion rewards given, they will be given half of the unallocated rewards regardless of their percentage.

Examples:

Service provider: Rewards Given: Percent: Promotion Rewards: % of unallocated rewards given:
Sp1 12 50% 6 2/3
Sp2 6 50% 3 1/3
Service provider: Rewards Given: Percent: Promotion Rewards: % of unallocated rewards given:
Sp1 12 50% 6 1/2
Sp2 6 100% 6 1/2
Service provider: Rewards Given: Percent: Promotion Rewards: % of unallocated rewards given:
Sp1 10 100% 10 1/3
Sp2 1,000 2% 20 2/3

Things left to complete in this PR:

  • Testing needs to be added and fixed
  • Currently, the updates to the Solana chain are in the develop branch and not in master, so we can't deploy this until after that occurs
  • Some refactoring needs to be done on the actual rewarding, it's a bit of a mess as it stands right now

@maplant maplant requested a review from bbalser August 23, 2024 21:06
@bbalser
Copy link
Contributor

bbalser commented Aug 26, 2024

I believe you forgot to commit file_store/lib/promotion_reward.rs

mobile_verifier/migrations/36_promotion_rewards.sql Outdated Show resolved Hide resolved
mobile_verifier/src/promotion_reward.rs Outdated Show resolved Hide resolved
mobile_verifier/src/promotion_reward.rs Outdated Show resolved Hide resolved
mobile_verifier/migrations/36_promotion_rewards.sql Outdated Show resolved Hide resolved
mobile_verifier/src/promotion_reward.rs Outdated Show resolved Hide resolved
mobile_verifier/src/promotion_reward.rs Outdated Show resolved Hide resolved
the lines are left commented because it's useful when debugging a single test.
when using an agg function like sum(), if a name is not provided, the
column will be called 'sum'.

I'm not sure why, the type of the summed column with a numeric column,
which is incompatible with an int8 field that maps to a i64 in rust.
@michaeldjeffrey
Copy link
Contributor

Closed in lieu of #867

michaeldjeffrey added a commit that referenced this pull request Sep 30, 2024
michaeldjeffrey added a commit that referenced this pull request Sep 30, 2024
michaeldjeffrey added a commit that referenced this pull request Sep 30, 2024
michaeldjeffrey added a commit that referenced this pull request Oct 2, 2024
michaeldjeffrey added a commit that referenced this pull request Oct 3, 2024
* Add promotion funds workspace

This workspace is all about dealing with Service Provider Promotion Fund
allocation.

HIP-114
https://github.com/helium/HIP/blob/main/0114-incentive-escrow-fund-for-subscriber-referrals.md

Service Provider Promotions are stored in CarrierV0 on Solana.
To keep the mobile-verifier from talking to a chain, this service will
periodically check Solana and compare Service Providers allocations to
what is stored in S3.

If the values have changed, a new file will be output to a bucket for
the mobile-verifier rewarder to read from.

NOTE: Allocation Values are stored in Bps (Basis Points)
https://www.investopedia.com/terms/b/basispoint.asp

** Commands

*** ./promotion_fund write-solana

Fetch Allocation values from Solana and write them to S3.
This command _always_ writes an S3 file.

*** ./promotion_fund print-s3

Using the lookback time in the provided settings file, show the
Allocation values this service would start up with.

*** ./promotion_fund server

Start a server that reads from S3, then checks with Solana periodically
for updated Allocatino values. Writing new files when needed.

* Supporting material for promotion_fund workspace

- ingest promotion rewards, nothing will be done with them until the
  processor is added into mobile-verifier.
- dump reward files
- add sp_allocations dummy field to rewarder output
- reward indexer mobile promotion type added

* use existing reward_types for reward_indexer

Otherwise inserting a new reward would match on the address and
continually change the reward_type column for no reason.

* update proto

* Add Continuous struct helper for file_source

Default trait impls cannot be added to functions, but they can be added
to structs. This struct keeps us from needing to do the gross blank
generic filling in when we want a continuous file source with a decode
other than MsgDecodeFileInfoPollerParser.

* Add the Service Provider Promotions Daemon

* Swap over Service Provider rewards to use percents

Rather than always dealing with conrete numbers, now that Service
Providers can allocate a percentage of their rewards to promotions for
subscribers or gateways, it becomes easier to speak of everything in
percentages.

This is a quick overview of what a more detailed overview you will find
in the PR.

For every Service Provider (SP) we figure out how much of the total
rewards allocation they are being awarded for data transfer. We get the
percent they have allocated for promotions (essentially from solana, but
really s3), and we determine which percentage of the _total rewards
allocation_ that is.

If a SP is getting 50% of the total rewards, and they allocate 20% of
those rewards to promotions, then the SP will receive 40% of the total,
and promotions from them will represent 10% of the total.

We do that for all SPs. The unallocated percentage is then distributed
to the promotions of each SP. If there is more than enough unallocated
left over, each SP get's a matched percentage of the whole to what they
set aside. When there is not enough, they get a percentage equal to
their initial rewards percentage.

This is to keep a service provider from getting the bulk of extra
rewards by settings aside a large amount for promotions, and receiving
little in rewards for data transfer, but getting more for matching.

A SP may never receive more in matched rewards than they have allocated
themselves.

* Wrap everything in a service provider type

This makes invocations of rewarding look very consistent

* Update tests to use new service_provider code

* remove unused code

* use wrapped types for promotions

* add back promotion_fund cli

* port over existing tests

* service provider reward info collection can hold onto the reward date

* add test with seeded promotions

* the nature of the math has changed

because we're dealing with percentages, and not doing bankers rounding
or nearest even, the likelihood that a calculation comes out extremely
close to a hole number then gets rounded down is increased. Especially
when dealing with percentages to the 7th decimal point and a base number
in the trillions.

* make sure we're cleaning up promotions

* stub for reporting sp allocations

I'm hoping there's an easy way to do this someone can point me to

* rename collection class for consistency

it get a bit verbose with all the service_provider flying around, but I
think it will be rather helpful when you only have the type and it
hasn't been aliased.

* fix up uncompiled tests

* add tests from good examples in original PR

#856

* if for some reason a key is duplicated, absorb both

* add proptests for service provider rewards

* Found a rounding error

truncating to 5 decimal places for a % can result in the summed
allocation exceeding 100%.

Thanks proptest

* Discussion has been had

It has been noted that in tests a single bone is okay, as long as we're
not going over the allocated bones

* commit commit

let's not have the worst of both worlds where we comment out unused
code.
Remove the printlns, they're not hard to add back in if you need them.

* fill out service provider reward allocations in reward_manifest

* Service Providers can use multiple keys for dc_transfer

For accounting reasons, Service Providers can have multiple payer keys
listed. We need to ensuure all their dc transfer are accumulated into
their service provider entry when we are generating rewards.

* fixup cargo deps after rebase

* Change promotion_fund to promotion-fund

* Read Service Provider Promotion values from unique bucket

- Add settings `promotion_ingest`

---------

Co-authored-by: Brian Balser <bbalser@nova-labs.com>
@michaeldjeffrey michaeldjeffrey deleted the map/hip-114 branch October 18, 2024 16:05
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.

5 participants