HIP 94: Response Time Windows for Witness Rewarding

• Author(s): @disk91, @jmarcelino
• Start Date: 2023-07-20
• Category: Economic, Technical
• Original HIP PR: #749
• Tracking issue: #764
• Voting Requirements: veIOT Holders

Summary

Currently the Proof-of-Coverage Oracles reward the 14 first hotspots (defined in default_max_witnesses_per_poc ) reporting a witness. This rewards the fastest hotspots, incentivizing fiber backhauls and specific hardware models that happen to be able to produce fast signatures. The result is that the same hotspots are selected, making others unviable even if they provide unique and useful coverage for the network. In other words, it punishes hotspots for falling short of millisecond optimizations when the LoRaWAN protocol functions to the order of seconds - see also.
A hotspot’s utility in providing LoRaWAN coverage is based on measuring “good enough” response times, not absolute fastest as absolute speeds provides no marginal utility, the Uplink does not have a particular time-window, the downlink time windows is up to 2 seconds, and the Join process up to 6 seconds.

Since HIP-83, changing the way hotspot are selected, we see an acceleration of hotspots not participating to PoC anymore conducting to network size reduction.

This HIP proposes to evolve the hotspot selection by adding a response time window to eliminate only
slow hotspots that fail to meet LoRaWAN-grade timing constraints and push helium hotspots to improve their reponse time, over time, reasonably.

Rendered View

https://github.com/helium/HIP/blob/main/0094-response-time-windows-for-witness-rewarding.md