Light Hotspots are the evolution of current hotspots, which sync the complete blockchain, use peer-to-peer network to talk to each other, rely on IP addresses being involved, and commonly start out behind a relay due to a lack of port forwarding. 

New Light Hotspots will be cheaper, and they will no longer need to sync to the blockchain, have relay issues, or create challenges. Validators will take over this role via HIP 55. 

Helium will invite new hardware manufacturers to the network and test them on the test-net to make sure they work without problems before adding them to the main-net.

Light Hotspot software will allow Hotspots to participate in data transfer as well as Proof-of-Coverage beaconing and witnessing via Validators. With Validators producing new blocks, processing this data, and initiating PoC challenges, this would eliminate relayed status, syncing and snapshot issues, SD card issues that stem from high-bandwidth, storage, and compute requirements of a 500k+ network. This change to validators handling block information will mean that hotspots can provide consistent coverage with no downtime due to blockchain issues.

Helium

Before continuing, be aware that this is the last section of our Master Guide to Helium Mining, check out the link for more information on how to maximize your HNT rewards.

HIP 54

“Targeting HIP”

As the network expands, some hotspots that are surrounded by offline Hotspots will get challenged more frequently than they are intended to. HIP 54 intends on solving this by changing to a H3 based-index. This will take offline hotspots off the list that decides how many times an area will be challenged, making for more balanced rewards across the network.

This HIP serves as both an explanation of the current Proof-of-Coverage (PoC) targeting behavior as well as a proposal for a more scalable replacement using an H3-based index. We are proposing it as a HIP to communicate and acknowledge that this is a change to the current implementation but we believe it still falls within the original intent of PoC.

The current targeting mechanism relies on a global list of asserted Hotspots. This list, as the network grows, is increasingly expensive to maintain and examine. Additionally, this list does not support garbage collection, so inactive Hotspots are counted towards targeting probability, leading to targeting skew in hexes with many inactive Hotspots.

The goal of this proposed work is to maintain the existing targeting semantics as closely as possible but rework them to operate on a more scalable data structure. A secondary goal is to reduce the active use of this edge case in order to enable more frequent PoC activity in an area. We don’t believe this particular edge case is being exploited in a widespread manner (although we do see a few instances of it). With the publishing of this HIP, however, we believe it may become more interesting to arbitrageurs.

Helium HIP 54

Here is an example of mistargeting:

HIP 55

“Validator Challenges”

Validators will now provide information to light hotspots so they don’t have to follow the blockchain themselves, saving bandwidth and easing stress on individual Hotspots.

Light Hotspots will connect to a nearby Validator or group of Validators and they will communicate with each other when their region gets challenged, the Validator will confirm or deny that a specific hotspot was challenged. Validators taking on this role will make challenges easier to complete as they are run on industrial servers (often AWS) and a faster more secure internet connection.

Currently, the challenger needs to communicate with the “challengee”, and the witnesses of the “challengee” communicate with the challenger. This isn’t an easy task with over half a million hotspots online, many with unstable internet connections and some behind relays. HIP 55 will solve this issue and regulate the number of challenges that are supposed to happen. Bandwidth usage of Hotspots will go down tremendously due to validators stepping in, putting less stress on individual hotspots. 

While current Hotspots will lose out on .9% rewards (which will go to Validators), Hotspot owners should notice that this change will come with a lot less downtime on individual Hotspots that can occur when the SD is full or when they get stuck on a block.  This should make the network as a whole more stable and therefore more attractive to industrial MNOs and MVNOs (mobile network operators such as AT&T & Verizon).

This HIP proposes a change to how Proof-of-Coverage (PoC) Challenges are generated and submitted to the Helium blockchain to allow for further network scalability and to lower the hardware complexity/cost of Hotspots. Specifically, it moves the responsibility of PoC Challenge creation to Validators and consequently proposes moving the economic reward for creating Challenges to this group as well.

Originally Hotspots were the only kind of entity on the network; they were responsible for block production, Challenges/Witnesses, etc. With the switch to Validators we moved beyond that model for block production, but we still have significant computational overhead and complexity on Hotspots as a result of the old design and constraints of Proof-of-Coverage.

This complexity has become a significant pain point, Hotspots must now keep up with a blockchain that is produced on significantly more powerful hardware and they must contend with an enormous peer-to-peer (p2p) network to route Challenges and witness reports. The global chip shortage have also made it harder to source capable hardware for building Hotspots that can meet these requirements.

To address these issues the core developers have been working on design and implementation of an alternative PoC Challenge mechanism we call Validator Challenges. In brief, Validator Challenges move the role of generating Challenges to the Consensus Group. This not only allows us to free Hotspots from the burden of following the blockchain but it also moves the entities initiating Challenges to machines with much more stable and predictable networking which reduces the likelihood of connectivity failures. Hotspots can become clients of Validators to learn about blockchain updates in general, whether or not they’re currently being challenged, and where to deliver Witness receipts.

helium HIP 55

Conclusion

HIP 54 and 55 are essential to Helium building a worldwide network. Hotspots don’t have the computing power needed to perform the tasks required as the network grows, and many Hotspots don’t have the internet connection required for a stable experience.

While some people are concerned with decreasing rewards associated with this change, we think the benefits will be with it. Individual hotspots will no longer get rewards for challenges, but these rewards were incredibly low to begin with. With the new system in place, Hotspots won’t go offline every time the SD card gets full which can account for 1-3 days in sync time. Additionally, Hotspots won’t get stuck on blocks anymore when all Hotspots become Light Hotspots. The bandwidth usage for each hotspot will also decrease significantly from ~50GB/month to ~1-2GB/month (data transfer and firmware upgrades).

The hardware requirements for new Hotspots will also decrease, making it easier for manufacturers to get involved and produce mass hotspots more efficiently. We think that this change will have a positive price correlation as Helium begins to partner with more well-known companies and the network becomes more reliable as a whole.

For additional information on how the Helium network works, what equipment is best, and the future of helium, check out our Master Guide to Helium Mining article.