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

HIP15: Beaconing Rewards #51

Closed
jamiew opened this issue Oct 8, 2020 · 4 comments
Closed

HIP15: Beaconing Rewards #51

jamiew opened this issue Oct 8, 2020 · 4 comments
Labels

Comments

@jamiew
Copy link
Contributor

jamiew commented Oct 8, 2020

Author: @Carniverous19
Initial PR: #49
Start Date: 2020-10-07
Category: Technical

Rendered view:
https://github.com/helium/HIP/blob/master/0015-beaconing-rewards.md

Summary:
This proposal suggests a change to proof-of-coverage (PoC) from multihop to beaconing as well as a change in how PoC is rewarded that combines HNT mining for witnessing and PoC into one pool and gives the bulk of the reward to hotspot witnessing or receiving RF payloads vs transmitting RF payloads.

@Carniverous19
Copy link
Contributor

Carniverous19 commented Oct 10, 2020

I simulated rewards for nearly all active hotspots as of ~10/1/2020.

For a map of simulation see: https://carniverous19.github.io/expected_rewards_HIP15.html

A distribution of rewards for all hotpots (ignoring max earner at 26 reward units):
image

Notes on Data

This simulated only looked at hotspots in the USA (or near the border, filtering is based on lat/long bounding box).

Hotspots are colored by "Reward Units". This linearly translates to HNT rewarded (if hotspot A has 2x the reward units of hotspot B its expected to earn 2x the HNT as hotspot B). The colors go from red to green corresponding to low to high rewards. There are 10 distinct colors divided up reward percentile. The cutoffs for each percentile are below:

10% cutoff at 0.266 reward units
20% cutoff at 0.652 reward units
30% cutoff at 1.007 reward units
40% cutoff at 1.553 reward units
50% cutoff at 2.133 reward units
60% cutoff at 2.759 reward units
70% cutoff at 3.434 reward units
80% cutoff at 4.167 reward units
90% cutoff at 5.082 reward units

Clicking on a hotspot will give a popup with the following information:
image

First line is the hotspot name
rew. units: is the simulated number of reward units a hotspot earned.
rew. pct: this is the rewards percentile range the hotspot falls into (same as color)
#wits: this is the number of valid witnesses the hotspot has (not necessarily the number of hotspots it witnessed). Valid witnesses are > 300m, < 50km, and have a status of "online"

How I simulated

I took two sets of actual witness lists over a 1 week timeframe and combined them (this was to avoid hotspots with recently reset witness lists looking isolated). With real-world witness lists I estimated hop reliability based on observed network-wide averages (see Known simulation limitations). With this real-world witness lists and estimated witness reliability I simulated 500 transmits for each hotspot, selected witnesses based on witness probabilities, and rewarded the transmitter and all witnesses according to the reward formula presented in this HIP. I normalized rewards to be per transmit (divided by 500). Since this HIP recommends targeting all hotspots at an equal rate this simulation is representative of long term HNT distribution.

Known simulation limitations

  • I do not filter out witnesses that fail PoCv10 these will be rewarded in simulation.
  • I filtered out any hotspot with > 250 witnesses assuming these would be flagged by the PoC timeout and are likely invalid (Modesto).
  • I estimate witness reliability based on distance to transmitter. This reliability is roughly based on observed network-wide witness reliability but may not be representative for specific hotspots or witnesses. A plot of reliability vs distance is below:
    image

@Carniverous19
Copy link
Contributor

I dont want to directly compare todays rewards to simulated hotspot rewards as there are too many assumptions in simulating that are not reflective of real world behavior for each individual hotspot.

A very simple comparison just to "gut check" the expected change is below:

1835/4724 hotspots see >20% increase in rewards with beaconing (38.8%)
1567/4724 hotspots see >20% decrease in rewards with beaconing (33.2%)
1322/4724 hotspots see < 20% change in rewards (28.0%)

So in general 33% of hotspots may see a drop in earnings of 20% or more after the switch and ~67% will see increased earnings or roughly unchanged earnings after this HIP is implemented assuming the simulation is completely representative. (see caveat above). Overall I would not expect this change to be massively disruptive to the majority of hotspots' earnings.

@maco2035
Copy link
Contributor

I think this proposal will also help the consensus groups. Because without the complexity of multi hop, there can be an increase of connesous membership. This helps strengthen the network, because you currently only need to take down a few hotspots to bring the network to a halt.

I think we should go with it. Even though with my hotspots I will have a drop in earnings. I think it is better for the network.

@jamiew
Copy link
Contributor Author

jamiew commented Oct 29, 2020

Rough consensus among the community was discussed and ratified at the October 2020 community call: https://docs.google.com/document/d/1bMm2alBigBj3detA775Dn0Gz9UM5XczAeK9vnjBB3l0/edit#bookmark=id.1isrxrlxktk9

Next steps are writing an actual implementation, reviewing, testing and deploying

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants