From 01e926483eac2eafd5952813ed7feef83da9ed1e Mon Sep 17 00:00:00 2001 From: Andrew Thompson Date: Thu, 10 Feb 2022 10:39:52 -0800 Subject: [PATCH 1/8] Add HIP for validator challenges --- xxxx-validator-challenges.md | 304 +++++++++++++++++++++++++++++++++++ 1 file changed, 304 insertions(+) create mode 100644 xxxx-validator-challenges.md diff --git a/xxxx-validator-challenges.md b/xxxx-validator-challenges.md new file mode 100644 index 000000000..07e0b18cc --- /dev/null +++ b/xxxx-validator-challenges.md @@ -0,0 +1,304 @@ +# Validator Challenges + +- Author(s): @vagabond, @andymck +- Start Date: 2022-02-03 +- Category: Technical +- Original HIP PR: +- Tracking Issue: + +# Summary +[summary]: #summary + +This HIP proposes a change to how PoC challenges are generated and submitted to +the chain to allow for further network scalability and to lower the hardware +complexity/cost of Hotspots. + +# Motivation +[motivation]: #motivation + +Originally Hotspots were the only kind of entity on the network, they did the +block production, the challenges/witnessing, etc. With the switch to validators +we moved beyond that model for block production, but we still have significant +complexity in challenges as a result of the old design and constraints. + +This complexity has become a significant pain point, Hotspots must now keep up +with a chain that is produced on significantly more powerful hardware and they +must contend with an enormous peer to peer (p2p) network to route challenges and +witness reports around. The global chip shortages have also made it harder to +source capable hardware for building Hotspots that can meet these requirements. + +To address these issues Helium has been working on design and implementation +of an alternative challenge mechanism we call Validator Challenges. In brief, +Validator Challenges move the role of generating challenges to the consensus +group. This not only allows us to free Hotspots from the burden of following the +chain but it also moves the entities doing the challenges to machines with much +more stable and predictable networking which reduces the likihood of +connectivity failures. Hotspots can use Validators to learn about chain updates, +including if they're being challenged. + +# Stakeholders +[stakeholders]: #stakeholders + +* Who is affected by this HIP? + +Users running Hotspots or Validators. + +* How are we soliciting feedback on this HIP from these stakeholders? Note that + they may not be watching the HIPs repository or even aren't directly active in + the Helium Community Slack channels. + +# Detailed Explanation +[detailed-explanation]: #detailed-explanation + +## Description of Current Implementation + +First it is probably useful to recapitulate the current challenge process. First +refer to the Detailed Explanation section of the [H3Dex Targeting HIP](link when +merged) which describes how a challenge is constructed and submitted to the +chain. + +Once the PoC request has appeared on chain and the Challengee has been selected +the Hotspot attempts to connect to it over p2p (failure point #1). If successful +it sends the challengee the data to transmit. The Challengee then consults its +ledger to see if the PoC is active (failure point #2 if the Challengee is not +synced). The Challengee then transmits the packet and sends a receipt to the +Challengeer over the same connection the Challenger dialed on (this avoids +another potential p2p failure). Any Hotspots observing the challenge packet then +consult their ledger to see if they can resolve the challenge to a Challenger +(failure point #3 if the witness is not synced). If the challenge can be +resolved to a Challenger then the Witness attempts to dial that Challenger over +p2p (failure point #4). Once the Challenger has decided enough blocks have +passed it submits the `poc_receipt` transaction to the chain to report on the +information gathered (if any) (failure point #5 if the Challenger is lagging +behind the chain and takes so long to submit the receipt that the PoC has +expired). + +So, as can be seen from above there are a number of failure points in this +process. These failures are all related to the speed/size of the chain and the +size of the p2p network. When the network was smaller this was much less of an +issue, but with over 500,000 Hotspots on the network now and larger blocks these +failure points are becoming more and more common. + +An important aspect of this system is that the actual challenge Entropy is kept +secret until the receipt transaction is published. This requires Hotspots to +observe the actual data from the Challenger to correctly respond to the +challenge and prevents poisoning attacks. However Hotspots can verify the +challenge information against the chain information once they see it. + + +### Light Gateways & GRPC + +Light gateways will maintain a durable GRPC connection to a validator. The +target validator could be random or specified. Via this durable connection, +light gateways will be streamed chain related data, events and notifications. + +Light gateways can also connect to additional validators as required. Such +connections will be ephemeral in nature and typically for unary requests. + +All message types sent to a light gateway from a validator will be wrapped in a +top level msg of the type 'gateway_resp_v1' ( see proto link below ). This msg +type includes a signed payload of the msg and in addition the block height at +which the msg contents were valid. Together these two fields serve as an +attestation on behalf of the sending validator. + +### PoC Challenge Creation and the Consensus Group + +Each block, in addition to metadata (BBA seen, timestamps, etc) and +transactions, each member of the consensus group will generate a set of +ephemeral key pairs. A hash of the public keys will be included in the block +proposals, whilst the private key will be saved to state on the generating +validator. Each consensus group member will propose ChallengeRate / (((N-1)/3) +* 2 ) to ensure if only 2f+1 nodes participate in the block we are able to run +ChallengeRate challenges per block. + +The set of agreed on public keys hashes will then be deterministically truncated +to ChallengeRate and form part of the block metadata. + +Upon handling a block, each CG member will inspect the public keys in the block +and identify any of their own keys and for each initiate a new PoC. In running +the PoC the public key hash will be used along with the block hash to generate +entropy via which a H3 region will be selected. Entropy from a combination of +the associated private key hash and the block hash will then be used to identify +the target within the region and subsequently the challenge itself will be +generated. The region, target and challenge will be persisted to disk. + +### Validators & Light Gateway Communication + +All validators, whether they are in consensus or not, as part of handling each +block will pull the public key hashes from the block metadata and together with +the block hash generate the same entropy as the CG members to identify the +target region. The validators will then pull a list of all gateways within that +region and send each gateway in that region connected to them a notification msg +of type 'poc_challenge_notification_resp_v1' informing them of a challenge +within their region. The payload provides the necessary routing data ( pubkey +and IP) to enable the light gateway to connect to the challenging validator and +in addition includes the onion key hash of the challenge. + +All gateways upon receipt of a challenge notification will respond with a unary +GRPC request of type 'gateway_poc_check_challenge_target_req_v1' to the +challenging CG member to check if they are the target. + +The request will be signed by the challengee and also include the onion key hash +it received from the validator. The challenger will verify the signature of the +requesting gateway and if it is the target return it the onion payload. + +Upon receipt of the challenge payload the challengee will then transmit the +challenge packet as normal. + +### Observing Gateways and Witnessing + +Any light gateway hearing the transmitted packet will serve as witnesses as +normal. However rather that submit their witness report over libp2p they will +now submit over gRPC. The witness can lookup the challenging validator by the +hash of the PoC packet and deliver its witness report to it. + +The challenger, after the PoC interval expires, will subsequently create a +'blockchain_txn_poc_receipts_v2' txn using the received receipts and witness +reports and publish to the chain as normal thereby completing the PoC challenge. + +### Attestation and slashing enablement + +As outlined above all messages which originate from a validator and sent to a +light gateway will be attested. This includes not just the messages in this +document but all messages from a validator containing an assertion about the +chain. + +If a light gateway receives a message from a validator and needs to act on this +for example to contact a consensus group member, the light gateway will include +the attestation in its request to that consensus group member. The attestation +provides evidence on behalf of the light gateway to the consensus group member +that it received the instruction and or data that resulted in the said action. + +If the consensus group member determines the instruction/data was spurious in +nature, unsolicited or otherwise untrustworthy then the member can decide to act +on this which could include for example publishing the verifiably false +assertion, with the malicious validator's attestation, to the chain to allow for +slashing of the validator's stake. + +Similarly light gateways themselves, if they determine the message received from a +validator is untrustworthy, can build their own untrusted list of validators. + +[Proto +definitions](https://github.com/helium/proto/blob/andymck/poc-grpc-msg-defs-WIP/src/service/gateway.proto#L101) + +[Message Sequence +Diagram](https://docs.google.com/drawings/d/1eVTK89ob66vlcEwwoVNi0BFaCEaU2DYki8778LIRWpA/edit) + +- Introduce and explain new concepts. + +- It should be reasonably clear how the proposal would be implemented. + +- Provide representative examples that show how this proposal would be commonly + used. + +- Corner cases should be dissected by example. + +# Drawbacks +[drawbacks]: #drawbacks + +- Why should we *not* do this? + +This is a fairly extensive change to the network and may be disruptive if not +executed well. This also somewhat disturbs the economics of the system by +removing the challenger rewards. + +# Rationale and Alternatives +[alternatives]: #rationale-and-alternatives + +This is your chance to discuss your proposal in the context of the whole design +space. This is probably the most important section! + +- Why is this design the best in the space of possible designs? + +Simpler designs would include retaining the hotspot doing the challenge, just +via information submitted/received via a validator. This would involve less +change but it would not remove the reliance on p2p routing. + +Another design would be to have a separate group do the challenges, and indeed +that may be a further evolution of this design, but was deemed too complex as an +initial design. This would also remove the ability to piggy back challenges onto +existing block production (which will massively lower the chain's transaction +rate). + +Other designs include proposals like "self beaconing" but those remove a lot of +the separation of concerns that make collusion harder and would be significantly +weaker. Such a design also would not allow for further enhancements to how PoC +packets are transmitted. + +- What other designs have been considered and what is the rationale for not + choosing them? + +- What is the impact of not doing this? + +# Unresolved Questions +[unresolved]: #unresolved-questions + +- What parts of the design do you expect to resolve through the HIP process + before this gets merged? + +What to do with the challenger rewards. + +- What parts of the design do you expect to resolve through the implementation + of this feature? + +- 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? + +This plan *does* consider and allow for validator slashing to the extent the +data payloads exchanged between the light gateways, the validators and the +consensus group will include data points that can enable a slashing mechanism to +be added at a later point. It does not however propose the slashing +implementation itself, that will be done in a future HIP. + +Additionally this plan does allow for an establishment of tracking which +validators Hotspots are using for their source of chain information but it does +not propose what to use that information for, that will be done in a future HIP + +Finally this plan also allows for a change to how challenges work and would +allow for multiple challengees to be involved in transmitting packets to both +reduce the scope for collusion between a challengee and witnesses but also +obtain better positional information as a result of the challenge. + +# Deployment Impact +[deployment-impact]: #deployment-impact + +Describe how this design will be deployed and any potential impact it may have on +current users of this project. + +- How will current users be impacted? + +Overall users should see more reliable challenge behaviour, less data use on the +hotspot (which makes cellular/satellite backhaul hotspots more feasible) and +more or less immediate onboarding of new hotspots (no need to sync the chain or +load a snapshot). + +Hardware costs for hotspots will also be able to go down as the hardware +requirements can be relaxed to reflect the lower demands of the new challenge +model. + +- How will existing documentation/knowlegebase need to be supported? + +Documentation will need to be updated to explain the new model, this HIP can +serve as a reference. + +- Is this backwards compatible? + +The activation would be done via a chain var which would switch the system over +to this new model, before that happens we need the new code to be merged, +deployed to the fleet (routers, hotspots, validators, exchanges) and this HIP +needs to be ratified. + + +# Success Metrics +[success-metrics]: #success-metrics + +What metrics can be used to measure the success of this design? + +- What should we measure to prove a performance increase? + +- What should we measure to prove an improvement in stability? + +- What should we measure to prove a reduction in complexity? + +- What should we measure to prove an acceptance of this by it's users? From 98b5551ae75b80167aefb05564f66862931adcfd Mon Sep 17 00:00:00 2001 From: Abhay Kumar Date: Fri, 11 Feb 2022 13:32:50 -0800 Subject: [PATCH 2/8] Validator Challenges (#361) --- xxxx-validator-challenges.md | 338 ++++++++++++++++------------------- 1 file changed, 158 insertions(+), 180 deletions(-) diff --git a/xxxx-validator-challenges.md b/xxxx-validator-challenges.md index 07e0b18cc..f88371a45 100644 --- a/xxxx-validator-challenges.md +++ b/xxxx-validator-challenges.md @@ -1,25 +1,30 @@ # Validator Challenges -- Author(s): @vagabond, @andymck +- Author(s): [@Vagabond](https://github.com/Vagabond), + [@andymck](https://github.com/andymck), [@abhay](https://github.com/abhay) - Start Date: 2022-02-03 - Category: Technical - Original HIP PR: - Tracking Issue: +- Status: Draft # Summary [summary]: #summary -This HIP proposes a change to how PoC challenges are generated and submitted to -the chain to allow for further network scalability and to lower the hardware -complexity/cost of Hotspots. +This HIP proposes a change to how Proof-of-Coverage (PoC) challenges are +generated and submitted to the Helium blockchain to allow for further network +scalability and to lower the hardware complexity/cost of Hotspots. Specifically, +it moves the responsibility of PoC challenge creation to Validators and +consequently, moves economic reward to this group as well. # Motivation [motivation]: #motivation -Originally Hotspots were the only kind of entity on the network, they did the -block production, the challenges/witnessing, etc. With the switch to validators -we moved beyond that model for block production, but we still have significant -complexity in challenges as a result of the old design and constraints. +Originally Hotspots were the only kind of entity on the network; they were +responsible for block production, challenges/witnessing, etc. With the switch to +Validators we moved beyond that model for block production, but we still have +significant computational overhead and complexity on Hotspots as a result of the +old design and constraints of Proof-of-Coverage. This complexity has become a significant pain point, Hotspots must now keep up with a chain that is produced on significantly more powerful hardware and they @@ -27,57 +32,51 @@ must contend with an enormous peer to peer (p2p) network to route challenges and witness reports around. The global chip shortages have also made it harder to source capable hardware for building Hotspots that can meet these requirements. -To address these issues Helium has been working on design and implementation -of an alternative challenge mechanism we call Validator Challenges. In brief, -Validator Challenges move the role of generating challenges to the consensus -group. This not only allows us to free Hotspots from the burden of following the -chain but it also moves the entities doing the challenges to machines with much -more stable and predictable networking which reduces the likihood of -connectivity failures. Hotspots can use Validators to learn about chain updates, -including if they're being challenged. +To address these issues the core developers have been working on design and +implementation of an alternative challenge mechanism we call Validator +Challenges. In brief, Validator Challenges move the role of generating +challenges to the Consensus Group. This not only allows us to free Hotspots from +the burden of following the chain but it also moves the entities doing the +challenges to machines with much more stable and predictable networking which +reduces the likihood of connectivity failures. Hotspots can become clients of +Validators to learn about chain updates, including if they're being challenged. # Stakeholders [stakeholders]: #stakeholders -* Who is affected by this HIP? - Users running Hotspots or Validators. -* How are we soliciting feedback on this HIP from these stakeholders? Note that - they may not be watching the HIPs repository or even aren't directly active in - the Helium Community Slack channels. - # Detailed Explanation [detailed-explanation]: #detailed-explanation ## Description of Current Implementation First it is probably useful to recapitulate the current challenge process. First -refer to the Detailed Explanation section of the [H3Dex Targeting HIP](link when -merged) which describes how a challenge is constructed and submitted to the -chain. - -Once the PoC request has appeared on chain and the Challengee has been selected -the Hotspot attempts to connect to it over p2p (failure point #1). If successful -it sends the challengee the data to transmit. The Challengee then consults its -ledger to see if the PoC is active (failure point #2 if the Challengee is not -synced). The Challengee then transmits the packet and sends a receipt to the -Challengeer over the same connection the Challenger dialed on (this avoids -another potential p2p failure). Any Hotspots observing the challenge packet then -consult their ledger to see if they can resolve the challenge to a Challenger -(failure point #3 if the witness is not synced). If the challenge can be -resolved to a Challenger then the Witness attempts to dial that Challenger over -p2p (failure point #4). Once the Challenger has decided enough blocks have -passed it submits the `poc_receipt` transaction to the chain to report on the -information gathered (if any) (failure point #5 if the Challenger is lagging -behind the chain and takes so long to submit the receipt that the PoC has -expired). - -So, as can be seen from above there are a number of failure points in this -process. These failures are all related to the speed/size of the chain and the -size of the p2p network. When the network was smaller this was much less of an -issue, but with over 500,000 Hotspots on the network now and larger blocks these -failure points are becoming more and more common. +refer to the Detailed Explanation section of [HIP53: H3Dex Targeting][hip53] +which describes how a challenge is constructed and submitted to the chain. + +Once the PoC request has appeared on chain and the Challengee has been selected, +the Hotspot attempts to connect to it over p2p (potential failure point #1). If +successful it sends the challengee the data to transmit. The Challengee then +consults its ledger to see if the PoC is active. This is another potential +failure point (#2) if the Challengee is not synced. The Challengee then +transmits the packet and sends a receipt to the Challenger over the same +connection the Challenger dialled on. Tthis avoids another potential p2p failure. +Any Hotspots observing the challenge packet then consults their ledger to see if +they can resolve the challenge to a Challenger. This is another potential +failure point (#3) if the witness is not in sync with the chain. If the +challenge can be resolved to a Challenger then the Witness attempts to dial that +Challenger over p2p, another potential failure point (#4). Once the Challenger +has decided enough blocks have passed it submits the `poc_receipt` transaction +to the chain to report on the information gathered (if any). The final, +potential failure point (#5) is if the Challenger is lagging behind the chain +and takes so long to submit the receipt that the PoC has expired. + +So, as can be seen from above there are a number of potential failure points in +this process. These failures are all related to the speed/size of the chain and +the size of the p2p network. When the network was smaller this was much less of +an issue, but with over 500,000 Hotspots on the network now and larger blocks, +these failure points are becoming more and more common. An important aspect of this system is that the actual challenge Entropy is kept secret until the receipt transaction is published. This requires Hotspots to @@ -86,36 +85,44 @@ challenge and prevents poisoning attacks. However Hotspots can verify the challenge information against the chain information once they see it. -### Light Gateways & GRPC +### Light Hotspots & GRPC -Light gateways will maintain a durable GRPC connection to a validator. The -target validator could be random or specified. Via this durable connection, -light gateways will be streamed chain related data, events and notifications. +Light Hotspots will maintain a durable GRPC connection to a Validator. The +target Validator could be random or specified. Via this durable connection, +Light Hotspots will be streamed chain related data, events and notifications. -Light gateways can also connect to additional validators as required. Such +Light Hotspots can also connect to additional Validators as required. Such connections will be ephemeral in nature and typically for unary requests. -All message types sent to a light gateway from a validator will be wrapped in a -top level msg of the type 'gateway_resp_v1' ( see proto link below ). This msg -type includes a signed payload of the msg and in addition the block height at -which the msg contents were valid. Together these two fields serve as an -attestation on behalf of the sending validator. +All message types sent to a Light Hotspot from a Validator will be wrapped in a +top level message of the type `gateway_resp_v1` (Protocol buffer schema provied +below). This message type includes metadata which serves as an attestation on +behalf of the sending Validator. The attestation data includes: + +- Signed payload of the message +- Block age, height, and time when the payload was signed ### PoC Challenge Creation and the Consensus Group -Each block, in addition to metadata (BBA seen, timestamps, etc) and -transactions, each member of the consensus group will generate a set of -ephemeral key pairs. A hash of the public keys will be included in the block -proposals, whilst the private key will be saved to state on the generating -validator. Each consensus group member will propose ChallengeRate / (((N-1)/3) -* 2 ) to ensure if only 2f+1 nodes participate in the block we are able to run -ChallengeRate challenges per block. +Today each block on the chain includes metadata (BBA seen, timestamps, etc) and +transactions. With this change, each member of the Consensus Group will generate +a set of ephemeral key pairs. A hash of the public keys will be included in the +block proposals, whilst the private key will be saved to state on the generating +Validator. We propose a fixed `poc_challenge_rate` parameter to be added to the +chain that defines the target number of challenges per block. Each Consensus +Group member will propose a certain number of keys in order to ensure that we +will meet this target. Assuming there are a minimum of `2f+1` nodes +participating in a block, we are able to reach `poc_challenge_rate` if each +Validator in the Group generates enough challenges to fulfill this formula: + +![\frac{\text{PoC Challenge Rate}}{\frac{N-1}{3}* 2}][poc-challenge-rate] The set of agreed on public keys hashes will then be deterministically truncated -to ChallengeRate and form part of the block metadata. +(in case there are more than `2f+1` participating to `poc_challenge_rate` and +form part of the block metadata. Upon handling a block, each CG member will inspect the public keys in the block -and identify any of their own keys and for each initiate a new PoC. In running +and identify any of their own keys and for each initiate a new PoC. In running the PoC the public key hash will be used along with the block hash to generate entropy via which a H3 region will be selected. Entropy from a combination of the associated private key hash and the block hash will then be used to identify @@ -124,94 +131,83 @@ generated. The region, target and challenge will be persisted to disk. ### Validators & Light Gateway Communication -All validators, whether they are in consensus or not, as part of handling each -block will pull the public key hashes from the block metadata and together with -the block hash generate the same entropy as the CG members to identify the -target region. The validators will then pull a list of all gateways within that -region and send each gateway in that region connected to them a notification msg -of type 'poc_challenge_notification_resp_v1' informing them of a challenge -within their region. The payload provides the necessary routing data ( pubkey -and IP) to enable the light gateway to connect to the challenging validator and -in addition includes the onion key hash of the challenge. +All Validators, whether they are in consensus or not, sync blocks normally to +keep up with the blockchain. As a part of normal processing, they will pull the +public key hashes from the block metadata and, with the block hash, are able to +generate the same entropy as the Consensus Group members to identify the target +h3 region. The Validators will then pull a list of all Hotspots within that +region and send each gateway connected to them a notification message informing +them of a challenge within their region. The notification provides the onion key +hash of the Challenge and, more importantly, the necessary routing data (public +key and IP) to enable the Light Hotspot to connect to the challenging Validator. -All gateways upon receipt of a challenge notification will respond with a unary -GRPC request of type 'gateway_poc_check_challenge_target_req_v1' to the -challenging CG member to check if they are the target. +All gateways upon receipt of a challenge notification will send a request over +GRPC to the challenging Validator to check if they are the target. The request will be signed by the challengee and also include the onion key hash -it received from the validator. The challenger will verify the signature of the -requesting gateway and if it is the target return it the onion payload. +it received from their Validator. The challenger will verify the signature of +the requesting gateway and if it is indeed the target, an challenge onion +payload will be returned. -Upon receipt of the challenge payload the challengee will then transmit the -challenge packet as normal. +Upon receipt of the challenge payload the Challengee will then transmit the +challenge packet as described above and as currently in the Helium network. ### Observing Gateways and Witnessing -Any light gateway hearing the transmitted packet will serve as witnesses as -normal. However rather that submit their witness report over libp2p they will -now submit over gRPC. The witness can lookup the challenging validator by the -hash of the PoC packet and deliver its witness report to it. - -The challenger, after the PoC interval expires, will subsequently create a -'blockchain_txn_poc_receipts_v2' txn using the received receipts and witness -reports and publish to the chain as normal thereby completing the PoC challenge. - -### Attestation and slashing enablement - -As outlined above all messages which originate from a validator and sent to a -light gateway will be attested. This includes not just the messages in this -document but all messages from a validator containing an assertion about the -chain. - -If a light gateway receives a message from a validator and needs to act on this -for example to contact a consensus group member, the light gateway will include -the attestation in its request to that consensus group member. The attestation -provides evidence on behalf of the light gateway to the consensus group member -that it received the instruction and or data that resulted in the said action. - -If the consensus group member determines the instruction/data was spurious in +Any Light Hotspot hearing the transmitted packet will serve as a Witness as we +have today on the Helium network. However rather that submit their witness +report over libp2p they will now submit over gRPC. The witness uses the +Validator(s) they are connected to as a client to lookup the challenging +Validator by the hash of the PoC packet. The Light Hotspot then uses this +routing information to directly submit the witness receipt to the Challenger. +Please see the Attestation section below on how the Validator providing data to +Light Hotspots can be verified. + +The Challenger, after the `poc_timeout` number of blocks, will create a +`blockchain_txn_poc_receipts_v2` txn using received receipts and witness reports +and publish it to the chain thereby completing the PoC challenge. + +### Attestation and Slashing enablement + +All messages which originate from a Validator and sent to a Light Hotspot will +be attested. This includes not just the messages in this document but all +messages from a validator containing an assertion about the chain. + +If a Light Hotspot receives a message from a Validator and needs to act on this, +for example to contact a Consensus Group member to submit receipts, the Light +Hotspot will include the attestation in its request to that Consensus Group +member. The attestation provides evidence on behalf of the Light Hotspot to the +Consensus Group member that it received the instruction and/or data that +resulted in the said action. + +If the Consensus Group member determines the instruction/data was spurious in nature, unsolicited or otherwise untrustworthy then the member can decide to act -on this which could include for example publishing the verifiably false -assertion, with the malicious validator's attestation, to the chain to allow for +on this which could include, for example publishing the verifiably false +assertion, with the malicious Validator's attestation, to the chain to allow for slashing of the validator's stake. -Similarly light gateways themselves, if they determine the message received from a -validator is untrustworthy, can build their own untrusted list of validators. - -[Proto -definitions](https://github.com/helium/proto/blob/andymck/poc-grpc-msg-defs-WIP/src/service/gateway.proto#L101) - -[Message Sequence -Diagram](https://docs.google.com/drawings/d/1eVTK89ob66vlcEwwoVNi0BFaCEaU2DYki8778LIRWpA/edit) - -- Introduce and explain new concepts. +Similarly Light Hotspots themselves, if they determine the message received from +a Validator is untrustworthy, can build their own untrusted list of Validators. -- It should be reasonably clear how the proposal would be implemented. - -- Provide representative examples that show how this proposal would be commonly - used. - -- Corner cases should be dissected by example. +* [Proto definitions][proto] +* [Message Sequence Diagram][message-sequence] # Drawbacks [drawbacks]: #drawbacks -- Why should we *not* do this? - This is a fairly extensive change to the network and may be disruptive if not executed well. This also somewhat disturbs the economics of the system by -removing the challenger rewards. +removing the Challenger rewards (currently 0.95% of rewards) from Hotspots and +giving it to Validators. By moving PoC Challenges away from the Hotspots, we +also lose a potential "liveness" check that can be used to determine whether or +not a Hotspot is online and instead we must rely solely on Data Transfer and PoC +activity. # Rationale and Alternatives [alternatives]: #rationale-and-alternatives -This is your chance to discuss your proposal in the context of the whole design -space. This is probably the most important section! - -- Why is this design the best in the space of possible designs? - -Simpler designs would include retaining the hotspot doing the challenge, just -via information submitted/received via a validator. This would involve less +Simpler designs would include retaining the Hotspot doing the challenge, just +via information submitted/received via a Validator. This would involve less change but it would not remove the reliance on p2p routing. Another design would be to have a separate group do the challenges, and indeed @@ -225,55 +221,46 @@ the separation of concerns that make collusion harder and would be significantly weaker. Such a design also would not allow for further enhancements to how PoC packets are transmitted. -- What other designs have been considered and what is the rationale for not - choosing them? - -- What is the impact of not doing this? - # Unresolved Questions [unresolved]: #unresolved-questions -- What parts of the design do you expect to resolve through the HIP process - before this gets merged? - -What to do with the challenger rewards. - -- What parts of the design do you expect to resolve through the implementation - of this feature? - -- 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? +We initially propose that the Challenger reward moves to the Validators +initiating the challenge. Although this is a relatively small change, as it +constitutes only 0.95% of all rewards today and decreases over time through the +yearly token emissions adjustments, we still believe it's important to note and +debate. Validators will be taking on more responsibility of the network and more +work that simply cannot scale on Hotspot hardware so our proposal makes an +opinionated choice. This plan *does* consider and allow for validator slashing to the extent the -data payloads exchanged between the light gateways, the validators and the -consensus group will include data points that can enable a slashing mechanism to +data payloads exchanged between the Light Hotspots, the Validators and the +Consensus Group will include data points that can enable a slashing mechanism to be added at a later point. It does not however propose the slashing implementation itself, that will be done in a future HIP. Additionally this plan does allow for an establishment of tracking which -validators Hotspots are using for their source of chain information but it does -not propose what to use that information for, that will be done in a future HIP +Validators that Hotspots are using for their source of chain information but it +does not propose what to use that information for, that could be used in a +future improvement. Finally this plan also allows for a change to how challenges work and would allow for multiple challengees to be involved in transmitting packets to both reduce the scope for collusion between a challengee and witnesses but also -obtain better positional information as a result of the challenge. +obtain better positional information as a result of the challenge. This has been +described in other forums as "Region" or "Multi-Hotspot" Challenges. This is out +of scope for this HIP but we imagine future work in this direction could be +possible. # Deployment Impact [deployment-impact]: #deployment-impact -Describe how this design will be deployed and any potential impact it may have on -current users of this project. - -- How will current users be impacted? - Overall users should see more reliable challenge behaviour, less data use on the -hotspot (which makes cellular/satellite backhaul hotspots more feasible) and -more or less immediate onboarding of new hotspots (no need to sync the chain or -load a snapshot). +Hotspot (which makes cellular/satellite backhaul hotspots more feasible) and +more or less immediate onboarding of new Hotspots (no need to sync the chain or +load a snapshot in order to participate in PoC or transfer Data on the Helium +Network). -Hardware costs for hotspots will also be able to go down as the hardware +Hardware costs for hotspots could potentially go down as the hardware requirements can be relaxed to reflect the lower demands of the new challenge model. @@ -284,21 +271,12 @@ serve as a reference. - Is this backwards compatible? -The activation would be done via a chain var which would switch the system over -to this new model, before that happens we need the new code to be merged, -deployed to the fleet (routers, hotspots, validators, exchanges) and this HIP -needs to be ratified. - - -# Success Metrics -[success-metrics]: #success-metrics - -What metrics can be used to measure the success of this design? - -- What should we measure to prove a performance increase? - -- What should we measure to prove an improvement in stability? - -- What should we measure to prove a reduction in complexity? +The activation would be done via a set of chain variable changes which would +switch the system over to this new model, before that happens we need the new +code to be merged, deployed to the fleet (routers, hotspots, validators, node +users) and this HIP needs to be ratified. -- What should we measure to prove an acceptance of this by it's users? +[hip53]: https://github.com/helium/HIP/blob/main/0054-h3dex-targeting.md +[proto]: https://github.com/helium/proto/blob/andymck/poc-grpc-msg-defs-WIP/src/service/gateway.proto#L101 +[message-sequence]: https://docs.google.com/drawings/d/1eVTK89ob66vlcEwwoVNi0BFaCEaU2DYki8778LIRWpA/edit +[poc-challenge-rate]: https://user-images.githubusercontent.com/75/153673071-550eb970-4ab6-44e0-b9fc-e9b04e1b4dad.png From e7309b0cb6e779082a59232047a515285155a92c Mon Sep 17 00:00:00 2001 From: Abhay Kumar Date: Fri, 11 Feb 2022 15:19:33 -0800 Subject: [PATCH 3/8] Final edits --- xxxx-validator-challenges.md | 345 +++++++++++++++++++---------------- 1 file changed, 191 insertions(+), 154 deletions(-) diff --git a/xxxx-validator-challenges.md b/xxxx-validator-challenges.md index f88371a45..d4edebea4 100644 --- a/xxxx-validator-challenges.md +++ b/xxxx-validator-challenges.md @@ -11,242 +11,277 @@ # Summary [summary]: #summary -This HIP proposes a change to how Proof-of-Coverage (PoC) challenges are +This HIP proposes a change to how Proof-of-Coverage (PoC) Challenges are generated and submitted to the Helium blockchain to allow for further network scalability and to lower the hardware complexity/cost of Hotspots. Specifically, -it moves the responsibility of PoC challenge creation to Validators and -consequently, moves economic reward to this group as well. +it moves the responsibility of PoC Challenge creation to Validators and +consequently proposes moving the economic reward for creating Challenges to this +group as well. # Motivation [motivation]: #motivation Originally Hotspots were the only kind of entity on the network; they were -responsible for block production, challenges/witnessing, etc. With the switch to +responsible for block production, Challenges/Witnesses, etc. With the switch to Validators we moved beyond that model for block production, but we still have significant computational overhead and complexity on Hotspots as a result of the old design and constraints of Proof-of-Coverage. This complexity has become a significant pain point, Hotspots must now keep up -with a chain that is produced on significantly more powerful hardware and they -must contend with an enormous peer to peer (p2p) network to route challenges and -witness reports around. The global chip shortages have also made it harder to -source capable hardware for building Hotspots that can meet these requirements. +with a blockchain that is produced on significantly more powerful hardware and +they must contend with an enormous peer-to-peer (p2p) network to route +Challenges and witness reports. The global chip shortage have also made it +harder to source capable hardware for building Hotspots that can meet these +requirements. To address these issues the core developers have been working on design and -implementation of an alternative challenge mechanism we call Validator +implementation of an alternative PoC Challenge mechanism we call Validator Challenges. In brief, Validator Challenges move the role of generating -challenges to the Consensus Group. This not only allows us to free Hotspots from -the burden of following the chain but it also moves the entities doing the -challenges to machines with much more stable and predictable networking which +Challenges to the Consensus Group. This not only allows us to free Hotspots from +the burden of following the blockchain but it also moves the entities initiating +Challenges to machines with much more stable and predictable networking which reduces the likihood of connectivity failures. Hotspots can become clients of -Validators to learn about chain updates, including if they're being challenged. +Validators to learn about blockchain updates in general, whether or not they're +currently being challenged, and where to deliver Witness receipts. # Stakeholders [stakeholders]: #stakeholders -Users running Hotspots or Validators. +Hotspot and Validator owners/operators. # Detailed Explanation [detailed-explanation]: #detailed-explanation ## Description of Current Implementation -First it is probably useful to recapitulate the current challenge process. First -refer to the Detailed Explanation section of [HIP53: H3Dex Targeting][hip53] -which describes how a challenge is constructed and submitted to the chain. - -Once the PoC request has appeared on chain and the Challengee has been selected, -the Hotspot attempts to connect to it over p2p (potential failure point #1). If -successful it sends the challengee the data to transmit. The Challengee then -consults its ledger to see if the PoC is active. This is another potential -failure point (#2) if the Challengee is not synced. The Challengee then -transmits the packet and sends a receipt to the Challenger over the same -connection the Challenger dialled on. Tthis avoids another potential p2p failure. -Any Hotspots observing the challenge packet then consults their ledger to see if -they can resolve the challenge to a Challenger. This is another potential -failure point (#3) if the witness is not in sync with the chain. If the -challenge can be resolved to a Challenger then the Witness attempts to dial that -Challenger over p2p, another potential failure point (#4). Once the Challenger -has decided enough blocks have passed it submits the `poc_receipt` transaction -to the chain to report on the information gathered (if any). The final, -potential failure point (#5) is if the Challenger is lagging behind the chain -and takes so long to submit the receipt that the PoC has expired. +It is useful to recapitulate the current challenge process. First refer to the +Detailed Explanation section of [HIP53: H3Dex Targeting][hip53] which describes +how a challenge is constructed and submitted to the blockchain. + +1. Once the PoC Request has appeared on the blockchain and the Challengee has + been selected, the Hotspot attempts to connect to it over p2p (potential + failure point). If successful it sends the challengee the data to transmit. +2. The Challengee then consults its local blockchain ledger to see if the PoC is + active. This is another potential failure point if the Challengee is not + synced. +3. The Challengee then transmits the packet and sends a receipt to the + Challenger over the same connection from the Challenger. Tthis avoids another + potential p2p failure. +4. Any Hotspots observing the challenge packet then consults their local + blockchain ledger to see if they can resolve the challenge to a Challenger. + This is another potential failure point if the witness is not in sync with + the blockchain. +5. If the challenge can be resolved to a Challenger then the Witness attempts to + dial that Challenger over p2p, another potential failure point. +6. Once the Challenger has decided enough blocks have passed it submits the + `poc_receipt` transaction to the blockchain to report on the information + gathered (if any. The final, potential failure point is if the Challenger is + lagging behind the blockchain and takes so long to submit the receipt that + the PoC has expired. So, as can be seen from above there are a number of potential failure points in -this process. These failures are all related to the speed/size of the chain and -the size of the p2p network. When the network was smaller this was much less of -an issue, but with over 500,000 Hotspots on the network now and larger blocks, -these failure points are becoming more and more common. +this process. These failures are all related to the speed/size of the blockchain +and the size of the p2p network. When the network was smaller this was much less +of an issue, but with over 500,000 Hotspots on the network now and larger +blocks, these failures are becoming more and more common. -An important aspect of this system is that the actual challenge Entropy is kept +An important aspect of this system is that the actual challenge entropy is kept secret until the receipt transaction is published. This requires Hotspots to observe the actual data from the Challenger to correctly respond to the challenge and prevents poisoning attacks. However Hotspots can verify the -challenge information against the chain information once they see it. +challenge information against the blockchain once they see it. +## Light Hotspots & GRPC -### Light Hotspots & GRPC +Light Hotspots will maintain a durable GRPC connection to one (or many) +Validators. The target Validator(s) could be random or specified. Via the +first durable connection, Light Hotspots will be streamed chain related data, +events and notifications. Additional connections can be considered ephermeral +and used for lookup requests if neded. -Light Hotspots will maintain a durable GRPC connection to a Validator. The -target Validator could be random or specified. Via this durable connection, -Light Hotspots will be streamed chain related data, events and notifications. - -Light Hotspots can also connect to additional Validators as required. Such -connections will be ephemeral in nature and typically for unary requests. - -All message types sent to a Light Hotspot from a Validator will be wrapped in a -top level message of the type `gateway_resp_v1` (Protocol buffer schema provied -below). This message type includes metadata which serves as an attestation on -behalf of the sending Validator. The attestation data includes: +All messages sent to a Light Hotspot from a Validator will be wrapped in a top +level message (Protocol buffer schema provied below). This message includes +metadata which serves as an attestation on behalf of the sending Validator. The +attestation data includes: - Signed payload of the message - Block age, height, and time when the payload was signed ### PoC Challenge Creation and the Consensus Group -Today each block on the chain includes metadata (BBA seen, timestamps, etc) and +Today, each block on the blockchain includes metadata (BBA seen, timestamps, etc) and transactions. With this change, each member of the Consensus Group will generate -a set of ephemeral key pairs. A hash of the public keys will be included in the -block proposals, whilst the private key will be saved to state on the generating +a set of ephemeral key pairs. A hash of the public keys will be included in +block proposals, whilst the private key will be saved to local state on the generating Validator. We propose a fixed `poc_challenge_rate` parameter to be added to the -chain that defines the target number of challenges per block. Each Consensus +chain that defines the target number of Challenges per block. Each Consensus Group member will propose a certain number of keys in order to ensure that we will meet this target. Assuming there are a minimum of `2f+1` nodes participating in a block, we are able to reach `poc_challenge_rate` if each -Validator in the Group generates enough challenges to fulfill this formula: +Validator in the Group generates enough Challenges to fulfill this formula: ![\frac{\text{PoC Challenge Rate}}{\frac{N-1}{3}* 2}][poc-challenge-rate] The set of agreed on public keys hashes will then be deterministically truncated (in case there are more than `2f+1` participating to `poc_challenge_rate` and -form part of the block metadata. - -Upon handling a block, each CG member will inspect the public keys in the block -and identify any of their own keys and for each initiate a new PoC. In running -the PoC the public key hash will be used along with the block hash to generate -entropy via which a H3 region will be selected. Entropy from a combination of -the associated private key hash and the block hash will then be used to identify -the target within the region and subsequently the challenge itself will be -generated. The region, target and challenge will be persisted to disk. - -### Validators & Light Gateway Communication +form part of the block metadata. The advantage of a fixed `poc_challenge_rate` +is that regardless of Hotspot growth, this value can remain fixed unless changed +through governance and can be adjusted based on the ability for Validators to +serve the capacity needs of the network. This avoids the need for periodic +changes to `poc_challenge_interval` as we do today in order to reduce load on +the network. + +Upon handling a block, each CG member will inspect the public keys in the block, +identify any of their own keys, and for each, initiate a new PoC. The public key +hash will be used with the block hash to generate entropy to generate an H3 +region for the Challenge. Entropy from a combination of the associated private +key hash and the block hash will then be used to identify the target within the +region to generate the Challenge itself. The region, challenge, and target will +be persisted locally on the Challenger Validator. + +### Validators & Light Hotspot Communication All Validators, whether they are in consensus or not, sync blocks normally to keep up with the blockchain. As a part of normal processing, they will pull the -public key hashes from the block metadata and, with the block hash, are able to -generate the same entropy as the Consensus Group members to identify the target -h3 region. The Validators will then pull a list of all Hotspots within that -region and send each gateway connected to them a notification message informing -them of a challenge within their region. The notification provides the onion key -hash of the Challenge and, more importantly, the necessary routing data (public -key and IP) to enable the Light Hotspot to connect to the challenging Validator. - -All gateways upon receipt of a challenge notification will send a request over -GRPC to the challenging Validator to check if they are the target. - -The request will be signed by the challengee and also include the onion key hash -it received from their Validator. The challenger will verify the signature of -the requesting gateway and if it is indeed the target, an challenge onion +public key hashes from the block metadata and, with the block hash, generate the +same entropy as the Consensus Group members to identify the target H3 region. +The Validators will then pull a list of all Hotspots within that region and send +each Hotspot connected to them a notification message informing them of a +challenge within their region. The notification provides the onion key hash of +the Challenge and, more importantly, the necessary routing data (public key and +IP) to enable the Light Hotspot to connect to the Challenger Validator. + +All Hotspots, upon receipt of a challenge notification, will send a request over +GRPC to the Challenger Validator to check if they are the target. + +The request will be signed by the Challengee and also include the onion key hash +it received from their Validator. The Challenger will verify the signature of +the requesting Hotspot and, if it is indeed the target, a Challenge onion payload will be returned. -Upon receipt of the challenge payload the Challengee will then transmit the -challenge packet as described above and as currently in the Helium network. +Upon receipt of the Challenge payload, the Challengee will then transmit the +Challenge packet as described above and as currently exists in the Helium +network. -### Observing Gateways and Witnessing +### Observing Hotspots and Witnessing Any Light Hotspot hearing the transmitted packet will serve as a Witness as we -have today on the Helium network. However rather that submit their witness -report over libp2p they will now submit over gRPC. The witness uses the -Validator(s) they are connected to as a client to lookup the challenging +have today on the Helium network. However, rather that submit their Witness +report over libp2p, they will now submit over gRPC. The Witnessing Hotspot uses +the Validator(s) they are connected to as a client to lookup the Challenger Validator by the hash of the PoC packet. The Light Hotspot then uses this -routing information to directly submit the witness receipt to the Challenger. +routing information to directly submit the Witness receipt to the Challenger. Please see the Attestation section below on how the Validator providing data to Light Hotspots can be verified. The Challenger, after the `poc_timeout` number of blocks, will create a -`blockchain_txn_poc_receipts_v2` txn using received receipts and witness reports -and publish it to the chain thereby completing the PoC challenge. +`blockchain_txn_poc_receipts_v2` transaction, using received Challengee receipts +and Witness reports, and publish it to the blockchain thereby completing the PoC +challenge. ### Attestation and Slashing enablement -All messages which originate from a Validator and sent to a Light Hotspot will -be attested. This includes not just the messages in this document but all -messages from a validator containing an assertion about the chain. +All messages originating from a Validator containing an assertion about the +blockchain will be attested. This includes messages not described in this +document. -If a Light Hotspot receives a message from a Validator and needs to act on this, -for example to contact a Consensus Group member to submit receipts, the Light -Hotspot will include the attestation in its request to that Consensus Group -member. The attestation provides evidence on behalf of the Light Hotspot to the -Consensus Group member that it received the instruction and/or data that -resulted in the said action. +If a Light Hotspot receives a message from a Validator and needs to act on it +(e.g., contacting a Consensus Group member to submit receipts) the Light Hotspot +will include the attestation in its request to that Consensus Group member. The +attestation provides evidence on behalf of the Light Hotspot to the Consensus +Group member that it received the instruction and/or data that resulted in the +said action. If the Consensus Group member determines the instruction/data was spurious in -nature, unsolicited or otherwise untrustworthy then the member can decide to act -on this which could include, for example publishing the verifiably false -assertion, with the malicious Validator's attestation, to the chain to allow for -slashing of the validator's stake. +nature, unsolicited, or otherwise untrustworthy then the member can decide to +act on this. This allows for future implementations where the verifably false +assertion is published, with the malicious Validator's attestation, to allow for +slashing of the Validator's stake. -Similarly Light Hotspots themselves, if they determine the message received from +Similarly, Light Hotspots themselves, if they determine the message received from a Validator is untrustworthy, can build their own untrusted list of Validators. -* [Proto definitions][proto] +### PoC Challenger Rewards + +Today, the Hotspots creating PoC Challenges and submitting receipts to the +blockchain are rewarded with 0.9% of HNT rewarded per epoch. We propose that +this subsidy be moved to the Validator Challenger (member of the Consensus +Group) that is creating and collecting Challenge data and submitting this +information to the blockchain. We don't recommend any other changes at this time +as it would increase the scope of implementation. Please refer to [HIP +10][hip10] or [docs.helium.com][docs] for the details of the current reward +scheme for PoC and specifically for Challengers. + +We believe that there could be a future iteration of Validator Challengers that +could introduce a separate Consensus Group responsible for Challenges only but +this is also too complex as an initial design. This would also remove the +ability to piggy back Challenges onto existing block production (which will +massively lower the blockchain's transaction rate). + +### New Chain Variables + +* `poc_challenger_type`: This chain variable allows us to control if Validators + are responsible for creating challenges on the network. Activating this HIP + requires setting this value to `validator`. +* `poc_challenge_rate`: This chain variable represents the target number of + challenges per block. We propose an initial value of: `TODO` +* `poc_timeout`: This chain variable represents the number of blocks a + Challenger will wait before collecting all available Challengee and Witness + data and submitting a receipt transaction to the blockchain. We propose an + initial value of `TODO` +* `poc_receipts_absorb_timeout`: This chain variable represents the number of + blocks after the timeout where public PoC data will remain on the local ledger + of Validators. This allows Validators to garbage collect this data so it can + conserve space for future Challenges but ensures that the information is + available to allow sufficient time for absorbing the transaction. We propose + an initial value of `TODO` + + +### Additional Documentation + +* [Protocol Buffer definitions][proto] * [Message Sequence Diagram][message-sequence] # Drawbacks [drawbacks]: #drawbacks This is a fairly extensive change to the network and may be disruptive if not -executed well. This also somewhat disturbs the economics of the system by -removing the Challenger rewards (currently 0.95% of rewards) from Hotspots and -giving it to Validators. By moving PoC Challenges away from the Hotspots, we -also lose a potential "liveness" check that can be used to determine whether or -not a Hotspot is online and instead we must rely solely on Data Transfer and PoC -activity. +executed well. This also somewhat disturbs the economics of the system by moving +the Challenger rewards (currently 0.9% of rewards) from Hotspots to Validators. +By moving PoC Challenges away from the Hotspots, we also lose a potential +"liveness" check that can be used to determine whether or not a Hotspot is +online and instead we must rely solely on Data Transfer and PoC activity. # Rationale and Alternatives [alternatives]: #rationale-and-alternatives -Simpler designs would include retaining the Hotspot doing the challenge, just -via information submitted/received via a Validator. This would involve less +Simpler designs would include retaining the Hotspot initiating the Challenge, +just via information submitted/received via a Validator. This would involve less change but it would not remove the reliance on p2p routing. -Another design would be to have a separate group do the challenges, and indeed -that may be a further evolution of this design, but was deemed too complex as an -initial design. This would also remove the ability to piggy back challenges onto -existing block production (which will massively lower the chain's transaction -rate). - -Other designs include proposals like "self beaconing" but those remove a lot of -the separation of concerns that make collusion harder and would be significantly -weaker. Such a design also would not allow for further enhancements to how PoC -packets are transmitted. +Other designs include proposals like "self beaconing" but those create a +significantly weaker security model and enables more opportunity for collusion. +Such a design also would not allow for further enhancements to how PoC packets +are transmitted. # Unresolved Questions [unresolved]: #unresolved-questions -We initially propose that the Challenger reward moves to the Validators -initiating the challenge. Although this is a relatively small change, as it -constitutes only 0.95% of all rewards today and decreases over time through the -yearly token emissions adjustments, we still believe it's important to note and -debate. Validators will be taking on more responsibility of the network and more -work that simply cannot scale on Hotspot hardware so our proposal makes an -opinionated choice. - -This plan *does* consider and allow for validator slashing to the extent the -data payloads exchanged between the Light Hotspots, the Validators and the -Consensus Group will include data points that can enable a slashing mechanism to -be added at a later point. It does not however propose the slashing -implementation itself, that will be done in a future HIP. - -Additionally this plan does allow for an establishment of tracking which -Validators that Hotspots are using for their source of chain information but it -does not propose what to use that information for, that could be used in a -future improvement. - -Finally this plan also allows for a change to how challenges work and would -allow for multiple challengees to be involved in transmitting packets to both -reduce the scope for collusion between a challengee and witnesses but also -obtain better positional information as a result of the challenge. This has been +This plan *does* consider and allow for Validator slashing to the extent the +data payloads exchanged between the Light Hotspots, the Validators, and the +Consensus Group will include attestation data. This can can enable a slashing +mechanism. It does not however propose the slashing implementation itself, that +could be proposed in a future HIP. + +This plan also allows for an establishment of tracking which Validators that +Hotspots are using for their source of blockchain information but it does not +propose what to use that information for, like affinity or delegation. We leave +this for a future proposal as well. + +This plan, finally, allows for a change to how Challenges work and would allow +for multiple challengees to be involved in transmitting packets. This could +reduce the scope for collusion between a Challengee and Witnesses and also +obtain better positional information as a result of the Challenge. This has been described in other forums as "Region" or "Multi-Hotspot" Challenges. This is out of scope for this HIP but we imagine future work in this direction could be possible. @@ -254,13 +289,13 @@ possible. # Deployment Impact [deployment-impact]: #deployment-impact -Overall users should see more reliable challenge behaviour, less data use on the +Overall users should see more reliable Challenge behaviour, less data use on the Hotspot (which makes cellular/satellite backhaul hotspots more feasible) and -more or less immediate onboarding of new Hotspots (no need to sync the chain or +effectively immediate onboarding of new Hotspots (no need to sync the chain or load a snapshot in order to participate in PoC or transfer Data on the Helium Network). -Hardware costs for hotspots could potentially go down as the hardware +Hardware costs for Hotspots could potentially go down as the hardware requirements can be relaxed to reflect the lower demands of the new challenge model. @@ -271,12 +306,14 @@ serve as a reference. - Is this backwards compatible? -The activation would be done via a set of chain variable changes which would -switch the system over to this new model, before that happens we need the new -code to be merged, deployed to the fleet (routers, hotspots, validators, node -users) and this HIP needs to be ratified. +The activation would be done via a set of chain variables which would switch the +system over to this new model, before that happens we need the new code to be +merged, deployed to the fleet (routers, hotspots, validators, node users) and +this HIP needs to be ratified. [hip53]: https://github.com/helium/HIP/blob/main/0054-h3dex-targeting.md [proto]: https://github.com/helium/proto/blob/andymck/poc-grpc-msg-defs-WIP/src/service/gateway.proto#L101 [message-sequence]: https://docs.google.com/drawings/d/1eVTK89ob66vlcEwwoVNi0BFaCEaU2DYki8778LIRWpA/edit [poc-challenge-rate]: https://user-images.githubusercontent.com/75/153673071-550eb970-4ab6-44e0-b9fc-e9b04e1b4dad.png +[hip10]: https://github.com/helium/HIP/blob/main/0010-usage-based-data-transfer-rewards.md +[docs]: https://docs.helium.com/blockchain/mining#hnt-distributions-per-epoch From 002cabbb55f37b30cc5b54ad25fa4e6e9529a7d6 Mon Sep 17 00:00:00 2001 From: Abhay Kumar Date: Fri, 11 Feb 2022 15:22:07 -0800 Subject: [PATCH 4/8] Formatting --- xxxx-validator-challenges.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xxxx-validator-challenges.md b/xxxx-validator-challenges.md index d4edebea4..5a82d04f9 100644 --- a/xxxx-validator-challenges.md +++ b/xxxx-validator-challenges.md @@ -299,12 +299,12 @@ Hardware costs for Hotspots could potentially go down as the hardware requirements can be relaxed to reflect the lower demands of the new challenge model. -- How will existing documentation/knowlegebase need to be supported? +## How will existing documentation/knowlegebase need to be supported? Documentation will need to be updated to explain the new model, this HIP can serve as a reference. -- Is this backwards compatible? +## Is this backwards compatible? The activation would be done via a set of chain variables which would switch the system over to this new model, before that happens we need the new code to be From 700019ce7ee38097fbe4e3d4883beb98e6df631e Mon Sep 17 00:00:00 2001 From: Abhay Kumar Date: Fri, 11 Feb 2022 15:56:02 -0800 Subject: [PATCH 5/8] Typo fixes Co-authored-by: Coco Tang --- xxxx-validator-challenges.md | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/xxxx-validator-challenges.md b/xxxx-validator-challenges.md index 5a82d04f9..a36e692a7 100644 --- a/xxxx-validator-challenges.md +++ b/xxxx-validator-challenges.md @@ -40,7 +40,7 @@ Challenges. In brief, Validator Challenges move the role of generating Challenges to the Consensus Group. This not only allows us to free Hotspots from the burden of following the blockchain but it also moves the entities initiating Challenges to machines with much more stable and predictable networking which -reduces the likihood of connectivity failures. Hotspots can become clients of +reduces the likelihood of connectivity failures. Hotspots can become clients of Validators to learn about blockchain updates in general, whether or not they're currently being challenged, and where to deliver Witness receipts. @@ -65,7 +65,7 @@ how a challenge is constructed and submitted to the blockchain. active. This is another potential failure point if the Challengee is not synced. 3. The Challengee then transmits the packet and sends a receipt to the - Challenger over the same connection from the Challenger. Tthis avoids another + Challenger over the same connection from the Challenger. This is another potential p2p failure. 4. Any Hotspots observing the challenge packet then consults their local blockchain ledger to see if they can resolve the challenge to a Challenger. @@ -75,7 +75,7 @@ how a challenge is constructed and submitted to the blockchain. dial that Challenger over p2p, another potential failure point. 6. Once the Challenger has decided enough blocks have passed it submits the `poc_receipt` transaction to the blockchain to report on the information - gathered (if any. The final, potential failure point is if the Challenger is + gathered (if any). The final, potential failure point is if the Challenger is lagging behind the blockchain and takes so long to submit the receipt that the PoC has expired. @@ -91,13 +91,13 @@ observe the actual data from the Challenger to correctly respond to the challenge and prevents poisoning attacks. However Hotspots can verify the challenge information against the blockchain once they see it. -## Light Hotspots & GRPC +## Light Hotspots & gRPC -Light Hotspots will maintain a durable GRPC connection to one (or many) +Light Hotspots will maintain a durable gRPC (Google Remote Procedure Call) connection to one (or many) Validators. The target Validator(s) could be random or specified. Via the first durable connection, Light Hotspots will be streamed chain related data, events and notifications. Additional connections can be considered ephermeral -and used for lookup requests if neded. +and used for lookup requests if needed. All messages sent to a Light Hotspot from a Validator will be wrapped in a top level message (Protocol buffer schema provied below). This message includes @@ -131,13 +131,13 @@ serve the capacity needs of the network. This avoids the need for periodic changes to `poc_challenge_interval` as we do today in order to reduce load on the network. -Upon handling a block, each CG member will inspect the public keys in the block, -identify any of their own keys, and for each, initiate a new PoC. The public key -hash will be used with the block hash to generate entropy to generate an H3 -region for the Challenge. Entropy from a combination of the associated private -key hash and the block hash will then be used to identify the target within the -region to generate the Challenge itself. The region, challenge, and target will -be persisted locally on the Challenger Validator. +Upon handling a block, each Consensus Group member will inspect the public keys +in the block, identify any of their own keys, and for each, initiate a new PoC. +The public key hash will be used with the block hash to generate entropy to +generate an H3 region for the Challenge. Entropy from a combination of the +associated private key hash and the block hash will then be used to identify the +target within the region to generate the Challenge itself. The region, +challenge, and target will be persisted locally on the Challenger Validator. ### Validators & Light Hotspot Communication @@ -152,7 +152,7 @@ the Challenge and, more importantly, the necessary routing data (public key and IP) to enable the Light Hotspot to connect to the Challenger Validator. All Hotspots, upon receipt of a challenge notification, will send a request over -GRPC to the Challenger Validator to check if they are the target. +gRPC to the Challenger Validator to check if they are the target. The request will be signed by the Challengee and also include the onion key hash it received from their Validator. The Challenger will verify the signature of @@ -290,7 +290,7 @@ possible. [deployment-impact]: #deployment-impact Overall users should see more reliable Challenge behaviour, less data use on the -Hotspot (which makes cellular/satellite backhaul hotspots more feasible) and +Hotspot (which makes cellular/satellite backhaul Hotspots more feasible) and effectively immediate onboarding of new Hotspots (no need to sync the chain or load a snapshot in order to participate in PoC or transfer Data on the Helium Network). From 01470f752fc49a7d0743dc971574a03c3baaee55 Mon Sep 17 00:00:00 2001 From: Abhay Kumar Date: Fri, 11 Feb 2022 16:02:09 -0800 Subject: [PATCH 6/8] clarification --- xxxx-validator-challenges.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/xxxx-validator-challenges.md b/xxxx-validator-challenges.md index a36e692a7..eaceb2c4b 100644 --- a/xxxx-validator-challenges.md +++ b/xxxx-validator-challenges.md @@ -68,11 +68,11 @@ how a challenge is constructed and submitted to the blockchain. Challenger over the same connection from the Challenger. This is another potential p2p failure. 4. Any Hotspots observing the challenge packet then consults their local - blockchain ledger to see if they can resolve the challenge to a Challenger. - This is another potential failure point if the witness is not in sync with - the blockchain. -5. If the challenge can be resolved to a Challenger then the Witness attempts to - dial that Challenger over p2p, another potential failure point. + blockchain ledger to see if they can find the Challenger based on the packet + they received and Challenge data on the blockchain. This is another potential + failure point if the witness is not in sync with the blockchain. +5. If the Challenger is found, the Witnessing Hotspot attempts to dial them over + p2p, another potential failure point. 6. Once the Challenger has decided enough blocks have passed it submits the `poc_receipt` transaction to the blockchain to report on the information gathered (if any). The final, potential failure point is if the Challenger is From b89ba69f14b72a06fd5d33aaae24489ab20ea735 Mon Sep 17 00:00:00 2001 From: eda Date: Mon, 14 Feb 2022 17:33:56 +0300 Subject: [PATCH 7/8] Update draft HIP frontmatter --- xxxx-validator-challenges.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/xxxx-validator-challenges.md b/xxxx-validator-challenges.md index eaceb2c4b..d360ec573 100644 --- a/xxxx-validator-challenges.md +++ b/xxxx-validator-challenges.md @@ -1,12 +1,12 @@ -# Validator Challenges +# HIP 55: Validator Challenges - Author(s): [@Vagabond](https://github.com/Vagabond), [@andymck](https://github.com/andymck), [@abhay](https://github.com/abhay) - Start Date: 2022-02-03 - Category: Technical -- Original HIP PR: -- Tracking Issue: -- Status: Draft +- Original HIP PR: https://github.com/helium/HIP/pull/359 +- Tracking Issue: TODO +- Status: In Discussion # Summary [summary]: #summary From 424ad249bda281ec730085c4562e0373ba3d93ab Mon Sep 17 00:00:00 2001 From: eda Date: Mon, 14 Feb 2022 17:36:15 +0300 Subject: [PATCH 8/8] Rename file --- xxxx-validator-challenges.md => 0055-validator-challenges.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename xxxx-validator-challenges.md => 0055-validator-challenges.md (100%) diff --git a/xxxx-validator-challenges.md b/0055-validator-challenges.md similarity index 100% rename from xxxx-validator-challenges.md rename to 0055-validator-challenges.md