IOT Proof-of-Coverage Roadmap
Because Proof-of-Coverage (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 (1))
- The Network has diversified; there are more actors and roles available
- A talented and committed community has continued to grow as more IoT Hotspots come online
The Current Plan
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 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 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 time, 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 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 PoC 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
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).
Future Exploration
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”.
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
Modeled Coverage
Use suspicious coverage reports as a possible indicator of a misbehaving Hotspot. The IOT Proof-of-Coverage shouldn't reward for coverage that is physically impossible to provide and the Verifier Oracle 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.
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.
Secured Mappers and Concentrators
Introduce specially hardened hardware elements that can cryptographically attest to their locations and observations. Incentivize this extra expense with extra rewards but continue to let the Network be composed of standardized and cheaper hardware.
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. This doesn't require a specialized third party to attest which Hotspots are real and which are virtualized.