IOT Proof of Coverage Roadmap
IOT Proof of Coverage Roadmap
The Helium “IOT” network is the original and largest sub-network in the Helium system. It uses the LoRaWAN protocol to provide Internet connectivity to a class of devices that are often described as “the Internet of Things” (IOT).
Proof-of-Coverage is the novel work algorithm that the Helium IOT network uses to reward Hotspot owners for providing useful coverage for the network. Proof-of-Coverage (PoC) is designed to incentivize Hotspot owners to deploy Hotspots in underserved areas and report their deployments accurately so that users of the network can clearly see where coverage is likely to be available.
The Changing Landscape
Because PoC is such an important part of the network’s success and continued growth, it must adapt to change. Change comes in many forms, but the key changes that have happened since the start of the network are:
- The network has grown exponentially
- Newer radio hardware has been developed
- Newer LoRaWAN features have arisen
- Attempts to subvert PoC have grown in sophistication
- The network has been re-organized to be more scalable (HIP-70)
- The network has diversified; there are more actors and roles available
- A talented and committed community has continued to grow as more Hotspots come online
While some of these changes are challenges to overcome, most of them are improvements that have remained as untapped resources — until now. Each of the items in the roadmap that follows either capitalizes on one of these improved resources or addresses one of the difficult challenges.
It is also important to recognize that many ideas for improvements to PoC have been proposed by core developers and community members, not all of which are a part of this immediate roadmap. After we accomplish the most fundamental and important steps, improvements that may otherwise have been tabled because they were deemed too complex to implement will become viable and reconsidered.
Step 1: Oracle-Based PoC - In Progress
From the launch of the network in 2019 until February 2, 2023, the IOT PoC system relied on a “Challenger, Beaconer, Witness, Validator, Rewarder” model. In this model at least five separate actors had to work together in order to make PoC events happen. Any break in the chain meant the loss of the entire event and its rewards.
A History of Artificial Limits
Over these several years the Core Developers noticed breaks in this chain and have had to enact limits to PoC to keep it functioning under the extraordinary demand generated by the growth of the network. These limits have frustrated Hotspot owners and network users alike by making it hard to see just how effective changes and additions to Hotspot setups were. These limits included:
- A Hotspot could only expect to Beacon roughly once every two days, and
- Only 14 Witnessing Hotspots could be recorded in the results
Room to Breathe
With the adoption of HIP-70, the Core Developers have been able to adopt a newer, higher performing model known as “Oracle-Based PoC”. Oracle-Based PoC brings two important improvements:
- It eliminates the Challenger role, allowing Hotspots to be in charge of their own Beacons, and
- It shifts PoC validation to a higher performance actor, known as the IOT PoC Verifier Oracle.
The Verifier Oracle can process and validate PoC events with significantly less overhead than before, when PoC events had to be validated under strict real-time deadlines by the members of the currently elected Consensus Group, and which often led to events silently being dropped just to keep the blockchain moving.
Step 2: Removing the Limits to PoC
Now that Oracle-Based PoC is in effect, we can begin to remove some of the restrictions that had been holding PoC back. In short, we will:
- Increase the Beacon rate, and
- Separate Witness reports from Witness Rewards.
Increasing the Beacon Rate
Increasing the Beacon rate per Hotspot will provide the network and Hotspot owners with more timely measurements, which in turn will allow them to make improvements with confidence and allow network users to quickly see new areas of coverage. Increasing the beacon rate will be evaluated by the IoT PoC Working Group as a potential upgrade to functionality on the network.
Publishing the Full Witness List
Under Oracle-Based PoC we can now separately report the entire list of Witnesses to every Beacon without also requiring the entire list to be represented on the blockchain, which is solely dedicated to handing out rewards for the event. The ability to separate these concerns is important because many Hotspots are routinely Witnessed by many more than the 14 Hotspots reported in the blockchain rewards transaction, but until now there simply was no place to report them.
With the advent of Oracle-Based PoC, the IOT Verifier Oracle can publish a side report, off chain, of the entire witness list to each and every Beacon on the network.
Step 3: Economic Scale Adjustments
Rewards for Beacons and Witness events under PoC are prioritized by a scheme that was introduced under HIP-17, which was designed to pay higher rewards for Beacon events that are transmitted from less-covered areas as a way to encourage Hotspot owners to deploy Hotspots in these areas 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, somewhat arbitrarily, how many Hotspots are needed to effectively cover a given area.
Currently there are seven “targets” in the list, each of which is a pairing of an area scale and the ideal number of Hotspots that should be deployed at that scale. As each Hotspot is added to or removed from the network, the system examines the deployment and how it affects the Hotspot count at each of these scales, then it computes a new Transmit Scale for every Hotspot in the regions affected. If the change is an addition to the network and that addition increases the density of Hotspots at a particular scale beyond the ideal density, then every Hotspot in that region has its Transmit Scale reduced.
Since HIP-17’s adoption in late 2020, these scales and density targets have remained unchanged.
We should reconsider each density target individually to ensure that its limit makes sense, and if not, change it. Additionally, we should consider shortening the list and removing area scale targets that aren’t helpful, such as the “Res 4” scale, which roughly covers an area of 1,770 square kilometers (683 square miles).
A Collection of Next Steps
After the previously listed steps are adopted, the way forward becomes harder to predict and the order in which developments must be made is less certain. Nonetheless, we are certain they will include these “Next Steps”.
Next Steps: Algorithmic Experiments
With more rapid Beaconing and more stable reporting, we can begin performing experimental adjustments to PoC that will help it measure the surrounding radio environment better and make the algorithm more robust against simulation attacks, aka, “gaming”.
It is hard to predict how effective any one of the many algorithmic proposals that these changes will be without simply testing them. Proposed ideas include:
- Randomized transmit powers
- Randomized coding rates (Spreading Factors)
- The Addition and/or Removal of Error-correcting codes
- Reintroduction of multi-hop paths, secondary Beacons
Next Steps: Modeled Coverage
Proof-of-Coverage shouldn’t reward for coverage that is physically impossible to provide and should use suspicious coverage reports as a possible indicator of a misbehaving Hotspot. The IOT PoC Verifier should incorporate basic terrain data and electromagnetic wave propagation models to judge the plausibility of Witness events and begin to build a trust model to identify well-behaved Hotspots amongst those that are untrustworthy.
Next Steps: Worldwide Reward Harmonization
The IOT network uses several different “unlicensed” radio bands across the world. Each of these bands comes with its own regulations, some of which can change from country to country in the space of just a few kilometers. Some of these regulations limit the output power and dwell times that a Hotspot can use when transmitting a Proof-of-Coverage Beacon, which ultimately changes how easily it is heard by other Hotspots in the area, and ultimately affects a Hotspot’s PoC rewards.
Not all of these limits ultimately affect how well a Hotspot can cover a given area, and as such, any parameter that artificially inflates or deflates a Hotspot’s apparent coverage should be accounted for when computing a Hotspot’s PoC rewards for a Beacon. Once Reward Harmonization is enacted, Hotspot owners should be able to expect their rewards to be based only on the effectiveness and uniqueness of their coverage and not by the particular country or region in which they are deployed.
Next Steps: Secured Mappers and Concentrators
Introduce specially-hardened hardware elements that can cryptographically attest to their locations and observations. Incentivise this extra expense with extra rewards, but continue to let the network be composed of standardized and cheaper hardware.
Next Steps: Permissionless Participation
Make it possible for anyone to add a Hotspot to the network and participate in PoC, just as long as they provide the onboarding fee. The PoC algorithm will sort out who is providing coverage and who is not. Don’t require a specialized third party to attest which Hotspots are real and which are virtualized.