From 8406181101c314675566caa2d098bbf5f0867fc9 Mon Sep 17 00:00:00 2001 From: Rahul Garg Date: Thu, 20 Feb 2020 11:54:51 -0800 Subject: [PATCH 01/14] WIP: Ensuring trust for non-helium hotspots --- 0009-non-helium-hotspots.md | 174 ++++++++++++++++++++++++++++++++++++ 1 file changed, 174 insertions(+) create mode 100644 0009-non-helium-hotspots.md diff --git a/0009-non-helium-hotspots.md b/0009-non-helium-hotspots.md new file mode 100644 index 000000000..f00586de5 --- /dev/null +++ b/0009-non-helium-hotspots.md @@ -0,0 +1,174 @@ +- Start Date: 02/19/2020 +- HIP PR: +- Tracking Issue: + +# Summary +[summary]: #summary + +Ensuring trust in the network when non-helium hotspots begin to +participate in the network. + +# Motivation +[motivation]: #motivation + +Helium's primary objective has always been to establish a decentralized +permissionless wireless network allowing anyone to be able to join and +provide RF Coverage with off-the-shelf hardware and open source +software. + +This goal poses some interesting challenges specifically regarding +network growth. Once we allow non-helium hotspots to be able to join the +network, we lose the ability to verifiably prove that any sub-network +created by such new hotspots truly exist physically since it's easily +possible for dishonest actors to fake geographic locations and radio +transmit/receive and claim that they are providing network coverage. + +# Stakeholders +[stakeholders]: #stakeholders + +- 3rd party hotspot manufacturers +- DIY hotspot builders + +# Detailed Explanation +[detailed-explanation]: #detailed-explanation + +In order to ensure organic network growth while still maintaining +verifiable trust regarding the claim of location of newly joining 3rd +party or DIY hotspots we propose that every hotspot joins the network in +a probationary mode with limited PoC capability. + +In the current network onboarding a helium manufactured hotspot allows +full proof-of-coverage priviledges as soon as the hotspots syncs fully +with the blockchain, however this behavior is insufficient to ensure +that non-helium manufactured hotspots or DIY hotspots by individual +developers adhere to the consensus rules and also honestly provide RF +coverage. + +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 introducing a probationary mode. Every +single hotspot which will join the network (including helium +manufactured) will do so in "probation". In probation mode, the PoC +activity of a hotspot would be limited to only participate in challenges +which involve the external device. + +To gain full PoC priviledges, a hotspot must complete a pre-determined +number of successful challenges involving the external device. This +number can be set via chain variable on the blockchain. + +Consider the below network where hotspot A-F are non-helium manufactured +hotspots, with the lines representing RF visibility between hotspots. + + +------+ + | | + +-----------+ A | + | | | + | +------+ + | + +------+ + | | + | F | + | | + +------+ + | +------+ + | | | + | | B | + | | | + | +------+ +------+ + +------+ | | | + | | | | C | + | E +-----------------------------+ | + | | | +------+ + +------+ | + | | + | +------+ + | | | + +-------------+ D | + | | + +------+ + +There exists no possible way to ensure that these hotspots do not form +part of a virtual network, since they can easily fake locations and RF +coverage and verify each other via the existing PoC mechanism. + +Until and unless there is a helium (or an authorized retailer) +manufatured hotspot introduced in the above network, we cannot make any +conclusions regarding the claim of location of any hotspot A - F. + +Reimagining the above network with the introduction of a helium hotspot, +consider the graph below: + + + +------+ + | | + | A +---------------+ + | | | + +------+ | + +--+---+ + +------+ | | + | | | X +<--+Helium Hotspot + | F | +---------------+ | + | | | +------+ + +------+ | + +---+--+ + | | + | B | + | | + +---+--+ +------+ + +------+ | | | + | | | | C | + | E | | | | + | | | +------+ + +---+--+ | + | | + | +--+---+ + | | | + +-------------+ D | + | | + +------+ + +We can verifiably prove that A, B, D and E can successfully complete +PoC challenges which involve hotspot X. Since we know that hotspot X is +bound to be trustworthy by design and 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, we still cannot make logical conclusions about C and F since +they have not had any PoC activity with X. Therefore both C and F remain +in probation mode but A, B, D and E can transition to full PoC activity +once they all successfully complete `N` PoC challenges successfully +involvind hotspot X. + + +# Drawbacks +[drawbacks]: #drawbacks + +TBD + +# Rationale and Alternatives +[alternatives]: #rationale-and-alternatives + +- Why the limitation for PoC-ing with helium hotspots? + +The helium hotspot solves the problem of seeding trust in a new network +by serving as a "trust authority". Furthermore, this authority can be +delegated to other 3rd party manufacturers. + +# Unresolved Questions +[unresolved]: #unresolved-questions + +TBD + +# Deployment Impact +[deployment-impact]: #deployment-impact + +TBD + +# Success Metrics [success-metrics]: #success-metrics + +TBD From 64dc2eedc7a22d73e239810cec1c6a8a352f3693 Mon Sep 17 00:00:00 2001 From: Rahul Garg Date: Mon, 24 Feb 2020 16:26:19 -0800 Subject: [PATCH 02/14] WIP: Add a high level workflow for diy hotspots --- 0009-non-helium-hotspots.md | 53 ++++++++++++++++++++++++++++++++++--- 1 file changed, 50 insertions(+), 3 deletions(-) diff --git a/0009-non-helium-hotspots.md b/0009-non-helium-hotspots.md index f00586de5..e885ef7aa 100644 --- a/0009-non-helium-hotspots.md +++ b/0009-non-helium-hotspots.md @@ -93,10 +93,11 @@ hotspots, with the lines representing RF visibility between hotspots. There exists no possible way to ensure that these hotspots do not form part of a virtual network, since they can easily fake locations and RF -coverage and verify each other via the existing PoC mechanism. +coverage and verify each other via the existing PoC mechanism. Therefore +these remain in probation mode with limited PoC priviledges. Until and unless there is a helium (or an authorized retailer) -manufatured hotspot introduced in the above network, we cannot make any +manufactured hotspot introduced in the above network, we cannot make any conclusions regarding the claim of location of any hotspot A - F. Reimagining the above network with the introduction of a helium hotspot, @@ -142,7 +143,53 @@ However, we still cannot make logical conclusions about C and F since they have not had any PoC activity with X. Therefore both C and F remain in probation mode but A, B, D and E can transition to full PoC activity once they all successfully complete `N` PoC challenges successfully -involvind hotspot X. +involving hotspot X. + +## High-Level Workflow + +All the below actions would happen behind chain var `diy` (or +something). Setting `diy` to true, triggers all of the below: + +Another chain var, `probation_height_limit`, set to 2000 or whatever will +be set to allow witness collection for hotspots in probation mode. + +Yet another chain var, `probabtion_required_pocs`, set to 100 or +whatever will be set to count down whether a probationary hotspot has +completed enough successful pocs with non-probationary hotspots. + +- Add `probation` flag to gateway entries in the ledger. This would help + us identify which hotspots have full/limited PoC priviledges. + +- Add `added_at_block_height` to gateway entries in the ledger. This + would help identify how long to keep collecting witnesses for hotspots + in probation mode. Also helpful in general. Not quite sure what to set + this for existing hotspots when upgrading the ledger gateway entries. + +- Add `count_golden_pocs` to gateway entries in the ledger. This is the + count of pocs which a probationary hotspot maintains every time it + successfully and verifiably transmits a receipt with an active hotspot. + +- Modify existing ledger gateway entries to have `probation` flag set to + false. + +- When a new hotspot is added to the network, `probation` is set to + true. + +- Hotspots with `probation` set to true are prohibited from creating + `poc_request` transactions. + +- Hotspots with `probation` set to true are allowed to be witnesses, + however, they do not earn any tokens for being witnesses. This allows + such hotspots to potentially witness helium manufactured hotspots + opening chances of eventually getting pathed through those. + +- At each `poc_receipt`, after all the existing validity checks, if a + probationary hotspot successfully transmitted and received packets + from a non-probationary hotspot, the probationary hotspot gains +1 + `golden_poc` count in its ledger entry. Furthermore, as soon as the + total `golden_poc` count for the probationary hotspot reaches + `probabtion_required_pocs` count, it transitions to `active` mode by + setting the `probation` mode to false. # Drawbacks From 2d936bd4750842f24ddd7ec4436c09a0bdc7ac1d Mon Sep 17 00:00:00 2001 From: Rahul Garg Date: Thu, 27 Feb 2020 10:40:14 -0800 Subject: [PATCH 03/14] Reword --- 0009-non-helium-hotspots.md | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/0009-non-helium-hotspots.md b/0009-non-helium-hotspots.md index e885ef7aa..5a9aa2d6e 100644 --- a/0009-non-helium-hotspots.md +++ b/0009-non-helium-hotspots.md @@ -147,15 +147,17 @@ involving hotspot X. ## High-Level Workflow -All the below actions would happen behind chain var `diy` (or -something). Setting `diy` to true, triggers all of the below: +Chain Vars: -Another chain var, `probation_height_limit`, set to 2000 or whatever will -be set to allow witness collection for hotspots in probation mode. +- `diy`: boolean. All the changes would be hidden behind the activation + of this chain variable. -Yet another chain var, `probabtion_required_pocs`, set to 100 or -whatever will be set to count down whether a probationary hotspot has -completed enough successful pocs with non-probationary hotspots. +- `required_pocs`: pos_integer. Number of PoCs a porobationary hotspot + must complete before it can transition to active mode. Note that this + count only increments if a probationary hotspot completes a PoC + successfully with a non-probationary hotspot. + +TODO: - Add `probation` flag to gateway entries in the ledger. This would help us identify which hotspots have full/limited PoC priviledges. @@ -165,9 +167,9 @@ completed enough successful pocs with non-probationary hotspots. in probation mode. Also helpful in general. Not quite sure what to set this for existing hotspots when upgrading the ledger gateway entries. -- Add `count_golden_pocs` to gateway entries in the ledger. This is the - count of pocs which a probationary hotspot maintains every time it - successfully and verifiably transmits a receipt with an active hotspot. +- Add `count_required_pocs` to gateway entries in the ledger. This is + the count of pocs which a probationary hotspot maintains every time it + successfully transmits a receipt with an active hotspot. - Modify existing ledger gateway entries to have `probation` flag set to false. From 421f77de6167b83df30b8f8f87c25b23308fa672 Mon Sep 17 00:00:00 2001 From: Rahul Garg Date: Sun, 1 Mar 2020 12:17:52 -0800 Subject: [PATCH 04/14] More rewording, comment feedback --- 0009-non-helium-hotspots.md | 64 ++++++++++++++++++------------------- 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/0009-non-helium-hotspots.md b/0009-non-helium-hotspots.md index 5a9aa2d6e..7d6852d98 100644 --- a/0009-non-helium-hotspots.md +++ b/0009-non-helium-hotspots.md @@ -51,14 +51,14 @@ 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 introducing a probationary mode. Every -single hotspot which will join the network (including helium -manufactured) will do so in "probation". In probation mode, the PoC -activity of a hotspot would be limited to only participate in challenges -which involve the external device. +single hotspot which will join the network will do so in "probation". In +probation mode, the PoC activity of a hotspot would be limited to only +participate in challenges as witnessees with no PoC request priviledges. -To gain full PoC priviledges, a hotspot must complete a pre-determined -number of successful challenges involving the external device. This -number can be set via chain variable on the blockchain. +To gain full PoC priviledges, a hotspot must complete a chain variable +controlled maximum number of successful challenges involving either a +helium manufactured hotspot or an authorized 3rd party manufactured +hotspots. Consider the below network where hotspot A-F are non-helium manufactured hotspots, with the lines representing RF visibility between hotspots. @@ -106,31 +106,31 @@ consider the graph below: +------+ | | - | A +---------------+ - | | | - +------+ | - +--+---+ - +------+ | | + | A +---------------+ + | | | + +------+ | + +--+---+ + +------+ | | | | | X +<--+Helium Hotspot - | F | +---------------+ | - | | | +------+ - +------+ | - +---+--+ - | | - | B | - | | - +---+--+ +------+ - +------+ | | | - | | | | C | - | E | | | | - | | | +------+ - +---+--+ | - | | - | +--+---+ - | | | - +-------------+ D | - | | - +------+ + | F | +---------------+ | + | | | +------+ + +------+ | + +---+--+ + | | + | B | + | | + +---+--+ +------+ + +------+ | | | + | | | | C | + | E | | | | + | | | +------+ + +---+--+ | + | | + | +--+---+ + | | | + +-------------+ D | + | | + +------+ We can verifiably prove that A, B, D and E can successfully complete PoC challenges which involve hotspot X. Since we know that hotspot X is @@ -206,7 +206,7 @@ TBD The helium hotspot solves the problem of seeding trust in a new network by serving as a "trust authority". Furthermore, this authority can be -delegated to other 3rd party manufacturers. +delegated to other 3rd party manufacturers. # Unresolved Questions [unresolved]: #unresolved-questions From b53ed48d38728a1c2e2f9b9e20f0a16e91454681 Mon Sep 17 00:00:00 2001 From: Rahul Garg Date: Tue, 3 Mar 2020 16:32:11 -0800 Subject: [PATCH 05/14] Start working on levels of trust --- 0009-non-helium-hotspots.md | 221 ++++++++++++++++++++---------------- 1 file changed, 126 insertions(+), 95 deletions(-) diff --git a/0009-non-helium-hotspots.md b/0009-non-helium-hotspots.md index 7d6852d98..7567033f1 100644 --- a/0009-non-helium-hotspots.md +++ b/0009-non-helium-hotspots.md @@ -29,36 +29,8 @@ transmit/receive and claim that they are providing network coverage. - 3rd party hotspot manufacturers - DIY hotspot builders -# Detailed Explanation -[detailed-explanation]: #detailed-explanation - -In order to ensure organic network growth while still maintaining -verifiable trust regarding the claim of location of newly joining 3rd -party or DIY hotspots we propose that every hotspot joins the network in -a probationary mode with limited PoC capability. - -In the current network onboarding a helium manufactured hotspot allows -full proof-of-coverage priviledges as soon as the hotspots syncs fully -with the blockchain, however this behavior is insufficient to ensure -that non-helium manufactured hotspots or DIY hotspots by individual -developers adhere to the consensus rules and also honestly provide RF -coverage. - -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 introducing a probationary mode. Every -single hotspot which will join the network will do so in "probation". In -probation mode, the PoC activity of a hotspot would be limited to only -participate in challenges as witnessees with no PoC request priviledges. - -To gain full PoC priviledges, a hotspot must complete a chain variable -controlled maximum number of successful challenges involving either a -helium manufactured hotspot or an authorized 3rd party manufactured -hotspots. +# Problem Deinifition +[problem-definition]: #problem-definition Consider the below network where hotspot A-F are non-helium manufactured hotspots, with the lines representing RF visibility between hotspots. @@ -93,15 +65,16 @@ hotspots, with the lines representing RF visibility between hotspots. There exists no possible way to ensure that these hotspots do not form part of a virtual network, since they can easily fake locations and RF -coverage and verify each other via the existing PoC mechanism. Therefore -these remain in probation mode with limited PoC priviledges. +coverage and verify each other via the existing PoC mechanism. -Until and unless there is a helium (or an authorized retailer) -manufactured hotspot introduced in the above network, we cannot make any -conclusions regarding the claim of location of any hotspot A - F. +To correctly identify whether the above network is legitimate, we have +the option of introducing a Helium (or authorized 3rd party reseller) +hotspot in the network and learning more about the behavior of each +hotspot. Only the real hotspots can successfully participate with +eventual PoC challenges involving the Helium hotspots. Reimagining the above network with the introduction of a helium hotspot, -consider the graph below: +consider the updated graph below: +------+ @@ -132,66 +105,128 @@ consider the graph below: | | +------+ -We can verifiably prove that A, B, D and E can successfully complete -PoC challenges which involve hotspot X. Since we know that hotspot X is -bound to be trustworthy by design and 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, we still cannot make logical conclusions about C and F since -they have not had any PoC activity with X. Therefore both C and F remain -in probation mode but A, B, D and E can transition to full PoC activity -once they all successfully complete `N` PoC challenges successfully -involving hotspot X. - -## High-Level Workflow - -Chain Vars: +With this information, we can verifiably prove that A, B, D and E can +successfully complete PoC challenges which involve hotspot X. Since we +know that hotspot X is bound to be trustworthy by design and 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. -- `diy`: boolean. All the changes would be hidden behind the activation - of this chain variable. +However, even with the above explained scheme, we still need a way to be +able to allow hotspots not manufactured by Helium or authorized +manufacturers to not only participate in PoC but also be candidates for +consensus membership to build a truly decentralized permissionless +network. -- `required_pocs`: pos_integer. Number of PoCs a porobationary hotspot - must complete before it can transition to active mode. Note that this - count only increments if a probationary hotspot completes a PoC - successfully with a non-probationary hotspot. +To counter that and allow any hotspot to participate in PoC and have +consensus membership candidacy, we propose to introduce "Levels of +Trust". -TODO: - -- Add `probation` flag to gateway entries in the ledger. This would help - us identify which hotspots have full/limited PoC priviledges. - -- Add `added_at_block_height` to gateway entries in the ledger. This - would help identify how long to keep collecting witnesses for hotspots - in probation mode. Also helpful in general. Not quite sure what to set - this for existing hotspots when upgrading the ledger gateway entries. - -- Add `count_required_pocs` to gateway entries in the ledger. This is - the count of pocs which a probationary hotspot maintains every time it - successfully transmits a receipt with an active hotspot. - -- Modify existing ledger gateway entries to have `probation` flag set to - false. - -- When a new hotspot is added to the network, `probation` is set to - true. +# Detailed Explanation +[detailed-explanation]: #detailed-explanation -- Hotspots with `probation` set to true are prohibited from creating - `poc_request` transactions. +## Current Network Behavior -- Hotspots with `probation` set to true are allowed to be witnesses, - however, they do not earn any tokens for being witnesses. This allows - such hotspots to potentially witness helium manufactured hotspots - opening chances of eventually getting pathed through those. +In the current network onboarding a helium manufactured hotspot allows +full proof-of-coverage priviledges as soon as the hotspot syncs fully +with the blockchain, however this behavior is insufficient to ensure +that non-helium manufactured hotspots or DIY hotspots by individual +developers adhere to the consensus rules and also honestly provide RF +coverage. -- At each `poc_receipt`, after all the existing validity checks, if a - probationary hotspot successfully transmitted and received packets - from a non-probationary hotspot, the probationary hotspot gains +1 - `golden_poc` count in its ledger entry. Furthermore, as soon as the - total `golden_poc` count for the probationary hotspot reaches - `probabtion_required_pocs` count, it transitions to `active` mode by - setting the `probation` mode to false. +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, perhaps aptly +named "Levels of Trust". + +## Levels of Trust + +We introduce the concept of levels of trust, defining constraints, +relationships and progress of what it means for a hotspot to be in a +particular level and subsequently transition between levels. This is +akin to a character leveling up in a game, except the characters are +hotspots! + +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. + + ++--------------------------------------------------+ +| | +| | +| +--------------------------------------+ | +| | | | +| | | | +| | +--------------------------+ | | +| | | | | | +| | | | | | +| | | +--------------+ | | | +| | | | | | | | +| | | | Level I | | | | +| | | | | | | | +| | | +--------------+ | | | +| | | | | | +| | | Level II | | | +| | | | | | +| | +--------------------------+ | | +| | | | +| | Level III | | +| | | | +| +--------------------------------------+ | +| | +| Level IV | +| | ++--------------------------------------------------+ + + +### Level I + +- Any hotspot which aims to enter the helium network starts it + progressing at this level. The entry fee to gain access to this level + is burning data credits worth $X. Note that the market price of data + credits is not controlled by Helium. +- The only PoC priviledge a hotspot has in this level, is that it can + add other hotspots in its witness list, given that it is successfully + witnessing nearby occuring PoCs. +- A hotspot in this level can freely transmit data and earn HNT based + solely on transmitting network data. + +### Level 2 + +- The minimum criteria to enter this level require that a hotspot must + have witnessed X% of nearby occuring PoCs involving a Level 3 hotspot + over the course of Y days (or Z block equivalent). +- A hotspot can also be promoted to this level via a TBD governance + proposal. +- In addition to the Level I priviledges, this level also grants the + ability to participate in PoCs. + +### Level 3 + +- The minimum criteria to enter this level require that a hotspot must + have completed X successful PoC challenges involving other Level 3 + hotspots. +- In addition to the Level II priviledges, hotspots are granted the + ability to construct challenges. Constructing challenges is only + granted to hotspots which have been proven to be consistent and is + also the most reliable and regular way to gain a steady HNT influx, + therefore it's reserved as a priviledge for Level 3. + +### Level 4 + +- This is the final, most coveted level. +TBD....This is where hotspots gain consensus membership candidacy +priviledge. # Drawbacks @@ -202,11 +237,7 @@ TBD # Rationale and Alternatives [alternatives]: #rationale-and-alternatives -- Why the limitation for PoC-ing with helium hotspots? - -The helium hotspot solves the problem of seeding trust in a new network -by serving as a "trust authority". Furthermore, this authority can be -delegated to other 3rd party manufacturers. +TBD # Unresolved Questions [unresolved]: #unresolved-questions From b509656e3a3f9e55f180daf0d2bbd5accfa46bb7 Mon Sep 17 00:00:00 2001 From: Rahul Garg Date: Tue, 3 Mar 2020 16:35:05 -0800 Subject: [PATCH 06/14] Fix formatting --- 0009-non-helium-hotspots.md | 52 ++++++++++++++++++------------------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/0009-non-helium-hotspots.md b/0009-non-helium-hotspots.md index 7567033f1..7a90ce211 100644 --- a/0009-non-helium-hotspots.md +++ b/0009-non-helium-hotspots.md @@ -161,32 +161,32 @@ important takeaway here is that any higher level encompasses all the benefits and constraints of the lower levels. -+--------------------------------------------------+ -| | -| | -| +--------------------------------------+ | -| | | | -| | | | -| | +--------------------------+ | | -| | | | | | -| | | | | | -| | | +--------------+ | | | -| | | | | | | | -| | | | Level I | | | | -| | | | | | | | -| | | +--------------+ | | | -| | | | | | -| | | Level II | | | -| | | | | | -| | +--------------------------+ | | -| | | | -| | Level III | | -| | | | -| +--------------------------------------+ | -| | -| Level IV | -| | -+--------------------------------------------------+ + +--------------------------------------------------+ + | | + | | + | +--------------------------------------+ | + | | | | + | | | | + | | +--------------------------+ | | + | | | | | | + | | | | | | + | | | +--------------+ | | | + | | | | | | | | + | | | | Level I | | | | + | | | | | | | | + | | | +--------------+ | | | + | | | | | | + | | | Level II | | | + | | | | | | + | | +--------------------------+ | | + | | | | + | | Level III | | + | | | | + | +--------------------------------------+ | + | | + | Level IV | + | | + +--------------------------------------------------+ ### Level I From e6107631fa43f60272120368a97a28206528cb12 Mon Sep 17 00:00:00 2001 From: Amir Haleem Date: Fri, 6 Mar 2020 08:54:01 -0800 Subject: [PATCH 07/14] WIP updates --- 0009-non-helium-hotspots.md | 88 ++++++++++++------------------------- 1 file changed, 28 insertions(+), 60 deletions(-) diff --git a/0009-non-helium-hotspots.md b/0009-non-helium-hotspots.md index 7a90ce211..e745cbe2f 100644 --- a/0009-non-helium-hotspots.md +++ b/0009-non-helium-hotspots.md @@ -5,35 +5,37 @@ # Summary [summary]: #summary -Ensuring trust in the network when non-helium hotspots begin to -participate in the network. +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 -Helium's primary objective has always been to establish a decentralized -permissionless wireless network allowing anyone to be able to join and -provide RF Coverage with off-the-shelf hardware and open source -software. +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. -This goal poses some interesting challenges specifically regarding -network growth. Once we allow non-helium hotspots to be able to join the -network, we lose the ability to verifiably prove that any sub-network -created by such new hotspots truly exist physically since it's easily -possible for dishonest actors to fake geographic locations and radio -transmit/receive and claim that they are providing network coverage. +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 hotspot builders +- 3rd party Hotspot manufacturers +- DIY miners # Problem Deinifition [problem-definition]: #problem-definition -Consider the below network where hotspot A-F are non-helium manufactured -hotspots, with the lines representing RF visibility between hotspots. +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. +------+ | | @@ -63,18 +65,11 @@ hotspots, with the lines representing RF visibility between hotspots. | | +------+ -There exists no possible way to ensure that these hotspots do not form -part of a virtual network, since they can easily fake locations and RF -coverage and verify each other via the existing PoC mechanism. +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 have -the option of introducing a Helium (or authorized 3rd party reseller) -hotspot in the network and learning more about the behavior of each -hotspot. Only the real hotspots can successfully participate with -eventual PoC challenges involving the Helium hotspots. +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 helium hotspot, -consider the updated graph below: +Reimagining the above network with the introduction of a trusted Hotspot, consider the below: +------+ @@ -84,7 +79,7 @@ consider the updated graph below: +------+ | +--+---+ +------+ | | - | | | X +<--+Helium Hotspot + | | | X +<--+ Trusted Hotspot | F | +---------------+ | | | | +------+ +------+ | @@ -105,44 +100,17 @@ consider the updated graph below: | | +------+ -With this information, we can verifiably prove that A, B, D and E can -successfully complete PoC challenges which involve hotspot X. Since we -know that hotspot X is bound to be trustworthy by design and 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 the above explained scheme, we still need a way to be -able to allow hotspots not manufactured by Helium or authorized -manufacturers to not only participate in PoC but also be candidates for -consensus membership to build a truly decentralized permissionless -network. +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. -To counter that and allow any hotspot to participate in PoC and have -consensus membership candidacy, we propose to introduce "Levels of -Trust". +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. -# Detailed Explanation -[detailed-explanation]: #detailed-explanation +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 manufactured hotspot allows -full proof-of-coverage priviledges as soon as the hotspot syncs fully -with the blockchain, however this behavior is insufficient to ensure -that non-helium manufactured hotspots or DIY hotspots by individual -developers adhere to the consensus rules and also honestly provide RF -coverage. - -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. +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, perhaps aptly From dc1ee7d6f4998d795b14f48e327096062b1915f9 Mon Sep 17 00:00:00 2001 From: Rahul Garg Date: Thu, 12 Mar 2020 15:02:24 -0700 Subject: [PATCH 08/14] Rework levels of trust --- 0009-non-helium-hotspots.md | 196 +++++++++++++++++++----------------- 1 file changed, 102 insertions(+), 94 deletions(-) diff --git a/0009-non-helium-hotspots.md b/0009-non-helium-hotspots.md index e745cbe2f..ee2b404e1 100644 --- a/0009-non-helium-hotspots.md +++ b/0009-non-helium-hotspots.md @@ -5,14 +5,21 @@ # 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. +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. +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. +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 @@ -20,7 +27,7 @@ The goal of this proposal is to propose a set of measures that make it safe for - 3rd party Hotspot manufacturers - DIY miners -# Problem Deinifition +# Problem Definition [problem-definition]: #problem-definition There are a number of problems we hope to address with this proposal: @@ -35,7 +42,8 @@ There are a number of problems we hope to address with this proposal: ## The problem -Consider the below network where Hotspots A through F are of unknown origin, with the lines representing reported RF connectivity between hotspots. +Consider the below network where Hotspots A through F are of unknown origin, with the lines representing reported RF +connectivity between hotspots. +------+ | | @@ -65,13 +73,16 @@ Consider the below network where Hotspots A through F are of unknown origin, wit | | +------+ -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. +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. +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 +---------------+ @@ -100,102 +111,98 @@ Reimagining the above network with the introduction of a trusted Hotspot, consid | | +------+ -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. +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. +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". +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. +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, perhaps aptly -named "Levels of Trust". +To mitigate that, we propose a new model for establishing trust among hotspots and subsequently change how hotspots earn +HNT, perhaps aptly named "Levels of Trust". ## Levels of Trust -We introduce the concept of levels of trust, defining constraints, -relationships and progress of what it means for a hotspot to be in a -particular level and subsequently transition between levels. This is -akin to a character leveling up in a game, except the characters are -hotspots! - -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. - - - +--------------------------------------------------+ - | | - | | - | +--------------------------------------+ | - | | | | - | | | | - | | +--------------------------+ | | - | | | | | | - | | | | | | - | | | +--------------+ | | | - | | | | | | | | - | | | | Level I | | | | - | | | | | | | | - | | | +--------------+ | | | - | | | | | | - | | | Level II | | | - | | | | | | - | | +--------------------------+ | | - | | | | - | | Level III | | - | | | | - | +--------------------------------------+ | - | | - | Level IV | - | | - +--------------------------------------------------+ - - -### Level I - -- Any hotspot which aims to enter the helium network starts it - progressing at this level. The entry fee to gain access to this level - is burning data credits worth $X. Note that the market price of data - credits is not controlled by Helium. -- The only PoC priviledge a hotspot has in this level, is that it can - add other hotspots in its witness list, given that it is successfully - witnessing nearby occuring PoCs. -- A hotspot in this level can freely transmit data and earn HNT based - solely on transmitting network data. - -### Level 2 - -- The minimum criteria to enter this level require that a hotspot must - have witnessed X% of nearby occuring PoCs involving a Level 3 hotspot - over the course of Y days (or Z block equivalent). -- A hotspot can also be promoted to this level via a TBD governance - proposal. -- In addition to the Level I priviledges, this level also grants the - ability to participate in PoCs. - -### Level 3 - -- The minimum criteria to enter this level require that a hotspot must - have completed X successful PoC challenges involving other Level 3 - hotspots. -- In addition to the Level II priviledges, hotspots are granted the - ability to construct challenges. Constructing challenges is only - granted to hotspots which have been proven to be consistent and is - also the most reliable and regular way to gain a steady HNT influx, - therefore it's reserved as a priviledge for Level 3. - -### Level 4 - -- This is the final, most coveted level. -TBD....This is where hotspots gain consensus membership candidacy -priviledge. - +We introduce the concept of Levels of trust, defining constraints, relationships and progress of what it means for a +hotspot to be in a particular Level and subsequently transition between Levels. This is akin to a character Leveling up +in a game, except the characters are hotspots! + +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 +---------+ + | | | | + +-----------+ +-----------+ | +------------+ | +-----------+ + | | | | | | | | + | Level 1 +-------->+ Level 2 +-------->+ +-------->+ Level 4 | + | | | | | | | | + +-----------+ +-----------+ | +------------+ | +-----------+ + | | | | + +-------+ Level 3B +---------+ + | | + +------------+ + +### Level I: Getting on the network + +- 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: Asserting location on the network + +- 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 hotspots. +- A hotspot at Level 2 gains access to participate in PoC challenges (become a member in the PoC path). + +### Level 3: Gaining PoC challenge priviledges + +Level 3 is divided into two broad categories: + +#### Level 3A: Organic network growth + +- 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 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: On-chain governance + +- 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 candidacy + +- 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. # Drawbacks [drawbacks]: #drawbacks @@ -217,6 +224,7 @@ TBD TBD -# Success Metrics [success-metrics]: #success-metrics +# Success Metrics +[success-metrics]: #success-metrics TBD From 9834784ac12f574a37ab0a51f84fca364ab83d9c Mon Sep 17 00:00:00 2001 From: Rahul Garg Date: Thu, 12 Mar 2020 15:54:25 -0700 Subject: [PATCH 09/14] More wip --- 0009-non-helium-hotspots.md | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/0009-non-helium-hotspots.md b/0009-non-helium-hotspots.md index ee2b404e1..d32d1fd65 100644 --- a/0009-non-helium-hotspots.md +++ b/0009-non-helium-hotspots.md @@ -204,6 +204,12 @@ Level 3 is divided into two broad categories: 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. If the score for a hotspot drops by X for Y blocks, it will be demoted down to +one previous level. + # Drawbacks [drawbacks]: #drawbacks @@ -217,14 +223,17 @@ TBD # Unresolved Questions [unresolved]: #unresolved-questions -TBD +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 -TBD +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. # Success Metrics [success-metrics]: #success-metrics -TBD +NA From e5059a69114cc64a55f8c3d0f3c3d53bd464e085 Mon Sep 17 00:00:00 2001 From: Rahul Garg <3199183+vihu@users.noreply.github.com> Date: Fri, 13 Mar 2020 14:47:14 -0700 Subject: [PATCH 10/14] Update 0009-non-helium-hotspots.md Co-Authored-By: Evan Vigil-McClanahan --- 0009-non-helium-hotspots.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/0009-non-helium-hotspots.md b/0009-non-helium-hotspots.md index d32d1fd65..317b0866a 100644 --- a/0009-non-helium-hotspots.md +++ b/0009-non-helium-hotspots.md @@ -133,7 +133,7 @@ and has the required hardware to participate in proof-of-coverage challenges, as 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, perhaps aptly named "Levels of Trust". +HNT, named "Levels of Trust". ## Levels of Trust From e37df7fcca3db5fe2766ba93a2e6c97f0084d970 Mon Sep 17 00:00:00 2001 From: Rahul Garg <3199183+vihu@users.noreply.github.com> Date: Fri, 13 Mar 2020 14:48:14 -0700 Subject: [PATCH 11/14] Update 0009-non-helium-hotspots.md Co-Authored-By: Evan Vigil-McClanahan --- 0009-non-helium-hotspots.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/0009-non-helium-hotspots.md b/0009-non-helium-hotspots.md index 317b0866a..d66d2bc12 100644 --- a/0009-non-helium-hotspots.md +++ b/0009-non-helium-hotspots.md @@ -137,9 +137,6 @@ HNT, named "Levels of Trust". ## Levels of Trust -We introduce the concept of Levels of trust, defining constraints, relationships and progress of what it means for a -hotspot to be in a particular Level and subsequently transition between Levels. This is akin to a character Leveling up -in a game, except the characters are hotspots! 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). From aea1569ddb6b6ab8bd4a95b87e6f01f10dce7a10 Mon Sep 17 00:00:00 2001 From: Rahul Garg Date: Mon, 16 Mar 2020 10:24:38 -0700 Subject: [PATCH 12/14] Address review comment --- 0009-non-helium-hotspots.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/0009-non-helium-hotspots.md b/0009-non-helium-hotspots.md index d66d2bc12..bf1728aa4 100644 --- a/0009-non-helium-hotspots.md +++ b/0009-non-helium-hotspots.md @@ -169,7 +169,7 @@ encompasses all the benefits and constraints of the lower Levels (with a few exc - 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 hotspots. + * 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: Gaining PoC challenge priviledges @@ -180,7 +180,7 @@ Level 3 is divided into two broad categories: - 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 hotspots. + * 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. From 0b1017604d5a027521b18cf8766cab9015b2d9ea Mon Sep 17 00:00:00 2001 From: Rahul Garg Date: Mon, 16 Mar 2020 13:13:07 -0700 Subject: [PATCH 13/14] More details on lvl progression --- 0009-non-helium-hotspots.md | 26 +++++++++++++++++++------- 1 file changed, 19 insertions(+), 7 deletions(-) diff --git a/0009-non-helium-hotspots.md b/0009-non-helium-hotspots.md index bf1728aa4..ca7b9b715 100644 --- a/0009-non-helium-hotspots.md +++ b/0009-non-helium-hotspots.md @@ -137,23 +137,35 @@ 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 +---------+ + +------>+ Level 3A +---------+ | | | | +-----------+ +-----------+ | +------------+ | +-----------+ | | | | | | | | | Level 1 +-------->+ Level 2 +-------->+ +-------->+ Level 4 | | | | | | | | | - +-----------+ +-----------+ | +------------+ | +-----------+ - | | | | - +-------+ Level 3B +---------+ - | | - +------------+ + +-----+-----+ +-----------+ | +------------+ | +-----------+ + | | | | | + | +------>+ Level 3B +---------+ + | | | + | +------+-----+ + | ^ + | | + | | + +----------------------------------------------------+ + + +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: Getting on the network From 7b715a0614d4c529144e1d6c0083ee8b38c05b29 Mon Sep 17 00:00:00 2001 From: Rahul Garg Date: Mon, 23 Mar 2020 12:43:23 -0700 Subject: [PATCH 14/14] Address more review comments - Add level demotion - Add level names --- 0009-non-helium-hotspots.md | 78 ++++++++++++++++++++++++------------- 1 file changed, 51 insertions(+), 27 deletions(-) diff --git a/0009-non-helium-hotspots.md b/0009-non-helium-hotspots.md index ca7b9b715..ac0da3aa6 100644 --- a/0009-non-helium-hotspots.md +++ b/0009-non-helium-hotspots.md @@ -124,7 +124,7 @@ introduce "Levels of Trust". ## Current Network Behavior -In the current network, onboarding a Helium Inc manufactured Hotspot grants full Proof-of-Coverage priviledges. +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 @@ -141,23 +141,23 @@ Below is a visual representation of the aforementioned Levels, the most importan encompasses all the benefits and constraints of the lower Levels (with a few exceptions). - +------------+ - | | - +------>+ Level 3A +---------+ - | | | | - +-----------+ +-----------+ | +------------+ | +-----------+ - | | | | | | | | - | Level 1 +-------->+ Level 2 +-------->+ +-------->+ Level 4 | - | | | | | | | | - +-----+-----+ +-----------+ | +------------+ | +-----------+ - | | | | | - | +------>+ Level 3B +---------+ - | | | - | +------+-----+ - | ^ - | | - | | - +----------------------------------------------------+ + +-----------------------------+ + | | + +---->+ 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: @@ -167,7 +167,7 @@ Before we get into the details and constraints of each level, we need to set som * 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: Getting on the network +### 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. @@ -176,7 +176,7 @@ Before we get into the details and constraints of each level, we need to set som 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: Asserting location on the network +### 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. @@ -184,11 +184,11 @@ Before we get into the details and constraints of each level, we need to set som * 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: Gaining PoC challenge priviledges +### Level 3: Network Challenger Level 3 is divided into two broad categories: -#### Level 3A: Organic network growth +#### 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. @@ -197,7 +197,7 @@ Level 3 is divided into two broad categories: 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: On-chain governance +#### 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. @@ -205,7 +205,7 @@ Level 3 is divided into two broad categories: 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 candidacy +### 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. @@ -216,8 +216,29 @@ Level 3 is divided into two broad categories: ## 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. If the score for a hotspot drops by X for Y blocks, it will be demoted down to -one previous 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 @@ -239,9 +260,12 @@ TBD # Deployment Impact [deployment-impact]: #deployment-impact -We need to ensure we transition the existing hotspots on the network in a meaningful way. Whether every single existing +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