The Helium Network uses a unique consensus algorithm called "Proof-of-Coverage" (PoC) to verify thatHotspots accurately represent their location, configuration, and the wireless coverage they create.
Proof-of-Coverage incentivizes Hotspot Operators to deploy Hotspots in underserved areas and reporttheir deployments accurately so that users of the Helium Network can see where coverage is likely tobe available.
Why Proof-of-Coverage
The Helium Network is a physical wireless network that succeeds based on the reliable coverage itcan create for users deploying connected devices. As such, it required a working algorithm built forthis use case.
Proof-of-Coverage leverages unique, undeniable properties of radio frequency (RF) propagation toproduce meaningful proofs to the Helium Network and its participants. Specifically, PoC relies onthe 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 fromthe transmitter.
- RF travels at the speed of Light with (effectively) no latency.
The Helium Network uses the data generated by ongoing proofs to verify the wireless coverageprovided by Hotspots on the network.
Oracled Proof-of-Coverage
- Oracled Proof-of-Coverage ChainVar was set in block 1,731,335.
- The first Oracled Proof-of-Coverage Receipts were in block 1,731,339.
- "Bitter Concrete Parakeet" is the animal name of the Injector Oracle for Oracled PoC.
Oracled PoC moves the responsibility of validating all PoC events to dedicated Oracles, powerfulmachines that ingest completed challenges, verify challenges, and witness validity, then inject theresults back into the Helium Network for rewards to be issued.
Oracles interact with data and systems outside of a native blockchain environment where theprocessing can be completed much more efficiently and at scale, providing a solution to afundamental limitation of smart contracts.
Oracled Proof-of-Coverage allows Hotspots running miner version 2022.12.13.0 or later to"self-beacon", transmitting Beacons on their own to participate in Proof-of-Coverage, ensuring morereliable Beacon events.
At the start, Hotspots self-beacon every 6 hours, though this time window may change as Oracled PoCis improved. The Beacon rate includes a "jitter" component to offset the Beacon timing acrossHotspots on the Network to avoid overloading the Oracles with large data spikes.
Oracled PoC is essential in implementing HIP-70 and the Helium Network's migration to theSolana blockchain and is a significant step forward in increasing the usability and scalability ofthe Network.
PoC Reward Scaling
Rewards for Beacons and Witness events under PoC are prioritized by a scheme that was introducedunder HIP-17, which was designed to pay higher rewards for Beacon events that aretransmitted from less-covered areas as a way to encourage Hotspot owners to deploy Hotspots in theseareas and discourage deployments in areas that are already densely covered.
PoC currently judges an area as over- or under-served by consulting a table of density scale values,which dictates how many Hotspots are needed to effectively cover a given area.
As each Hotspot is added to or removed from the Network, the Oracle examines the deployment and howit affects the Hotspot count at each of the seven scales, computing a new Transmit Scale (TS) forevery Hotspot in the regions affected.
If the change is an addition to the Network which increases the density of Hotspots at a particularscale beyond the ideal density, every Hotspot in that region has its Transmit Scale reduced.
Currently, there are seven “targets” in the list, each of which is a pairing of an area scale andthe ideal number of Hotspots that should be deployed at that scale.
In every epoch, rewards split amongst Hotspots that had a role in that reward pool.
For example, a Hotspot might earn a "reward unit" for witnessing a beacon. If five additionalHotspots successfully witnessed a Beacon during the epoch, each Hotspot earns a "reward unit." Inthat case, each Hotspot gets 1/6th of the 20% of rewards in that epoch.
The activation of HIP-15, HIP-17 and HIP-104 introduced the idea ofscaling these reward units. So the units earned when being witnessed or witnessing a packet scaledepend on three things:
- The number of Witnesses, as detailed in HIP-15
- The number of Hotspots in the hex tile of the transmitter, detailed in HIP-17
- The adjusted parameters from HIP-17, detailed in HIP-104
The HIPs themselves provide a rich explanation of these mechanisms, but they can be summarized asfollows:
From HIP-15
- 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 eachWitness in that challenge.
From HIP-17
- 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 inseveral chain variables.
From HIP-104
- The Hotspots in rural areas (or less densely covered regions) now earn more PoC rewards than theydid previously, in order to guide the Helium IoT Network coverage towards a more well-balanced andexpansive state.
IOT token rewards
