diff --git a/.prettierrc b/.prettierrc index 80ada0917..4a0f57b36 100644 --- a/.prettierrc +++ b/.prettierrc @@ -1,6 +1,6 @@ { - "printWidth": 100, - "proseWrap": "always", + // "printWidth": 100, + // "proseWrap": "always", "semi": false, "trailingComma": "all", "singleQuote": true, diff --git a/0000-template.md b/0000-template.md index 0288762b1..4e867da08 100644 --- a/0000-template.md +++ b/0000-template.md @@ -5,6 +5,7 @@ - Category: - Original HIP PR: - Tracking Issue: +- Vote Requirements: ## Summary diff --git a/0008-lorawan-routing.md b/0008-lorawan-routing.md new file mode 100644 index 000000000..4c76d9adf --- /dev/null +++ b/0008-lorawan-routing.md @@ -0,0 +1,310 @@ +- Start Date: 2020-02-11 +- HIP PR: +- Tracking Issue: + +# Summary + +[summary]: #summary + +This HIP proposes to add [XOR filter](https://lemire.me/blog/2019/12/19/xor-filters-faster-and-smaller-than-bloom-filters/) +based routing tables to the blockchain ledger to aid in routing LoRaWAN join +packets to the correct destination. Additionally once the device has joined, it +can be assigned a DevAddr corresponding to an address allocation the OUI controls. + +# Motivation + +[motivation]: #motivation + +#Why are we doing this? What use cases does it support? What problems does it solve? What is the expected outcome? + +With the addition of LoRaWAN support, we have inherited some of the routing +problems inherent in the LoRaWAN network model. LoRaWAN assumes that the network +has a centralized network server (or set of them) (similar to a LAN) and our model +is much closer to internet routing. Additionally, it turns out many LoRaWAN devices +do not allow end-user configuration of DevEUI/AppEUI/AppKey. Thus the existing +model of co-opting the AppEUI to route the join packet is unsuitable and +something new is needed. + +In addition, the current scheme for DevAddr allocation (the session address, +essentially) is not ideal because we map the 32 bit OUI to the DevAddr directly. +This will cause problems for large OUIs at the expense of small ones. It would +be good for OUIs to be able to obtain more address space for their DevAddrs if +they're willing to pay for it. + +# Stakeholders + +[stakeholders]: #stakeholders + +- LoRaWAN device users + +# Detailed Explanation + +[detailed-explanation]: #detailed-explanation + +A XOR filter is a probabalistic data structure that allows for fast checking for +key membership It never has false negatives but can have false positives. XOR +filters come in 2 flavors, xor8 and xor16. xor8 has a false positive rate of +about 0.3 percent and xor16 has a false positive rate of about 0.002%. We +propose that the space tradeoff (2x) for xor16 is worth it because it results in +much less ambiguous routing for large numbers of devices. + +XOR filters require inputs be hashed to a 64 bit integer before being stored or +compared against the XOR filter. We propose the use of +[xxhash](http://cyan4973.github.io/xxHash/)'s 64 bit mode. This is one of the +fastest hash functions available and seems to provide good distribution for the +XOR filter. Both the DevEUI and the AppEUI (totaling 128 bits together) would be +hashed to a 64 bit key, this should help in cases of DevAddr collisions. + +A new ledger entity would be added to the blockchain, a 'routing entry'. These +would have a total ordering (assigned by the order they are added to the chain) +and an XOR filter built from the set of active DevEUI/AppEUIs for the owning OUI. + +XOR16 filters for a range of sizes are presented below for illustration purposes: + +| Devices | Bytes on chain | +| --------- | -------------- | +| 100 | 322 bytes | +| 1,000 | 2.48 kbytes | +| 10,000 | 24.09 kbytes | +| 100,000 | 240.21 kbytes | +| 1,000,000 | 2.34 mbytes | + +With the largest XOR filter, we can check for key membership in about 14 +milliseconds on an raspberry pi 3b+ in 32 bit mode. The smallest xor filter can +be checked in well under a millisecond. + +In a more complete test, 10,000 OUIs holding device space for 50 million devices +was able route an address to its destination in 1.1 seconds, again on a +raspberry pi 3b+ in 32 bit mode. 64 bit mode is expected to be slightly faster. +The same test on a pi 4 is about 200 milliseconds faster, and the same test on +an intel i7-7700HQ runs in about 96 milliseconds. + +Some more benchmarks are presented below. The memory and database sizes are +approximate. + +On an Intel i7-7700HQ running Void linux: + +``` +running xor8_xxhash with 10000 OUIs and 8000000 Devices +Attempting 1000 random lookups +Average memory 0.21Mb, max 0.51Mb, min 0.10Mb +Approximate database size 9.99Mb +Average errors 39.300, max 59, min 20 +Average lookup 0.056s, max 0.150s, min 0.034s +Lookup misses 0 + + +running xor16_xxhash with 10000 OUIs and 8000000 Devices +Attempting 1000 random lookups +Average memory 0.54Mb, max 0.96Mb, min 0.23Mb +Approximate database size 23.76Mb +Average errors 0.155, max 2, min 0 +Average lookup 0.077s, max 0.202s, min 0.054s +Lookup misses 0 + + +running bloom with 10000 OUIs and 8000000 Devices +Attempting 1000 random lookups +Average memory 0.55Mb, max 1.02Mb, min 0.24Mb +Approximate database size 38.65Mb +Average errors 0.036, max 2, min 0 +Average lookup 0.101s, max 0.218s, min 0.068s +Lookup misses 0 +``` + +On a Raspberry Pi 3b+ running 32 bit Raspbian: + +``` +running xor8_xxhash with 10000 OUIs and 8000000 Devices +Attempting 1000 random lookups +Average memory 0.12Mb, max 0.25Mb, min -0.06Mb +Approximate database size 9.99Mb +Average errors 39.300, max 59, min 20 +Average lookup 0.360s, max 0.426s, min 0.278s +Lookup misses 0 + + +running xor16_xxhash with 10000 OUIs and 8000000 Devices +Attempting 1000 random lookups +Average memory 0.27Mb, max 0.84Mb, min 0.08Mb +Approximate database size 23.76Mb +Average errors 0.155, max 2, min 0 +Average lookup 0.533s, max 0.629s, min 0.487s +Lookup misses 0 + + +running bloom with 10000 OUIs and 8000000 Devices +Attempting 1000 random lookups +Average memory 0.14Mb, max 0.88Mb, min 0.02Mb +Approximate database size 38.65Mb +Average errors 0.030, max 1, min 0 +Average lookup 0.700s, max 0.838s, min 0.651s +Lookup misses 1000 +``` + +On a Raspberry Pi 4 running 32 bit Rasbian: + +``` +running xor8_xxhash with 10000 OUIs and 8000000 Devices +Attempting 1000 random lookups +Average memory 0.15Mb, max 0.26Mb, min -0.02Mb +Approximate database size 9.99Mb +Average errors 39.300, max 59, min 20 +Average lookup 0.269s, max 0.386s, min 0.227s +Lookup misses 0 + + +running xor16_xxhash with 10000 OUIs and 8000000 Devices +Attempting 1000 random lookups +Average memory 0.24Mb, max 0.37Mb, min 0.08Mb +Approximate database size 23.76Mb +Average errors 0.155, max 2, min 0 +Average lookup 0.391s, max 0.436s, min 0.355s +Lookup misses 0 + + +running bloom with 10000 OUIs and 8000000 Devices +Attempting 1000 random lookups +Average memory 0.20Mb, max 0.40Mb, min 0.02Mb +Approximate database size 38.65Mb +Average errors 0.030, max 1, min 0 +Average lookup 0.536s, max 0.583s, min 0.500s +Lookup misses 1000 +``` + +As we can see, xor16-xxhash seems to be the best combination of speed, size and +accuracy. Additionally the bloom filter seems to have some portability issue +(likely related to the 32/64 bit switch) which would need to be resolved. + +Finally, a more ambitious test, on the same 3 machines, in the same order: + +``` +running xor16_xxhash with 10000 OUIs and 50000000 Devices +Attempting 1000 random lookups +Average memory 0.53Mb, max 1.58Mb, min 0.04Mb +Approximate database size 118.54Mb +Average errors 0.179, max 2, min 0 +Average lookup 0.096s, max 0.137s, min 0.079s +Lookup misses 0 + +running xor16_xxhash with 10000 OUIs and 50000000 Devices +Attempting 1000 random lookups +Average memory -0.01Mb, max 1.58Mb, min -0.09Mb +Approximate database size 118.54Mb +Average errors 0.179, max 2, min 0 +Average lookup 1.112s, max 1.322s, min 0.945s +Lookup misses 0 + +running xor16_xxhash with 10000 OUIs and 50000000 Devices +Attempting 1000 random lookups +Average memory 0.17Mb, max 1.99Mb, min 0.07Mb +Approximate database size 118.54Mb +Average errors 0.179, max 2, min 0 +Average lookup 0.916s, max 1.009s, min 0.864s +Lookup misses 0 +``` + +The benchmark code can be found +[here](https://github.com/Vagabond/bloom_router). These runs were generated by +the command in the README. The benchmark was first run on the Intel machine to +generate the routing tables, run a second time to use the generated routing +tables, and then the tables were copied to the Pi to run the test with the same +databases (generating the tables can be quite RAM intensive, so it is unsuitable +to be done on the Pi). + +# Drawbacks + +[drawbacks]: #drawbacks + +## Why should we _not_ do this? + +No matter how you slice it, this adds quite a lot of information to the ledger. +However, storing every possible DevEUI in a list would be 32Gb ( 2^32 \* 8 bytes) +of data. Storing AppEUIs or the associated routing destination just makes it +worse. XOR filters compress massively more, but they're not free. + +One flaw with this scheme will be 'route posioning' where I will be able to get +join packets for devices I want to see routed to myself simply by adding that +device to my bloom filter. In theory this could be used as a denial of service +attack by interfering with the receive window for the legitimate join response +packet. + +# Rationale and Alternatives + +[alternatives]: #rationale-and-alternatives + +## Why is this design the best in the space of possible designs? + +XOR16 filters using xxhash64 were evaluated against bloom filters using a 1 in +200 million false positive rate, XOR8 filters using erlang:phash2 and xxhash64 and +xor16 filters using erlang:phash2. XOR16 with xxhash64 provided the best all +around speed and memory usage, and were very competitive for lookup times. +phash2 has too many collisions (it's only a 60 bit hash) for this application, +so it was rejected. + +Other alternatives include cuckoo filters, but they're expected to be slower +than xor16+xxhash64 and require a more complicated implementation. Simply +storing a complete routing table, as discussed before, is not reasonable +because of size constraints. + +## What other designs have been considered and what is the rationale for not choosing them? + +Suggestions for other designs are welcome, routing arbitrary addresses without +being able to use prefix routing seems hard. + +## What is the impact of not doing this? + +We will be unable to support routing join packets for arbitrary LoRaWAN +join packets and thus unable to support LoRaWAN devices that are +already provisioned or unable to have their credentials modified. + +# Unresolved Questions + +[unresolved]: #unresolved-questions + +## What parts of the design do you expect to resolve through the HIP process before this gets merged? + +We need to nail down the permissible sizes of the XOR filters we want to store. + +We need to decide if these routing table entries also contain a range of +DevAddr entries to be used for routing of non-join packets. + +## What parts of the design do you expect to resolve through the implementation of this feature? + +We need to define where/how these routing entries are stored, how they're +created/updated and if they can be transferred (like IP space can be traded). + +## What related issues do you consider out of scope for this HIP that could be addressed in the future independently of the solution that comes out of this HIP? + +Pricing and availability of routing table entries for organizations operating +their own OUI. + +# Deployment Impact + +[deployment-impact]: #deployment-impact + +## How will current users be impacted? + +All existing LoRaWAN devices will either have to have their credentials added +to the routing table, or they will need new credentials. + +## How will existing documentation/knowlegebase need to be supported? + +We don't have a lot of documentation for the existing thing, so we can probably +forego this. + +#Is this backwards compatible? + +It can be made to be, we can probably generate routing tables out of console's +DB, for the devices we know the DevEUI for. + +# Success Metrics + +[success-metrics]: #success-metrics + +What metrics can be used to measure the success of this design? + +## What should we measure to prove an acceptance of this by it's users? + +A user should be able to onboard any arbitrary LoRaWAN device without altering +its DevEUI/AppEUI/AppKey. diff --git a/0009-non-helium-hotspots.md b/0009-non-helium-hotspots.md new file mode 100644 index 000000000..23813e61e --- /dev/null +++ b/0009-non-helium-hotspots.md @@ -0,0 +1,278 @@ +- Start Date: 02/19/2020 +- HIP PR: +- Tracking Issue: + +# Summary + +[summary]: #summary + +A comprehensive set of improvements to Proof-of-Coverage, the scoring system, how Hotspots join the network, and +participate in mining and the HBBFT consensus group. + +# Motivation + +[motivation]: #motivation + +On the Helium network today, only Hotspot hardware purchased from Helium Inc. is considered trustworthy. These Hotspots +are sold using a hardware key storage device (a secure element) that makes it reasonably challenging for an attacker to +create a virtual network of Hotspots that have valid keys. The downside of this situation is that the tens of thousands +of non-Helium Inc. LoRa gateways that exist in the world cannot join the network and participate in mining. + +The goal of this proposal is to propose a set of measures that make it safe for LoRa gateways of unknown origin to +participate in Proofs-of-Coverage and earn tokens for that participation. This goal poses some interesting challenges, +as in the current system the network loses the ability to verifiably prove that any sub-network created by such new +gateways truly exists since it's possible for dishonest actors to fake geographic locations and radio activitity. + +# Stakeholders + +[stakeholders]: #stakeholders + +- 3rd party Hotspot manufacturers +- DIY miners + +# Problem Definition + +[problem-definition]: #problem-definition + +There are a number of problems we hope to address with this proposal: + +1. Allow non-Helium Inc manufactured Hotspots to participate in Proof-of-Coverage and mining +2. Provide a way for non-radio hardware to participate in consensus groups +3. Increase the requirements for consensus group participation to improve the overall health of the network +4. Introduce a number of penalties for failing to perform any of the roles required for earning HNT + +# Allowing non-Helium Inc manufactured Hotspots to participate in Proof-of-Coverage + +[non-helium-hotspots]: #non-helium-hotspots + +## The problem + +Consider the below network where Hotspots A through F are of unknown origin, with the lines representing reported RF +connectivity between hotspots. + + +------+ + | | + +-----------+ A | + | | | + | +------+ + | + +------+ + | | + | F | + | | + +------+ + | +------+ + | | | + | | B | + | | | + | +------+ +------+ + +------+ | | | + | | | | C | + | E +-----------------------------+ | + | | | +------+ + +------+ | + | | + | +------+ + | | | + +-------------+ D | + | | + +------+ + +Since it is possible for RF data to be fabricated - there is no way to verify that data was sent via RF once it has been +demodulated - the network does not know whether these Hotspots are part of a virtual network, or whether they are +physically deployed at their claimed locations. + +To correctly identify whether the above network is legitimate, we can introduce a Helium Inc (or authorized 3rd party +reseller) 'trusted' Hotspot into the network and learn more about the behavior of the Hotspots A-F. Only real Hotspots +will be able to successfully participate in PoC challenges involving the trusted Hotspot. + +Reimagining the above network with the introduction of a trusted Hotspot, consider the below: + + +------+ + | | + | A +---------------+ + | | | + +------+ | + +--+---+ + +------+ | | + | | | X +<--+ Trusted Hotspot + | F | +---------------+ | + | | | +------+ + +------+ | + +---+--+ + | | + | B | + | | + +---+--+ +------+ + +------+ | | | + | | | | C | + | E | | | | + | | | +------+ + +---+--+ | + | | + | +--+---+ + | | | + +-------------+ D | + | | + +------+ + +With this information, we can verify that A, B, D and E can successfully complete PoC challenges which involve X. Since +we know that Hotspot X is trustworthy, we can conclude that any Hotspot which can participate in a PoC challenge +involving X can only do so if it's operating within the rules set by the consensus mechanism and also has an operating +radio chip. + +However, even with this scheme we still need a way to allow Hotspots not manufactured by Helium Inc or authorized +manufacturers to not only participate in PoC but also be candidates for consensus membership. + +To counter that and allow any hotspot to participate in PoC and have consensus membership candidacy, we propose to +introduce "Levels of Trust". + +## Current Network Behavior + +In the current network, onboarding a Helium Inc manufactured Hotspot grants full Proof-of-Coverage priviledges. + +As mentioned in the problem defintion, we cannot assume that every single DIY hotspot is going to incorporate a GPS chip +or a radio chip. Malicious enttities may try to game the system by tweaking/removing hardware and yet be able to +participate in PoC. Currently we _know_ that every single hotspot being added to the network is manufactured by helium +and has the required hardware to participate in proof-of-coverage challenges, as soon as we allow other hotspots to join +the network we have no verifiable way of being able to separate a virtual network from a real one. + +To mitigate that, we propose a new model for establishing trust among hotspots and subsequently change how hotspots earn +HNT, named "Levels of Trust". + +## Levels of Trust + +Below is a visual representation of the aforementioned Levels, the most important takeaway here is that any higher Level +encompasses all the benefits and constraints of the lower Levels (with a few exceptions). + + +-----------------------------+ + | | + +---->+ Level 3A +----+ + | | (Organic Challenger) | | + +--------------+ +---------------+ | | | | +-----------------------+ + | | | | | +-----------------------------+ | | | + | Level 1 +------>+ Level 2 +------+ +----->+ Level 4 | + | (Observer) | | (Participant) | | | | (Consensus Candidate) | + | | | | | +----------------------------+ | | | + +---------+----+ +---------------+ | | | | +-----------------------+ + | | | Level 3B | | + | +---->+ (Governance Challenger) +-----+ + | | | + | +-----------------+----------+ + | ^ + | | + +-----------------------------------------------------------+ + +Before we get into the details and constraints of each level, we need to set some common ground: + +- Every hotspot joining the network starts at the first level. +- Every successive level is granted the priviledges of all previous levels. +- Organic network growth allows hotspots to get to level 3A. In order to reach level 4, the owner must stake HNT. +- There is a path to get to level 3B from level 1 via on-chain governance mechanism (TBD). + +### Level I: Network Observer + +- Every hotspot which joins the helium network starts at Level 1 by issuing an `add_gateway` transaction. +- The entry fee is set to burning data credits worth $10 USD. +- A hotspot at Level 1 does not have any location asserted on the network, however, it is allowed to witness nearby PoC + challenges. This is to ensure that when the hotspot does assert a location via `assert_location` transaction, we can + be confident about its claim of location by analyzing its witness list. +- A hotspot at Level 1 is allowed to transmit data and earn HNT based only on transmitting network data. + +### Level 2: Network Participant + +- A hotspot must satisfy the below minimum criteria to enter Level 2: + - It must be a Level 1 hotspot for X number of blocks. + - Issue an `assert_location` transaction by incurring a $40 USD data credit burn fee. + - Witness sufficient number of PoC challenges involving Level 3 and above hotspots. +- A hotspot at Level 2 gains access to participate in PoC challenges (become a member in the PoC path). + +### Level 3: Network Challenger + +Level 3 is divided into two broad categories: + +#### Level 3A: Organic Network Challenger + +- A hotspot must satisfy the below minimum criteria to enter Level 3A: + - It must be a Level 2 hotspot for X number of blocks. + - Successfully participate in X number of PoC challenges involving other Level 3 and above hotspots. + - A successful challenge comprises of the hotspot being able to receive a PoC packet from a Level 3 hotspot, + successfully decrypt it and successfully transmit it to a Level 2 or above hotspot. +- A hotspot at Level 3A gains access to construct PoC challenges. + +#### Level 3B: Governance Network Challenger + +- A hotspot must satisfy the below minimum criteria to enter Level 3B: + - It must be a Level 1 hotspot for X number of blocks. + - It must be voted in via the on-chain governance mechanism (TBD) wherein either Helium (or an authorized 3rd party) + countersigns the `assert_location` transaction on the hotspot owner's behalf. +- A hotspot at Level 3B gains access to construct PoC challenges. + +### Level 4: Consensus Candidates + +- A hotspot must satisfy the below minimum criteria to enter Level 4: + - It must be a Level 3 hotspot for X number of blocks. + - The hotspot owner or another miner in the network must stake 10000 HNT in order to claim Level 4 status for the + hotspot. +- A hotspot at Level 4 gains access to consensus membership candidacy. + +## Level Demotion + +With the exception of Level 3B and Level 4 hotspots, any hotspot belonging to other levels is susceptible to level +demotion governed by the hotspot's score. + +### Level 4 to Level 3A + +TBD + +### Level 3A to Level 2 + +A hotspot operating at Level 3A may get demoted to Level 2 and lose challenger priviledges if its score continually +drops below a chain-var configured threshold for X number of blocks. + +### Level 2 to Level 1 + +- A hotspot operating at Level 2 may get demoted to Level 1 and lose challenging priviledges if its score continually + drops below a chain-var configured threshold for X number of blocks. + +- Once this happens, the hotspot would lose its asserted location via an `unassert_location` transaction and would go + back to observer mode. + +- The hotspot owner must issue an `assert_location` and incur the onboarding fee to get back onto the network and + qualify for Level 2 and above organic network growth. + +# Drawbacks + +[drawbacks]: #drawbacks + +TBD + +# Rationale and Alternatives + +[alternatives]: #rationale-and-alternatives + +TBD + +# Unresolved Questions + +[unresolved]: #unresolved-questions + +1. Under what conditions do we remove the stake for Level 4 hotspots? +2. Where does the removed stake go to? Does it just vanish? +3. How do we actually remove the stake? + +# Deployment Impact + +[deployment-impact]: #deployment-impact + +1. We need to ensure we transition the existing hotspots on the network in a meaningful way. Whether every single existing + hotspot goes into the same level or not is yet to be determined. + +2. We would also need to determine which hotspots qualify for Level 4 access as we need an initial pool of consensus + members candidates which would continue to miner the blocks once this HIP goes live in production. + +# Success Metrics + +[success-metrics]: #success-metrics + +NA diff --git a/0013-transfer-hotspot.md b/0013-transfer-hotspot.md index baf9caf31..5edb61126 100644 --- a/0013-transfer-hotspot.md +++ b/0013-transfer-hotspot.md @@ -5,9 +5,6 @@ - Author: [@mrallen1](https://github.com/mrallen1), [@abhay](https://github.com/abhay) - HIP Number: 13 - Tracking Issue: [#43](https://github.com/helium/HIP/issues/43) -- Status: Deployed - - [audit](https://github.com/helium/miner/blob/master/audit/var-48.md) - - [txn](https://explorer.helium.com/txns/DywtCExrXhTxv8VoDZl_hJDjQ2PUcov_AYrW98ZPpcg) # Summary diff --git a/0016-random-consensus-group-election.md b/0016-random-consensus-group-election.md index 8cd7b5cd4..f501df8e7 100644 --- a/0016-random-consensus-group-election.md +++ b/0016-random-consensus-group-election.md @@ -5,9 +5,6 @@ - Category: Economic, Technical - Original HIP PR: - Tracking Issue: -- Status: Deployed - - [audit](https://github.com/helium/miner/blob/master/audit/var-48.md) - - [txn](https://explorer.helium.com/txns/DywtCExrXhTxv8VoDZl_hJDjQ2PUcov_AYrW98ZPpcg) # Summary diff --git a/0018-remove-oracle-forecast-for-dc-burn.md b/0018-remove-oracle-forecast-for-dc-burn.md index 02ae6f21e..bc3446bf1 100644 --- a/0018-remove-oracle-forecast-for-dc-burn.md +++ b/0018-remove-oracle-forecast-for-dc-burn.md @@ -5,7 +5,6 @@ - Category: Technical - Original HIP PR: [#59](https://github.com/helium/HIP/pull/62) - Tracking Issue: [#65](https://github.com/helium/HIP/issues/65) -- Status: Approved # Summary diff --git a/0019-third-party-manufacturers.md b/0019-third-party-manufacturers.md index e76c14f74..fc2b414cb 100644 --- a/0019-third-party-manufacturers.md +++ b/0019-third-party-manufacturers.md @@ -6,7 +6,6 @@ - Category: Meta - Original HIP PR: - Tracking Issue: -- Status: Approved ## Light Hotspots diff --git a/0020-hnt-max-supply.md b/0020-hnt-max-supply.md index bb74be0fa..df425ac05 100644 --- a/0020-hnt-max-supply.md +++ b/0020-hnt-max-supply.md @@ -4,8 +4,6 @@ - Start Date: November 4, 2020 - Category: Economic - Tracking Issue: [#73](https://github.com/helium/HIP/issues/73) -- Status: Deployed - - [audit](https://github.com/helium/miner/blob/master/audit/var-79.md) # Summary diff --git a/0021-poc-link-layer.md b/0021-poc-link-layer.md index 60cba64eb..da565d607 100644 --- a/0021-poc-link-layer.md +++ b/0021-poc-link-layer.md @@ -4,7 +4,6 @@ - Start Date: November 11, 2020 - Category: Technical - Tracking Issue: [#78](https://github.com/helium/HIP/issues/78) -- Status: Closed # Summary diff --git a/0023-decouple-consensus-from-gateways.md b/0023-decouple-consensus-from-gateways.md index 22ecee7c6..fee499b2b 100644 --- a/0023-decouple-consensus-from-gateways.md +++ b/0023-decouple-consensus-from-gateways.md @@ -5,7 +5,6 @@ - Category: Technical - Original HIP PR: - Tracking Issue: -- Status: Closed # Summary diff --git a/0025-validators.md b/0025-validators.md index 323066798..d98778fb6 100644 --- a/0025-validators.md +++ b/0025-validators.md @@ -7,8 +7,6 @@ - Tracking Issue: [#111](https://github.com/helium/HIP/issues/111) - Frequently Asked Questions: [FAQ](https://github.com/helium/HIP/blob/master/0025-validators.md#frequently-asked-questions) -- Status: Deployed - - [audit](https://github.com/helium/miner/blob/master/audit/var-70.md) ## Summary diff --git a/0027-cbrs-5g-support.md b/0027-cbrs-5g-support.md index 5f0ebc9e4..95b013b0d 100644 --- a/0027-cbrs-5g-support.md +++ b/0027-cbrs-5g-support.md @@ -4,7 +4,6 @@ - Start Date: February 23th, 2021 - Category: Technical - Tracking Issue: -- Status: Approved ## Summary diff --git a/0028-consensus-reward-adjustments.md b/0028-consensus-reward-adjustments.md index 05a7d0a26..07dac1ff0 100644 --- a/0028-consensus-reward-adjustments.md +++ b/0028-consensus-reward-adjustments.md @@ -6,7 +6,6 @@ - Original HIP PR: - Tracking Issue: - Code PR: -- Status: [Approved](https://github.com/helium/HIP/issues/140#issuecomment-892848351) # Summary diff --git a/0029-multisignature-keys.md b/0029-multisignature-keys.md index afd04a220..afa47a50c 100644 --- a/0029-multisignature-keys.md +++ b/0029-multisignature-keys.md @@ -6,7 +6,6 @@ - Category: Technical - Original HIP PR: [#154](https://github.com/helium/HIP/pull/154) - Tracking Issue: [#157](https://github.com/helium/HIP/issues/157) -- Status: Deployed (2021-05-04) # Summary diff --git a/0030-update-threshold-cryptography.md b/0030-update-threshold-cryptography.md index 55473dcb2..092eb99db 100644 --- a/0030-update-threshold-cryptography.md +++ b/0030-update-threshold-cryptography.md @@ -6,7 +6,6 @@ - Category: Technical - Original HIP PR: [#155](https://github.com/helium/HIP/pull/155) - Tracking Issue: [#158](https://github.com/helium/HIP/issues/158) -- Status: Deployed (2021-05-04) # Summary diff --git a/0031-governance-by-token-lock.md b/0031-governance-by-token-lock.md index 8d5f7c891..c7a10f1b3 100644 --- a/0031-governance-by-token-lock.md +++ b/0031-governance-by-token-lock.md @@ -5,7 +5,6 @@ - Category: Governance - Original HIP PR: - Tracking Issue: -- Status: In Discussion # Summary diff --git a/0032-split-dcs.md b/0032-split-dcs.md index 19ad2af64..e9c6abbe0 100644 --- a/0032-split-dcs.md +++ b/0032-split-dcs.md @@ -5,7 +5,6 @@ - Category: Economic - Original HIP PR: - Tracking Issue: -- Status: In Discussion # Summary diff --git a/0033-regional-reward-adjustments.md b/0033-regional-reward-adjustments.md index 3c2d12f27..4e604888d 100644 --- a/0033-regional-reward-adjustments.md +++ b/0033-regional-reward-adjustments.md @@ -5,7 +5,6 @@ - Category: Technical, Economic - Original HIP PR: - Tracking Issue: -- Status: In Discussion ## Summary diff --git a/0034-validator-node-security.md b/0034-validator-node-security.md index 98015e4f1..895e5aadf 100644 --- a/0034-validator-node-security.md +++ b/0034-validator-node-security.md @@ -5,7 +5,6 @@ - Category: Technical - Original HIP PR: [211](https://github.com/helium/HIP/pull/211) - Tracking Issue: -- Status: In Discussion # Summary diff --git a/0035-safe-rf-metadata-side-channel.md b/0035-safe-rf-metadata-side-channel.md index 3a4053d8f..4e9866f7b 100644 --- a/0035-safe-rf-metadata-side-channel.md +++ b/0035-safe-rf-metadata-side-channel.md @@ -5,7 +5,6 @@ - Category: Technical - Original HIP PR: - Tracking Issue: -- Status: In Discussion # Safe extraction of RF Meta-Data diff --git a/0036-blockheights-instead-of-time.md b/0036-blockheights-instead-of-time.md index 41d088ef9..2622ddbf2 100644 --- a/0036-blockheights-instead-of-time.md +++ b/0036-blockheights-instead-of-time.md @@ -5,7 +5,6 @@ - Category: Technical - Original HIP PR: [257](https://github.com/helium/HIP/pull/257) - Tracking Issue: [260](https://github.com/helium/HIP/issues/260) -- Status: In Discussion # Summary diff --git a/0037-omni-protocol-poc.md b/0037-omni-protocol-poc.md index 89ec07b82..f8f1d2fd3 100644 --- a/0037-omni-protocol-poc.md +++ b/0037-omni-protocol-poc.md @@ -3,7 +3,6 @@ - Authors: @zer0tweets (FreedomFi), @JMF, @hashc0de - Start Date: August 28th, 2021 - Category: Technical -- Status: In Discussion - Original HIP PR: - Tracking Issue: - Discord channel: `#hip-37-omniprotocol-poc` on diff --git a/0039-hnt-redenomination.md b/0039-hnt-redenomination.md index 7021d89a1..dab2e6cfd 100644 --- a/0039-hnt-redenomination.md +++ b/0039-hnt-redenomination.md @@ -5,7 +5,6 @@ - Category: Economic - Original PR: - Tracking Issue: -- Status: In Discussion ## ​​Summary diff --git a/0040-validator-denylist.md b/0040-validator-denylist.md index 2a9ff0612..509c6a270 100644 --- a/0040-validator-denylist.md +++ b/0040-validator-denylist.md @@ -5,7 +5,6 @@ - Category: Economic, Technical - Original HIP PR: - Tracking Issue: -- Status: In Discussion ## Summary diff --git a/0041-governance-by-token-lock-v2.md b/0041-governance-by-token-lock-v2.md index a3356b5ec..c506f265b 100644 --- a/0041-governance-by-token-lock-v2.md +++ b/0041-governance-by-token-lock-v2.md @@ -3,7 +3,6 @@ - Authors: @tjain-mcc (tushar) - Start Date: November 1, 2021 - Category: Governance -- Status: In Discussion - Original HIP PR: - Tracking Issue: TODO - Discord Channel: TODO diff --git a/0042-beacon-witness-ratio-witness-reward-limit.md b/0042-beacon-witness-ratio-witness-reward-limit.md index 3898941c9..e4c320798 100644 --- a/0042-beacon-witness-ratio-witness-reward-limit.md +++ b/0042-beacon-witness-ratio-witness-reward-limit.md @@ -6,7 +6,6 @@ - Original HIP PR: - Tracking Issue: - Discord channel: #hip-42-beacon-witness-ratio -- Status: In Discussion # Motivation diff --git a/0045-lorawan-frequency-plan-selection.md b/0045-lorawan-frequency-plan-selection.md index 6f55f51cb..31571dce5 100644 --- a/0045-lorawan-frequency-plan-selection.md +++ b/0045-lorawan-frequency-plan-selection.md @@ -6,7 +6,6 @@ - Category: Technical - Original HIP PR: - Tracking Issue: -- Status: Withdrawn # Problem Statement diff --git a/0046-lorawan-netid-routing.md b/0046-lorawan-netid-routing.md index a2084144f..03e21300c 100644 --- a/0046-lorawan-netid-routing.md +++ b/0046-lorawan-netid-routing.md @@ -5,7 +5,6 @@ - Category: Technical - Original HIP PR: - Tracking Issue: TBD -- Status: Approved ## Summary and Motivation diff --git a/0047-increase-dkg-penalty.md b/0047-increase-dkg-penalty.md index 847fc90e9..6716a2736 100644 --- a/0047-increase-dkg-penalty.md +++ b/0047-increase-dkg-penalty.md @@ -5,7 +5,6 @@ - Category: Technical - Original HIP PR: - Tracking Issue: -- Status: Approved # Summary diff --git a/0051-helium-dao.md b/0051-helium-dao.md index 71c4b0ab2..91c68eef3 100644 --- a/0051-helium-dao.md +++ b/0051-helium-dao.md @@ -6,7 +6,6 @@ - Category: Economic / Technical - Original HIP PR: [#334](https://github.com/helium/HIP/pull/334) - Tracking Issue: [#336](https://github.com/helium/HIP/issues/336) -- Status: Approved # **Summary** diff --git a/0052-iot-dao.md b/0052-iot-dao.md index 7d2cfa98c..985167831 100644 --- a/0052-iot-dao.md +++ b/0052-iot-dao.md @@ -6,7 +6,6 @@ - Category: Economic, Technical - Original PR: - Tracking Issue: -- Status: Draft ## Summary diff --git a/0053-mobile-dao.md b/0053-mobile-dao.md index ba916f5e9..9932bcfc8 100644 --- a/0053-mobile-dao.md +++ b/0053-mobile-dao.md @@ -7,7 +7,6 @@ - Category: Economic, Technical - Orignal PR: - Tracking Issue: -- Status: In Discussion **Summary** diff --git a/0054-h3dex-targeting.md b/0054-h3dex-targeting.md index 1c9b20a63..c5bfa150a 100644 --- a/0054-h3dex-targeting.md +++ b/0054-h3dex-targeting.md @@ -6,7 +6,6 @@ - Category: Technical - Original HIP PR: - Tracking Issue: -- Status: In Discussion # Summary diff --git a/0055-validator-challenges.md b/0055-validator-challenges.md index 8db6a8bb0..8690b3727 100644 --- a/0055-validator-challenges.md +++ b/0055-validator-challenges.md @@ -6,7 +6,6 @@ - Category: Technical - Original HIP PR: - Tracking Issue: -- Status: In Discussion # Summary diff --git a/0056-state-channel-dispute-strategy.md b/0056-state-channel-dispute-strategy.md index c434bb27b..44a049535 100644 --- a/0056-state-channel-dispute-strategy.md +++ b/0056-state-channel-dispute-strategy.md @@ -7,7 +7,6 @@ - Category: Technical - Original HIP PR: - Tracking Issue: -- Status: In Discussion # Summary diff --git a/0057-poc-rewards-establishment-period.md b/0057-poc-rewards-establishment-period.md index 576e8666e..5d653d00e 100644 --- a/0057-poc-rewards-establishment-period.md +++ b/0057-poc-rewards-establishment-period.md @@ -6,7 +6,6 @@ - Category: Technical - Original HIP PR: - Tracking Issue: -- Status: In Discussion # Summary diff --git a/0058-poc-distance-limit.md b/0058-poc-distance-limit.md index 8865fef13..4f1fd3ebd 100644 --- a/0058-poc-distance-limit.md +++ b/0058-poc-distance-limit.md @@ -6,7 +6,6 @@ - Category: Technical - Original HIP PR: - Tracking Issue: -- Status: In Discussion # Summary diff --git a/0059-reduce-xor-filter-fees.md b/0059-reduce-xor-filter-fees.md index a5eede5c9..f76b9777c 100644 --- a/0059-reduce-xor-filter-fees.md +++ b/0059-reduce-xor-filter-fees.md @@ -7,7 +7,6 @@ [https://github.com/helium/blockchain-core/pull/1303](https://github.com/helium/blockchain-core/pull/1303) - Tracking Issue: [https://github.com/helium/HIP/issues/391](https://github.com/helium/HIP/issues/391) -- Status: In Discussion # Summary diff --git a/0060-entity-weighted-vote.md b/0060-entity-weighted-vote.md index 623f59d43..4f90239d9 100644 --- a/0060-entity-weighted-vote.md +++ b/0060-entity-weighted-vote.md @@ -5,7 +5,6 @@ - Category: Governance - Original HIP PR: - Tracking Issue: -- Status: In Discussion # Summary diff --git a/0065-vendor-token-lockup.md b/0065-vendor-token-lockup.md index cb8c7889a..eb8c12e6a 100644 --- a/0065-vendor-token-lockup.md +++ b/0065-vendor-token-lockup.md @@ -3,7 +3,6 @@ - Category: Economic, Technical - Original PR: - Tracking Issue: -- Status: In Discussion # Addendum to HIP-19 diff --git a/0066-trust-score-and-denylist-convenience.md b/0066-trust-score-and-denylist-convenience.md index ee9a7b36a..d80505eaf 100644 --- a/0066-trust-score-and-denylist-convenience.md +++ b/0066-trust-score-and-denylist-convenience.md @@ -5,7 +5,6 @@ - Category: Technical - Original HIP PR: - Tracking Issue: -- Status: In Discussion # Summary diff --git a/0067-repeal-redenomination.md b/0067-repeal-redenomination.md index c83df280d..ffce653aa 100644 --- a/0067-repeal-redenomination.md +++ b/0067-repeal-redenomination.md @@ -5,7 +5,6 @@ - Category: Economic - Original HIP PR: - Tracking Issue: -- Status: In Discussion # Summary diff --git a/0068-open-service-subdao.md b/0068-open-service-subdao.md index 062cabe05..7b7f76c8d 100644 --- a/0068-open-service-subdao.md +++ b/0068-open-service-subdao.md @@ -5,7 +5,6 @@ - Category: Economic, Technical - Original HIP PR: - Tracking Issue: -- Status: In Discussion # Summary diff --git a/0069-reassertion-fee-reduction.md b/0069-reassertion-fee-reduction.md index 736ae9c13..213494b7c 100644 --- a/0069-reassertion-fee-reduction.md +++ b/0069-reassertion-fee-reduction.md @@ -5,7 +5,6 @@ - Category: Economy - Original HIP PR: - Tracking Issue: -- Status: Approved # Summary diff --git a/0070-scaling-helium.md b/0070-scaling-helium.md index 6086f547d..2867b61d6 100644 --- a/0070-scaling-helium.md +++ b/0070-scaling-helium.md @@ -5,7 +5,6 @@ - Category: Technical - Original HIP PR: - Tracking Issue: -- Status: In Discussion # Summary diff --git a/0071-scaling-with-governance-hedera.md b/0071-scaling-with-governance-hedera.md index 179bccb76..699e7b369 100644 --- a/0071-scaling-with-governance-hedera.md +++ b/0071-scaling-with-governance-hedera.md @@ -8,7 +8,6 @@ - Original HIP PR: [#480](https://github.com/helium/HIP/blob/main/0071-scaling-with-governance-hedera.md) - Tracking Issue: [#486](https://github.com/helium/HIP/issues/486) -- Status: In Discussion # Summary diff --git a/0072-secure-concentrators.md b/0072-secure-concentrators.md index 254d230b7..ec34068d4 100644 --- a/0072-secure-concentrators.md +++ b/0072-secure-concentrators.md @@ -8,280 +8,246 @@ ## Summary -In this HIP, we propose a new type of IoT network actor: the Secure Concentrator Card (SCC). Secure -Concentrator Card is similar to standard LoRaWAN concentrator cards, but with additional Secure -Microcontroller Unit (SMCU) and onboard GPS receiver. The SMCU digitally signs LoRa data packets as -they are received from the radio. In this way, packet data and its corresponding metadata (RSSI, -Frequency, GPS location and time) can be verified to be authentic. +In this HIP, we propose an amendment to HIP 19 to enable a new type of IoT network actor: a Secure Concentrator Card (SCC). A Secure Concentrator Card is similar to a standard LoRaWAN concentrator card, but with an additional Secure Microcontroller Unit (SMCU) and onboard GPS receiver. The SMCU digitally signs LoRa data packets as they are received from the radio. In this way, packet data and its corresponding metadata (RSSI, Frequency, GPS location and time) can be verified to be authentic. The primary intention of this HIP is to combat Proof-of-Coverage gaming. Secure Concentrtors achieve this by providing trustworthy data upon which better gaming detectors and PoC algorithms can be built. - Secure Concentrators are _optional._ There is **no** requirement to upgrade or purchase new hardware. Helium Hotspots without Secure Concentrator will continue functioning as normal. -- Helium Hotspots with Secure Concentrators will earn **1.25x** rewards. (See _Proof Of Coverage - Rewards_ section) +- Helium Hotspots with Secure Concentrators will earn **1.25x** rewards. (See _Proof Of Coverage Rewards_ section) ## Motivation -Today's Helium Hotspot have a large security flaw. Anyone can modify the software running on a -Hotspot and generate fake LoRa packets. This is a big problem because PoC rewards are based on these -packets. The new Secure Concentrator Card solves this problem by digitally signing packets in -hardware. Secure Concentrators make it _prohibitively_ difficult to game the PoC system by also -utilizing tamper-resistant design elements (routed traces, hard cured potting material, etc). The -end result is a more secure Physical Root of Trust for the Helium IoT system and fair PoC earnings -for all. +Today's Helium Hotspots have a large security flaw. Anyone can modify the software running on a Hotspot and generate fake LoRa packets. This is a big problem because PoC rewards are based on these packets. The new Secure Concentrator Card solves this problem by digitally signing packets in hardware making it _prohibitively_ difficult to generate fake data. -The proposed SCC design allows existing Helium miners to upgrade by swapping out existing -concentrator cards with new secure card. In addition, SCC would enable the DIY community to build -their own hardware, greatly increasing the diversity and proliferation of Hotspots. +Also, Secure Concentrators will provide the Helium PoC Oracles data about the local area in which they are deployed. The trustworthy data can be used to build the next generation of gaming detection AI and improved PoC algorithms. The end result is a more secure Physical Root of Trust for the Helium IoT system and fair PoC earnings for all. + +This HIP defines general hardware requirements for a Secure Concentrator and provides an example open-source implementation. The proposed requirements allow existing Helium Hotspots to be upgradable to Secure Hotspots simply by swapping out existing concentrator cards with a new secure card. In addition, SCC would enable the DIY community to build their own hotspot hardware capable of earning PoC rewards, greatly increasing the diversity and proliferation of Hotspots. ## Stakeholders -The entire IoT Helium network will be affected by this HIP as the introduction of SCC will create a -reliable source of data to base Proof of Coverage algorithms on. SCC will also enable DIY Hotspot -builds increasing the diversity and proliferation of Helium Hotspots. Finally, SCCs will enable a -new type of location service for low-power devices (TDoA). +The entire IoT Helium network will be affected by this HIP as the introduction of SCC will create a reliable source of data to base Proof of Coverage algorithms on. SCC will also enable DIY Hotspot builds increasing the diversity and proliferation of Helium Hotspots. Finally, SCCs will enable a new type of location service for low-power devices (TDoA). ## Detailed Explanation -### Design Goals +## Design Goals - Increase security level of Helium's Proof-of-Coverage. - Ability to replace/upgrade existing Miner's concentrator card with secure concentrator card - Turn off-the-shelf LoRaWAN gateways into full PoC Helium miner (DIY Hotspot) - - Secure Concentrators effectively replace the need for ECC806 security chip as mandated in - HIP-19. -- Enable new class of Helium nodes that can provide additional functionality (LoRa PoC Mapper? - Mobile Hotspot?) -- Enable new level of Proof-of-Coverage verification (possibly using Time Difference of Arrival + - Secure Concentrators effectively replace the need for ECC608 security chip as mandated in HIP-19. +- Enable new class of Helium nodes that can provide additional functionality (LoRa PoC Mapper? Mobile Hotspot?) +- Enable new types of Proof-of-Coverage verification (possibly using Time Difference of Arrival (TDOA)) -### Hardware Architecture +## Proof of Coverage Rewards +In order to incentivize adoption of Secure Concentrators, we propose increasing the earnings of PoC Witness packets received by Secure Concentrator by a factor of **(1.25x)**. We believe this is justified due to the increased security benefits the entire Helium network will enjoy with the addition of Secure Concentrators. A Secure Concentrator Hotspot is only eligible for the PoC reward if the Witness packet includes valid GPS time and location data. If a Secure Concentrator does not have a valid GPS lock at the time of receiving the Witness packet, it will not receive any reward. -![image ](0072-secure-concentrators/hardware_block.png) The new hardware architecture for SCC is -based on Semtech's LoRa Corecell Gateway reference design. The major change involves the addition of -a Secure MCU (**SMCU**) placed in between the communication path of the Host CPU and the SX1303. The -SMCU's primary job is to cryptographically sign RF data received over the air such that other nodes -participating on the Helium network are able to verify the data is authentic and unaltered from it -original form. It is important the SMCU has exclusive access SX1303's SPI bus to eliminate the -possibility of spoofing incoming RF packets. The hardware design will consider several techniques to -make it physically difficult to access the SMPU and SX130x including using buried traces, placing -the components under a metal shield, and/or using potting material. +This incentive structure is part of a larger future roadmap with more network improvements and +hardware types that will each have their own incentives. The proposed 1.25x rewards is intended to incentivize initial adoption. The rewards structure is subject to change with adoption of future HIP. -### Hardware Key +## Manufacturers +Hardware Manufacturers of Secure Concentrators will be required to be approved by the Helium +Manufacturer Compliance Committee and pass a hardware audit process similar to the hardware audit process required for Hotspot manufacturers (see HIP-19). -The SMCU stores a unique ED25519 keypair generated at manufacturing time in its non-volatile memory -known as the **Hardware Key**. Note: the Hardware Key is not the same as the `swarm_key`. This is an -important concept as it allows existing Miner's to upgrade their existing concentrator card with new -SCC. The Hardware's private key is considered a secret and stored in a special section of the SMCU -non-volatile memory used for secure storage. Secure storage can not be read-out and is not -accessible to the Host CPU or via hardware debugging tools. +The process of onboarding new Secure Concentrators onto the Helium network is very similar to the Hotspot onboarding process as described in HIP-19. Manufacturers will also be bound by the same code of ethics as described in HIP-19. Also, the Helium Manufacturing Compliance Committee (MCC) will have the same authority over approved Manufacturers. -The Hardware Key can also be used to sign other types of transactions beyond RF data. However, it -does not allow signing _arbitrary_ data. Doing so would put the security on par with existing HIP-19 -secure element approach and thus defeat the purpose of this HIP. Note: If the SMCU's firmware -allowed for signing arbitrary data with its Hardware Key, an attacker could jailbreak the Host CPU -and craft a signing request that contained fake RF data. +## Installation +Hotspot owners can optionally upgrade their existing Hotspot with a Secure Concentrator if they have a Hotspot that is capable of the upgrade. Most Hotspot designs that use a mPCIe card slot are capable of the upgrade. However, upgrading a Hotspot may void the warranty. Hotspot manufacturers are NOT required to support upgrade to Secure Concentrator. It is the Hotspot Manufacturer's discretion to provide support for SCCs. -### Semtech SX1303 +manufacturers can include SCCs in new Hotspots designs, in which case manufacturers are responsible for providing installation and service for Secure Concentrator. Use of SCC in Hotspot design satisfies the HIP 19 requirement for Encrypted/locked-down firmware and Encrypted storage of the miner swarm_key. To be clear, Hotspots that use SCC will not be required to have locked-down firmware and will not be required to securely store the swarm_key. (Note swarm_key is not the same as the SCC's Hardware Key). + +## General Requirements +This HIP gives authority the MCC to design a process for approving Secure Concentrators. The approval process may involve engaging with 3rd party security labs for intensive hardware/software penetration testing. Ultimately, the MCC shall hold final approval power of a candidate Secure Concentrator design. That being said, a Secure Concentrator design should meet the following requirements: + +### Hardware features + +An SCC design must meet the following minimum hardware requirements: + + - Onboard GNSS (GPS) receiver. GPS provides geolocation and timestamping reference of every received packet. The GPS horizontal and vertical position error must be less than 20 meters 99% of the time. + - Appropriate hardware to precisely timestamp the arrival of received LoRa packets on par with Semtech SX1303. + - Ability to sign the received LoRa packets and associated metadata (GPS location, time, frequency, etc) with a secured asymmetric key (see further security requirements). + +### Security requirements + +An SCC design must meet all the following minimum security requirements: + + 1. A Secure Element capable of managing a permanent, unique ED25519 asymmetric key. + 2. A Security Boundary that ensures that: + - The Secure Element only obeys signature requests from a Secure Processor. + - The radio hardware is exclusively controlled by the Secure Processor. + - All packets and meta-data attested by the Secure Processor come only from the radio and not from an external source. + - The Secret key is only used to sign packet and meta-data or data with `no-rf` prefix. + - Read access to Secret key material is restricted to the Secure Processor only. + - Write access to the Secret key material if forbidden. + 3. A Secure Processor that only runs software which has been cryptographically authenticated to have come from the Manufacturer (or the MCC). -The Semtech SX1303 is a new generation of LoRa baseband processor for gateways. It is size and pin -compatible with SX1302 and like SX1302, it excels in cutting down current consumption, simplifying -thermal design, lowering Bill Of Materials cost, and reducing overall size of gateways. In addition -to supporting all the features of SX1302, SX1303 introduces a new Fine Timestamp capability that -enables Time Difference of Arrival (TDOA) network-based geolocation. The new TDOA feature could -potentially enable another layer of Proof of Coverage. For example, Helium Hotspots using SX1303 -chipset could coordinate together to assert that another Helium Hotspot's beacon signal actually -originated from the stated geo-location. +No design will be approved unless it meets all criteria. -### GPS Receiver +Example design choices that reflect these requirements are: + - Using buried traces (2 & 3) + - Placing components under metal shields (2 & 3) + - Using potting material (2 & 3) + - Resistance to timing attacks (1) + - Resistance to fault injection (1, 2 and 3). + - Separate buses between the Host and the Secure Element (2) -The GPS receiver is a required component. GPS provides geolocation and timestampling of every -received packet. GPS is also needed to provide precise timing required for the Semtech SX1303 TDOA -feature. +### Performance requirements + 1. Can sign 10 or more packet receipts per second. -### RF Data Signature +### Process requirements +All effort must be taken to ensure the Hardware Key stored in the Secure Concentrator remains a secret. Manufacturers themselves should never have access to the keys. Also, Manufacturers are required to have strong processes in place for handling firmware updates. manufacturers must demonstrate prudence when handling firmware update key. Manufacturers must also have a firmware update contingency plan in place in the event the Manufacturer should cease to support their product. To these ends, Manufacturers of Secure Concentrator are required to practice the following process requirements: + + 1. Secure key generation is performed on the Secure Concentrator hardware itself. The key material is never transferer in or out of the Secure Concentrator. + 2. The Provisioning process must disable all diagnostic/debug interfaces permanently. + 3. The Manufacturer must disclose via written document to the MCC their process for handling firmware updates including who has access to the firmware update keys and how the key is securely stored. + 4. The Manufacturer must disclose via written document to the MCC their firmware update contingency plan. + +One possible contingency plan is to use the "dual-key" update design. Under this plan, a Secure Concentrator will accept updates from either the Manufacturer's firmware update key OR the MCC's firmware update key. Another possible contingency plan is to enter into an escrow agreement in which a third-party keeps a copy of the firmware update key. In the event the Manufacturer ceases to support the product, the third party transfers control of the firmware update key to the MCC. + +## Hotspot Mechanics + +Registering a Hotspot that uses a Secure Concentrator is a similar process to registering a Data-Only Hotspot. First, the Hotspot generates a new random `swarm_key`. Unlike other Hotspot types, the `swarm_key` on a Secure Hotspot is not considered a high priority secret because it is not used for earning PoC rewards. As such, it is not required to store the `swarm_key` in a secure element. In fact, a Secure Hotspot is not required to have a hardware secure element at all (for example, it can be stored in flash). Next, a transaction is sent to the blockchain defining the new Hotspot as a 'secure' type. This transaction (the Binding transaction) includes the Hotspot's `swarm_key`, the Secure Concentrator's Hardware Key, and the Hotpot Owner's wallet address. The Binding transaction is signed by all keys. The first time the Secure Concentrator's Hardware Key is used in a Binding transaction, there is no fee. Every subsequent Binding transaction cost 500000 DC ($5 USD). Note: this mechanism enables several things that are currently difficult or impossible such as resale of Secure Concentrators/Hotspots on the secondary market. + +Note: hotspot currently on the denylist will continue to be denied earning PoC rewards even if they are upgraded with a Secure Concentrator. + +Note: the Binding transaction still requires a small Solana transaction fee. It is expected that +initial transaction fee will be paid out of the Maker's wallet. Subsequent binding transaction fees +will be covered from the Hotspot owner's wallet. + +## RF Data Signature ![image ](0072-secure-concentrators/rf_signing.png) -Semtech's open-source LoRa packet forwarder is traditionally the software that runs on the Host CPU -and reads data from the SX130x hardware via SPI or USB. The packet forwarder produces output JSON -formatted data when RF data is received. We propose modifying the packet forwarder software to -include an additional key/value pair containing the RF data cryptographic signature. +The Secure Concentrator signs LoRa packets and metadata with its unique ED25519 Hardware Key. To optimize for low-latency, the unsigned data if first sent to the host CPU and the packet signature is later computed. This design allows the host CPU to serve latency-sensitive applications. + +Signing data packets is performed by first converting the packet's metadata, payload, gps time, and location into a byte stream. The data is encoded using [Borsh](https://borsh.io/) serialization. +Here we have the structure of received LoRa packets and metadata. ``` -{ - "rxpk": { - "tmst":20900514000, - "chan":2, - "rfch":0, - "freq":866.349812, - "stat":1, - "modu":"LORA", - "datr":"SF9BW125", - "codr":"4/6", - "rssis":-108, - "rssic":-45, - "lsnr":-12.8, - "size":23, - "data":"AMy7qgAAAAAATYMmmnj6AADl6YP1Jrw", - // New fields below - "hw_sig": "HsOIwoZaHB8Iw4LDq1QTwqV0w7HDqcOOHRxvdQ8vwobDjsO2Jg7CnRrDtHLDtA==", - // optional fields below - "gps_time_s": 465465, - "gps_time_ns": 322983, - "gps_lat": 48.858288, - "gps_long": 2.294479, - "gps_alt": 10, - } +struct RxPkt { + /// Frequency in Hertz + pub freq: u32, + /// Datarate. Something like "SF7BW125" + pub datarate: String, + /// Signal to Noise radio (in 0.01 dB) + pub snr: i16, + /// Received Signal Strength Indicator (in 0.1 dBm) + pub rssi: i16, + /// 32 Mhz clock timestamp + pub tmst: u32, + /// Unique identifier of the Secure Concentrator. + pub card_id: [u8 ; 8], + // timestamp the packet was received (nanoseconds since the GPS epoch 1980-01-06 0:00 UTC) + pub gps_time: Option, + pub pos: Option, + pub payload: Vec, +} + +struct WGS84Position { + /// longitude (deg) 1e-7 scale + pub lon: i32, + + /// latitude (deg) 1e-7 scale + pub lat: i32, + + /// Height above ellipsoid (millimeters) + pub height: i32, + + /// Horizontal accuracy estimate (millimeters) + pub hacc: u32, + + /// Vertical accuracy estimate (millimeters) + pub vacc: Option, } ``` +### Example Signature +``` +let pkt = RxPkt { + freq: 904_000_000, + datarate: "SF7BW125", + snr: -1200, + rssi: 100, + tmst: 10_000, + card_id: [1, 2, 3, 4, 5, 6, 7, 8], + gps_time: Some(1209600100000000000), + pos: Some(WGS84Position { + lat: 7353466, + lon: -3588727, + height: 38472, + hacc: 3425, + vacc: Some(683485), + }), + payload: b"hello world", +}; + +// The above example encoded with Borsh serialization results in the following hex-encoded data: + +00f2e13508000000534637425731323550fb64001027000001020304050607080100e8c6d8e15cc91001893dc9ff7a34700048960000610d000001dd6d0a000b00000068656c6c6f20776f726c64 + +``` + +Given the following private key and noise initiation, the resulting ED25519 signature of the above data would be: + +``` +private key: 38870584fa7cb9e56efe921a65e02fcc18d6d8e9fcfec7796181f422e6aa1e3fd466e616d43b44e2e045be240ad9faf7090fb444312445cef01f21ed5f74e55e +noise: 000102030405060708090a0b0c0d0e0f +sig (ED25519): c90fce6cc6810b6099cadfeb276a9b49077ec88a421d49045e1c7220fe459e081e75e4b77af51178396d1a94be3d6800b93605afe9fd5165134893c4b04e550b +``` + +Note: Secure Concentrators use ED25519 streaming (incremental) API for producing encrypted signatures. + ### Sign Non-RF data -The SMCU can also sign non-RF data with its Hardware Key upon request. The signature will always -include the string prefix `nonrf` in its message creation to distinguish from RF data. +The SMCU can also sign any arbitrary data with its Hardware Key upon request. However, the signature will always include the string prefix `nonrf` in its message creation to distinguish from RF data. +For example, signing the ascii-encoded byte array: `hello world` would result: ``` -payload_hash = sha512(payload | int32_msb(payload size)) -msg = 'nonrf' | payload_hash | int32_msb(tmst) -signature = ed25519_sign(msg, pubKey, privKey) +private key: 38870584fa7cb9e56efe921a65e02fcc18d6d8e9fcfec7796181f422e6aa1e3fd466e616d43b44e2e045be240ad9faf7090fb444312445cef01f21ed5f74e55e +noise: 000102030405060708090a0b0c0d0e0f +sig (ED25519): 388609f27448a6981876edac0b9ed13f65015b36e48963056393434f562af0763ce81971c5421e0d54014fed3f7003489847241971e8c0be0d5f70bcee7fc500 ``` -## Secure Firmware - -The firmware running on Secure Concentrator's SMCU is licensed under the GPLv3 open-source license. -Its code repository is kept public and maintained by the Community. The firmware itself has a -bootloader that checks the cryptographic signature of the application image at each power up to -ensure it is unaltered from its original form. The key used to sign the application image is called -the `App Signing Key`. The firmware actually has two App Signing Keys slots. One of the key slots -must be populated with Helium Foundation's App Signing Key. The other key slot can optionally be -populated with a Manufacturer's App Signing Key. Helium Foundation will use its App Signing Key to -sign firmware from the official open-source repository. Manufacturers can optionally fork the -open-source repository and create changes specific to their hardware variants. Manufacturer's must -comply with the reciprocal nature of the GPLv3 license and make their modifications compatible with -the GPLv3. - -The intention of the "two-slot" scheme is to always allow any Secure Concentrator produced by any -Manufacturer to be updated with the official open-source firmware. In the case a Manufacturer goes -out of business or otherwise unable to provide support for their hardware, owners of Secure -Concentrators can always choose to run the open-source firmware. +Note: Secure Concentrators use ED25519 streaming (incremental) API for producing encrypted signatures. -## Proof of Coverage Rewards -In order to incentivize adoption of Secure Concentrators, we propose increasing the earnings of PoC -Witness packets received by Secure Concentrator by a factor of **(1.25x)**. We believe this is -justified due to the increased security benefits the entire Helium network will enjoy with the -addition of Secure Concentators. A Secure Concentrator is only eligible for the PoC reward if the -Witness packet includes valid GPS time and location data. If a Secure Concentrator does not have a -valid GPS lock at the time of receiving the Witness packet, it will not receive any reward. -This incentive structure is part of a larger future roadmap with more network improvements and -hardware types that will each have their own incentives. +## Example Hardware Architecture +NLighten Systems has developed an open-source hardware and firmware Secure Concentrator reference design with the aid of a Helium Foundation grant. The design files can be found here: https://gitlab.com/nlighten-systems/kompressor/ +The following sections describe the reference design choices. Alternative Secure Concentrator design does not necessarily need to include the same design components as long as it adheres to the General Requirements. -## Manufacturers +Note: approval of this HIP does NOT automatically approve NLighten System's design. The MCC has final approval power of any Secure Concentrator design, including the design by NLighten Systems. -Hardware Manufacturers of Secure Concentrators will be required to be approved by the Helium -Manufacturer Compliance Committee and pass a hardware audit process similar to the hardware audit -process required for Hotspot manufacturers (see HIP-19). - -Responsibility for installation and service: - -- Manufactures can include SCCs in Hotspots, in which case Manufactures are responsible for - providing installation and service. -- Hotspot owners can buy and install SCCs in which case the Hotspot falls under the OEM's warranty. -- Note: upgrading an existing Hotspot with SCCs may require changes to the Hotspot firmware. It is - the Hotspot Manufacture's discretion to provide support for SCCs. - -Responsibility for MCC audit - -The hardware audit process for SCCs are exactly the same as the process for Hotspot hardware under -HIP 19. - -- MCC audits the SCC design and implementation. -- Use of SCC in Hotspot design satisfies the HIP 19 requirement for Encrypted/locked-down firmware - and Encrypted storage of the miner swarm_key. To be clear, Hotspots that use SCC will not be - required to have locked-down firmware and will not be required to securely store the swarm_key. - (Note swarm_key is not the same as the SCC's Hardware Key). - -## Onboarding - -Onboarding refers to the action a Manufacture takes to add new Secure Concentrator Hardware Key to -the blockchain. Onboarding will occur at a time before shipping to final customers. a Secure -Concentrator is only capable of earning Proof of Coverage rewards after its Hardware Key has been -Onboarded. - -Manufacturers will be required to stake $10 USD worth of HNT (as determined by HNT price oracle -using the trailing 30-day average from the time of the staking transaction) for each Secure -Concentrator they produce. The staking period is fixed at three years. The HNT is converted to veHNT -and automatically 100% delegated to the IoT subDAO. Any earning generated as a result of staking -activity is transferred to the Manufacturer wallet as per usual. If a Manufacturer is found to have -violated any of the terms of the Helium Foundation Ethics document (as determined by the Helium -Tribunal Process), their staking balance can be partially or fully Burned. The "Burned" action is -defined as converting the offending Manufacturer's stake balance into HNT and then removing the -resulting HNT from circulation permanently. - -Onboarding is fully automatic processes performed by interacting with a Solana Smart Contract. A -Manufacturer will create an Oboarding transaction containing the new Secure Concentrator Hardware -Public key and $10 worth of HNT and send it to the Solana Smart Contract. The Smart Contract -processes the transaction, adds the Hardware Key to the blockchain, and converts the HNT to veHNT -and delegates 100% to IoT subDAO for a period of three years. +![image ](0072-secure-concentrators/hardware_block.png) NLighten hardware architecture for SCC is based on Semtech's LoRa Corecell Gateway reference design. The major change involves the addition of a Secure MCU (**SMCU**) placed in between the communication path of the Host CPU and the SX1303. The SMCU's primary job is to cryptographically sign RF data received over the air such that other nodes participating on the Helium network are able to verify the data is authentic and unaltered from it original form. It is important the SMCU has exclusive access SX1303's SPI bus to eliminate the possibility of spoofing incoming RF packets. The hardware design employs several techniques to make it physically difficult to access the SMPU and SX130x including using buried traces, placing the components under a metal shield, and using hard-curing potting material. -## Hotspot Mechanics +### Semtech SX1303 +The Semtech SX1303 is a new generation of LoRa baseband processor for gateways. It is size and pin compatible with SX1302 and like SX1302, it excels in cutting down current consumption, simplifying thermal design, lowering Bill Of Materials cost, and reducing overall size of gateways. In addition to supporting all the features of SX1302, SX1303 introduces a new Fine Timestamp capability that enables Time Difference of Arrival (TDOA) network-based geolocation. The new TDOA feature could potentially enable another layer of Proof of Coverage. For example, Helium Hotspots using SX1303 chipset could coordinate together to assert that another Helium Hotspot's beacon signal actually originated from the stated geo-location. -Registering a Hotspot that uses a Secure Concentrator is similar process to registering a Data-Only -Hotspot. First, the Hotspot generates a new random `swarm_key`. Unlike other Hotspot types, the -`swarm_key` on a Secure Hotspot is not considered a high priority secret because it is not used for -earning PoC rewards. As such, it is not required to store the `swarm_key` in a secure element. In -fact, a Secure Hotspot is not required to have a hardware secure element at all (can store in -flash). Next, a transaction is sent to the blockchain defining the new Hotspot as a 'secure' type. -This transaction (the Binding transaction) includes the Hotspot's `swarm_key`, the Secure -Concentrator's Hardware Key, and the Hotpot Owner's wallet address. The Binding transaction is -signed by all keys. The first time the Secure Concentrator's Hardware Key is used in a Binding -trasaction, there is no fee. Every subsequent Binding transaction cost 500000 DC ($5 USD). Note: -this mechanism enables several things that are currently difficult or impossible such as resale of -Secure Concentrators/Hotspots on the secondary market and repurposing Hotspots with lost keys or -Hotspots on the denylist. - -For clarity, Hotspots with Secure Concentrators are not subject to any fees when adding a Hotspot to -the blockchain (with the exception of the $5 'Binding' fee which is only applicable for subsequent -Binding transactions). Hotspots with Secure Concentrators are not subject to Assert Location fees. -In fact, Secure Hotspots are free to continually move their physical location because the GPS -metadata is included in the signed packets. Secure Hotspots are still subject to the same density -scale rules. +### Hardware Key -Note: the Binding transaction still requires a small Solana transaction fee. It is expected that -initial transaction fee will be paid out of the Maker's wallet. Subsequent binding transaction fees -will be covered from the Hotspot owner's wallet. +The SMCU stores a unique ED25519 keypair generated at manufacturing time in its non-volatile memory known as the **Hardware Key**. Note: the Hardware Key is not the same as the `swarm_key`. This is an important concept as it allows existing Miner's to upgrade their existing concentrator card with new SCC. The Hardware's private key is considered a secret and stored in a special section of the SMCU non-volatile memory used for secure storage. Secure storage can not be read-out and is not accessible to the Host CPU or via hardware debugging tools. -## Reference Hardware Design +The Hardware Key can also be used to sign other types of transactions beyond RF data. However, it does not allow signing _arbitrary_ data. Doing so would put the security on par with existing HIP-19 secure element approach and thus defeat the purpose of this HIP. Note: If the SMCU's firmware allowed for signing arbitrary data with its Hardware Key, an attacker could jailbreak the Host CPU and craft a signing request that contained fake RF data. -NLighten Systems has developed Open-Source hardware and firmware Secure Concentrator reference -design. The design files can be found here: https://gitlab.com/nlighten-systems/kompressor/ +### Secure Firmware + +The firmware running on NLighten’s Secure Concentrator's SMCU is licensed under the GPLv3 open-source license. Its code repository is kept public and maintained by the Community. The firmware itself has a bootloader that checks the cryptographic signature of the application image at each power up to ensure it is unaltered from its original form. The key used to sign the application image is called the `App Signing Key`. The firmware actually has two App Signing Keys slots. One of the key slots must be populated with Helium Foundation's App Signing Key. The other key slot can optionally be populated with a Manufacturer's App Signing Key. Helium Foundation will use its App Signing Key to sign firmware from the official open-source repository. Manufacturers can optionally fork the open-source repository and create changes specific to their hardware variants. Manufacturer's must comply with the reciprocal nature of the GPLv3 license. + +The intention of the "two-slot" scheme is to always allow any Secure Concentrator produced by any Manufacturer to be updated with the official open-source firmware. In the case a Manufacturer goes out of business or otherwise unable to provide support for their hardware, owners of Secure Concentrators can always choose to run the open-source firmware. ## Drawbacks ## Rationale and Alternatives The proposed architecture of SCC is the best possible design because it cleanly and securely -decouples low-level RF packet data from high-level Helium network protocol and constructs. This -decoupling is important because we expect the Helium network protocol to continue to grow and evolve -in the future and it would be prohibitively difficult to maintain SMCU firmware to keep up. This -architecture also enables potential new class of Helium nodes that can provide additional future -functionality. For example, a SCC could be used in a PoC Mapper device to securely verify coverage -in remote locations. Perhaps most importantly, this architecture can be used to upgrade existing -Helium miners providing reliable data to PoC algorithms. +decouples low-level RF packet data from high-level Helium network protocol and constructs. This decoupling is important because we expect the Helium network protocol to continue to grow and evolve in the future and it would be prohibitively difficult to maintain SMCU firmware to keep up. This architecture also enables potential new class of Helium nodes that can provide additional future functionality. For example, a SCC could be used in a PoC Mapper device to securely verify coverage in remote locations. Perhaps most importantly, this architecture can be used to upgrade existing Helium miners providing reliable data to PoC algorithms. ## Unresolved Questions ## Deployment Impact -Changes to the blockchain code will need to be made and tested on the `testnet`. When ready, these -changes can be merged to `mainnet` but should have no impact on existing nodes. These changes are -backwards compatible. Upgrading an existing miner with new SCC should not require any action on the -Hotspot owner's part. +Changes to the blockchain code will need to be made and tested on the `testnet`. When ready, these changes can be merged to `mainnet` but should have no impact on existing nodes. These changes are backwards compatible. Upgrading an existing miner with new SCC should not require any action on the Hotspot owner's part. ## Success Metrics -SCC success can be measured several ways. One metric will be the number of DIY Hotspots and Secure -mapper devices built with SCC. Another metric is the amount of low-power sensors that utilize the -TDoA location services SCC provide. Also the amount of DCs associated with those sensors. Finally, -Secure Concentrators will enjoy in the success of any future PoC algorithm that utilizes its data. +SCC success can be measured several ways. One metric will be the number of DIY Hotspots and Secure mapper devices built with SCC. Another metric is the amount of low-power sensors that utilize the TDoA location services SCC provide. Also the amount of DCs associated with those sensors. Finally, Secure Concentrators will enjoy in the success of any future PoC algorithm that utilizes its data. + diff --git a/0077-solana-parameters.md b/0077-solana-parameters.md index 1cd9589fb..072ae9f1e 100644 --- a/0077-solana-parameters.md +++ b/0077-solana-parameters.md @@ -90,7 +90,7 @@ The Treasury Circuit Breakers protect the subDAO treasuries. The subDAO treasuri ### Emission Schedules -The emission schedules until 2025 are codified [in the helium program library repository](https://github.com/helium/helium-program-library/tree/master/packages/helium-cli/emissions). These emission values +The emission schedules until 2025 are codified [in the helium program library repository](https://github.com/helium/helium-program-library/tree/master/packages/helium-admin-cli/emissions). These emission values will need to be adjusted as more rewardable entities, like mappers, are added. The values present in these json files represent the amount that will be emitted per epoch given the current set of rewardable entities. The full token emissions schedule as of Solana Migration can be downloaded diff --git a/0078-mobile-subdao-onboarding-fees.md b/0078-mobile-subdao-onboarding-fees.md index 3a1cfa370..e3884bd45 100644 --- a/0078-mobile-subdao-onboarding-fees.md +++ b/0078-mobile-subdao-onboarding-fees.md @@ -5,7 +5,6 @@ - Category: Economic, Technical - Original HIP PR: #580 - Tracking Issue: #582 -- Status: Closed # Summary diff --git a/0079-mobile-poc-mappers-rewards.md b/0079-mobile-poc-mappers-rewards.md index c8cc50585..931bd109c 100644 --- a/0079-mobile-poc-mappers-rewards.md +++ b/0079-mobile-poc-mappers-rewards.md @@ -92,24 +92,24 @@ Given the above, this HIP proposes the following framework for Discovery Mapping Use [this spreadsheet](https://docs.google.com/spreadsheets/d/1nDYbj4APWg_XEeGEsLdR17CW8q2EiuEqoLKs_I6T1Dc/edit#gid=1971124829) to experiment with values. -| Item | MOBILE Tokens | -| :-------------------------------------------- | ------------: | -| Total Tokens Minted Monthly | 5,000,000,000 | -| Total Tokens Minted in 24 Hours | 166,666,667 | -| Total Token Pool for Mappers (20%) | 33,333,333 | -| Fixed 24 hour reward for discovery mapping | 30 | -| Average 24 hour reward for Mapper\* | 168 | -| Active Discovery Mappers (Subscribers/Phones) | 10,000 | -| Active Verification Mappers | 2,000 | -| Total Points Earned by All Mappers | 636,000 | -| Mobile Earned per Discovery Mapper | **1,572** | -| Mobile Earned per Verification Mapper | **8,805** | +| Item | Rewards | +| :------------------------------------------------ | ------------: | +| Total MOBILE Tokens Minted Monthly | 5,000,000,000 | +| Total MOBILE Tokens Minted in 24 Hours | 164,383,561 | +| Total MOBILE Token Pool for Mappers (20%) | 32,876,712 | +| Fixed 24 hour Reward Points for Discovery Mapping | 30 | +| Average 24 hour Reward Points for Mapper\* | 168 | +| Active Discovery Mappers (Subscribers/Phones) | 10,000 | +| Active Verification Mappers | 2,000 | +| Total Reward Points Earned by All Mappers | 636,000 | +| MOBILE Earned per Discovery Mapper | **1,572** | +| MOBILE Earned per Verification Mapper | **8,805** | \*Assume it mapped 2 semi-charged hexes ### Adjusting Hotspot Rewards Based on Mapper Input -The Mobile PoC Working Group has discussed and documented a potential path to adjust MOBILE Hotspot rewards using the data collected by Mappers that would utilize the concept of the confidence score. A detailed description of the current thinking and community comments are available [here](TODO: find a link). +The Mobile PoC Working Group has discussed and documented a potential path to adjust MOBILE Hotspot rewards using the data collected by Mappers that would utilize the concept of the confidence score. A detailed description of the current thinking and community comments are available [here](./0079-mobile-poc-mappers-rewards/adjusting_hotspot_rewards_based_on_mapper_input.pdf). The Mobile PoC Working Group has decided to postpone the final decision regarding the specific algorithm to the second stage of Mapper reward implementation. This approach would create Hotspot rewards adjustment algorithms based on the actual data from mapping activity vs. speculating regarding variables and weights. @@ -117,6 +117,18 @@ The Mobile PoC Working Group has decided to postpone the final decision regardin The Mobile PoC Working Group has also agreed to initiate work on a Mapper subDAO. The Mapper subDAO would enable Mappers to provide usable data across various networks - IoT, MOBILE, Wi-Fi, and others - and receive incentives for mapping macro operator coverage. After implementing a Mapper subDAO, Mobile subDAO will become one of the first “customers” of Mapper subDAO. +### Location Sharing Details + +#### Subscribers + +Subscribers will share detailed location information with their Service Providers, allowing them to define which hexes to boost. Service Providers voted to participate in Helium Mobile subDAO are required to keep exact subscriber mobile location data confidential. The specific confidentiality terms are subject to the service agreement between each particular service provider and the subscribers. + +Subscribers will share binary information about whether location sharing event has occurred and the timestamp of the event to the Mobile Oracle for reward eligibility determination. Service Providers will verify the information Subscribers share before it is sent to the Mobile Oracle to prevent gaming. + +#### Mappers + +Mappers will share the location of res12 hex where the attach event occurred with the Mobile Oracle for reward eligibility determination and use by other services like Modeled Coverage Planner. + ## Drawbacks There are no obvious drawbacks. diff --git a/0079-mobile-poc-mappers-rewards/adjusting_hotspot_rewards_based_on_mapper_input.pdf b/0079-mobile-poc-mappers-rewards/adjusting_hotspot_rewards_based_on_mapper_input.pdf new file mode 100644 index 000000000..3e55a7e6d Binary files /dev/null and b/0079-mobile-poc-mappers-rewards/adjusting_hotspot_rewards_based_on_mapper_input.pdf differ diff --git a/0082-helium-mobile-service-provider.md b/0082-helium-mobile-service-provider.md new file mode 100644 index 000000000..b5b3ee85c --- /dev/null +++ b/0082-helium-mobile-service-provider.md @@ -0,0 +1,106 @@ +# HIP 82: Add Helium Mobile as a Service Provider to the Helium Mobile subDAO + +- Author(s): [@zer0tweets](https://github.com/zer0tweets), [@meowshka](https://github.com/meowshka) (Nova Labs, Inc.), [@Max Gold](https://github.com/Maxgold91), [@KeithRettig](https://github.com/Rettig) +- Start Date: 2023-03-15 +- Category: Economic, Technical +- Original HIP PR: #581 +- Tracking Issue: #628 +- Voting Requirements: veMOBILE Holders + +## Summary + +This HIP proposes to introduce Helium Mobile as a Service Provider (as defined in [HIP53](https://github.com/helium/HIP/blob/main/0053-mobile-dao.md#economics-overview)) on the Mobile Network. The main goal is to bring usage to the Network and pave the way for other Service Providers to join. The HIP describes integration with the Helium Mobile Network, an anti-gaming mechanism, and overall impact on the Network. + +## Motivation + +The Community has gone a long way in building the Helium Mobile Network. Now is the perfect time to bring usage and utility to it. + +As a Service Provider member of the Helium Mobile subDAO, Helium Mobile will actively offload its subscriber traffic onto the Helium Mobile Network. The launch of the Helium Mobile carrier will help pave the way for other Service Providers coming to the Helium Mobile Network by ironing out any undiscovered issues and creating a smooth onboarding process. In addition, the increased traffic on the network as a result of the launch will have a commensurate increase in HNT burn and data rewards for Hotspot operators. + +## Stakeholders + +This HIP affects: + +- Subscribers interested in using a crypto-carrier for cellular services - will benefit by having inexpensive, private cellular Service and being enabled to get rewards for improving the Network. +- Mobile carrier partners of Helium Mobile - will have an economic opportunity to increase revenue by sharing their mobile infrastructure. +- Owners of Hotspots with active Radios - will be rewarded for providing data access to Subscribers. +- Helium Mobile - will have an opportunity to provide cellular Service to Subscribers and earn rewards. +- Holders of HNT and MOBILE tokens - we anticipate an increase in utility of both HNT and MOBILE. + +## Detailed Explanation + +The staking amount, rewards, and responsibilities of Helium Mobile as a Service Provider will follow those outlined in [HIP53](https://github.com/helium/HIP/blob/main/0053-mobile-dao.md). + +### Onboarding to the Helium Mobile Network + +In compliance with HIP53 staking requirements for Service Providers, Helium Mobile will stake 500M MOBILE for the right to operate as a Service Provider on the Helium Mobile Network. + +Once the required amount is staked, the Helium Mobile Service Provider will be minted as an NFT by the ‘Helium entity manager’ smart contract on the Solana blockchain and will become a rewardable entity. + +This stake will need to remain locked and will not earn any staking rewards, as long as the Service Provider remains as part of the MOBILE subDAO. In lieu of staking rewards, the Service Provider has the right to claim up to 10% of MOBILE rewards (provided [HIP79](https://github.com/helium/HIP/blob/main/0079-mobile-poc-mappers-rewards.md) passes) in the Service Provider bucket. + +This HIP requires a cooldown period of 90-days after a public announcement by the Service Provider of its intention to cease data offloading on Helium's mobile network before it can stop such data offloading. An additional 90-day cooldown period will be required before the Service Provider can claim the tokens they staked for the right to operate as a Service Provider on Helium's mobile network. + +### Data Offloading to the Helium Mobile Network + +Helium Mobile will operate as a roaming partner on Helium's mobile network using Data Credits (DC) to pay for data transfer at a minimum price of $0.50 per 1 GB as specified in HIP53. Any changes to the minimum price for data transfer anywhere on Helium's mobile network must be approved by MOBILE subDAO vote. More specific regional or individual radio pricing options above the minimum price can be set by Helium Mobile but are subject to approval by MOBILE subDAO vote. + +Where Helium Mobile Network coverage is unavailable, Helium Mobile will rely on the additional coverage provided by their current Mobile Network Operator (MNO), T-Mobile. The partnership of Nova Labs with their MNO allows Helium Mobile subscribers to access both nationwide 5G coverage by the MNO and the growing Helium Mobile Network, which, due to its people-driven nature, is available in places that are hard to reach and acquire by traditional service providers. + +More details about Nova Labs and T-Mobile partnership can be found in the [press release](https://www.webwire.com/ViewPressRel.asp?aId=294475). + +### Governance + +HIP53 specifies two conditions which a Service Provider needs to meet to be allowed to operate on the Mobile Network: + +- Stake a minimum of 500M MOBILE, +- Obtain MOBILE subDAO governance approval. + +Once voted in as a Service Provider, the operation of Helium Mobile on the Mobile Network should be governed with subsequent HIPs, until a new process of governance is created. + +### Data Reward Limits for Hotspot Owners and Gaming Prevention for Unlimited Plans + +Helium Mobile specifically plans to launch an Unlimited Plan offering to the market as part of its line-up and is faced with solving a potential gaming problem. Helium Mobile rewards Hotspots for data on a per GB basis. This creates a potential gaming loophole whereby a person can purchase an unlimited plan for a fixed price and then stream movies and shows from a streaming service 24/7 through their own hotspots to rake up massive rewards. + +We propose a basic anti-gaming mechanism for unlimited plans that is Helium Mobile-specific. This means that other carriers planning to join the Helium Mobile Network can propose their own algorithms or none. + +For Helium Mobile unlimited plans we propose to set the limit on rewardable data that each Subscriber can send to the Helium MOBILE subDAO during the 30-day billing cycle. We propose that this limit is expressed in terms of gigabytes and equal to $COST_of_Subscription / $0.50 (price per GB set by MOBILE subDAO). For instance, if a subscriber purchases a Helium Mobile unlimited subscription for $20, the maximum number of rewardable gigabytes to be sent to the Helium network is $20/$0.50 = 40. 40 Gb will be the rewardable limit to the network for this subscriber. As such, the total value of MOBILE rewards received by all hotspots for servicing any unique unlimited plan cannot exceed the price for which the plan was purchased; thus decreasing the incentive to game. + +The rewardable limit will reset at the start of a new 30-day billing cycle for each Subscriber with an unlimited data plan. The data traffic cap is not limited to a particular Hotspot. It is applicable to all Hotspots that provide data for a specific Subscriber. + +It’s important to note that Helium Mobile offers an unlimited plan without data caps for Subscribers. This means that the data offloading will still continue after the maximal rewardable limit is reached, however Hotspot Owners won’t earn MOBILE rewards for providing data traffic to such Subscribers. Additionally, DCs won’t be burned from the Helium Mobile Carrier account for the data traffic routing after the data caps are reached for Subscribers. + +Additionally, we propose a 6 calendar month grace period to allow for unrewarded traffic over rewardable limit on the Hotspots. Nova Labs will implement an option to opt-in for unrewarded data traffic in a Cloud Dashboard or similar tool no later than the expiration of the grace period. 6 month countdown will start on the day this HIP is approved. The default setting will be for radios to opt-out of allowing unrewarded traffic; it will require operators to manually opt-in before unrewarded traffic can be transferred on their radios. + +If Nova Labs fails to implement the opt-in feature past the expiration of the grace period, the reward cap is to be completely removed on the day of the expiration of the grace period and will remain so until Nova Labs has implemented the opt-in feature. + +Helium Mobile shall provide a subscriber usage report to the MOBILE subDAO on a minimum of a yearly basis, on the 1st of August, if not on a continual basis, such as a dashboard. The report will present information about how much data traffic has been transferred; indicating the amount of rewarded traffic and unrewarded traffic by subscriber plan. + +Approval of this approach is necessary for Helium Mobile to start offloading data to the Helium Mobile Network. + +## Implementation + +We leave the implementation of the smart contract components, verifiability, and Service Provider compliance up to the Helium Core Developers to determine. +We note that staking MOBILE to become a Service Provider locks up MOBILE independently of veMOBILE, meaning that a Service Provider does not get governance rights in addition to Service Provider rights. + +## Drawbacks + +The only drawback of this proposal is related to the anti-gaming mechanism. In rare cases a Hotspot Owner might not get rewarded for the data traffic they provide if the Subscriber of the unlimited plan uses all the rewardable data per a 30-day billing cycle. + +## Unresolved Questions + +Staking mechanics for Service Providers on the Solana blockchain. + +## Dependencies + +Nova Labs has done most of the work necessary to launch the Helium Mobile carrier on the data offloading, customer tooling and support flows side. Launch of staking, Hotspot rewards, and other blockchain related functionality is dependent on the Solana migration and the successful implementation of these features by Helium Core Developers. + +## Deployment Impact + +- Hotspot owners will start earning MOBILE rewards for the data transfer work. +- Service Providers will be able to offload data traffic to the Helium Mobile Network and receive Service Provider rewards. +- Subscribers to Helium Mobile will be able to opt-in to earn MOBILE rewards for discovery mapping activity (provided [HIP79](https://github.com/helium/HIP/blob/main/0079-mobile-poc-mappers-rewards.md) passes). + +## Success Metrics + +The main success metric would be cellular data being offloaded to the Helium Mobile Network by the Helium Mobile Service Provider, creating increased utility for HNT and MOBILE. diff --git a/0083-restore-first-to-witness.md b/0083-restore-first-to-witness.md new file mode 100644 index 000000000..d43e169f0 --- /dev/null +++ b/0083-restore-first-to-witness.md @@ -0,0 +1,86 @@ +# HIP 83: Restore First to Respond Witness Rewarding + +- Author(s): [@BFGNeil](https://github.com/BFGNeil), [@mawdegroot](https://github.com/mawdegroot) +- Start Date: 2023-05-05 +- Category: Economic, Technical +- Original HIP PR: [#605](https://github.com/helium/HIP/pull/605) +- Tracking Issue: [#632](https://github.com/helium/HIP/issues/632) +- Voting Requirements: veIOT Holders + +## Summary + +Currently, the Proof-of-Coverage Oracles collect all the witnesses for a beacon and randomly reward a selection of 14 witnesses. This HIP proposes to revert to rewarding the first 14 Hotspots responding to a beacon, incentivizing the most useful Hotspots to sensor traffic by prioritizing the low latency connections that sensors need for uplinks, downlinks, and join requests to work correctly. + +## Motivation + +Rewarding witnesses that are the first to respond will incentivize Hotspots to provide the low-latency connection that the sensors desperately need. + +Sensors use uplinks to transfer their data over the Helium network. For a sensor to join the Helium network, it must perform a handshake that requires both an uplink and a downlink. As a power-saving measure, a sensor often has a limited time window to listen for the downlink. + +Because the sensor only listens for the downlink for a limited time, the Helium LNS and the Hotspots must minimize latency to ensure the Hotspot can deliver downlinks to sensors within the narrow sensor listening window. + +The Helium network originally rewarded the fastest witnesses and moved to a random selection for several technical reasons that no longer apply to the Oracle-based POC architecture introduced as part of HIP 70. + +Technical limitations included, but are not limited to: + +- Regular retransmissions on the libp2p network left Hotspot unable to deliver witness reports. +- Hotspots struggled to sync the Helium blockchain before Validators and needed more time to + determine which challenger to deliver a witness to. + +## Stakeholders + +Both Hotspot Operators and network users will be affected by this change as it will incentivize Hotspot deployments that are more beneficial to network users. + +## Detailed Explanation + +When a Hotspot transmits a beacon, it first fetches entropy from the Entropy Oracle to create the beacon data and construct the beacon. + +The Hotspot broadcasts the constructed beacon and transmits a beacon report to the Ingest Oracle, which then attaches the current time in the `receivedTimestamp` field of the beacon report. + +When a Hotspot witnesses a beacon, it signs the witness report and sends it to the Ingest Oracle, which attaches the current time in the `receivedTimestamp` field of the witness report. + +The Verifier will invalidate witness reports with a `receivedTimestamp` value outside the entropy validity window (currently 3 minutes). + +The Verifier Oracle will fetch a beacon report from the Ingester Oracle output together with all the corresponding witnesses of that beacon. + +Currently, the Verifier Oracle will shuffle the witnesses and randomly selects 14 witnesses to reward for their work. **This HIP proposes ordering the witnesses by the `receivedTimestamp` field and selecting the 14 Hotspots with the lowest `receivedTimestamp` values instead.** + +_NB: The amount of witnesses that is selected per beacon is currently set to 14, but can be reconfigured in the [oracles](https://github.com/helium/oracles/blob/1.1.0/iot_verifier/src/settings.rs#L39)_ + +## Drawbacks + +There are several potential drawbacks to rewarding the fastest Hotspots to respond: + +- Some network connections inherently have lower latency than others (e.g., fiber has lower latency than 4G). +- Though the vast majority of Hotspots use the same method to secure Hotspot identity, several other security methods are in use which may be faster or slower than the majority use case. Though given the minority position, this drawback should be limited. +- Approximately 600 DIY-Hotspots are using file-based keys and thus can sign witness reports faster than those with an ECC-based key. + +## Rationale and Alternatives + +Sensors require Hotspots to have a low latency connection to the Helium LNS for confirming uplinks, downlinks, and join requests to work correctly. If the latency is too high, the Hotspot will not be in time to transmit the downlink to the sensor, which may be sleeping and unable to receive the downlink. The rationale behind this HIP is that it incentivizes Hotspot owners to create a low latency setup and thereby reward those Hotspots that are most useful for sensors. + +The most viable of the several considered alternatives is limiting the entropy validity window, with witness reports received outside the window automatically invalidated by the Verifier Oracle. This approach has a similar but dampened effect and will not affect witness stuffing, contrary to rewarding the first to respond. + +The most crucial reason for proposing rewarding the first witnesses to respond above this alternative is to make witness stuffing much harder. Witness stuffing introduces delays, meaning the witness is less likely to arrive among the first 14 witnesses. + +## Unresolved Questions + +- Which hotspots are faster than others, and which hotspots are slower. + +With the help of [HeliumGeek](https://heliumgeek.com/) a tool has been created to visualize what the proposed change means for individual hotspots. + +[HeliumGeek HIP 83 tool](https://heliumgeek.com/maps/hip83.html). + +"_The data displayed here represents a 7-day period and is updated once or twice a day. Please note that the presented Reward Units reflect the rewards earned specifically from witnessing activities. It's important to remember that hotspots are also rewarded for beaconing. Therefore, if the [Reward Units](https://heliumgeek.com/faq/what-is-a-reward-unit.html) shown here increase, it does not necessarily mean that the actual IOT rewards will increase by the same amount._" + +## Deployment Impact + +The deployment of this proposal is minimal as it is a relatively simple change to the Verifier Oracle with the added benefit of being easily reverted by rolling back Verifier Oracle code changes. This deployment is supported by staged code and can be viewed [here](https://github.com/helium/oracles/compare/main...mawdegroot:oracles:mg/first-to-respond-witnessing). + +## Success Metrics + +Successful deployment means that: + +- Hotspots too slow to serve sensors will receive fewer rewards. +- Legitimate Hotspots receive more rewards in areas where witness stuffing is active. +- Hotspots handling data traffic receive more rewards than those that are consistently too slow. diff --git a/0084-service-provider-hex-boosting.md b/0084-service-provider-hex-boosting.md new file mode 100644 index 000000000..2b3d270dd --- /dev/null +++ b/0084-service-provider-hex-boosting.md @@ -0,0 +1,75 @@ +# HIP 84: Service Provider Hex Boosting + +- Author(s): Mobile PoC Working Group +- Start Date: 2023-04-26 +- Category: Economic, Technical +- Original HIP PR: #625 +- Tracking Issue: #638 +- Vote Requirements: veMOBILE Holders + +## Summary + +This HIP proposes a framework for Service Providers to influence the growth of the Network in the location where the data offload is most likely to happen. + +## Motivation + +Currently, there is little guidance around the placement of Radios for Mobile Hotspot Owners. The provided information mainly focuses on the installation rather than on geographical optimization. The lack of direction in the growth of the Mobile Network is not optimal for building useful coverage. + +## Stakeholders + +This HIP affects only participants of the MOBILE SubDAO: + +- Service Providers, +- Mobile Hotspot Owners with Radios, +- Subscribers of the Mobile Network. + +**More specifically, this HIP will affect these Stakeholders in the following ways:** + +Service Providers: with this proposal will be able to incentivize the building of new coverage in locations where prospective users of the MOBILE Network exist. This will allow the acquisition of new customers and, as a result, increase usage on the MOBILE Network. + +Mobile Hotspot Owners: Mobile Hotspot Owners will get the ability to earn extra MOBILE rewards by providing coverage with 5G Radios in the boosted hexes. Those with functional equipment in a boosted hex will automatically receive additional MOBILE rewards. Such owners will see an automatic increase in earnings if the hex they are in (identified by GPS location and/or Spectrum Access Service SAS)) is boosted, provided they are eligible to receive rewards based on other Proof-of-Coverage (PoC) requirements. 5G Hotspot owners planning to deploy in boosted hexes will need to ensure they can meet all PoC requirements in the same way as in non-boosted hexes to receive Service Provider boosted rewards. +Mobile Hotspot owners in non-boosted hexes might see a decrease in MOBILE rewards. The decrease will depend on the number of hexes boosted, boost multipliers, duration of the boost, and the number of Radios deployed in boosted hexes. + +Network Subscribers: More coverage will be available to new and existing users of the MOBILE Network as 5G Radios are deployed in nascent hexes boosted by Service Providers. This will make the Network more appealing and reliable, especially for those in the areas that are not adequately covered by other players on the market. + +## Detailed Explanation + +### General Concepts + +- Any Service Provider in the MOBILE subDAO can boost hexes to increase PoC rewards for certain hexes. +- Boost is temporary, and to keep hexes boosted, a Service Provider must continuously burn some amount of MOBILE into the hex. +- Multiple Service Providers can burn MOBILE into the same hex for cumulative effect. +- We stick with res12 hex resolution for boosting to stay consistent with HIP74. +- Since the price of MOBILE fluctuates, the cost of unlocking and/or boosting a hex should remain stable and be defined in dollar stable terms based on price oracle data. + +### Mechanics and Price of Boosting Hexes + +- The minimum boost time commitment is six months, so there is a reasonable reward for people to invest in creating coverage at a given location. Service Providers can extend boost in 1-month increments, following 6-month expiration by burning additional MOBILE into the hexes. +- Once a Service Provider burns MOBILE into a hex, it remains “boosted” indefinitely until some coverage is created in the hex location. +- Creation of coverage will be considered to have been confirmed when at least three unique phones with discovery mapping enabled have successfully connected and passed at least 1MB of data at the location of coverage (as evidenced by the Mobile Oracle). +- We propose the price for boosting one res12 hex for one month by 1x be initially set at $.005. This would roughly mean that boosting an area covered by a 436h (assuming it covers 500 res12 hexes) for six months to a 10x multiplier would cost $150. +**- The above number is able to be adjusted by the subDAO community vote down the line.** + +## Drawbacks + +The downside of this HIP is that Mobile Hotspots in non-boosted hexes might see a decrease in MOBILE rewards. The decrease will depend on the number of hexes boosted, boost multipliers, duration of the boost, and the number of Radios deployed in boosted hexes. + +## Rationale and Alternatives + +The alternative approach is to let the Network grow without factoring in demand for the coverage. The downside of this approach is that Network growth won’t follow the Subscribers’ demand and, therefore, will have less utility. New Service Providers might be reluctant to join the Helium Mobile Network without the ability to influence the Network development. + +## Unresolved Questions + +This HIP doesn’t address the problem of preventing installations in hexes that are not expected to have any data offloading, like over water or in the desert. There’s an ongoing discussion within the Mobile PoC working group on how to tackle that. Once sufficiently defined, the approach will be added to this HIP. + +## Deployment Impact + +Deployment of this HIP will allow Service Providers to boost hexes and therefore change the growth trajectory of the Mobile Network. +Owners of Mobile Hotspots that meet all PoC requirements will receive increased MOBILE rewards when they deploy in boosted hexes, while those located in non-boosted hexes might see a decrease in earnings. +Implementation of this HIP will require updates to the Mobile Coverage Planner to allow deployers to quickly locate boosted hexes with details about boost multiplier, duration, etc. Estimated reward points should reflect boosting. +Additionally, a UI tool should be implemented for Service Provider to manage hex boosting. +Note, the Community can propose and vote to revert this HIP, but requires honoring the boosted period for which Service Providers have burned the MOBILE. + +## Success Metrics + +The usefulness of Mobile coverage is the primary success metric for this HIP. This can be measured by the amount of data being offloaded to the Network per user compared to previous periods. diff --git a/0085-mobile-hex-coverage-limit.md b/0085-mobile-hex-coverage-limit.md new file mode 100644 index 000000000..8e2d7ac70 --- /dev/null +++ b/0085-mobile-hex-coverage-limit.md @@ -0,0 +1,106 @@ +# HIP 85: MOBILE Hex Coverage Limit + +- Author: [Andy Zyvoloski](https://github.com/heatedlime) +- Start Date: 5/12/2023 +- Category: Technical & Economic +- Original HIP PR: #654 +- Tracking Issue: #673 +- Voting Requirements: veMOBILE + +## Summary: +This Helium Improvement Proposal (HIP) suggests adding a baseline hex multiplier score to the MOBILE Proof-of-Coverage (PoC) Modeled Coverage Points based on whether other coverage from Helium 5G deployments exists within that res12 hex. This HIP only applies to outdoor radios, and no changes to the reward structure of indoor mobile radios are being made with this HIP. + +## Motivation: +The Helium Community passed HIP 74 to incorporate obstruction data and radio signal power into the PoC reward model; however, it weighed all coverage within each res12 hex equally, even if multiple radios already provided coverage within that res12 hex. This means deployers could point five (5) outdoor radios in the same direction and still be awarded total Modeled Coverage points for each res12 hex. This results in the dilution of MOBILE and reduced MOBILE rewards to deployments that are strategically placed to minimize overlap in coverage. + +This proposal aims to improve the value of Mobile network coverage by incentivizing users to deploy radios that minimize overlapping coverage and encourage deployments in new areas. + +## Stakeholders: +All Mobile Radio Deployers / Mobile Hotspot Owners. + +## Detailed Explanation: +Currently, any redundant and overlapping network coverage is still rewarded the same as non-overlapping coverage under HIP 74. This discourages the buildout of coverage to new areas. To prevent overcrowding and overlapping of coverage in hexes, this HIP proposes to limit the amount of modeled coverage points radios receive for redundant coverage in res12 hexes. + +To ensure that only the best setups are rewarded, only the top three (3) ranked radio signals in each res12 hex will be awarded modeled coverage points, with a decaying multiplier based on the radio rank noted below. Any radios not ranked within the top three (3) will be ranked as “Fail”, and receive no modeled coverage points for that res12 hex. + +| Rank |Multiplier| +|--------------|----------| +| 1 | 1X | +| 2 | .75X | +| 3 | .25X | +| Fail | 0X | + +Please note that the multiplier table above only affects the modeled coverage points that are given to each outdoor radio and does not affect rewards distributed for the transfer of data or PoC rewards for indoor radios. + +### Radio Ranking & Criteria + +All outdoor radios that provide coverage to any res12 hex will be given a rank for each res12 hex they provide coverage in based on the following potential attributes (note, this rank is only for a single res12 hex and not the entire radio): + +- Modeled Signal Strength + +- Heartbeat Steak - The Heartbeat Streak is the time that has elapsed since the first heartbeat of that radio at its current location, in which has had at least one (1) heartbeat every 72 hours. If a radio does not produce at least one (1) heartbeat over 72 consecutive hours, the streak is reset. This attribute is only used as a tiebreaker when two or more radios tie for Modeled Signal Strength. If somehow, two or more radios tie both Modeled Signal Strength and Heartbeat Streak, the radio to be ranked will be randomly selected every epoch. + +### Modeling Radio Ranking + +See the example below of how ranking based on a hex multiplier would affect deployment of five (5) outdoor radios if they are providing modeled coverage to the same res12 hex: + +| Radio |Signal Strength| Heartbeat Streak Start Date | Rank | Coverage Points Per HIP 74| New Coverage Points| +|-------|---------------|-----------------------------|-------|---------------------------|--------------------| +| A | -77.33 dBm |05/01/2023 23:24:25 | 1 | 16 (16 * 1) | 16 (16 * 1) | +| B | -88.75 dBm |12/01/2022 01:01:01 | 2 | 16 (16 * 1) | 12 (16 * .75) | +| C | -88.75 dBm |12/02/2022 12:11:01 | 3 | 16 (16 * 1) | 4 (16 * .25) | +| D | -93.60 dBm |12/05/2022 11:51:01 | Fail | 16 (16 * 1) | 0 (16 * 0) | +| E | -94.69 dBm |08/01/2022 05:01:59 | Fail | 16 (16 * 1) | 0 (16 * 0) | + +**Table Key:** +- **Radio:** Example radio name. +- **Signal Strength:** The Signal Strength of the res12 hex from the modeled coverage explorer. +- **Heartbeat:** The date/time that the Heartbeat Streak started. +- **Rank:** The assigned rank based on which radio has the strongest Signal Strength (or Heartbeat Streak if tied for Signal Strength). +- **Coverage Points Per HIP 74:** The amount of modeled coverage points currently awarded under HIP 74. +- **New Coverage Points:** The amount of modeled coverage points that would be awarded under this HIP. + +**Table Explanation:** + +Since Radio A has the highest signal strength in that hex, it will be ranked as "1", and granted a 1X multiplier to the modeled coverage score of 16, which will award it with the full 16 (16 x 1) modeled coverage points for that epoch. + +Since radios B and C tied in Signal Strength, the Heartbeat Streak date is used to determine which radio is ranked next. For this example, radio B had its Heartbeat Streak start on 12/01/2022 01:01:01 while radio C had a its HeartBeat streak start on 12/02/2022 12:11:01. Therefore, since radio B has an earlier Heartbeat Streak, it will be ranked "2", while radio C having a rank of "3". + +Since radios D and E had the lowest signal strength out of all five (5) radios, and only the top three (3) radios will earn PoC rewards, radios D and E will not earn any modeled coverage points for this res12 hex, and are ranked as "Fail". + +As noted in the example above, outdoor radio deployers will now need to be cognizant of where they are placing their radios in order to maximize modeled coverage point. + +### Changes to Multipliers and Ranks +As the MOBILE network matures, these multiplier scores may need to be fine tuned or changed. Therefore, the multipliers and ranks presented in this HIP shall be implemented as chain variables. In order for these chain variables to be modified, or deleted, one of two things must happen: + +1. A new HIP is proposed modifying the multipliers and or ranks; or +2. A Governance or Working Group (herewithin reffered to as "the group") for the MOBILE Network must create a MOBILE PoC Change Proposal. The proposal will then be discussed by the group, in which a general consensus must be reached (consensus defined by the group). Once consensus is reached, the proposal will be put to a vote by the community, with the voting requirement being veMOBILE. + +The proposal must be announced within the Official Helium Community Discord Server under the “Governance-Announcement” channel (or similar channel if the “Governance-Announcement” channel is removed), at least five (5) calendar days prior to the start of voting. Voting shall remain open for seven (7) calendar days. A 66.67% vote in favor of the change(s) must be reached in order for the vote to pass. + +A new vote with the same or modified change(s) to that multiplier and or rank may be put to vote by the community again with the groups consensus no earlier than 60 calendar days after the last voting has ended. + +## Drawbacks: +Implementing this proposal could increase the complexity of modeled coverage scores due to adding additional variables used to calculate total MOBILE rewards. + +Additionally, radio deployers may lose out on awarded coverage points in instances where multiple radios are set up in the same hex. + +## Rationale and Alternatives: +An alternative would be allowing radios and hexes to keep earning the defined amount of modeled coverage points as described in HIP 74. + +However, this may prevent or stagnate the network's growth because HIP 74 does not incentivize deployment of Hotspots to minimize overlapping coverage. + +## Unresolved Question: +None + +## Deployment Impact: +HIP 85 affects only Outdoor radios, and coverage from indoor radios will continue to earn Modeled Coverage Points based on HIP 74. New fields will need to be added into the Modeled Coverage Explorer to make Radio Hex Ranks and Heartbeat Streaks visible. + +Further, a large amount of overlapping coverage exists within the MOBILE network. Deployers may have to find new locations for some or all of their radios in order for them to continue to earn modeled coverage points. + +This HIP leaves the implementation open to interpretation by Helium Core Developers who will implement this change on behalf of the community. + +## Success Metrics: +This HIP is successful if: +1. There is more broad coverage extended to new locations on the modeled coverage map +2. and less redundant coverage in areas of saturation diff --git a/0086-increase-iot-data-transfer-cost.md b/0086-increase-iot-data-transfer-cost.md new file mode 100644 index 000000000..87ee6b2b0 --- /dev/null +++ b/0086-increase-iot-data-transfer-cost.md @@ -0,0 +1,37 @@ +# HIP 86: Increase IOT Data Transfer Cost +- Author(s): [@KeithRettig](https://github.com/KeithRettig) +- Start Date: 2023-05-28 +- Category: Economic +- Original HIP PR: [#698](https://github.com/helium/HIP/pull/698) +- Tracking Issue: [#703](https://github.com/helium/HIP/issues/703) +- Voting Requirements: veIOT Holders + +## Summary +This HIP proposes to change the per packet cost of transferring messages on the Helium IOT Network from 1 data credit (DC) per 24-byte packet to 2 data credits (DC) per 24-byte packet to better align the price with its value to our customers. + +## Motivation +The primary motivation is to align the cost of packet transfer closer to the true value of packet transfer within the IOT subDAO. While it is believed by the author that the true value of packet transfer is closer to 100 DC, it would be economically unfeasible to implement a 100-fold increase in the price in one action. + +## Stakeholders +Any and all customers (e.g., sensor owners), hosts, and operators of the Helium IOT Network. + +## Detailed Explanation +The cost of packet transfer on the Helium IOT Network, is far too inexpensive. Our customers have publicly commented that the cost is too low. Due to the low cost of data transfer, a Hotspot must transfer a huge number of packets to earn meaningful revenue. The cost of packet transfer is so cheap, that this proposed change of doubling the cost is unlikely to change any behaviors of the users of the Helium IOT Network. + +Currently to transfer a 24 byte packet on the Helium IOT Network, a customer must spend 1 DC. This HIP proposes to make that cost be 2 DC per 24 byte packet. This HIP does not change any mechanism on how Hotspots are paid for data transfer; if the HIP passes, a Hotspot will now earn 2 DC for each message transferred. + +## Implementation +We leave the implementation of the smart contract components, verifiability, and compliance up to the Helium Core Developers to determine. It is understood that the cost function of packet transfer is implemented as a variable and thus it is believed this change should be very easy to implement in the IOT Packet Verifier. It would be ideal if the proposed increase could be appropriately scaled based on region, and thus allow for regional governance to define said increase. For instance, the community may decide to raise the price of data transfer in regions where backhaul costs are more expensive. Or they may allow a country to delay the price increase to help adoption of the service. However, since there are currently no known mechanisms for such regional policy actions, implementing such scaling will need to be left as a future feature. Therefore, regional pricing is out of scope of this HIP but is mentioned so that the developers will consider the possibilities as they code for this HIP (if there is any coding necessary). + +## Drawbacks +A potential drawback is that customers will view the doubling of cost as too aggressive and not transfer as many packets in the future. It is believed that at this time, and with the current price range, the usage of packet transfer is one of relatively inelastic demand. No change in purchasing nor usage behavior is expected. +Since Data Credits are distributed to wallets first, there will be a reduction in available tokens for Proof-of-Coverage rewards. With only a doubling of the cost at this point, it is unlikely to be a significant reduction. However, some thought should be given as to this when future increases in the cost are considered. + +## Unresolved Questions +There are no unresolved questions other than how our customers will respond to the price change. + +## Deployment Impact +There are no known dependencies by the author. As soon as the variable has been changed, customers would pay 2 DC to transfer data rather than 1 DC. + +## Success Metrics +There are two success metrics. First that the price is changed and, second, that the demand remains inelastic. Only the first is required for the HIP to be considered successful. diff --git a/0087-proportional-service-provider-rewards.md b/0087-proportional-service-provider-rewards.md new file mode 100644 index 000000000..90ba026aa --- /dev/null +++ b/0087-proportional-service-provider-rewards.md @@ -0,0 +1,67 @@ +# HIP 87: Proportional Service Provider Rewards +- Author(s): [@KeithRettig](https://github.com/KeithRettig), [@zer0tweets](https://github.com/zer0tweets), [@meowshka](https://github.com/meowshka) +- Start Date: 2023-05-15 +- Category: Economic, Technical +- Original HIP PR: [#699](https://github.com/helium/HIP/pull/699) +- Tracking Issue: [#704](https://github.com/helium/HIP/issues/704) +- Voting Requirements: veMOBILE Holders + +## Summary +This HIP proposes to make specific how Service Providers are eligible for rewards from the HIP53-specified Service Provider MOBILE Reward bucket. The proposal suggests a usage-based approach to calculate rewards for Service Providers based on the amount of Data Credits burned. Service Providers would be rewarded in MOBILE tokens at a 1:1 ratio for the burned Data Credits with proportional distribution if the total exceeds the reward bucket value. + +## Motivation +The primary motivation is clarify how Service Provider Rewards are calculated. There is also a motivation to prevent a scenario in which a Service Provider is rewarded the full MOBILE reward bucket while burning little to no Data Credits. The content of this HIP was originally written within HIP82. However, since the concept applies to all Service Providers in the Helium 5G Network and not to the specific Service Provider of HIP82, it is more appropriate to have this as its own HIP. + +## Stakeholders +Any and all Service Providers of the Helium MOBILE Network. There are currently none. + +## Detailed Explanation +HIP53 specifies an overall rewards bucket for Service Providers but does not go into specifics of how rewards should be calculated based on the amount of data being offloaded. To prevent a scenario in which a Service Provider is rewarded the full MOBILE reward bucket while burning little to no Data Credits (DC), we propose to follow a similar usage-based approach as outlined in HIP10 for the IoT Network. +We propose that Service Providers are rewarded up to 1:1 in MOBILE tokens for the amount of DC burned during a reward period, similar to the approach in HIP10. If the Service Providers collectively burn more DC than the equivalent amount of MOBILE tokens in the Service Provider reward bucket, each Service Provider will be rewarded proportionally to its share of DC burn. If the Service Providers collectively burn less DC than the equivalent amount of MOBILE tokens, the remainder of the Service Provider bucket will not be minted. + +To illustrate, here are two scenarios where the value of DC burned is **less than or exceeds** the rewards bucket: + +1. Value of DCs burned for data traffic **is less than** the Service Provider reward bucket (10% of MOBILE emissions): + +|Item|Rewards| +|:----------------------|---------:| +|DCs burned by SP|100,000,000| +|Price of DC|$0.00001| +|Price of MOBILE*|$0.0001| +|DCs burned in MOBILE**|10,000,000| +|10% SP bucket|500,000,000 MOBILE| +|SP rewards|10,000,000 MOBILE| + +2. Value of DCs burned for data traffic **exceeds** the Service Provider reward bucket (10% of MOBILE emissions): + +|Item|Rewards| +|:----------------------|---------:| +|DCs burned by SP|100,000,000,000| +|Price of DC|$0.00001| +|Price of MOBILE*|$0.0001| +|DCs burned in MOBILE**|10,000,000,000| +|10% SP bucket|500,000,000 MOBILE| +|SP rewards|500,000,000 MOBILE| + +\* The price chosen is an example, not the actual price. The actual price will be determined by the Price Oracle on the Solana blockchain during the rewards calculation time. +\** Amount of MOBILE tokens with the same value as the value of the DCs burned by SP: (10,000 DC * $0.00001 (fixed price of DC) / $0.0001 (example price of MOBILE)) + +While approval of this approach is not necessary for Helium Mobile to start offloading data to the Helium Mobile Network, it does modify a policy that is important for to Helium Mobile as it determines the amount of its expected rewards from the Service Provider MOBILE Reward bucket. + +## Implementation +We leave the implementation of the smart contract components, verifiability, and Service Provider compliance up to the Helium Core Developers to determine. + +## Drawbacks +As Helium 5G Network's first and only potential Service Provider suggested the idea, there are no perceived drawbacks; there are no other Service Providers to be affected by this HIP. + +## Unresolved Questions +The only unresolved issue is whether HIP79 goes to vote and is approved. While this HIP is not dependent on the outcome of HIP79, the size of the Service Provider Rewards bucket is directly influenced from the outcome. + +## Dependencies +Nova Labs has done most of the work necessary to launch the Helium Mobile carrier on the data offloading, customer tooling, and support flows side. Launch of staking, Hotspot rewards, and other blockchain related functionality is dependent on the successful implementation of these features by Helium Core Developers. + +## Deployment Impact +Service Providers will be able to offload data traffic to the Helium Mobile Network and receive Service Provider rewards. + +## Success Metrics +The main success metric would be Service Providers receiving their proportionate rewards from the MOBILE Reward bucket. diff --git a/0088-adjustment-of-dao-utility-a-score.md b/0088-adjustment-of-dao-utility-a-score.md new file mode 100644 index 000000000..1bf9d4713 --- /dev/null +++ b/0088-adjustment-of-dao-utility-a-score.md @@ -0,0 +1,68 @@ +# HIP 88: Adjustment of DAO Utility A Score +- Authors: [Gateholder](https://github.com/gateholder), [Andy Zyvoloski](https://github.com/heatedlime), [Groot](https://github.com/mawdegroot) +- Start Date: 6/15/2023 +- Category: Technical & Economic +- Original HIP PR: [#702](https://github.com/helium/HIP/pull/702) +- Tracking Issue: [#707](https://github.com/helium/HIP/issues/707) +- Voting Requirements: veHNT + +## Summary +This HIP proposes to make the $A$ factor of the subDAO utility score more granular by using the individual onboarding fee of an active device paid instead of relying on a homogeneous onboarding fee. This will allow subDAOs to change their onboarding fee without either negatively affecting their subDAO utility score. + +## Motivation +The current definition of the subDAO utility score as specified in HIP51 is shown below. The definition does not allow the changing of the onboarding fee without significantly affecting the $A$ factor of the score. The community has expressed the preference to change the onboarding fee; however, lowering the onboarding fee will significantly lower the subDAO utility score and thus subDAOs are disincentivized to do so. At the same time, increasing the onboarding fee will artificially inflate the subDAO utility score, an offense punishable by slashing as written in HIP51. This HIP proposes to change the $A$ score to align with the original intention of HIP51 while still allowing a subDAO to change their onboarding fee via their internal governance. + +$\text{DAO Utility Score} = V \times D \times A$ + +where + +$V = \text{max}(1, veHNT_{DNP})$ + +$D = \text{max}(1, \sqrt{\text{DNP DCs burned in USD}})$ + +$A = \text{max}(1, \sqrt[4]{\text{DNP Active Device Count} \times \text{DNP Device Activation Fee}})$ + +## Stakeholders + +This change will impact the entire ecosystem as it alters the interpretation of the HIP51 subDAO utility score that is directly responsible for the distribution of HNT between subDAOs. + +## Detailed Explanation +This HIP proposes to change the $A$ factor to only count the onboarding fees paid by each active device. The $A$ factor will _only_ take into account fees paid in DC. If a device has paid 40 USD but the current onboarding fee is 10 USD the device will still be counted as 40 USD Conversely a device that has paid 10 USD while the current onboarding fee is 40 USD will still be counted as 10 USD. This change will allow subDAOs to change their onboarding factor without affecting the $A$ factor of subDAO utility score that it had been awarded for previous onboarding fees. + +An active device is any rewardable entity that has been onboarded and has received rewards in the past 30 days. This definition of what an _active device_ entails allows any subDAO to use their own definition of _device_ without requiring Helium DAO oversight. The use of the actual onboarding fee that was paid for a device removes the ability to onboard devices for a low onboarding fee and later game the subDAO utility score by increasing the onboarding fee for new devices. + +The exact and explicit specification of the proposal is shown below. It is important to note that the remaining factors of the subDAO utility score, namely $V$ and $D$ remain unchanged. + +![0088-formulas](0088-adjustment-of-dao-utility-a-score/0088-formulas.png) + +### examples + +Example 1: subDAO A has 450k active devices of which 448k devices have paid $40 and 2k devices have paid $10 onboarding fees. + +$A_{\text{A}} = max\left(1, \sqrt[4]{\sum_{k \in \mathcal{K_\text{A}}}A_{\text{A}}(k)}\right) = max\left(1, \sqrt[4]{448 000 \cdot 40 + 2 000 \cdot 10}\right) = max\left(1, \sqrt[4]{17 940 000}\right) \approxeq 65.08$ + +Example 2: subDAO B has 4000 active devices of which 3800 have paid no onboarding fees and 200 have paid $10 onboarding fees. + +$A_{\text{B}} = max\left(1, \sqrt[4]{\sum_{k \in \mathcal{K_\text{B}}}A_{\text{B}}(k)}\right) = max\left(1, \sqrt[4]{3 800 \cdot 0 + 200 \cdot 10}\right) = max\left(1, \sqrt[4]{2 000}\right) \approxeq 6.69$ + +Example 3: subDAO C has opted not to pay any onboarding fees and have 100k active devices. + +$A_{\text{C}} = max\left(1, \sqrt[4]{\sum_{k \in \mathcal{K_\text{C}}}A_{\text{C}}(k)}\right) = max\left(1, \sqrt[4]{100 000 \cdot 0}\right) = max\left(1, \sqrt[4]{0}\right) = 1$ + +## Drawbacks: +This HIP would negatively impact any subDAOs in which have not paid onboarding fees for each active device. + +## Alternatives +There are two alternatives to this HIP, the first is leaving the $A$ factor as is; however, this would allow any subDAO to artificially set an onboard fee to increase their $A$ factor, without requiring them to retroactively pay any unpaid fees. + +The second is a major revamp of the subDAO utility score. A major revamp of the subDAO utility score takes months of discussion and modeling whereas several actors within the ecosystem have voiced their wish to change the onboarding fee sooner rather than later. Without this change the changing of a subDAOs onboarding fee is either artificially inflating the subDAO utility score (punishable by slashing) or very disincentivized by losing part of the $A$ factor. + +## Deployment Impact +The implementation of the `active-devices` will have to be altered. The `active-devices` oracle uses a database in which it stores key metrics such as `lastReward` that it can use to correctly determine the number of active devices. The `distribution` oracle uses this information to distribute HNT to the treasuries of the different subDAOs. This proposal proposes to add paid onboarding fee to this database in order to provide the `distribution` oracle with the correct values to use for the $A$ factor of the subDAO utility score. + +It is also suggested that the [Helium Network Stats](https://explorer.helium.com/stats) webpage be updated after implementation to include the sum of onboard fees paid for all active devices within each subDAO. + +The specific implementation of the proposed changes will be determined by the Helium Core Developers while conforming to the intent of the proposal in the fullest extent possible. + +## Success Metrics +This proposal is a success when the `distribution` and `active-devices` oracles can correctly determine the $A$ factor of the subDAO utility score based on the amount of active devices and the corresponding onboarding fee that was paid. As a consequence, this will allow the the subDAOs to set the onboarding fee via their internal governance without requiring a veHNT vote. diff --git a/0088-adjustment-of-dao-utility-a-score/0088-formulas.png b/0088-adjustment-of-dao-utility-a-score/0088-formulas.png new file mode 100644 index 000000000..055de297c Binary files /dev/null and b/0088-adjustment-of-dao-utility-a-score/0088-formulas.png differ diff --git a/0089-mobile-network-onboard-fees.md b/0089-mobile-network-onboard-fees.md new file mode 100644 index 000000000..83de0d0b2 --- /dev/null +++ b/0089-mobile-network-onboard-fees.md @@ -0,0 +1,39 @@ +# HIP 89: MOBILE Network Onboarding Fees +- Authors: [Andy Zyvoloski](https://github.com/heatedlime), [Keith Rettig](https://github.com/keithrettig), [Max Gold](https://github.com/MaxGold91) +- Start Date: 6/14/2023 +- Category: Technical & Economic +- Original HIP PR: [#701](https://github.com/helium/HIP/pull/701) +- Tracking Issue: [#714](https://github.com/helium/HIP/issues/714) +- Voting Requirements: veMOBILE + +## Summary +This HIP requests that Helium Foundation correct the MOBILE Onboarding Fee from 0 USD to 40 USD and the MOBILE Location Assert Fee from 0 USD to 10 USD as soon as possible so that the fees are in compliance with HIP-53 and HIP-19. + +## Stakeholders +MOBILE Hotspots - All currently onboarded MOBILE Hotspot owners. + +Approved MOBILE Hotspot Makers - The sub-group of Approved Hotspot Makers that manufacture omni-protocol Hotspots that utilize the MOBILE Network and the IOT Network. + +## Motivation +Current MOBILE Hotspots, such as the FreedomFi Gateway and the Bobcat 500, are both omni-protocol Hotspots; that is, they contain both IOT and MOBILE network capabilities. HIP-53 ('Economics Overview' section) dictates that all Hotspots must pay an Onboarding Fee of 40 USD and a Location Assert Fee of 10 USD. [Helium Maker Ethics Documentation](https://docs.helium.com/hotspot-makers/maker-ethics/) Section 9 indicates that Approved Hotspot Makers are responsible for funding the onboarding server for their Hotspots. HIP-19 ('Issuing Keys & Paying Staking Fees' section) requires manufacturers to acquire codes to validate, onboard a Hotspot, and pay the 40 USD Staking Fee, also referred to as the Onboarding Fee. + +At the time of onboarding these Hotspots, there was no MOBILE subDAO which to designate the MOBILE subDAO's 40 USD Onboarding Fee. As such, all MOBILE Hotspots were only onboarded to the IOT network with its associated Onboarding Fee of 40 USD and Location Assert Fee of 10 USD. At the time of the Solana migration in April of 2023, these Hotspots continued to be onboarded to the MOBILE network with an Onboarding Fee of 0 USD instead of 40 USD and Location Assert Fee of 0 USD instead of 10 USD, as the migration kept feature parity with the old chain. The discrepancy continues to this day. As a result, 0 USD in Onboarding Fees have been burned towards the MOBILE subDAO's $A$ Factor, which creates a negative impact in the $A$ Score of the DAO Utility Score established in HIP-51. + +## Detailed Explanation +Unfortunately, the framework for the MOBILE subDAO was established after the passage of HIP-51; and as such, there was no MOBILE subDAO to apply the paid Onboarding Fees for MOBILE Hotspots. Until the MOBILE subDAO framework was created, the Onboarding Fees for omni-protocol Hotspots were applied to the IOT subDAO only. The correct action at the time of migration in April of 2023 would have been to set the MOBILE Onboarding Fee to the required 40 USD and the Location Assert Onboarding Fee to the required 10 USD, pay the onboarding server for all Hotspots to be onboarded, and burn the Onboarding Fee for each Hotspot as required by HIP-51 and HIP-19. + +HIPs 51 through 53 provide for the Onboarding Server to be correctly paid with 100 USD worth of Data Credits for each Hotspot by the Approved Hotspot Makers such that it can pay for the IOT subDAO Onboarding Fee of 40 USD, the IOT subDAO Location Assert Fee of 10 USD, the MOBILE subDAO Onboarding Fee of 40 USD, and the MOBILE subDAO Location Assert Fee of 10 USD. Given that there is no Location Assert operation in the MOBILE subDAO, what to do with the excess funding (10 USD per Hotspot) presumed to be paid into each manufacturer's Maker Account for Location Asserts is outside of the scope of this HIP. + +### Technical Implementations +The correction is reportedly easy. As such, Helium Foundation has agreed to modify the Helium multisig for the MOBILE Onboarding Fee from 0 USD to 40 USD and the MOBILE subDAO Location Assert Fee from 0 USD to 10 USD upon passing of the HIP. The expected workload is to on the order of minutes and, therefore, should be able to be completed within the day. + +## Drawbacks +The biggest potential drawback applies if HIP-88 is passed. If the DAO Utility Score is modified to redefine the $A$ Factor calculation to be the sum of all onboarding fees for active devices rather than a multiple of active devices and the set Onboarding Fee value, then it would seem required to ensure that the funds from the Maker Accounts be used to burn the unpaid fees to the MOBILE subDAO's $A$ Factor. The mechanism for how to do such a burn is outside of the scope of this HIP. + +Another drawback is that since there are no Location Assert requirements for the MOBILE subDAO, there is no use to paying the Onboarding Server for any MOBILE subDAO Location Asserts as specified in HIP-51. A separate HIP should be created to set the MOBILE subDAO Location Assert Fee to 0 USD, no longer require the MOBILE subDAO Location Assert Fee to be funded into the maker account, and propose to allow any MOBILE subDAO Location Assert funds in the Maker's Accounts to be utilized for paying for MOBILE subDAO Onboarding Fees. + +## Alternatives +One alternative is to change the way the $A$ score of the DAO Utility Score is calculated so as to negate the need for Onboarding Fees. Given the significance of modifying the Helium ecosystem's tokenomics, such an alternative would require a vote to be held at the Helium DAO level with veHNT. + +## Success Metrics +This HIP is successful when the MOBILE Onboarding Fee is changed from 0 USD to 40 USD and the MOBILE Location Assert Fee from 0 USD to 10 USD. Once completed, all multi-protocol MOBILE Hotspots will automatically be onboarded to the MOBILE subDAO and the IOT subDAO and their required fees for both subDAOs are paid via the onboarding server. diff --git a/0090-reduce-iot-location-assert-cost-indefinitely.md b/0090-reduce-iot-location-assert-cost-indefinitely.md new file mode 100644 index 000000000..0326d5ec9 --- /dev/null +++ b/0090-reduce-iot-location-assert-cost-indefinitely.md @@ -0,0 +1,51 @@ +# HIP 90: Indefinitely Reduce IOT Location Assertion Cost + +- Author(s): [@nosmaster89](https://github.com/nosmaster89) +- Start Date: 2023-06-22 +- Category: Economic +- Original HIP PR: [#722](https://github.com/helium/HIP/pull/722) +- Tracking Issue: [#735](https://github.com/helium/HIP/issues/735) +- Vote Requirements: veIOT Holders + +## Summary + +This HIP proposes an adjustment to the Hotspot location assertion fees on the network. Currently, as per [HIP-69](https://github.com/helium/HIP/blob/main/0069-reassertion-fee-reduction.md) and since the Solana migration, the fees for IOT hotspots were halved. However, this adjustment is set to expire on July 20th, 2023, UTC, after which the fee will increase back to $10 in Data Credits. This proposal suggests maintaining the reduced fee to encourage hotspot relocation and support future HIPs aiming to distribute hotspots in densely populated areas. + +## Motivation +The key motivations behind this proposal are as follows: + +- Lowering the cost for hosts to relocate their hotspots going forward, facilitating better network coverage and decentralization. +- Establishing a minimum fee that reflects the network's expectations for hotspot relocation, ensuring a longer-term commitment from hotspot owners. + +## Stakeholders +IOT Hotspot Makers, who will not have to pay the increased 1M DC ($10) Location assert fee on the first location reassertions. +IOT Hotspot owners, who will not have to pay the increased 1M DC ($10) Location assert fee on subsequent location reassertions. +And this proposal impacts the entire network as it affects the amount of DC burned, which influences the economics of all networks. + +## Detailed Explanation +The proposal aims to extend the duration of the reduced asset fees for hotspot relocation that HIP 69 introduced indefinitely. By maintaining the lowered fee, +it becomes more attractive for hotspot owners to relocate their hotspots, increasing the likelihood of achieving better network coverage +in various locations. Additionally, this change supports future HIPss that aim to distribute hotspots in densely populated areas. + + +## Drawbacks +The primary drawback of this proposal is a lower overall DC burn for the network. +However, this can be balanced by the potential benefits gained from increased hotspot relocation and improved network coverage. + +## Rationale and Alternatives + +The rationale behind this proposal is that the current lowered asset fee represents a reasonable minimum fee for the expected lifespan of a hotspot at a new location. By keeping the fee reduced, hotspot owners are more likely to commit to longer-term hotspot operation, thus supporting network stability and coverage. +An alternative could be to maintain the original asset fee of $10, but this may discourage hotspot relocation and hinder efforts to optimize hotspot distribution. + +## Unresolved Questions + +- Is the asset cost a deciding factor for hotspot owners when considering hotspot relocation? +- How does the overall DC burn affect the economics of the network? + +## Deployment Impact + +To implement this proposal, IOT Hotspot makers need to ensure that Maker Apps display and use the correct requirement of 500K DC/$5 for hotspot relocation. + +## Success Metrics + +The success of this HIP can be measured by monitoring the burn for asset fees after its implementation. A successful outcome would be the retention or increase of the level of assert location DC burn, indicating active hotspot relocation and continued network growth. diff --git a/README.md b/README.md index bee754de7..acba0d677 100644 --- a/README.md +++ b/README.md @@ -1,111 +1,118 @@ -# HIP +# Helium Improvement Proposals (HIP) -Helium Improvement Proposals +Helium Improvement Proposals are the core unit of change in the Helium Network. _"How a bill becomes a law"_ -More details on process and how to participate can be found in HIP7, -["A Process For Managing Helium Improvement Proposals"](https://github.com/helium/HIP/blob/main/0007-managing-hip-process.md). +More details on process and how to participate can be found in HIP 7, ["A Process For Managing Helium Improvement Proposals"](0007-managing-hip-process.md). -If you have questions or feedback, please ask in -[#hip-open-discussion in the community Discord](https://discord.gg/helium). Each proposal in -discussion also has its own dedicated channel. +If you have questions or feedback, please see the [Discussion](https://github.com/helium/HIP/discussions) section of this Repo, where you can open forums to propose changes, provide feedback, and discuss ideas on how to make Helium Governance better. -**Looking for HIP19 hotspot manufacturer applications?** Those have moved to their own dedicated -repository: -[dewi-alliance/hotspot-manufacturers](https://github.com/dewi-alliance/hotspot-manufacturers) +**Looking for HIP19 hotspot manufacturer applications?** Those have moved to their own dedicated repository: [dewi-alliance/hotspot-manufacturers](https://github.com/dewi-alliance/hotspot-manufacturers) ## Index of proposals | ID | Title | Status | -| -- | ----- | ------ | -| 1 | [Longfi and LoRaWAN](https://github.com/helium/HIP/blob/main/0001-longfi-and-lorawan.md) | Deployed | -| 2 | [Sign miner](https://github.com/helium/HIP/blob/main/0002-sign-miner.md) | Deployed | -| 4 | [Expensing Data Credits for LoRaWAN Traffic](https://github.com/helium/HIP/blob/main/0004-expensing-data-credits-for-lorawan.md) | Deployed | -| 5 | [PoC fairness/epoch challenge limit](https://github.com/helium/HIP/blob/main/0005-poc-fairness.md) | [Closed](https://github.com/helium/HIP/issues/24#issuecomment-705308809) | -| 6 | [Ramp-up period for data transfer rewards](https://github.com/helium/HIP/blob/main/0006-reward-ramp-for-packets.md) | [Closed](https://github.com/helium/HIP/pull/20) | -| 7 | [Process for managing Helium Improvement Proposals](https://github.com/helium/HIP/blob/main/0007-managing-hip-process.md) | [Approved](https://github.com/helium/HIP/issues/26) | -| 8 | [XOR filter for LoRaWAN packet routing tables](https://github.com/helium/HIP/blob/c2f3ce61466b003731bb967959ca8b6e7706fca5/0008-lorawan-routing.md) | [Draft](https://github.com/helium/HIP/pull/9) | -| 9 | [Ensuring trust for non-Helium hotspots (DIY gateways)](https://github.com/helium/HIP/blob/7b715a0614d4c529144e1d6c0083ee8b38c05b29/0009-non-helium-hotspots.md) | [Draft](https://github.com/helium/HIP/pull/15) | -| 10 | [Proportional reward scheme for data transfers](https://github.com/helium/HIP/blob/main/0010-usage-based-data-transfer-rewards.md) | Deployed | -| 11 | [Amendment to proportional data transfer reward scheme](https://github.com/helium/HIP/blob/main/0011-usage-based-rewards-structure.md) | [Closed](https://github.com/helium/HIP/pull/49#issuecomment-705306806) | -| 12 | [Remote location assertion](https://github.com/helium/HIP/blob/main/0012-remote-location-assert.md) | [Deployed](https://github.com/helium/HIP/issues/39) ([audit](https://github.com/helium/miner/blob/master/audit/var-59.md) / [txn](https://explorer.helium.com/txns/B6SddkhG_OgayRYLfumkIUho1OpDYnqyzAA8Tkf0xzs)) | -| 13 | [Transfer hotspot](https://github.com/helium/HIP/blob/main/0013-transfer-hotspot.md) | [Deployed](https://github.com/helium/HIP/issues/43) ([audit](https://github.com/helium/miner/blob/master/audit/var-48.md) / [txn](https://explorer.helium.com/txns/DywtCExrXhTxv8VoDZl_hJDjQ2PUcov_AYrW98ZPpcg)) | -| 14 | [PoC Ripple Method](https://github.com/helium/HIP/blob/main/0014-poc-ripple-method.md) | [In Discussion](https://github.com/helium/HIP/issues/50) | -| 15 | [Beaconing Rewards](https://github.com/helium/HIP/blob/main/0015-beaconing-rewards.md) | [Deployed](https://github.com/helium/blockchain-core/pull/662) ([audit](https://github.com/helium/miner/blob/master/audit/var-50.md) / [txn](https://explorer.helium.com/txns/vnEqwbKtFfFxXgYI_9L5Th0LRVkpJlsX-sQzZTh2VwY)) | -| 16 | [Remove Score from Consensus Group Elections](https://github.com/helium/HIP/blob/main/0016-random-consensus-group-election.md) | [Deployed](https://github.com/helium/HIP/issues/55) ([audit](https://github.com/helium/miner/blob/master/audit/var-48.md) / [txn](https://explorer.helium.com/txns/DywtCExrXhTxv8VoDZl_hJDjQ2PUcov_AYrW98ZPpcg)) | -| 17 | [Hex Density-based Transmit Reward Scaling](https://github.com/helium/HIP/blob/main/0017-hex-density-based-transmit-reward-scaling.md) | [Deployed](https://github.com/helium/blockchain-core/pull/677) ([audit](https://github.com/helium/miner/blob/master/audit/var-50.md) / [txn](https://explorer.helium.com/txns/vnEqwbKtFfFxXgYI_9L5Th0LRVkpJlsX-sQzZTh2VwY)) | -| 18 | [Remove Oracle Forecast for DC Burn](https://github.com/helium/HIP/blob/main/0018-remove-oracle-forecast-for-dc-burn.md) | [Closed](https://github.com/helium/HIP/issues/60) | -| 19 | [Approval Process For Third-Party Manufacturers](https://github.com/helium/HIP/blob/main/0019-third-party-manufacturers.md) | [Deployed](https://github.com/helium/HIP/issues/87) | -| 20 | [HNT Max Supply](https://github.com/helium/HIP/blob/main/0020-hnt-max-supply.md) | [Deployed](https://github.com/helium/HIP/issues/73) ([audit](https://github.com/helium/miner/blob/master/audit/var-79.md)) | -| 21 | [PoC Link Layer Upgrades](https://github.com/helium/HIP/blob/main/0021-poc-link-layer.md) | [Closed](https://github.com/helium/HIP/issues/78) | -| 22 | [DIY Concentrators (f/k/a Golden or Anchor Gateways)](https://github.com/helium/HIP/blob/main/0022-diy-concentrators.md) | [In Discussion](https://github.com/helium/HIP/issues/94) | -| 23 | [Decouple Consensus From Gateways](https://github.com/helium/HIP/blob/main/0023-decouple-consensus-from-gateways.md) | [Closed](https://github.com/helium/HIP/issues/101) | -| 24 | [Transfer Percentage of Hotspot](https://github.com/helium/HIP/blob/main/0024-reward-splitting.md) | [In Discussion](https://github.com/helium/HIP/issues/105) | -| 25 | [Validators](https://github.com/helium/HIP/blob/main/0025-validators.md) | [Deployed](https://github.com/helium/HIP/issues/111) ([audit](https://github.com/helium/miner/blob/master/audit/var-70.md)) | -| 26 | [Payment Notes](https://github.com/helium/HIP/blob/main/0026-payment-notes.md) | [In Discussion](https://github.com/helium/HIP/issues/125) | -| 27 | [Support CBRS 5G](https://github.com/helium/HIP/blob/main/0027-cbrs-5g-support.md) | [Approved](https://github.com/helium/HIP/pull/133) | -| 28 | [Consensus Reward Adjustments](https://github.com/helium/HIP/blob/main/0028-consensus-reward-adjustments.md) | [Deployed](https://github.com/helium/HIP/issues/140) ([audit](https://github.com/helium/miner/blob/master/audit/var-84.md) / [txn](https://explorer.helium.com/txns/siOPX2IFSh9ey2U0X18BiDsPJHrgxQ0_YKleY4Vyew4)) | -| 29 | [Multi-signature Keys](https://github.com/helium/HIP/blob/main/0029-multisignature-keys.md) | [Deployed](https://github.com/helium/HIP/issues/157) ([commit](https://github.com/helium/miner/commit/b038f24c8ea801c2062644c7cd682832919b25b0)) | -| 30 | [BLS12-381 for Threshold Cryptography](https://github.com/helium/HIP/blob/main/0030-update-threshold-cryptography.md) | [Deployed](https://github.com/helium/HIP/issues/158) ([commit](https://github.com/helium/miner/commit/b038f24c8ea801c2062644c7cd682832919b25b0)) | -| 31 | [Governance by Token Lock](https://github.com/helium/HIP/blob/main/0031-governance-by-token-lock.md) | [Closed](https://github.com/helium/HIP/issues/183) | -| 32 | [Split DCs Among All Transferers](https://github.com/helium/HIP/blob/main/0032-split-dcs.md) | [In Discussion](https://github.com/helium/HIP/issues/221) | -| 33 | [Regional Reward Adjustments](https://github.com/helium/HIP/blob/main/0033-regional-reward-adjustments.md) | [In Discussion](https://github.com/helium/HIP/issues/222) | -| 34 | [Validator Node Security](https://github.com/helium/HIP/blob/main/0034-validator-node-security.md) | [In Discussion](https://github.com/helium/HIP/issues/223) | -| 35 | [RF Metadata Sidechannel](https://github.com/helium/HIP/blob/main/0035-safe-rf-metadata-side-channel.md) | [Closed](https://github.com/helium/HIP/issues/250) | -| 36 | [Blockheight Chainvar Activation](https://github.com/helium/HIP/blob/main/0036-blockheights-instead-of-time.md) | [Closed](https://github.com/helium/HIP/issues/260) | -| 37 | [Omni-Protocol PoC](https://github.com/helium/HIP/blob/main/0037-omni-protocol-poc.md) | [Closed](https://github.com/helium/HIP/issues/271) | -| 38 | [Validator Oracles](https://github.com/helium/HIP/blob/main/0038-validator-oracles.md) | [Closed](https://github.com/helium/HIP/issues/282) | -| 39 | [HNT Redenomination](https://github.com/helium/HIP/blob/main/0039-hnt-redenomination.md) | [In Discussion](https://github.com/helium/HIP/issues/283) | -| 40 | [Validator Denylist](https://github.com/helium/HIP/blob/main/0040-validator-denylist.md) | [Closed](https://github.com/helium/HIP/issues/285) | -| 41 | [Governance by Token Lock V2](https://github.com/helium/HIP/blob/main/0041-governance-by-token-lock-v2.md) | [Closed](https://github.com/helium/HIP/issues/302) | -| 42 | [Beacon/Witness Ratio - Witness Reward Limit](https://github.com/helium/HIP/blob/main/0042-beacon-witness-ratio-witness-reward-limit.md) | [Closed](https://github.com/helium/HIP/issues/303) | -| 43 | [Software Release Guidelines](https://github.com/helium/HIP/blob/main/0043-software-release-guidelines.md) | [Closed](https://github.com/helium/HIP/issues/309) | -| 44 | [Witness Reward Decay](https://github.com/helium/HIP/blob/main/0044-witness-decay.md) | [In Discussion](https://github.com/helium/HIP/issues/310) | -| 45 | [LoRaWAN Frequency Plan Selection](https://github.com/helium/HIP/blob/main/0045-lorawan-frequency-plan-selection.md) | [Withdrawn](https://github.com/helium/HIP/issues/311) | -| 46 | [LoRaWAN NetID Routing](https://github.com/helium/HIP/blob/main/0046-lorawan-netid-routing.md) | [Approved](https://github.com/helium/HIP/issues/312) | -| 47 | [Increase DKG Failure Penalty](https://github.com/helium/HIP/blob/main/0047-increase-dkg-penalty.md) | [Approved](https://github.com/helium/HIP/issues/313) | -| 48 | [IP-over-LoRaWAN](https://github.com/helium/HIP/blob/main/0048-ip-support.md) | [Closed](https://github.com/helium/HIP/issues/319) | -| 49 | [LoRaWAN Sub-region Max EIRP Limit](https://github.com/helium/HIP/blob/main/0049-max-eirp-adjustment.md) | [Closed](https://github.com/helium/HIP/issues/327) | -| 50 | [Display All Potential Witness Beacons](https://github.com/helium/HIP/blob/main/0050-display-all-potential-beacon-witnesses.md) | [Closed](https://github.com/helium/HIP/issues/331) | -| 51 | [Helium DAO](https://github.com/helium/HIP/blob/main/0051-helium-dao.md) | [Approved](https://github.com/helium/HIP/issues/336) | -| 52 | [IoT subDAO](https://github.com/helium/HIP/blob/main/0052-iot-dao.md) | [Approved](https://github.com/helium/HIP/issues/338) | -| 53 | [Mobile subDAO](https://github.com/helium/HIP/blob/main/0053-mobile-dao.md) | [Approved](https://github.com/helium/HIP/issues/345) | -| 54 | [H3Dex-based PoC Targeting](https://github.com/helium/HIP/blob/main/0054-h3dex-targeting.md) | [Deployed](https://github.com/helium/HIP/issues/347) | -| 55 | [Validator Challenges](https://github.com/helium/HIP/blob/main/0055-validator-challenges.md) | [Approved](https://github.com/helium/HIP/issues/362) | -| 56 | [Improved State Channel Disputes](https://github.com/helium/HIP/blob/main/0056-state-channel-dispute-strategy.md) | [Approved](https://github.com/helium/HIP/issues/369) | -| 57 | [PoC Rewards Establishment Period](https://github.com/helium/HIP/blob/main/0057-poc-rewards-establishment-period.md) | [Closed](https://github.com/helium/HIP/issues/376) | -| 58 | [PoC Distance Limit](https://github.com/helium/HIP/blob/main/0058-poc-distance-limit.md) | [Approved](https://github.com/helium/HIP/issues/384) | -| 59 | [Reduce XOR filter fees](https://github.com/helium/HIP/blob/main/0059-reduce-xor-filter-fees.md) | [Approved](https://github.com/helium/HIP/issues/391) | -| 60 | [Entity-Weighted Vote](https://github.com/helium/HIP/blob/main/0060-entity-weighted-vote.md) | [Closed](https://github.com/helium/HIP/issues/399) | -| 61 | [Increase Challenger Rewards](https://github.com/helium/HIP/blob/main/0061-increase-challenger-rewards.md) | [Closed](https://github.com/helium/HIP/issues/421) | -| 62 | [PoC Witness IP Check](https://github.com/helium/HIP/blob/main/0062-poc-witness-ip-check.md) | [Closed](https://github.com/helium/HIP/issues/422) | -| 63 | [Helium Hub](https://github.com/helium/HIP/blob/main/0063-helium-hub.md) | [In Discussion](https://github.com/helium/HIP/issues/423) | -| 64 | [WiFi subDAO](https://github.com/helium/HIP/blob/main/0064-wifi-dao.md) | [In Discussion](https://github.com/helium/HIP/issues/424) | -| 65 | [Vendor HNT Lockup](https://github.com/helium/HIP/blob/main/0065-vendor-token-lockup.md) | [In Discussion](https://github.com/helium/HIP/issues/437) | -| 66 | [Trust Score & Denylist Convenience](https://github.com/helium/HIP/blob/main/0066-trust-score-and-denylist-convenience.md) | [In Discussion](https://github.com/helium/HIP/issues/438) | -| 67 | [Repeal Redenomination](https://github.com/helium/HIP/blob/main/0067-repeal-redenomination.md) | [Approved](https://github.com/helium/HIP/issues/456) | -| 68 | [Open Service Subdao](https://github.com/helium/HIP/blob/main/0068-open-service-subdao.md) | [Closed](https://github.com/helium/HIP/issues/457) | -| 69 | [Re-assertion Fee Reduction](https://github.com/helium/HIP/blob/main/0069-reassertion-fee-reduction.md) | [In Discussion](https://github.com/helium/HIP/issues/458) | -| 70 | [Scaling the Helium Network](https://github.com/helium/HIP/blob/main/0070-scaling-helium.md) | [Approved](https://github.com/helium/HIP/issues/471) | -| 71 | [Scaling the Network with Governance & Hedera](https://github.com/helium/HIP/blob/main/0071-scaling-with-governance-hedera.md) | [Closed](https://github.com/helium/HIP/issues/480) | -| 72 | [Secure Concentrators](https://github.com/helium/HIP/blob/main/0072-secure-concentrators.md) | [In Discussion](https://github.com/helium/HIP/issues/489) | -| 73 | [Consensus Deselection Weighting](https://github.com/helium/HIP/blob/main/0073-consensus-deselection-history-weight.md) | [Deployed (audit/txn)](https://github.com/helium/HIP/issues/491) | -| 74 | [Mobile PoC - Modeled Coverage Rewards](https://github.com/helium/HIP/blob/main/0074-mobile-poc-modeled-coverage-rewards.md) | [Approved](https://github.com/helium/HIP/issues/504) | -| 75 | [Initiate Programmatic PoC Emissions with an Updated Emissions Curve](https://github.com/helium/HIP/blob/main/0075-mobile-poc-initiate-programmatic-minting-and-updated-emissions-curve.md) | [In Discussion](https://github.com/helium/HIP/issues/526) | -| 76 | [Simplify Lockup Curve and veTokens](https://github.com/helium/HIP/blob/main/0076-linear-lockup-curve.md) | [Approved](https://github.com/helium/HIP/issues/560) | -| 77 | [Launch Parameters for Solana Migration](https://github.com/helium/HIP/blob/main/0077-solana-parameters.md) | [In Discussion](https://github.com/helium/HIP/issues/573) | -| 78 | [Mobile SubDAO Onbaording Fees](https://github.com/helium/HIP/blob/main/0078-mobile-subdao-onboarding-fees.md) | [Closed](https://github.com/helium/HIP/issues/582) | -| 79 | [Mobile PoC Mobile Mappers](https://github.com/helium/HIP/blob/main/0079-mobile-poc-mappers-rewards.md) | [In Discussion](https://github.com/helium/HIP/issues/592) | -| 80 | [Simplifying the DAO Utility Score](https://github.com/helium/HIP/blob/main/0080-simplifying-dao-utility-score.md) | [In Discussion](https://github.com/helium/HIP/issues/599) | -| 81 | [Minimum Device Onboarding Fees](https://github.com/helium/HIP/blob/main/0081-minimum-onboarding-fee.md) | [In Discussion](https://github.com/helium/HIP/issues/612) | +| :---: | :--- | :-- | +| 1 | [Longfi and LoRaWAN](0001-longfi-and-lorawan.md) | | +| 2 | [Sign miner](0002-sign-miner.md) | | +| 4 | [Expensing Data Credits for LoRaWAN Traffic](0004-expensing-data-credits-for-lorawan.md) | | +| 5 | [PoC fairness/epoch challenge limit](0005-poc-fairness.md) | [](https://github.com/helium/HIP/issues/24#issuecomment-705308809) | +| 6 | [Ramp-up period for data transfer rewards](0006-reward-ramp-for-packets.md) | [](https://github.com/helium/HIP/pull/20) | +| 7 | [Process for managing Helium Improvement Proposals](0007-managing-hip-process.md) | [](https://github.com/helium/HIP/issues/26) | +| 8 | [XOR filter for LoRaWAN packet routing tables](0008-lorawan-routing.md) | [](https://github.com/helium/HIP/pull/9) | +| 9 | [Ensuring trust for non-Helium hotspots (DIY gateways)](0009-non-helium-hotspots.md) | [](https://github.com/helium/HIP/pull/15) | +| 10 | [Proportional reward scheme for data transfers](0010-usage-based-data-transfer-rewards.md) | | +| 11 | [Amendment to proportional data transfer reward scheme](0011-usage-based-rewards-structure.md) | [](https://github.com/helium/HIP/pull/49#issuecomment-705306806) | +| 12 | [Remote location assertion](0012-remote-location-assert.md) | [](https://github.com/helium/HIP/issues/39) | +| 13 | [Transfer hotspot](0013-transfer-hotspot.md) | [](https://github.com/helium/HIP/issues/43) | +| 14 | [PoC Ripple Method](0014-poc-ripple-method.md) | [](https://github.com/helium/HIP/issues/50) | +| 15 | [Beaconing Rewards](0015-beaconing-rewards.md) | [](https://github.com/helium/blockchain-core/pull/662) | +| 16 | [Remove Score from Consensus Group Elections](0016-random-consensus-group-election.md) | [](https://github.com/helium/HIP/issues/55) | +| 17 | [Hex Density-based Transmit Reward Scaling](0017-hex-density-based-transmit-reward-scaling.md) | [](https://github.com/helium/blockchain-core/pull/677) | +| 18 | [Remove Oracle Forecast for DC Burn](0018-remove-oracle-forecast-for-dc-burn.md) | [](https://github.com/helium/HIP/issues/60) | +| 19 | [Approval Process For Third-Party Manufacturers](0019-third-party-manufacturers.md) | [](https://github.com/helium/HIP/issues/87) | +| 20 | [HNT Max Supply](0020-hnt-max-supply.md) | [](https://github.com/helium/HIP/issues/73) | +| 21 | [PoC Link Layer Upgrades](0021-poc-link-layer.md) | [](https://github.com/helium/HIP/issues/78) | +| 22 | [DIY Concentrators (f/k/a Golden or Anchor Gateways)](0022-diy-concentrators.md) | [](https://github.com/helium/HIP/issues/94) | +| 23 | [Decouple Consensus From Gateways](0023-decouple-consensus-from-gateways.md) | [](https://github.com/helium/HIP/issues/101) | +| 24 | [Transfer Percentage of Hotspot](0024-reward-splitting.md) | [](https://github.com/helium/HIP/issues/105) | +| 25 | [Validators](0025-validators.md) | [](https://github.com/helium/HIP/issues/111) | +| 26 | [Payment Notes](0026-payment-notes.md) | [](https://github.com/helium/HIP/issues/125) | +| 27 | [Support CBRS 5G](0027-cbrs-5g-support.md) | [](https://github.com/helium/HIP/pull/133) | +| 28 | [Consensus Reward Adjustments](0028-consensus-reward-adjustments.md) | [](https://github.com/helium/HIP/issues/140) | +| 29 | [Multi-signature Keys](0029-multisignature-keys.md) | [](https://github.com/helium/HIP/issues/157) | +| 30 | [BLS12-381 for Threshold Cryptography](0030-update-threshold-cryptography.md) | [](https://github.com/helium/HIP/issues/158) | +| 31 | [Governance by Token Lock](0031-governance-by-token-lock.md) | [](https://github.com/helium/HIP/issues/183) | +| 32 | [Split DCs Among All Transferers](0032-split-dcs.md) | [](https://github.com/helium/HIP/issues/221) | +| 33 | [Regional Reward Adjustments](0033-regional-reward-adjustments.md) | [](https://github.com/helium/HIP/issues/222) | +| 34 | [Validator Node Security](0034-validator-node-security.md) | [](https://github.com/helium/HIP/issues/223) | +| 35 | [RF Metadata Sidechannel](0035-safe-rf-metadata-side-channel.md) | [](https://github.com/helium/HIP/issues/250) | +| 36 | [Blockheight Chainvar Activation](0036-blockheights-instead-of-time.md) | [](https://github.com/helium/HIP/issues/260) | +| 37 | [Omni-Protocol PoC](0037-omni-protocol-poc.md) | [](https://github.com/helium/HIP/issues/271) | +| 38 | [Validator Oracles](0038-validator-oracles.md) | [](https://github.com/helium/HIP/issues/282) | +| 39 | [HNT Redenomination](0039-hnt-redenomination.md) | [](https://github.com/helium/HIP/issues/283) | +| 40 | [Validator Denylist](0040-validator-denylist.md) | [](https://github.com/helium/HIP/issues/285) | +| 41 | [Governance by Token Lock V2](0041-governance-by-token-lock-v2.md) | [](https://github.com/helium/HIP/issues/302) | +| 42 | [Beacon/Witness Ratio - Witness Reward Limit](0042-beacon-witness-ratio-witness-reward-limit.md) | [](https://github.com/helium/HIP/issues/303) | +| 43 | [Software Release Guidelines](0043-software-release-guidelines.md) | [](https://github.com/helium/HIP/issues/309) | +| 44 | [Witness Reward Decay](0044-witness-decay.md) | [](https://github.com/helium/HIP/issues/310) | +| 45 | [LoRaWAN Frequency Plan Selection](0045-lorawan-frequency-plan-selection.md) | [](https://github.com/helium/HIP/issues/311) | +| 46 | [LoRaWAN NetID Routing](0046-lorawan-netid-routing.md) | [](https://github.com/helium/HIP/issues/312) | +| 47 | [Increase DKG Failure Penalty](0047-increase-dkg-penalty.md) | [](https://github.com/helium/HIP/issues/313) | +| 48 | [IP-over-LoRaWAN](0048-ip-support.md) | [](https://github.com/helium/HIP/issues/319) | +| 49 | [LoRaWAN Sub-region Max EIRP Limit](0049-max-eirp-adjustment.md) | [](https://github.com/helium/HIP/issues/327) | +| 50 | [Display All Potential Witness Beacons](0050-display-all-potential-beacon-witnesses.md) | [](https://github.com/helium/HIP/issues/331) | +| 51 | [Helium DAO](0051-helium-dao.md) | [](https://github.com/helium/HIP/issues/336) | +| 52 | [IoT subDAO](0052-iot-dao.md) | [](https://github.com/helium/HIP/issues/338) | +| 53 | [Mobile subDAO](0053-mobile-dao.md) | [](https://github.com/helium/HIP/issues/345) | +| 54 | [H3Dex-based PoC Targeting](0054-h3dex-targeting.md) | [](https://github.com/helium/HIP/issues/347) | +| 55 | [Validator Challenges](0055-validator-challenges.md) | [](https://github.com/helium/HIP/issues/362) | +| 56 | [Improved State Channel Disputes](0056-state-channel-dispute-strategy.md) | [](https://github.com/helium/HIP/issues/369) | +| 57 | [PoC Rewards Establishment Period](0057-poc-rewards-establishment-period.md) | [](https://github.com/helium/HIP/issues/376) | +| 58 | [PoC Distance Limit](0058-poc-distance-limit.md) | [](https://github.com/helium/HIP/issues/384) | +| 59 | [Reduce XOR filter fees](0059-reduce-xor-filter-fees.md) | [](https://github.com/helium/HIP/issues/391) | +| 60 | [Entity-Weighted Vote](0060-entity-weighted-vote.md) | [](https://github.com/helium/HIP/issues/399) | +| 61 | [Increase Challenger Rewards](0061-increase-challenger-rewards.md) | [](https://github.com/helium/HIP/issues/421) | +| 62 | [PoC Witness IP Check](0062-poc-witness-ip-check.md) | [](https://github.com/helium/HIP/issues/422) | +| 63 | [Helium Hub](0063-helium-hub.md) | [](https://github.com/helium/HIP/issues/423) | +| 64 | [WiFi subDAO](0064-wifi-dao.md) | [](https://github.com/helium/HIP/issues/424) | +| 65 | [Vendor HNT Lockup](0065-vendor-token-lockup.md) | [](https://github.com/helium/HIP/issues/437) | +| 66 | [Trust Score & Denylist Convenience](0066-trust-score-and-denylist-convenience.md) | [](https://github.com/helium/HIP/issues/438) | +| 67 | [Repeal Redenomination](0067-repeal-redenomination.md) | [](https://github.com/helium/HIP/issues/456) | +| 68 | [Open Service Subdao](0068-open-service-subdao.md) | [](https://github.com/helium/HIP/issues/457) | +| 69 | [Re-assertion Fee Reduction](0069-reassertion-fee-reduction.md) | [](https://github.com/helium/HIP/issues/458) | +| 70 | [Scaling the Helium Network](0070-scaling-helium.md) | [](https://github.com/helium/HIP/issues/471) | +| 71 | [Scaling the Network with Governance & Hedera](0071-scaling-with-governance-hedera.md) | [](https://github.com/helium/HIP/issues/480) | +| 72 | [Secure Concentrators](0072-secure-concentrators.md) | [](https://github.com/helium/HIP/issues/489) | +| 73 | [Consensus Deselection Weighting](0073-consensus-deselection-history-weight.md) | [](https://github.com/helium/HIP/issues/491) | +| 74 | [Mobile PoC - Modeled Coverage Rewards](0074-mobile-poc-modeled-coverage-rewards.md) | [](https://github.com/helium/HIP/issues/504) | +| 75 | [Initiate Programmatic PoC Emissions with an Updated Emissions Curve](0075-mobile-poc-initiate-programmatic-minting-and-updated-emissions-curve.md) | [](https://github.com/helium/HIP/issues/526) | +| 76 | [Simplify Lockup Curve and veTokens](0076-linear-lockup-curve.md) | [](https://github.com/helium/HIP/issues/560) | +| 77 | [Launch Parameters for Solana Migration](0077-solana-parameters.md) | [](https://github.com/helium/HIP/issues/573) | +| 78 | [Mobile SubDAO Onbaording Fees](0078-mobile-subdao-onboarding-fees.md) | [](https://github.com/helium/HIP/issues/582) | +| 79 | [Mobile PoC Mobile Mappers](0079-mobile-poc-mappers-rewards.md) | [](https://github.com/helium/HIP/issues/592) | +| 80 | [Simplifying the DAO Utility Score](0080-simplifying-dao-utility-score.md) | [](https://github.com/helium/HIP/issues/599) | +| 81 | [Minimum Device Onboarding Fees](0081-minimum-onboarding-fee.md) | [](https://github.com/helium/HIP/issues/612) | +| 82 | [Add Helium Mobile as a Service Provider to the Helium Mobile subDAO](0082-helium-mobile-service-provider.md) | [](https://github.com/helium/HIP/issues/628) | +| 83 | [Restore First to Respond Witness Rewarding](0083-restore-first-to-witness.md) | [](https://github.com/helium/HIP/issues/632) | +| 84 | [Service Provider Hex Boosting](0084-service-provider-hex-boosting.md) | [](https://github.com/helium/HIP/issues/638) | +| 85 | [MOBILE Hex Coverage Limit](0085-mobile-hex-coverage-limit.md) | [](https://github.com/helium/HIP/issues/673) | +| 86 | [Increase IOT Data Transfer Cost](0086-increase-iot-data-transfer-cost.md) | [](https://github.com/helium/HIP/issues/703) | +| 87 | [Proportional Service Provider Rewards](0087-proportional-service-provider-rewards.md) | [](https://github.com/helium/HIP/issues/704) | +| 88 | [Adjustment of DAO Utility A Score](0088-adjustment-of-dao-utility-a-score.md) | [](https://github.com/helium/HIP/issues/707) | +| 89 | [MOBILE Network Onboarding Fees](0089-mobile-network-onboard-fees.md) | [](https://github.com/helium/HIP/issues/714) | +| 90 | [Indefinitely Reduce IOT Location Assertion Cost](0090-reduce-iot-location-assert-cost-indefinitely.md) | [](https://github.com/helium/HIP/issues/735) | -## Status key +## Status Key -- Draft: HIP is in process of being written; author is not yet soliciting feedback from the - community at large -- In Discussion: HIP is under active consideration by the community -- Approved: HIP has been approved by rough consensus, and pending development and testing -- Deployed: Code to implement HIP has been merged and deployed to the network -- Closed: HIP abandoned, rendered obsolete by other changes, or otherwise withdrawn by the author +| Status | Label | Summary | +| :------------ | :--------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------- | +| Draft | | HIP is in process of being written; author is not yet soliciting feedback from the community at large | +| In Discussion | | HIP is under active consideration by the community | +| Voting Open | | HIP is currently being voted on +| Approved | | HIP has been approved by rough consensus, and pending development and testing | +| Deployed | | Code to implement HIP has been merged and deployed to the network | +| Rejected | | HIP did not pass voting | +| Closed | | HIP abandoned, rendered obsolete by other changes, or otherwise withdrawn by the author |