diff --git a/0014-poc-ripple-method.md b/0014-poc-ripple-method.md new file mode 100644 index 000000000..a750589b4 --- /dev/null +++ b/0014-poc-ripple-method.md @@ -0,0 +1,267 @@ +# HIP14: Proof of Coverage - Ripple Method + +- Authors: @anthonyra +- Start Date: 10/01/2020 +- Category: Technical +- Initial HIP PR: [#47](https://github.com/helium/HIP/pull/47) +- Tracking Issue: [#50](https://github.com/helium/HIP/issues/50) + +# Summary +[summary]: #summary + +The current Proof-of-Coverage allows for Virtual Machine (VM) farms or hotspot farms that have been engineered to maximize return of rewards without providing benefit to the network. + +The current PoC model also rewards those hotspots that are in the most dense part of the network more than the edges. Resulting in over-coverage of those areas and limited expansion to new areas. + +This HIP proposes a different method to to determine Proof-of-Coverage, by seperating the network into islands that are based on the geolocation of hotspots and their associated witness lists. + +![Initial Pebble Hop](https://github.com/helium/hip/blob/master/0014-poc-ripple-method/initial.png?raw=true) + + +# Motivation +[motivation]: #motivation + +With a new day comes a new way "bad actors" attempt to profit from the current system. To fully understand this proposal you first need to grasp the basics on how the current PoC system works. [PoC Documentation](https://developer.helium.com/blockchain/proof-of-coverage) + +#### Basics of current PoC +*Note* If the following doesn't make sense please check out the above PoC documenation. + +1. A challenger selects a target hotspot. +2. Once selected the challenger creates a PoC proof + 1. Starting with the target hotspot the challenger selects the next hotspot in the PoC path based on witness list and [hex](https://h3geo.org/docs) location (how the 300m limit is enforced). + 2. The challenger repeats the above step (2.i) but starting with the hotspot selected to be the next hop. + 3. This PoC path is created containing 2 - 5 hotspots (hops) +3. The initial challengee receives the PoC proof via the p2p network and decrypts the packet (envelope) it signs it and then returns it to the challenger +4. The hotspot then broadcasts the new envelope that is now one layer less than the previous one via Radio Frequency (LoRa / RF). +5. This signal is then picked up by neighboring hotspots. The receiving hotspots have two options. + 1. The hotspot is the next hop in the PoC proof so it's able to decrypt another layer of the envelope and perform steps (4-5.i). + 2. The hotspot isn't the next hop so it signs the envelope and returns to sender (challenger) via p2p. +6. Steps 4 - 5 continue until the end of the PoC proof is reached resulting in a PoC receipt. This PoC receipt is then sent from the challenger to the Consensus Group to be validated. + +#### Current Issues: +1. Due to the targeting techinque used (witness list) it's possible for farms to create isolated islands that will be picked for PoC and perform well between the hotspots in the farm but not to others. +2. The PoC path becomes very computationally extensive to validate the more dense the network is where the PoC took place. +3. All passed challengees and witnesses (up to 5 per challengee) are currently reward for a PoC receipt. Which can result in a farm receiving 20 rewards per hotspot even though only 5 PoC challenges were issued. + +# Stakeholders +[stakeholders]: #stakeholders + +* If this HIP is implemented it will effect everyone who owns a hotspot due to reward changes based on PoC. +* Feedback will be received via the Github `Issues` discussion and on [Discord #hips](https://discord.gg/helium) + +# Detailed Explanation +[detailed-explanation]: #detailed-explanation + +## Ripple PoC Method + +The network will be seperated into islands that are based on the geolocation of hotspots and their associated witness lists. + +The size of an island will be limited to the following: +* The smallest an island can be one hex +* The largest an island would be 7 hexs + +The above size constraints are due to the max chain count that occurs with the `ripple` method which will be described in more detail below. + +#### Definitions + +* `Island` - A hex-cluster that is created by the island construction method below which visualizes the coverage of an area +* `Island Hex` - The hex used to create the island. It'll be of resolution 8 (~415m [0.25 miles] sides, ~0.447454km2 [110 acres] total area) +* `Children Hex` - The hex's found inside of the `Island Hex` of resolution 12 linked via hotspot location hex +* `Island Rating` - The overall rating of an island +* `Challenger` - The hotspot that selects the `Island` to be targeted and the `Pebble` hotspots for the challenge +* `Pebble (challengee)` - Selected by the challenger to start the *ripple*. Minimum of 2 all must be in a different `Island Hex` +* `Accpeted Chain` - Chain that starts with a `Pebble` and ends with a `Pebble` hotspot with all hotspots signatures for each hop + +| Accepted Chains | +| --- | --- | +| pHi - pHo | +| pHi - iH - pHi | +| pHi - iH1 ... iHn - pHo | + +``` +pHi (blue) = initial pebble hotspot +pHo (orange) = opposite pebble hotspot +iH (green) = island hotspot +iHx (grey) = island hex +``` + +* `Witness List` - Will be generated from the `pHi - iH - pHi` chains. This list won't incorporate hotspots within the same `Island Hex` but is included in the PoC due to the island construction +* `Cave` - A cluster of hotspots that are isolated from the rest of the island + + +#### Island Construction + +Currently the island is constructed by selecting a random hotspot and based on it's associated hex will commence the construction of the island. + +1. A random hotspot is selected +2. The hotspot's location hex string is selected +3. The island hex is found by expanding the location hex (resolution 12) to the island hex (resolution 8) +4. The island hex (resolution 8) is used to find all children hex (resolution 12) +5. The hotspots that are located in one of the children hex is add to the list of hotspots for the island +6. The list of hotspots is looped to get all witnesses to those hotspots +7. Step 2 - 5 are repeated for all witness hotspots +8. Once there are no more witness found the process ends + +*The above process is only for proof of concept* + +Ideally if adopted for this to be efficient as possible when a hotspot performs an `assert_location` transaction it will not only be assigned a location but also an island hex. +This will greatly speed up the process since there wouldn't need to be a re-index of hotspots to island hexs. + +#### Ripple Effect + +Once an `Island` is created for an area the `Challenger` will be able to perform the `ripple` method of PoC on that `Island`. + +1. The `Challenger` will select the island it'll be challenging +2. Once the `Island` is selected the `Challenger` will select the `Pebble` hotspots +3. The `Challenger` will send the packet it created to the `Pebble` hotspots. Only the opposite `Pebble` of the pair can decrypt the packet received +4. The `Pebble` hotspots receive the envelope + 1. They sign the envelope with their `Island Hex` and broadcast it via RF (LoRa) +5. There are two options for the hotspots that receive that broadcasted envelope + 1. The receiving hotspot is the opposite `Pebble` hotspot, in this case the envelope will be able to be decrypted and sent back to the challenger + 2. The receiving hotspot is **not** the opposite `Pebble` hotspot, in this case it performs step (4.i) +6. This `ripple` occurs for a set timeframe or when the `Challenger` receives the expected number of chains from the `Pebble` hotspots + +##### Limitations + +To simplify the process and lower the packets (envelopes) received due to the `ripple` the following limitation is set. + +* If the hotspot receives an envelope that has been signed by it's island hex or an island hex it's already seen it's dropped. Forcing the packet to move outwards to the rest of the hex's in the `Island` + +##### Benefits +1. Only the challenger will know which `Pebble` hotspots were selected +2. Based on the size constraint and the fact that the `Chain` is terminated if it returns to an already signed `Island Hex` results in a max number of possible ` Accepted Chains` with a max `Chain` length +3. Since it's assumed that all hotspots within an `Island` are able to communicate due to the size of the `Island Hex` and associated witness lists. Any seperation in the `ripple` and `ideal ripple` will indicate the presense of isolated hotspot(s) `Cave`. + + Caves will be quite obvious with the `ripple` method + +#### Validation Process + +The validation comes from the fact that the `Pebble` hotspots will create the same number of chains and lengths as each other. The difference how ever is that the chains will be mirror copies of each other. + +This is of course based on ideal conditions and an ideal `Island`, in fact there will be differences between the ideal and real results. This will result in the `Island Rating`. The closer the `ripple` of a challenge gets to the `ideal ripple` the higher the rating. + +`Island Rating` Factors: + * Did the `ripple` create the max number of chains + * What's the longest chain received based on geolocation distance and not hop number + +``` +(# of chains received / Max # of Chains) + (Longest Chain / Longest Chain That Block) = 2 +``` + +Therefore, to receive the max rating the island needs to be spread out far enough in attempt to be the longest chain per that block. When this occurs it increases the chance of hotspots that originally weren't in the selected hotspots witness list to be incorporated in the PoC of the island. + +The `Island` than needs to ensure the max number of chains is received by the `Target` hotspot with all hops signed by the associated hotspot. + +To be accepted the `Pebble` hotspots chains need to match (but will be mirrored) + +#### Ideal `ripple` Illustrations + +![Initial Pebble Hop](https://github.com/helium/hip/blob/master/0014-poc-ripple-method/initial.png?raw=true) + +Figure 1-1 - Initial pebble hop + +![Longest Chain Example](https://github.com/helium/hip/blob/master/0014-poc-ripple-method/longest-chain-example-tall.png?raw=true) + +Figure 1-1 - Example of a Longest Chain, which results in a total 6 accepted chains + +``` +pH (blue) = pebble hotspot +iH (green) = island hotspot +tH (orange) = target hotspot +iHx (grey) = island hex + +Max Number of Chains = # of pH * (# of iHx - # of pH)! => 2 * (7-2)! => 2 * 5! = 240 +Longest Chain (length) = (# of iHx - # of pH) => (7 - 2) = 5 +Max Number of Longest Chain = # of iH = 5 +``` + +With the above equations, you can calculate the max number of chains and assocaited lengths. For a 7 hex island the resulting `ripple` would have 240 different chains that are 5 hex's in length. + +#### Real Life Examples + +Hotspot: big-corduroy-jaguar + +Location: 8c2a32a0e5669ff + +![Current Network View](https://github.com/helium/hip/blob/master/0014-poc-ripple-method/bcj-lone-wolf.png?raw=true) +Figure 2-1 - The current network view of the target hotspot (big-corduroy-jaguar) + +![Ripple Island](https://github.com/helium/hip/blob/master/0014-poc-ripple-method/bcj-island.png?raw=true) + +Figure 2-2 - The island that the target hotspot occupies + +The island that big-corduroy-jaguar resides in contains 16 different hotspots. + +* Max Number of Accepted Chains = 240 +* Longest Chain = 5 +* Max Number of Longest Chain = 14 + +## Rewards + +With the drastic change in PoC design the reward system would need to be altered as well. For my initial proposal the following reward scheme should be implemented. + +1. The Reward Pool divided by the sum of all island ratings. +2. The Island Reward would be divided by the # of hotspots in all of the accepted chain(s). +3. Each hotspot in each chain would receive 1 hotspot reward + +``` +1. Island Rewards = ( Reward Pool Size ) / ( Sum of Island Ratings ) * Island Rating + +2. Hotspot Reward = Island Rewards / # of hotspots in all accepted chain(s) +``` + +``` +Reward Pool = 10 HNT +Islands contain 7 hexs = 240 possible chains + +big-corduroy-jaguar Island Rating = (240 / 240) + ( 14000m / 14000m ) = 2 + +1. ( 10 HNT ) / ( 2 ) * 2 = 10 HNT +2. (10 HNT) / ( 240 ) = 0.42 HNT per hotspot + +------------------------------------------------------------------------- + +big-corduroy-jaguar Island Rating = (240 / 240) + ( 14000m / 14000m ) = 2 +Small Island Rating = (240 / 240) + ( 100m / 14000m ) = 1.007142857142857 + +1. big-corduroy-jaguar Island Rewards = ( 10 HNT ) / ( 3.0071... ) * 2 = 6.6508... HNT +2. (6.6508 HNT) / ( 240 ) = 0.027 HNT per hotspot + +1. Small Island Rewards = ( 10 HNT ) / ( 3.0071... ) * 1.0071... = 3.3491... HNT +2. (3.3491 HNT) / ( 240 ) = 0.014 HNT per hotspot +``` + +# Drawbacks +[drawbacks]: #drawbacks + +- It will require a lot of time coding the new model +- This could create *new* ways to game the system +- Current dense islands will not be rewarded as much + +# Rationale and Alternatives +[alternatives]: #rationale-and-alternatives + +This is a drastic change to the current Proof-of-Coverage model. It will require extensive review and testing. + +# Unresolved Questions +[unresolved]: #unresolved-questions + +- Currently None + +# Deployment Impact +[deployment-impact]: #deployment-impact + +This will impact everyone and turn all current documentations on end. + +# Success Metrics +[success-metrics]: #success-metrics + +What metrics can be used to measure the success of this design? + +- Ability to limit `Cave` participation and rewards + +- Overall performance of this compared to current PoC model + +- Number of possible "gaming" scenarios are limited + +- Penalize "bad actors" more than highly dense "good actors" diff --git a/0014-poc-ripple-method/bcj-island.png b/0014-poc-ripple-method/bcj-island.png new file mode 100644 index 000000000..600e141a5 Binary files /dev/null and b/0014-poc-ripple-method/bcj-island.png differ diff --git a/0014-poc-ripple-method/bcj-lone-wolf.png b/0014-poc-ripple-method/bcj-lone-wolf.png new file mode 100644 index 000000000..858122534 Binary files /dev/null and b/0014-poc-ripple-method/bcj-lone-wolf.png differ diff --git a/0014-poc-ripple-method/initial.png b/0014-poc-ripple-method/initial.png new file mode 100644 index 000000000..a75d56624 Binary files /dev/null and b/0014-poc-ripple-method/initial.png differ diff --git a/0014-poc-ripple-method/longest-chain-example-tall.png b/0014-poc-ripple-method/longest-chain-example-tall.png new file mode 100644 index 000000000..aa7d450c8 Binary files /dev/null and b/0014-poc-ripple-method/longest-chain-example-tall.png differ diff --git a/0015-beaconing-rewards.md b/0015-beaconing-rewards.md new file mode 100644 index 000000000..2547278c9 --- /dev/null +++ b/0015-beaconing-rewards.md @@ -0,0 +1,199 @@ +# HIP15: Beaconing Rewards + +- Author: [@Carniverous19](https://github.com/Carniverous19) +- Start Date: 2020-10-07 +- Category: Technical +- Original HIP PR: [#49](https://github.com/helium/HIP/pull/49) +- Tracking Issue: [#51](https://github.com/helium/HIP/issues/51) + +# Summary +[summary]: #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. + +# Motivation +[motivation]: #motivation + +The first motivation is to eliminate Multi-hop PoC has many flaws both in complexity of implementation and imbalance of rewards. This proposal wont focus on the flaws with multi-hop PoC because they are fairly well understood and agreed upon. Some main flaws are complexity of path building and receipt verification, poor path reliability, and uneven challenge rates (and corresponding reward distribution) based on network topology. + +Secondly, beaconing with the modified reward structure outlined below does a much better job of rewarding desired coverage. The existing PoC method and reward structure heavily rewards transmitters with minimal rewards for receivers while the vast majority of LoRaWAN usage is for unconfirmed downlinks meaning hotspots mostly receive data. Rewards should be biased towards hotspots that can receive well. + + +# Stakeholders +[stakeholders]: #stakeholders + +All hotspot owners will be affected by this HIP as the reward structure and PoC behavior will undergo a significant change. In general, hotspots that are able to witness many other hotspots are likely to see rewards go up and hotspots that can only witness a few hotspots may see rewards go down. + +The Helium Inc developer team will also need to change sections of the blockchain-core to change how reward distribution is calculated and PoCs are build (although this can be very similar to a length 1 multihop PoC). + +Finally, some chain variables may need updating to introduce new variables described below as well as change the reward distribution percentages. + + +# Detailed Explanation +[detailed-explanation]: #detailed-explanation + +Beaconing behaves a lot like a single hop of PoC but there is no intended target, everyone that can receive a transmission is a witness. +Beacons can be initiated in the same manner as PoC today, where challenger hotspots trigger a hotspot to beacon and gather witness receipts (this works fine if the challenger role is being moved to CG per [Consensus Group PoC Challenges](https://github.com/helium/HIP/pull/41)). +I assume each active hotspot will be targeted uniformly randomly so on average, each hotspot will be challenged the same number of times. + +To determine the rewards given for a beacon I first define a term ***reward unit***. +A reward unit is not a defined amount of HNT but a slice of the available PoC rewards for each epoch. +So, for example if there are 1,000 HNT to be rewarded for PoC activity and there are 100 reward units from all PoC activity, each reward unit will get 10 HNT. +If there are 5,000 reward units in an epoch, each unit will get 0.2 HNT. +This is very similar to how PoC and witness rewards are distributed today, where the value of each witness varies epoch to epoch depending on how many witnesses there were. + +The formulas below and example plot show how the number of reward units is calculated and distributed among the transmitter and witnesses for each beacon. + +### Reward Formula for beaconing +Definitions: + + - `w` = Number of witnesses to a transmission + - `N` = Desired redundancy. `N`+1 hotspots cover an area + - `r` = decay rate for additional transmitter reward if `w` > `N`. + + Reward formula for Transmitter: + + ![image RewardTX formula](./00NN-beaconing-rewards/RewardTX_equation.PNG) + + Reward Formula for each Receiver: + + ![image RewardRX formula](./00NN-beaconing-rewards/RewardTX_equation.PNG) + + + A chart showing reward distribution basd on the formulas listed above with example values of `N`=4 and `r`=0.8: + ![image Reward distribution](./00NN-beaconing-rewards/RewardDistributionHist.svg) + + + +There are 3 regions in this reward distribution described below: + +#### w < N +For each beacon challenge there is desired number of witnesses which should be set by chain variable `N`. +This number should be >1 because we want redundant RF coverage since hotspots are “unreliable” as compared to enterprise gateways like cell towers. +If the number of witnesses (`w`) is less than `N`, then this area is under desired coverage. +Each witness gets a full 1-unit of reward for providing needed coverage, the transmitter receives a fraction of a reward unit proportionally based on the number of witnesses. +This encourages the transmitter to broadcast as powerfully and broadly as possible. + +#### w = N +At this point we have ideal redundant coverage based on the chain variables. +The transmitter gets 1 unit of reward and each witness gets 1 unit of reward. +In total there are `N`+1 units of reward given for this beacon with each participant getting 1 unit. + +#### w > N +If the number of witnesses is greater than desired, we have too much coverage for this transmitter. +We still want to encourage the transmitter to transmit as wide reaching as possible to expose this over-coverage, so we give a small portion of the witness rewards to the transmitter up to 1 additional unit of rewards. +For witnesses they all split the pool of reward units remaining for witnesses. +This means the total reward given to all participants remains at `N`+1 so there is no significant gain to be had by having the number of witnesses way above `N`. +This reward structure still encourages witnesses to report receipts as even though they get a smaller and smaller slice of reward they still get rewarded so greedy witnesses will want to witness as many transmissions as possible. + +Overall, this method should encourage greedy transmitters to transmit as powerfully and with as much coverage as possible and witnesses to receive as many transmissions as possible and deliver witness receipts. +Thus each hotspot is motivated to provide as much coverage as possible without over-rewarding redundant coverage. +This reward structure does a much better job of giving rewards to “good” coverage meaning coverage over many neighboring hotspots and over hotspots without many existing witnesses. + +Note I do not specify a maximum number of witnesses but one can be set as desired to limit transaction size and effort required to validate a beacon. + +### Example Reward Distribution +The following tables list the reward distributed to transmitters and witnesses with example chain variables of `N`=4, `r`=0.8. Note `r` of 0.8 was chosen so that 10 additional witnesses above `N` is ~0.9 reward credits. + +| # witnesses | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | +|---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| +| RewardRX per witness | 1.00 | 1.00 | 1.00 | 1.00 | 0.76 | 0.61 | 0.50 | 0.43 | +| RewardTX | 0.25 | 0.50 | 0.75 | 1.00 | 1.20 | 1.36 | 1.49 | 1.59 | + + +| # witnesses | 9 | 10 | 11 | 12 | 13 | 14 | 15 | +|---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| +| RewardRX per witness | 0.37 | 0.33 | 0.29 | 0.26 | 0.24 | 0.22 | 0.21 | +| RewardTX | 1.67 | 1.74 | 1.79 | 1.83 | 1.87 | 1.89 | 1.91 | + +### Witness Distance Limits +A radius `R` (today ~300m) sets the minimum distance for “valid” witnesses. +Only witnesses beyond distance `R` are counted in the reward formulas. +It is left to the implementation whether the challenger should filter out witness receipts that violate this threshold or allow them to be included in beacon receipts which may take the place of witnesses sufficient distance away. +There is no penalty for having nearby witnesses (these can be accounted for in an additional proposal “*Method for geographic based transmit reward scaling*”). + +### Invalid Witnesses Due to RSSI, SNR, or other gaming detection methods + +Unlike nearby witnesses which are excluded even if honest, witness observations that are invalid due to suspect signals means either the transmitter or the witness may be lying about location or some other aspect of coverage. +This cannot simply be dropped since its possible for a gaming hotspot to have many witnesses with most invalid but some still have some “lucky” witnesses with valid signals. +The method of penalizing can change as the methods of evaluating signals change but this section describes a simple method that is compatible with PoC version 10 that is the most recent anti-gaming method active when this HIP is proposed. + +Witness with invalid signal count towards `w` but are given 0 reward. +This mildly penalizes honest witnesses since they are splitting rewards with invalid witnesses, but if the percentage of invalid witnesses for a transmission are low then this penalty is minimal. +If the percentage of invalid witnesses is high then its likely the transmitter is invalid and thus witnessing an invalid transmitter should get a small reward. + +For transmitters, the reward units earned are scaled by the number of valid witnesses divided by all witnesses. +Again, if the transmitter is valid then its likely only a small number of witnesses are invalid and this penalty is small. +If most witnesses are invalid, then its likely the transmitter is invalid and reward should be small. + +### Example Beacon Scenarios +This table gives some examples of rewards distributed for a beacon with varying number of witnesses. + +| Scenario | 12 witnesses | 8 witnesses | 4 witnesses | 2 witnesses | +|---:|:---:|:---:|:---:|:---:| +| Witnesses outside R | 12 | 8 | 4 | 2 | +| Invalid Witnesses | 0 | 0 | 0 | 0 | +| Reward per witness | 0.26 | 0.43 | 1.00 | 1.00 | +| Total RewardRX issued | 3.18 | 3.41 | 4.00 | 2.00 | +| RewardTX issued | 1.83 | 1.59 | 1.00 | 0.50 | +| Total Reward issued | 5.00 | 5.00 | 5.00 | 2.50 | + +This table gives examples of beacons with invalid witnesses + +| Scenario | 12 witns. 2 invalid | 12 witns. 10 invalid | 4 witns. 1 invalid | 4 witns. 3 invalid | +|---:|:---:|:---:|:---:|:---:| +| Witnesses outside R | 12 | 12 | 4 | 4 | +| Invalid Witnesses | 2 | 10 | 1 | 3 | +| Reward per witness | 0.26 | 0.26 | 1.00 | 1.00 | +| Total RewardRX issued | 2.65 | 0.53 | 3.00 | 1.00 | +| Tx Scale | 10/12 (0.83) | 2/12 (0.17) | 3/4 (0.75) | 1/4 (0.25) | +| RewardTX issued | 1.53 | 0.30 | 0.75 | 0.125 | +| Total Reward issued | 4.18 | 0.83 | 3.75 | 1.13 | + + +# Drawbacks +[drawbacks]: #drawbacks + +This will be a considerable implementation effort to change how PoC are constructed and verified. +Also, this change to the reward structure may drastically change how rewards are distributed. +Hotspot owners that optimized for the existing algorithm which has been largely unchanged since Helium’s introduction may find their setups to be suboptimal with the new scheme. +Note I think this is a benefit of the change since the existing system did not reward “good” topologies in favor of “dense” topologies. +It will still cause disruption. + +It may appear that beaconing is less secure since there is no multi-level onion packet. + +I believe this was false security as it is just as easy to distribute raw data received over LoRa to miners whether that is an onion packet or a pseudorandom payload for beaconing. + +Having an intended target chosen from witnesses does not validate the PoC more than simple witnessing. + + +# Rationale and Alternatives +[alternatives]: #rationale-and-alternatives + +Beaconing breaks down the PoC to a more fundamental form of a single transmit and group of receive observations. It allows more direct targeting of hotspots and PoC activity (and corresponding rewards) to be better controlled by targeting methods and not strongly dictated by witness topologies. + +There are many alternatives to this proposal, especially the reward structure. We can keep rewards the same giving significant rewards to beacon transmitters and a small amount to witnesses. I think this would be less optimal since the majority of LoRaWAN interactions are uplinks. + + +# Unresolved Questions +[unresolved]: #unresolved-questions + +**Chain Variables**: This HIP presented a reasonable first guess at chain variables of `N`=4, `r`=0.8 but additional analysis may be required to optimize these numbers + +**Beacon Payload**: This HIP does not specify what the contents of a payload should be. This is left to the implementers, but it could simply be a 0-hop onion packet like is used for beacons today (mainly for witness discovery). Overall, the reward structure is independent of beacon payload. + +**Hotspot Impact Analysis**: The community may want more real-world samples of expected beaconing behavior and reward distribution based on existing witness lists to see how this change will effect reward distribution and if it is desirable (and more importantly healthy for network efficiency and growth). + + +# Deployment Impact +[deployment-impact]: #deployment-impact + +Current users will likely see a significant change in reward distribution based on this change. This will also require a significant update to existing documentation on challenges and reward distribution. Applications such as the phone apps and blockchain explorer will need significant changes to reflect the new PoC structure. The blockchain core will need to be updated to implement beaconing and possibly changes to the ETL and API to reflect this change in behavior and the single PoC reward type. + +Note a lot of the development effort may be mitigated by treating beacons as length-1 multihop PoC, zeroing out witness rewards and moving into PoC percentages and expanding the allowed number of witnesses. This may not be the best beaconing implementation, but it would require the least amount of change to the codebase. + + +# Success Metrics +[success-metrics]: #success-metrics + +Success will be determined on smooth running of beaconing and real-world rewards better going to efficient network coverage. diff --git a/0015-beaconing-rewards/RewardDistributionHist.png b/0015-beaconing-rewards/RewardDistributionHist.png new file mode 100644 index 000000000..a7e68a4ed Binary files /dev/null and b/0015-beaconing-rewards/RewardDistributionHist.png differ diff --git a/0015-beaconing-rewards/RewardDistributionHist.svg b/0015-beaconing-rewards/RewardDistributionHist.svg new file mode 100644 index 000000000..62e0ce620 --- /dev/null +++ b/0015-beaconing-rewards/RewardDistributionHist.svg @@ -0,0 +1,1462 @@ + + + + + + + + + 2020-10-07T18:27:17.806727 + image/svg+xml + + + Matplotlib v3.3.1, https://matplotlib.org/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/0015-beaconing-rewards/RewardRX_equation.PNG b/0015-beaconing-rewards/RewardRX_equation.PNG new file mode 100644 index 000000000..b829c808b Binary files /dev/null and b/0015-beaconing-rewards/RewardRX_equation.PNG differ diff --git a/0015-beaconing-rewards/RewardTX_equation.PNG b/0015-beaconing-rewards/RewardTX_equation.PNG new file mode 100644 index 000000000..fe10dcc1a Binary files /dev/null and b/0015-beaconing-rewards/RewardTX_equation.PNG differ diff --git a/00NN-beaconing-rewards.md b/00NN-beaconing-rewards.md new file mode 100644 index 000000000..9041ebd04 --- /dev/null +++ b/00NN-beaconing-rewards.md @@ -0,0 +1,197 @@ +# Proposal for Beaconing Rewards + +- Start Date: 2020-10-07 +- HIP PR: +- Tracking Issue: + +# Summary +[summary]: #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. + +# Motivation +[motivation]: #motivation + +The first motivation is to eliminate Multi-hop PoC has many flaws both in complexity of implementation and imbalance of rewards. This proposal wont focus on the flaws with multi-hop PoC because they are fairly well understood and agreed upon. Some main flaws are complexity of path building and receipt verification, poor path reliability, and uneven challenge rates (and corresponding reward distribution) based on network topology. + +Secondly, beaconing with the modified reward structure outlined below does a much better job of rewarding desired coverage. The existing PoC method and reward structure heavily rewards transmitters with minimal rewards for receivers while the vast majority of LoRaWAN usage is for unconfirmed downlinks meaning hotspots mostly receive data. Rewards should be biased towards hotspots that can receive well. + + +# Stakeholders +[stakeholders]: #stakeholders + +All hotspot owners will be affected by this HIP as the reward structure and PoC behavior will undergo a significant change. In general, hotspots that are able to witness many other hotspots are likely to see rewards go up and hotspots that can only witness a few hotspots may see rewards go down. + +The Helium Inc developer team will also need to change sections of the blockchain-core to change how reward distribution is calculated and PoCs are build (although this can be very similar to a length 1 multihop PoC). + +Finally, some chain variables may need updating to introduce new variables described below as well as change the reward distribution percentages. + + +# Detailed Explanation +[detailed-explanation]: #detailed-explanation + +Beaconing behaves a lot like a single hop of PoC but there is no intended target, everyone that can receive a transmission is a witness. +Beacons can be initiated in the same manner as PoC today, where challenger hotspots trigger a hotspot to beacon and gather witness receipts (this works fine if the challenger role is being moved to CG per [Consensus Group PoC Challenges](https://github.com/helium/HIP/pull/41)). +I assume each active hotspot will be targeted uniformly randomly so on average, each hotspot will be challenged the same number of times. + +To determine the rewards given for a beacon I first define a term ***reward unit***. +A reward unit is not a defined amount of HNT but a slice of the available PoC rewards for each epoch. +So, for example if there are 1,000 HNT to be rewarded for PoC activity and there are 100 reward units from all PoC activity, each reward unit will get 10 HNT. +If there are 5,000 reward units in an epoch, each unit will get 0.2 HNT. +This is very similar to how PoC and witness rewards are distributed today, where the value of each witness varies epoch to epoch depending on how many witnesses there were. + +The formulas below and example plot show how the number of reward units is calculated and distributed among the transmitter and witnesses for each beacon. + +### Reward Formula for beaconing +Definitions: + + - `w` = Number of witnesses to a transmission + - `N` = Desired redundancy. `N`+1 hotspots cover an area + - `r` = decay rate for additional transmitter reward if `w` > `N`. + + Reward formula for Transmitter: + + ![image RewardTX formula](./00NN-beaconing-rewards/RewardTX_equation.PNG) + + Reward Formula for each Receiver: + + ![image RewardRX formula](./00NN-beaconing-rewards/RewardTX_equation.PNG) + + + A chart showing reward distribution basd on the formulas listed above with example values of `N`=4 and `r`=0.8: + ![image Reward distribution](./00NN-beaconing-rewards/RewardDistributionHist.svg) + + + +There are 3 regions in this reward distribution described below: + +#### w < N +For each beacon challenge there is desired number of witnesses which should be set by chain variable `N`. +This number should be >1 because we want redundant RF coverage since hotspots are “unreliable” as compared to enterprise gateways like cell towers. +If the number of witnesses (`w`) is less than `N`, then this area is under desired coverage. +Each witness gets a full 1-unit of reward for providing needed coverage, the transmitter receives a fraction of a reward unit proportionally based on the number of witnesses. +This encourages the transmitter to broadcast as powerfully and broadly as possible. + +#### w = N +At this point we have ideal redundant coverage based on the chain variables. +The transmitter gets 1 unit of reward and each witness gets 1 unit of reward. +In total there are `N`+1 units of reward given for this beacon with each participant getting 1 unit. + +#### w > N +If the number of witnesses is greater than desired, we have too much coverage for this transmitter. +We still want to encourage the transmitter to transmit as wide reaching as possible to expose this over-coverage, so we give a small portion of the witness rewards to the transmitter up to 1 additional unit of rewards. +For witnesses they all split the pool of reward units remaining for witnesses. +This means the total reward given to all participants remains at `N`+1 so there is no significant gain to be had by having the number of witnesses way above `N`. +This reward structure still encourages witnesses to report receipts as even though they get a smaller and smaller slice of reward they still get rewarded so greedy witnesses will want to witness as many transmissions as possible. + +Overall, this method should encourage greedy transmitters to transmit as powerfully and with as much coverage as possible and witnesses to receive as many transmissions as possible and deliver witness receipts. +Thus each hotspot is motivated to provide as much coverage as possible without over-rewarding redundant coverage. +This reward structure does a much better job of giving rewards to “good” coverage meaning coverage over many neighboring hotspots and over hotspots without many existing witnesses. + +Note I do not specify a maximum number of witnesses but one can be set as desired to limit transaction size and effort required to validate a beacon. + +### Example Reward Distribution +The following tables list the reward distributed to transmitters and witnesses with example chain variables of `N`=4, `r`=0.8. Note `r` of 0.8 was chosen so that 10 additional witnesses above `N` is ~0.9 reward credits. + +| # witnesses | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | +|---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| +| RewardRX per witness | 1.00 | 1.00 | 1.00 | 1.00 | 0.76 | 0.61 | 0.50 | 0.43 | +| RewardTX | 0.25 | 0.50 | 0.75 | 1.00 | 1.20 | 1.36 | 1.49 | 1.59 | + + +| # witnesses | 9 | 10 | 11 | 12 | 13 | 14 | 15 | +|---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| +| RewardRX per witness | 0.37 | 0.33 | 0.29 | 0.26 | 0.24 | 0.22 | 0.21 | +| RewardTX | 1.67 | 1.74 | 1.79 | 1.83 | 1.87 | 1.89 | 1.91 | + +### Witness Distance Limits +A radius `R` (today ~300m) sets the minimum distance for “valid” witnesses. +Only witnesses beyond distance `R` are counted in the reward formulas. +It is left to the implementation whether the challenger should filter out witness receipts that violate this threshold or allow them to be included in beacon receipts which may take the place of witnesses sufficient distance away. +There is no penalty for having nearby witnesses (these can be accounted for in an additional proposal “*Method for geographic based transmit reward scaling*”). + +### Invalid Witnesses Due to RSSI, SNR, or other gaming detection methods + +Unlike nearby witnesses which are excluded even if honest, witness observations that are invalid due to suspect signals means either the transmitter or the witness may be lying about location or some other aspect of coverage. +This cannot simply be dropped since its possible for a gaming hotspot to have many witnesses with most invalid but some still have some “lucky” witnesses with valid signals. +The method of penalizing can change as the methods of evaluating signals change but this section describes a simple method that is compatible with PoC version 10 that is the most recent anti-gaming method active when this HIP is proposed. + +Witness with invalid signal count towards `w` but are given 0 reward. +This mildly penalizes honest witnesses since they are splitting rewards with invalid witnesses, but if the percentage of invalid witnesses for a transmission are low then this penalty is minimal. +If the percentage of invalid witnesses is high then its likely the transmitter is invalid and thus witnessing an invalid transmitter should get a small reward. + +For transmitters, the reward units earned are scaled by the number of valid witnesses divided by all witnesses. +Again, if the transmitter is valid then its likely only a small number of witnesses are invalid and this penalty is small. +If most witnesses are invalid, then its likely the transmitter is invalid and reward should be small. + +### Example Beacon Scenarios +This table gives some examples of rewards distributed for a beacon with varying number of witnesses. + +| Scenario | 12 witnesses | 8 witnesses | 4 witnesses | 2 witnesses | +|---:|:---:|:---:|:---:|:---:| +| Witnesses outside R | 12 | 8 | 4 | 2 | +| Invalid Witnesses | 0 | 0 | 0 | 0 | +| Reward per witness | 0.26 | 0.43 | 1.00 | 1.00 | +| Total RewardRX issued | 3.18 | 3.41 | 4.00 | 2.00 | +| RewardTX issued | 1.83 | 1.59 | 1.00 | 0.50 | +| Total Reward issued | 5.00 | 5.00 | 5.00 | 2.50 | + +This table gives examples of beacons with invalid witnesses + +| Scenario | 12 witns. 2 invalid | 12 witns. 10 invalid | 4 witns. 1 invalid | 4 witns. 3 invalid | +|---:|:---:|:---:|:---:|:---:| +| Witnesses outside R | 12 | 12 | 4 | 4 | +| Invalid Witnesses | 2 | 10 | 1 | 3 | +| Reward per witness | 0.26 | 0.26 | 1.00 | 1.00 | +| Total RewardRX issued | 2.65 | 0.53 | 3.00 | 1.00 | +| Tx Scale | 10/12 (0.83) | 2/12 (0.17) | 3/4 (0.75) | 1/4 (0.25) | +| RewardTX issued | 1.53 | 0.30 | 0.75 | 0.125 | +| Total Reward issued | 4.18 | 0.83 | 3.75 | 1.13 | + + +# Drawbacks +[drawbacks]: #drawbacks + +This will be a considerable implementation effort to change how PoC are constructed and verified. +Also, this change to the reward structure may drastically change how rewards are distributed. +Hotspot owners that optimized for the existing algorithm which has been largely unchanged since Helium’s introduction may find their setups to be suboptimal with the new scheme. +Note I think this is a benefit of the change since the existing system did not reward “good” topologies in favor of “dense” topologies. +It will still cause disruption. + +It may appear that beaconing is less secure since there is no multi-level onion packet. + +I believe this was false security as it is just as easy to distribute raw data received over LoRa to miners whether that is an onion packet or a pseudorandom payload for beaconing. + +Having an intended target chosen from witnesses does not validate the PoC more than simple witnessing. + + +# Rationale and Alternatives +[alternatives]: #rationale-and-alternatives + +Beaconing breaks down the PoC to a more fundamental form of a single transmit and group of receive observations. It allows more direct targeting of hotspots and PoC activity (and corresponding rewards) to be better controlled by targeting methods and not strongly dictated by witness topologies. + +There are many alternatives to this proposal, especially the reward structure. We can keep rewards the same giving significant rewards to beacon transmitters and a small amount to witnesses. I think this would be less optimal since the majority of LoRaWAN interactions are uplinks. + + +# Unresolved Questions +[unresolved]: #unresolved-questions + +**Chain Variables**: This HIP presented a reasonable first guess at chain variables of `N`=4, `r`=0.8 but additional analysis may be required to optimize these numbers + +**Beacon Payload**: This HIP does not specify what the contents of a payload should be. This is left to the implementers, but it could simply be a 0-hop onion packet like is used for beacons today (mainly for witness discovery). Overall, the reward structure is independent of beacon payload. + +**Hotspot Impact Analysis**: The community may want more real-world samples of expected beaconing behavior and reward distribution based on existing witness lists to see how this change will effect reward distribution and if it is desirable (and more importantly healthy for network efficiency and growth). + + +# Deployment Impact +[deployment-impact]: #deployment-impact + +Current users will likely see a significant change in reward distribution based on this change. This will also require a significant update to existing documentation on challenges and reward distribution. Applications such as the phone apps and blockchain explorer will need significant changes to reflect the new PoC structure. The blockchain core will need to be updated to implement beaconing and possibly changes to the ETL and API to reflect this change in behavior and the single PoC reward type. + +Note a lot of the development effort may be mitigated by treating beacons as length-1 multihop PoC, zeroing out witness rewards and moving into PoC percentages and expanding the allowed number of witnesses. This may not be the best beaconing implementation, but it would require the least amount of change to the codebase. + + +# Success Metrics +[success-metrics]: #success-metrics + +Success will be determined on smooth running of beaconing and real-world rewards better going to efficient network coverage. diff --git a/00NN-beaconing-rewards/RewardDistributionHist.png b/00NN-beaconing-rewards/RewardDistributionHist.png new file mode 100644 index 000000000..a7e68a4ed Binary files /dev/null and b/00NN-beaconing-rewards/RewardDistributionHist.png differ diff --git a/00NN-beaconing-rewards/RewardDistributionHist.svg b/00NN-beaconing-rewards/RewardDistributionHist.svg new file mode 100644 index 000000000..62e0ce620 --- /dev/null +++ b/00NN-beaconing-rewards/RewardDistributionHist.svg @@ -0,0 +1,1462 @@ + + + + + + + + + 2020-10-07T18:27:17.806727 + image/svg+xml + + + Matplotlib v3.3.1, https://matplotlib.org/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/00NN-beaconing-rewards/RewardRX_equation.PNG b/00NN-beaconing-rewards/RewardRX_equation.PNG new file mode 100644 index 000000000..b829c808b Binary files /dev/null and b/00NN-beaconing-rewards/RewardRX_equation.PNG differ diff --git a/00NN-beaconing-rewards/RewardTX_equation.PNG b/00NN-beaconing-rewards/RewardTX_equation.PNG new file mode 100644 index 000000000..fe10dcc1a Binary files /dev/null and b/00NN-beaconing-rewards/RewardTX_equation.PNG differ diff --git a/README.md b/README.md index 56d78c49f..98c75cd0e 100644 --- a/README.md +++ b/README.md @@ -25,3 +25,5 @@ If you have questions or feedback, please ask in [#hips in the community Discord | 11 | [Amendment to proportional data transfer reward scheme](https://github.com/helium/HIP/blob/master/0011-usage-based-rewards-structure.md) | [In Discussion](https://github.com/helium/HIP/issues/34) | | 12 | [Remote location assertion](https://github.com/helium/HIP/blob/master/0012-remote-location-assert.md) | [In Discussion](https://github.com/helium/HIP/issues/39) | | 13 | [Transfer hotspot](https://github.com/helium/HIP/blob/master/0013-transfer-hotspot.md) | [In Discussion](https://github.com/helium/HIP/issues/43) | +| 14 | [PoC Ripple Method](https://github.com/helium/HIP/blob/master/0014-poc-ripple-method.md) | [In Discussion](https://github.com/helium/HIP/issues/50) | +| 15 | [Beaconing Rewards](https://github.com/helium/HIP/blob/master/0015-beaconing-rewards.md) | [In Discussion](https://github.com/helium/HIP/issues/51) |