HIP5: POC fairness/epoch reward limit #24
Comments
jamiew
changed the title
|
Some potential concerns:
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. |
|
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 |
|
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 |
|
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? |
|
@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 |
|
What about diminishing rewards for multiple challenges in an epoch? More technical complexity which I dislike but addresses your concern. |
|
@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.
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. |
|
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? |
|
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. |
|
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. |
|
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? |
|
My HIP 5 that builds off of my proposed HIP 10 distribution of the Data Network Transfer pool: 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: 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: New HIP 10 with HIP 5 Proposed Distribution: Per Month 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. |
|
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:
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. |
Good point, I was talking about challengees but we should look at witness as well. |
This would be invalid if HIP 9 is implemented or the like. DIY Hotspots will fall under 4 levels: https://github.com/helium/HIP/blob/7b715a0614d4c529144e1d6c0083ee8b38c05b29/0009-non-helium-hotspots.md Level I: Network Observer - Which can only be rewarded with PoC witnesses. Meaning that they have to have active hotspots near them participating in PoC challenges. Level 2: Network Participant - PoC challenges are then activated. To get to this point, however, requires specific requirements to be met which will require significant work to abuse. Level 3A: Organic Network Challenger (OEM hotspots) Level 4: Consensus Candidates New HIP 10, HIP 5, and HIP 9 Proposed Distribution: Per Month With this break down above, as the network grow which it will the rewards are also minimized. For example, the Challenger pool rewards at 33.5% (which it'll decrease with network growth) is only 0.16 HNT per epoch with 7000 units. That's the most a rural hotspot will see until more neighbors show up. |
Sounds like there should be a validation check during the |
Imagine if you are a newcomer to Helium and created a "lone wolf" hotspot. You see with my proposed distribution roughly 40HNT a week. That means an ROI of about 6.4 weeks for that first hotspot. You then understand that once you complete a successful challenge and witness you fall out of that reward pool. However, you also know that the PoC challenger reward is capped at 1 PoC proof per epoch. Whereas the PoC challengee and witness pools are capped at 20 PoC per epoch. You should theoretically see a jump as much as 20x the rewards as before. If you can't motivate a neighbor with those numbers than those numbers should motivate you in re-investing that 7 weeks of return into a second hotspot to start getting to that 20x reward. The 40 HNT a week is also dependent on the network not increasing. If you incentive "lone wolfs" and then them growing into grouped hotspots. It wouldn't be crazy to think the network could double to 14,000 and that reward pool now shrunk to 20 HNT a week and so on. |
|
@anthonyra I know HIP 9 well (see comments on that HIP). HIP9 alone is not effective at trusting DIY, it just means an exploiter just needs access to 1 real hotspot in an environment. It is only effective if PoC is super bulletproof which if it is, kind of eliminates the need for HIP9 anyway as you have bulletproof PoC to determine validity of a hotspot with. So I think HIP9 doesnt do anything. we have to wait for the mystery new PoC algo. Lets move discussion on "lone wolfs" to your HIP12 and keep this one focused on limiting PoC rewards. EDIT: for those following HIP12 issue is: #38 |
It can be a pretty solid start.. I haven't really put too much thought into HIP 9 because I feel that 10 and 5 should be implemented first. With that being said. If you can make the first two successful while keeping in mind DIY is on the horizon I think it'll work. |
Reading this over again to see how implementing this HIP along with HIP 10.. I noticed something. If you rewarded a hotspot that was a PoC challengee for up to 20 challenges. Couldn't that mean the first 1400 hotspots (based on 7000 on the network) to first reach 20 will collect the entire reward pool for that epoch? |
|
The below table shows the rewards based on the following network data:
*Includes hotspots that are new to the network because this number is based on a hotspot score ==
The above HIP 10 intentions were to prevent the DC arbitrage that was occurring by ensuring that the DC spent to move data was rewarded to the hotspot moving that data. However, with the new distribution of the remaining 32.5% is supposed to distributed rationally across all PoC reward pools. If you were to take the above table but look at the hotspots that benefit from each reward and potential gains there are issues that arise taking into account network size also.
*Since all hotspots on the current network can perform 1 PoC proof (1 challenger reward) per epoch the overall HNT reward pool needs to be divide by the entire network size.
*Since all hotspots on the current network can perform 1 PoC proof (1 challenger reward) per epoch the overall HNT reward pool needs to be divide by the entire network size. Concerns: This switches the ideal reward scheme back to what was occurring in Port Huron before the DC percent was changed. It also greatly reduces the onboard of new people in the act of building out the network. Companies or Patrons with money will be able to instantly tap into the resources provided by having more than one hotspot in a location. HIP 5: Introduces and 80% decrease with every additional PoC receipt (successful challengee or witness). This could result in the first 1400 hotspots to be rewarded with the full reward pool. Which is indeed the worst-case scenario however if you have a bigger grouping of hotspots (Port Huron) is it more or less likely that those will be picked for PoC proofs? Because an island of 4 hotspots will at most be picked 4 times per epoch. Since that island can only receive a max of 1 per hotspot to initiate the PoC proof.
*Since all hotspots on the current network can perform 1 PoC proof (1 challenger reward) per epoch the overall HNT reward pool needs to be divide by the entire network size. |
|
@anthonyra this seems off topic. Disuss HIP10 in the HIP10 issue or Discord. Discuss concerns about "lone wolfs" which has nothing to do with PoC in HIP12 issue. This HIP has nothing to do with the percentage of Helium distributed to PoC or Witness just "given a total of X HNT to be distributed for PoC this epoch how should it be divided among the set of all PoCs performed this epoch". That X% of HNT could be 0.1% could be 99% doesnt matter as far the proposals in this HIP go. |
This HIP is about PoC rewards no?
|
|
@anthonyra It is about how hotspots that participate in many PoC's per epoch should be rewarded relative to those that perform 1 to a few PoCs per epoch. Nothing to do with lone wolves nothing to do with DC arbitrage. Nothing to do with what percentage of the 5M HNT per month should go to PoC (as I said above, could be 0.1%, could be 99% doesnt effect this HIP). Purely "hotspot A did 1 PoC this epoch, hotspot B did 10 PoC this epoch, how much more should hotspot B be rewarded than hotspot A" |
|
@Carniverous19 All I'm trying to do in the above table is trying to determine your 100% reward and what 494% would mean. If you don't agree with how I tried to determine that could you edit your above table or make a new one to show what the rewards of Hotspot A with 1 PoC that epoch is, than Hotspot B at 10 PoC, and than Hotspot C at 20 PoC in terms of HNT would be? |
|
ah I see what you are talking about, When I say reward % its " relative reward compared to 1 PoC" ignoring HNT amounts entirely. so 100% doesnt mean 100% of HNT mined per epoch it means 100% of value of 1 PoC whatever that is. So in the table, a hotspot that performs 20 PoC in an epoch will earn 494% of the HNT of a hotspot that performed 1PoC in that epoch. and that 20th PoC earned 1.4% as much as the first PoC. So that could be 0.0000100 HNT vs 0.0000494 HNT or it could be 1.00 HNT vs 4.94 HNT. Its all normalized by the value of 1PoC in an epoch. More specifically with my X% = 80% like the first table Note hotspot C earns only 10.7% more than hotspot B even though it participated in double the # of PoC's. You cant put raw HNT numbers to any of this as it all depends on how many successful PoC hops there were in a given epoch as well as the distribution of HNT to PoC which changes over time. Thats why the best way to think about it is in ratios. |
|
I'm curious on what max PoC number would best represent the network. The reason I bring this up is that the current person making the max from PoC rewards is only averaging 12 PoC per hotspot of the 36 they own. With the average sitting at around 3 which would be consistent with a hotspot with 2-3 neighbors. |
|
Good questions @anthonyra certainly a good next-step is to apply some of these %X's to real-world data and see how the distribution of HNT changes and look closer at the big winners and big looser to make sure "work" and "proof" are being rewarded appropriately. Good to know ~12PoCs/epoch is high so analysis can focus on like the 1-20 PoC range and dont have to worry about 1-100+ PoC range (depending on future PoC algorithm changes). Im waiting for an ETL instance to load and once that is done (probably another few days). I'll pull some sample epochs and show distribution changes at various percentages. |
|
As discussed on last community call, we're retiring this HIP as no longer applicable: https://docs.google.com/document/d/1bMm2alBigBj3detA775Dn0Gz9UM5XczAeK9vnjBB3l0/edit#heading=h.afj80v7w0lhh Thank you for your participation |
|
@jamiew I looked at the notes you linked, but they don't explain why the HIP wasn't relevant any longer. Do you have another document or discussion that explains it? |
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.
The text was updated successfully, but these errors were encountered: