HIP5: POC fairness/epoch reward limit

[jamiew]

Authors: @tjain-mcc

Original PR: #19

Rendered view: https://github.com/helium/HIP/blob/master/0005-poc-fairness.md

Summary from HIP:

Proof of coverage challenge participation rewards are too concentrated for the top few hotspots. This has led to a concentration of mining rewards which are not ideal for the proliferation of the Helium Network.

I propose that we cap the number of challenges any given hotspot can participate in during a single Epoch.

[Carniverous19]

Some potential concerns:

1. PoC paths are planned well before they are executed so you dont get the receipts on whether a certain hotspot successfully completed a previous PoC before a new one is planned. So you cant really determine "hotspot H already passed X challenges this epoch so I wont send another". I think that would require significant changes to how PoC paths are calculated.
2. Since a lot of PoC paths fail early in the chain you really cant assume a planned PoC is executed, the 4th and 5th slot has like a < 5% chance of even reaching there.
3. Its possible this could penalize neighboring hotspots. For example, a subset of hotspot owners invest $$ and effort into upgrading their antennas and roof mounting with low loss cabling this could allow these "tent-pole" hotspots to communicate with neighbors that otherwise woudl be isolated. If you limit the PoC's these "tent-pole" hotspots can participate in you possibly limit cause the nearby hotspots to be ineligible to participate in a PoC if they are targeted after other neighbors.

You could implement the cap a posteriori by only considering the first X successful receipts from a hotspot in an epoch so those that are "tent-poles" can still be targeted and verify their neighbors they just wont be rewarded after a certain number. This could cause some issues as some malicous hotspot owners (or malicous DIY owners) could just not forward potential challenge messages after X + some margin (Not sure why they would do this, slightly decrease # of PoC receipts thus slightly increasing the reward for each receipt?) The general issue doing this after the fact is hotspots are being asked to do work they will not be rewarded for.

A modified version of this is to reward hotspots based on the length of time between successful PoC's. If a hotspot passed a PoC 5 minutes ago the knowledge gained by it passing a PoC again is small (If you were up and running 5 min ago, its likely you are still up and running). If it has been an hour since your last PoC then the knowledge of a passed PoC is higher since the odds that a hotspot is no longer reachable after an hour is higher than 5 minutes. So you basically pro-rate rewards based on last valid receipt. This give a hotspot a reward each time it does work and can all be calculated a posteriori when rewards are calculated. It is significantly more complicated math than just capping # of reciepts.

[tjain-mcc]

I tried to update my HIP to say that hotspots would not be rewarded for participating in more than 1 challenge per epoch rather than participate in more than 1 challenge per epoch. Not sure why it isn't showing up

[Carniverous19]

You shouldn't limit to 1 challenge, especially not this early, why not 2 or 3 or 5? certainly there is advantage to some redundancy and those hotspots that can reach more than 1 hotspot should get some reward. With just 1 PoC rewarded you will get hotspots paired off with yagi's pointed at eachother. You want to encourage wide, omidirectional reach.

Still some limit may be worthwhile. Certainly 20 PoC's in an epoch is a bit extreme but I would leave the limit as a generic number "N" for now without more analysis into what "N" should be. I would say 1 is too low to encourage healthy, redundant coverage

[tjain-mcc]

I think limiting rewards to 1 challenge is ok but the hotspot should be able to join as many challenges as possible. But there is nothing the network gains by rewarding a hotspot for more than 1 challenge per epoch. The network already knows that the hotspot is providing useful coverage, why does it need to pay for that info again in the same epoch?

[Carniverous19]

@tjain-mcc Why would a hotspot care to participate in more than 1 challenge? a single PoC verifies a point in time and coverage along a line. There is certainly some value in verififying at different points in time and along different lines. It also gives the hotspot a reason to forward PoC packets. A lot of PoC packets are pretty large compared to organic LoRa sensors so it is somewhat easy to detect them and just drop them late in an epoch or after a hotspot determines it has participated in a few already. with only 1 challenge per epoch reward it is in a hotspots best interest to prevent future PoC's from going through it and not participate. DIY makes this easier to control

[tjain-mcc]

What about diminishing rewards for multiple challenges in an epoch? More technical complexity which I dislike but addresses your concern.

[Carniverous19]

@tjain-mcc Yes I like that, it also acts as a soft limit you could do something like each additional PoC is worth X% the previous. This could even be some relative high percentage like 80% and still be effective.
For example:

PoC/Epoch	Reward %	Total Reward %
1	100	100
2	80	180
3	64	244
4	51	295
5	41	336
10	13	446
15	4	482
20	1.4	494

With each PoC worth 80% the previous a hotspot performing 20 PoCs per epoc would be rewarded 5x the amount as one PoC (while doing 20X the work).

At low end there is still significant reward for each additional POC in the 1-4 range so it still encourages redundant coverage and more regular verification.

could be 90% or 75% or 50% we should look at these numbers a bit more if this is a direction people want to go for this HIP but In general I like it! even more than a hard cap.

[lthiery]

To visualize:

As for the idea, to be clear, I think it is implying that a Miner wouldn't earn anything for doing over 20 POCs / epoch (but would probably do the work still). The table makes it easy to implement the decaying reward structure for end of epoch calculation (I would think) so I like that.

Does the table version number add a chain var?

[Carniverous19]

Hi @lthiery ,

So with the chart I just gave some example counts to make it easier to understand (like your chart!). My idea is this would continue for any number of PoC's so the 50th PoC would earn 0.0018% the reward of the first PoC. It is essentially a geometric sum which is asymptotic to 1/(1-X%) so an 80% will plateau at 5x (500%). 95% will plateau at 20x (2,000%) even with an infinite number of PoC's. This has the advantage that a hotspot gets rewarded for every PoC just a smaller and smaller amount. An example of various possible decay values:

Zoomed in on 10 challenges per epoch:

I would say this would introduce a single chain var which would be this "X%" or the decay for each additional PoC. It shouldnt be too difficult to implement as well although you would have to match receipts to hotspot participants and perform the weighing in order get a sum of the "effective" PoCs per epoch to know how to divide up rewards. This is also a bit more complicated as they actually split PoC into 3 segments (RF receipt, RF transmit, and Delivering receipt over P2P). Should each segment be weighted seperately (ie if I receive RF 3x the 3rd gets 64% weight but if I only successfully transmit once that gets 100%).

Overall though I think this is definitely a good way to address these tent-pole hotspots getting extremely high rewards without providing much additional value. Like you say after a few PoC's we know they are there providing coverage, after that they are just a vessel for other hotspots to prove coverage.

[lthiery]

Fair enough! Decaying function is succinct.

I have an aversion for floating point calculations from doing mostly embedded development so I always like a good look-up table, but in this case, brevity/simplicity seems nicer.

[Carniverous19]

For justification beyond "owner XXX is getting too much reward we want more!" I do think there is less valuable in verifying a hotspot every minute or even multiple times a minute. The hotspot is doing work (participating in the PoC and is providing extra, redundant verification of its location but the value to the network of this repetitive verification is diminished the more often it is verified.

Its like a 5 year old sitting in a car during a road trip asking "are we there yet". Asking every 30-40 minutes seems reasonable, time has passed, things might have changed. Asking every 10 seconds is annoying as obviously the answer is the same as it was 10 seconds ago.

A modification to the proposed decay that may acknowledge that the work of verifying neighbors by participating in a path is still valuable would be to set a lower limit on the incremental value of PoC of something like 1-15% of the normalized value of a PoC. This would eliminate the asymptote and end up giving constant but small reward for each additional PoC once the decay hits this min threshold.

[anthonyra]

For justification beyond "owner XXX is getting too much reward we want more!" I do think there is less valuable in verifying a hotspot every minute or even multiple times a minute. The hotspot is doing work (participating in the PoC and is providing extra, redundant verification of its location but the value to the network of this repetitive verification is diminished the more often it is verified.

Its like a 5 year old sitting in a car during a road trip asking "are we there yet". Asking every 30-40 minutes seems reasonable, time has passed, things might have changed. Asking every 10 seconds is annoying as obviously the answer is the same as it was 10 seconds ago.

A modification to the proposed decay that may acknowledge that the work of verifying neighbors by participating in a path is still valuable would be to set a lower limit on the incremental value of PoC of something like 1-15% of the normalized value of a PoC. This would eliminate the asymptote and end up giving constant but small reward for each additional PoC once the decay hits this min threshold.

With this when you mention PoC I'm assuming you're talking about PoC challengees? Or will this also affect the PoC witness group?

[anthonyra]

My HIP 5 that builds off of my proposed HIP 10 distribution of the Data Network Transfer pool:
See HIP 10 for full post: #32

This proposal for HIP 5 suggests a change to the Beneficiary for the PoC challenger reward pool specifically by applying a restriction to what a Rural / Single Hotspot should be considered and splitting the Consensus Group into two individual parties. It also recommends a change in the limitation on a hotspot in regards to being a challenger.

The current limitation for being a challenger is that each hotspot on the network can only be a challenger for a PoC proof once an epoch. Removing the grouped hotspots will drastically reduce the overall PoC proofs being submitted to the blockchain. To compensate I suggest allowing the Consensus Group Candidates (currently at 2528) the ability to fill in the rest.

For Example:
If there are only 1600 hotspots that now meet the new definition of Rural / Single Hotspots on the network they would only supply 1600 PoC proofs that epoch. The remaining 5400 proofs could come from the Consensus Group Candidates meaning most will average roughly 2 challenges created per epoch.

With the 33.45% each challenger will earn roughly 0.16 HNT per epoch.

This will provide virgin coverage area hotspots (Rural / Single Hotspots) better incentives than currently and also provide known good hotspots (Consensus group worthy hotspots an additional incentive for having a high S word)

New Definitions:
Rural / Single Hotspot: Are hotspots that have not successfully been a challengee or witness to any PoC proof before.
Consensus Group Candidate: Meets the requirements to be a Consensus Group Selectee but doesn't get selected for the current Consensus Group.
Consensus Group Selectee: One of the members of the Consensus Group.

New HIP 10 with HIP 5 Proposed Distribution: Per Month
| Reward Pool | % | HNT | Beneficiary
| --- | --- | --- |
| PoC Challengers | 33.45 | 1,672,500 | Rural / Single Hotspot, Consensus Group Candidate |
| PoC Witnesses | 8.55 | 427,500 | Grouped Hotspot, Consensus Group Candidate, Consensus Group Selectee |
| PoC Challengess | 18 | 1,963,604 | Grouped Hotspot, Consensus Group Candidate, Consensus Group Selectee |
| Consensus Group | 6 | 300,000 | Consensus Group Selectee |
| Data Network Transfer | 0.0010 | 50 | Rural / Single Hotspot, Grouped Hotspot, Consensus Group Candidate, Consensus Group Selectee |
| HST Holders | 34 | 1,700,000 | N/A |
| Total | 100 | 5,000,000 | --- |

With the HIP 10 distribution and the new limitation on the beneficiary per reward pool in regards to PoC challengers the max a grouped hotspot could acquire per month is now at 24.55% instead of 58%. Consensus Group and Rural/Single hotspots will have an increased reward pool in the interim where network traffic hasn't reached its max at 32.5%. However, once data traffic does catch up than those rural hotspots will become useless in terms of minting HNT.

[Carniverous19]

Interesting idea @anthonyra and I need to read it again but there are some general concerns that have been mentioned before about such a large percentage going to challenge creation:

• One is that its a very low value activity that will completely break when you allow DIY hardware. DIY hardware will allow me to "claim" to deploy thousands and thousands of hotspots in the vast swaths of rural areas in the USA (and soon around the world) with an AWS account. So heavily rewarding challengers will block allowing DIY.
• This also heavily rewards hotspots that are in the wrong country! You noticed a few hotspots showing up in the UK, mainland Europe, some in Asia before Helium went live there. These are US hotspots that someone imported. These will never provide any meaningful RF coverage because they use the wrong frequencies for their region yet will get a slice of 50% of the HNT for hotspot owners just for existing... These hotspots should not be rewarded.
• Since it is a low value activity it is giving a significant reward to hotspots that dont provide any real valuable coverage, they get rewarded simply for existing but they can be setup in someones basement without an antenna, or far from a window etc such that sensors couldnt get coverage even if they are nearby. These poorly placed hotspots would be earning ~50% of mined HNT available to non HST holders for providing zero valuable network coverage. With the reward for existing being low these hotspot owners would be more motivated to actually ensure they are providing real RF coverage.
• Single lone hotspots aren't reliable coverage. I get the motivation to encourage people to seed new areas but a single hotspot in a new town does not provide any meaningful coverage. There is no redundancy to the coverage and anyone relying on getting LongFi in that area is 100% dependent on a single individual to maintain that coverage. That hotspot owner may move, or decide to place the hotpsot differently. Or even with the hotspot staying in position someone might park a car in between the single hotspot and a sensor blocking coverage. You need redundancy even over the same area for the coverage to really be reliable, thus I like PoC as it (ignoring gaming for now) ensures overlap in RF coverage from hotspots in different locations.
• Some areas just arent valuable and shouldn't be rewarded for covering. Very rural areas with low population and low economic activity likely are less valuable than denser areas. If only one person in an area is willing to buy a single hotspot then there is unlikely to be sufficient demand for LoRa devices for it to matter that there is coverage. Some areas of the US and world wont be profitable to put a hotspot there. That is a benefit of the system if it discourages placement in low value areas. Also if it is a valuable rural area (say there is a large logistic distribution center in the area, or farming industry that fully adopting LoRa based smart technology). Then the data throughput reward or multiple hotspots entering the area to capitalize on that unique case will be the motivation to deploy.

At the end of the day, significant reward for challenge creation just wont happen, and I think there is enough to encourage growth of the network into new areas as long as more than one hotspot can be deployed.

TLDR: challenge creation is very easy to game, provides almost no value to the network and shouldnt be highly rewarded. Also lots of rural areas just arent valuable and its ok that the network doesnt motivate growth in those areas.