Skip to main content

Proof of Coverage

The Helium blockchain uses a novel work algorithm called “Proof of Coverage” (PoC) to verify that Hotspots are located where they claim. Put another way, PoC tries to verify, on an ongoing basis, that Hotspots are honestly representing their location and the wireless network coverage they are creating from that location.

See Proof of Coverage in Action

The Helium Network Explorer is the best resources for viewing POC-related data. Before you dive into the POC internals, here are a few PoC Challenges to help you visualize how this works:

Why Proof of Coverage?

The Helium Network is a physical wireless network that succeeds based on the amount of reliable coverage it can create for users deploying connected devices on it. As such, it required a work algorithm that was built for this use case. Proof-of-Coverage takes advantage of the unique, undeniable properties of radio frequency (RF) to produce proofs that are meaningful to the Helium Network and its participants. Specifically, PoC relies on the following characteristics:

  • RF has limited physical propagation and, therefore, distance;
  • The strength of a received RF signal is inversely proportional to the square of the distance from the transmitter; and
  • RF travels at the speed of light with (effectively) no latency;

Using these properties, the blockchain is constantly interrogating Hotspots using a mechanism known as a “PoC Challenge”. The ultimate power of Proof-of-Coverage lies in the fact that the data generated by the ongoing proofs and stored in the Helium blockchain is definitive verification of the wireless coverage provided by Hotspots on the Network.

Proof-of-Coverage Challenges

The "challenge" is the discrete unit of work for Proof of Coverage. To date, there have been 10s of millions of challenges issued and processed by the Helium blockchain. With each new challenge, the blockchain records more data about the quality of the network. Let's take a look at how challenges actually happen.

Proof-of-Coverage Roles

PoC Challenges involve three distinct roles:

  1. Challenger - The Validator that constructs and issues the PoC Challenge. See HIP 55 for further information about this change.
  2. Beaconer - Sometimes called "Challengee". This Hotspot is the target of the POC challenge and is responsible for transmitting (or "beaconing") challenge packets to potentially be witnessed by geographically proximate Hotspots.
  3. Witness - Hotspots that are geographically proximate to the Transmitter and report the existence of the challenge packet after it has been transmitted.

(Note: The goal is to reduce the PoC Interval to 200 blocks or lower)

Challenge Proof Construction and Target Selection

Validators can create a challenge request every block, but a chain variable poc_challenge_rate determines how many Challenge requests are allowed in a block. As this number increases, more challenges will appear on the network. They do this reliably to earn the portion of HNT rewards allocated to challengers.

Each Validator will generate a set of ephemeral key pairs and a hash of the public keys will be included in Validator heartbeat txns whilst the private key will be saved to local state on the generating Validator. During absorb of a heartbeat txn, if the proposed keys do not belong to a Consensus Group member they will be added to a local cache poc_key_proposals. 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 deterministically select a certain number of keys from the poc_key_proposals cache 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 can select enough Challenges to fulfill this formula:

\frac{\text{PoC Challenge Rate}}{\frac{N-1}{3}* 2}

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. Selected keys will be removed from the poc_key_proposals cache. 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 Validator 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.

Witnesses

Any Light Hotspot hearing the transmitted packet will serve as a Witness as we have today on the Helium network. Light Hotspots submit their Witness report 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.

The Challenger, after the poc_timeout number of blocks, will create a blockchain_txn_poc_receipts_v2 transaction, using received Challengee receipts and Witness reports, and submit it to the blockchain thereby completing the PoC challenge.

As of HIP 15, Proof of Coverage relies entirely on beaconing. A beacon is a single transmission witnessed by any Hotspot. Previous versions used multi-hop challenge paths that didn't accurately test Hotspots on what they are built to do: capture RF packets.

PoC Reward Scaling

For every epoch, each reward type is split amongst Hotspots who had a role in that reward pool.

For example, if your Hotspot was challenged during an epoch, it will be eligible to a portion of the 5.31% of rewards that go to PoC Transmitters. A practical way of thinking about this is that a Hotspot might earn a "reward unit" for succeeding at a challenge. If five additional Hotspots succeeded at a challenge during the epoch and each of them also earned a "reward unit", then each Hotspot gets 1/6th of the 5.31% of rewards in that epoch.

With the activation of HIP15 and HIP17, we introduced the idea of scaling these "reward units", so the units earned when being witnessed or witnessing a packet scale depending on two things:

  1. The number of witnesses, detailed in HIP15
  2. The number of Hotspots in the hex tile of the transmitter, detailed in HIP17

The HIPs themselves provide a rich explanation of these mechanisms, so you're encouraged to read those, but they can be summarized as follows:

From HIP15

  • For the Transmitters, the more witnesses, the more the Transmitter earns;
  • For the Witness, each additional witness past a total of four reduces what is earned by each witness in that challenge.
  • A change made with the 2021.09.14.0 release randomly shuffles the valid received witness receipts, and selects (up to) 25 of those valid to write to the chain.

From HIP17

  • The Witness earns less if the number of Hotspots in the area of the Transmitter exceeds the "target density". Target density varies by hex resolution, as detailed in the HIP and defined in several chain variables.

Attestation and Slashing enablement

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 it (e.g., contacting a Challenger Validator to submit receipts) the Light Hotspot will include the attestation in its request to that Challenger Validator. The attestation provides evidence on behalf of the Light Hotspot to the Challenger Validator that it received the instruction and/or data that resulted in the said action.

If the Challenger Validator member determines the instruction/data was spurious in nature, unsolicited, or otherwise untrustworthy then the member can decide to act on this. This allows for future implementations where the verifiably 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 a Validator is untrustworthy, can build their own untrusted list of Validators.

Edit this page