HIP 55: Validator Challenges

[hiptron]

• Author(s): @Vagabond,
  @andymck, @abhay
• Start Date: 2022-02-03
• Category: Technical
• Original HIP PR: Add HIP for validator challenges #359
• Tracking Issue: HIP 55: Validator Challenges #362 (this)
• Status: Approved

Summary

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.

Rendered view

https://github.com/helium/HIP/blob/main/0055-validator-challenges.md

[PaulVMo]

I am very excited to see this draft HIP. Moving challenge creation to validators is a huge step forward today light hotspots.

A couple thoughts to consider with regard to the load on the CG and incentives:

1. A challenge is going to trigger a lot of requests to the Challenge Validator, which in most cases will be an active CG member. This could add excessive load to the validators in CG. For example, all hotspots in a targeted hex must send a request to the challenge validator to see if it is the challengee. That is an average of 30 and max of >2000 hotspots in a hex. At the current poc interval, there are ~30,000 PoCs per epoch or ~700 challenges per validator. Add in witness counts per Poc and there could easily be tens of thousands of additional requests being made to in CG validators. At the same time, the rest of the validators (98%) remains relatively idle.
2. In this model, non-CG validators are being tasked with additional work but no additional rewards. There will be little incentive for validators to support light hotspots. I understand that this proposal leaves open future mechanisms like slashing. However, in the interim, I fear we will see validators opting out of providing the gateway service while not in CG if there is not a reward to do so.

Perhaps there could be a way to have the CG generate the challenges but assign other validators not in the CG to perform the work of notifying the challengee, collecting the witnesses, and submitting the blockchain_txn_poc_receipts_v2 transaction to the CG. The rewards from the 0.9% pool should then be given to those validators to provide incentive for them to do so.

[anthonyra]

I've also been thinking about what is currently being proposed and the past. I think we can leverage some lessons learned from the past and present to make a system that would scale better. Load on the CG being the biggest concern. I maybe missing some fundamentals with the following proposal on challenge creation and any criticism is welcome.

1. CG picks target H3 hex (res 5) appends to blocks metadata via already proposed method
2. All validators absorb the block and generates a list of all client hotspots found in target H3 hex
3. The validators with clients in target hex notifies them of challenge, those that reply will generate the "active" list txn which is then sent to the CG.
4. The CG generates the poc_request_v2 txns for the targets based on those "active" lists and target hex. All validators that returned an active list will see an associated poc_request_v2 for them in the next block.
5. When the parent validator get's the request in the next block, they simply forward the onion packet envelope to all their hotspots on the active list.
6. Only the target hotspot(s) are able to decode the envelope resulting in a beacon, the witness and beaconer return the receipts to the parent (challenger) validator.
7. The parent validator then packages those into a poc_receipt and submits it to the CG

[PaulVMo]

My thought on this @anthonyra would be similar to what the authors are already proposing - have the CG pick the hex/hotspot to be challenged, but then also pick an active, non-CG validator to handle the rest of the process of notifying the challengee, collecting receipts and witnesses, and submitting the poc txn to the blockchain - same as described in the HIP. And, reward the non-CG validator doing that work with the challenge creation rewards.

I think the added complexity is that block metadata would have to include not only the target hex, but also the details of the non-CG validator selected to do the rest of the challenge work. Also, there would need to be a mechanism for the CG member to share secret information with the selected non-CG validator including the specific hotspot in the hex and the onion key. This could potentially be encrypted with the non-CG validators public key and included in the block metadata or sent via a p2p connection directly to the non-CG validator.

The last piece of this is knowing whether the non-CG validators are active AND providing the necessary gRPC service to perform the challenge role. I propose adding an optional parameter to the heartbeat transaction that includes the gRPC listen address of the validator. If this is populated and the heartbeat meets the definition of live (i.e. withing 150 blocks of current), then the validator would be eligible to be selected to handle challenges.

CC: @abhay @Vagabond

[bkhall]

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.

Validators already have sufficient staking rewards.

Other than that, I think this will be a great improvement.

[Vagabond]

I think it would be possible for the validators to create challenge information and submit them to the group (vs the group generating them itself), then the challenging validator would remain the sole holder of any private information until the receipt was published. That challenge information could flow through the block metadata as proposed in the HIP but, as noted, would not be tied to a consensus group member under this alternative.

Doing that is now interesting because non-elected validators become invested in providing validation services to the light hotspots so they can maximize their chances of doing challenges. Because the actual challengees are unknown until the block is published, validators would be unwise to favor any specific light gateway connections because they don't know who they may need to communicate with in the future.

Then, as proposed above, the challenging validator would be in charge of constructing and reporting the receipt transaction.

[Vagabond]

I would also like to make the association of a validator and a light hotspot using that validator a trackable signal on-chain that could be used in election selection criteria down the road. This would help reward strong, reliable validators with good reputations and help align incentives between hotspots and validators if the hotspot owners are given agency over which validators their hotspots are using.

[kellybyrd]

I would also like to make the association of a validator and a light hotspot using that validator a trackable signal on-chain that could be used in election selection criteria down the road. This would help reward strong, reliable validators with good reputations and help align incentives between hotspots and validators if the hotspot owners are given agency over which validators their hotspots are using

This is in the HIP as written already, isn't it?

[kellybyrd]

So are we voting on the HIP as written or as @Vagabond described, or just the concept of moving challenge creation (and therefore the need to sync and all the related problems) away from hotspots? I'm definitely in favor of that last thing.

[anthonyra]

Another important caveat I was thinking about has to do with us shifting these rewards to the CG.

As of right now there's no incentive to have long epochs. Instead they want to have the shortest possible and most elections. If CG members were rewarded for challenges would they split the pot that was collected over the course of an epoch?

If so, that would be ~0.34 HNT per validator per epoch ideally. However, it then incentives the CG to have long epochs because sure they won't be getting the 2HNT ish per election but they can't control that. But what they can control is the length by purposely sabotaging the election. This could be unstuck with a rescue block sure, but I don't think we should provide even the chance to incentivize long epochs.

One option is to only allow challenge creation during the first 30 blocks of an election but then hotspots would get the short end of stick on a purposefully long one or an "issue" that resulted in a long block.

[Vagabond]

Yes, that's another good point for shifting things to the validator pool rather than the consensus group.

[cr9cristiano]

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.

Validators already have sufficient staking rewards.

Other than that, I think this will be a great improvement.

I would second third and fourth this sentiment. While this change will make for a more efficient network experience for consistency and the uptime of the hotspots, I absolutely do not believe that they should further allocate more share of the rewards to those who share an already disproportionately large portion of these rewards compared to the number of validators. The miners who make up the majority of this network should not have to pay the price for every change in this ecosystem. There really is no need to allocate an additional .9% to Validators in this network unless the message quite blatantly is suggesting that validators should not expect to do anything simply for the betterment of the network, while the regular miners should be expected to prop up the network of the pure goodness of our hearts and pay the price every time in terms of giving up our rewards. This was promoted as the people's network; this type of scenario feels all too similar to the world we already live in where the top 10-1% should benefit on top of their already lucrative advantages, while everyone else pays for them to be there.

[ColonelKlinck1972]

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.

Validators already have sufficient staking rewards.

Other than that, I think this will be a great improvement.

This is spot on. Rewards are in the toilet and the last thing we humble hotspot owners need is even more of the pie being taken away. Improve the network yes, but put the rewards back in the daily pool.

[anthonyra]

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.
Validators already have sufficient staking rewards.
Other than that, I think this will be a great improvement.

This is spot on. Rewards are in the toilet and the last thing we humble hotspot owners need is even more of the pie being taken away. Improve the network yes, but put the rewards back in the daily pool.

Which ever entity of the blockchain is tasked with creating challenges should be rewarded. I highly doubt you're willing to work for free so why should the entity picked to do challenge creations work for free?

[cr9cristiano]

Might I ask you, who is working for free in this network? But however, you are asking the majority to work now for less and give more to the validators for just doing/shifting a singular task to them; which still remains disproportionate to what they already earn. So please spare me such obviously rhetorical questions.

[bkhall]

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.
Validators already have sufficient staking rewards.
Other than that, I think this will be a great improvement.

This is spot on. Rewards are in the toilet and the last thing we humble hotspot owners need is even more of the pie being taken away. Improve the network yes, but put the rewards back in the daily pool.

Which ever entity of the blockchain is tasked with creating challenges should be rewarded. I highly doubt you're willing to work for free so why should the entity picked to do challenge creations work for free?

This is roughly a 17% raise for Validators - who dominate the vote, based on the way HNT weighting works.
While I support the technical aspects of this change, the large wallets typically held by Validators means they have the ability to vote themselves a raise, which calls into question whether they are voting for the change itself or the raise.

[cr9cristiano]

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.
Validators already have sufficient staking rewards.
Other than that, I think this will be a great improvement.

This is spot on. Rewards are in the toilet and the last thing we humble hotspot owners need is even more of the pie being taken away. Improve the network yes, but put the rewards back in the daily pool.

Which ever entity of the blockchain is tasked with creating challenges should be rewarded. I highly doubt you're willing to work for free so why should the entity picked to do challenge creations work for free?

This is roughly a 17% raise for Validators - who dominate the vote, based on the way HNT weighting works. While I support the technical aspects of this change, the large wallets typically held by Validators means they have the ability to vote themselves a raise, which calls into question whether they are voting for the change itself or the raise.

Hear hear! Very well said. It is extremely concerning.

[Raecaug]

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.
Validators already have sufficient staking rewards.
Other than that, I think this will be a great improvement.

This is spot on. Rewards are in the toilet and the last thing we humble hotspot owners need is even more of the pie being taken away. Improve the network yes, but put the rewards back in the daily pool.

Which ever entity of the blockchain is tasked with creating challenges should be rewarded. I highly doubt you're willing to work for free so why should the entity picked to do challenge creations work for free?

This is roughly a 17% raise for Validators - who dominate the vote, based on the way HNT weighting works. While I support the technical aspects of this change, the large wallets typically held by Validators means they have the ability to vote themselves a raise, which calls into question whether they are voting for the change itself or the raise.

Exactly this, Helium doesn't need to fall victim to same fault that US politicians do. An bird's eye rebalancing of the network's reward structure is definitely needed after so much development.

[anthonyra]

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.
Validators already have sufficient staking rewards.
Other than that, I think this will be a great improvement.

This is spot on. Rewards are in the toilet and the last thing we humble hotspot owners need is even more of the pie being taken away. Improve the network yes, but put the rewards back in the daily pool.

Which ever entity of the blockchain is tasked with creating challenges should be rewarded. I highly doubt you're willing to work for free so why should the entity picked to do challenge creations work for free?

This is roughly a 17% raise for Validators - who dominate the vote, based on the way HNT weighting works. While I support the technical aspects of this change, the large wallets typically held by Validators means they have the ability to vote themselves a raise, which calls into question whether they are voting for the change itself or the raise.

Where do you get 17%?

[bkhall]

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.
Validators already have sufficient staking rewards.
Other than that, I think this will be a great improvement.

This is spot on. Rewards are in the toilet and the last thing we humble hotspot owners need is even more of the pie being taken away. Improve the network yes, but put the rewards back in the daily pool.

Which ever entity of the blockchain is tasked with creating challenges should be rewarded. I highly doubt you're willing to work for free so why should the entity picked to do challenge creations work for free?

This is roughly a 17% raise for Validators - who dominate the vote, based on the way HNT weighting works. While I support the technical aspects of this change, the large wallets typically held by Validators means they have the ability to vote themselves a raise, which calls into question whether they are voting for the change itself or the raise.

Where do you get 17%?

5.2% up to 6.1% - that is a 17% change.

[anthonyra]

Ahh okay, well the math does check out but I still think it's the better option. I'm a proponent for who ever is left in charge of this work should get rewarded. How that rewarding is done can be negotiated. But a simple 0.9% change makes the most sense to me.

The other option would be to split the 0.9% to all the hotspots and charge the hotspots per challenge created? It'd be better for the challenger though, because hotspots rewards would be affected by network size and halvenings. But the challengers would charge the same rate per challenge.

[OrmEmbaar]

5.2% up to 6.1% - that is a 17% change.

This isn't right. Validators get 6% of network rewards. So 6% to 6.9% is 15%. The 5.1% is our APY (before costs).

Also, this doesn't mean an individual validator will earn 15% more. When you increase network rewards, more people are attracted to sign up. We'll end up back where we were with the APY, but there'll simply be more validators.

[mfalkvidd]

When you increase network rewards, more people are attracted to sign up. We'll end up back where we were with the APY, but there'll simply be more validators.

When the validator hip was introduced, the goal was to get to at least 100 validators. There are now 3,426 validators. To me, the fact that there are 34x more validators than needed shows that validators already are over-incentivized. So let's not increase the incentive further. Even if 90% of existing validators would drop because of the new work, the network would still be stable.

Also, hip25 already stated that validators would be

acting as proxies for lightweight (non-chain-following) gateways.

and

eventual changes to PoC challenge construction

so this change was announced from the beginning without mentioning additional rewards.

[mfalkvidd]

with regard to the load on the CG and incentives:

The Helium development team has made lots and lots of performance improvements to the validator code. Discovery mode was taken away, so we even have feature loss to lower the load on the validators.

The network didn't take away rewards from validators when the load was lowered, nor when disco mode was removed. Why should the network give validators more rewards now?

[OrmEmbaar]

When the validator hip was introduced, the goal was to get to at least 100 validators. There are now 3,426 validators. To me, the fact that there are 34x more validators than needed shows that validators already are over-incentivized.

That 100 validator count was an initial requirement to launch PoS, not a long term goal. In any case, network security in proof of stake networks is better measured by looking at the percentage of supply staked, which is currently 35%. This is how other proof of stake networks compare (data taken from StakingRewards):

• Solana: 75%
• Ethereum: 8%
• Cardano: 69%
• Avalanche: 60%
• Terra: 40%
• Polkadot: 53%
• BNB Chain: 84%
• Cosmos Hub: 64%

Helium's current 35% is considerably lower than any other network except Ethereum, which is an outlier because the migration to proof of stake has not actually happened yet. Helium has to pay for miners too, which is means our funding for validators is comparatively low, but I want to rebut the notion that validators are "over incentivised". It just clearly is not the case.

Frankly, I do not really care that much about taking 0.9% more of network rewards. As I have already said, those rewards will buy more validators, they won't improve the bottom line of individual validators. However, the PoC rewards are not some frivolous expenditure that will simply disappear into a black hole of growing validator count, but rather a critical component of the game theoretic assurances that a public blockchains needs to function. That is because the 0.9% will incentivise new behaviour whereby we spread work across non-CG validators. That has to be payed for, otherwise there is no assurance that validators will opt to provide the service.

Any public blockchain must properly leverage economic incentives to remain viable and robust long term. You cannot expect self-interested, pseudonymous strangers on the internet to perform work outside of their self interest. It just won't work. This goes for any actor in any crypto network, including both validators and miners on Helium.

So I get it, you're trying to take care of you income, and that is what I would expect you to do in this scenario. However, I have an eye to the future, and am not looking at this in terms of my income, which won't be much affected in the near term, but I am looking at it in terms of my capital investment. I need Helium to succeed, I need it to attract new miners and to expand the network to improve availability for ends users. To do that, we must make it as robust and scalable as possible, and this HIP is a major component of that effort.

[mfalkvidd]

To be clear: I own 0 mining hotspots and 0 validators. So your assumption that I am protecting my income is partly false. I do prefer to protect my investment in the very first OUI though, which is only valuable if the Helium network provides coverage.

Yes, we can push for the Helium Network to be like any other crypto currency. Or we can let the Helium Network do what the network was built for: provide utility in the real world by providing coverage. To provide coverage, we need hotspots. To me, the way to make Helium succeed is to expand the coverage (both in terms of new geographical areas and in terms of new connection types like 5G, wifi, etc). We don't need the validators eating an even bigger share of the value produced by Helium.

So it seems like we both want Helium to succeed. We just have very different ideas of what it takes to succeed (or maybe what it means to succeed).

[OrmEmbaar]

To provide coverage, we need hotspots

I completely agree, which is why I support this HIP. It makes hotspots much, MUCH more efficient and cheaper to run, meaning that the network can fund more of them with less. Giving validators PoC rewards is a necessary component of that because we have to incentivise the correct behaviour to make it all work.

[ColonelKlinck1972]

To provide coverage, we need hotspots

I completely agree, which is why I support this HIP. It makes hotspots much, MUCH more efficient and cheaper to run, meaning that the network can fund more of them with less. Giving validators PoC rewards is a necessary component of that because we have to incentivise the correct behaviour to make it all work.

Why? its not like the validators are just going to pack up, cash in their helium and leave. They already have a huge slice of the pie for less work than they did a year ago. Now they have to take on a bit more they should be rewarded? Did they lose some of that slice when they stopped supporting discovery mode? Their workload was reduced but their slice wasn't.

[Crisatian]

Seamna la fel de mult cu, oameni care ajung sus și muncesc din ce an ce mai puțin pe bani multi.

[bkhall]

5.2% up to 6.1% - that is a 17% change.

This isn't right. Validators get 6% of network rewards. So 6% to 6.9% is 15%. The 5.1% is our APY (before costs).

Also, this doesn't mean an individual validator will earn 15% more. When you increase network rewards, more people are attracted to sign up. We'll end up back where we were with the APY, but there'll simply be more validators.

Thank you for refining my numbers. But the point behind that thread is lost when you look at only the numbers. Let me make it again.

I support this HIP on its technical merits and what it means for Hotspots and the network at large. But I detest the idea of HNT weighted voting when part of the discussion involves rewards moving across the boundary between Hotspots and Validators. Validators will always win that vote due to their large wallets.

This HIP is only an improvement for Hotspots (performance), while also taking something away. Validators only stand to gain - or at least suffer no losses. Therefore, Validators should not have a voice in this vote, due to the their influence on the outcome by HNT weighting. Instead, this vote should be Hotspot count weighted. Then if it passes, you'd know that the Hotspot owners (as a group) fully understood the trade and elected to give the 0.9% to the Validators. In its current form, it's a conflict of interest for Validators and it feels like Validators are taking the 0.9% and there's nothing we can do about it. If the vote gets too close, a single Validator or a single HNT whale can tip the scale.

It would be interesting to see a histogram of the raw votes by HNT weight. How many raw votes have 100 HNT, 1000, 10000, 100000, etc.?
It would also be interesting to see a histogram of Hotspot count. How many raw votes have 1, 10, 25, 50, 100, 200, etc.?

[anthonyra]

To provide coverage, we need hotspots

I completely agree, which is why I support this HIP. It makes hotspots much, MUCH more efficient and cheaper to run, meaning that the network can fund more of them with less. Giving validators PoC rewards is a necessary component of that because we have to incentivise the correct behaviour to make it all work.

Why? its not like the validators are just going to pack up, cash in their helium and leave. They already have a huge slice of the pie for less work than they did a year ago. Now they have to take on a bit more they should be rewarded? Did they lose some of that slice when they stopped supporting discovery mode? Their workload was reduced but their slice wasn't.

The validators won't pack up, however there's nothing stopping an operator of a validator from not providing challenges. I know for a fact, if this work isn't rewarded that's exactly what's going to happen. And if there's no challenges being created there's no PoC.

It gets even worse when validators can "pick" the hotspots they serve. So I'd expect challenges won't go away completely they'll just be only created for those the validators want. The counter to this is just to provide the blanketed 0.9% of rewards like today that way they aren't incentivized to play favorites. They'll just create what's needed per block.

Because as it stands, validators would rather hotspots not bother them since their primary job becomes significantly easier. We want to prevent this motive

[mfalkvidd]

What prevents validators from playing favorites if they do get the 0.9%?

This is starting to look more and more like a hostage situation.

[bkhall]

Based on this morning's numbers (8AM CST on 2/19), 37% of voters are against this HIP, but due to HNT weighting this is less than 7% against.

Additionally, the displayed 93% approval likely makes those that are against this HIP, unlikely to pay the poll tax to vote, further skewing the results.

If HNT weighting was removed, 37% against is enough to block this HIP.

Because of the huge gap due to HNT weighting and polar opposite outcome without weighting, this vote should be cancelled and redesigned.

[anthonyra]

What prevents validators from playing favorites if they do get the 0.9%?
This is starting to look more and more like a hostage situation.

It's all about numbers, they can still play favorites. But the target hex is based on the block hash. They can't pick challengees. But if the only challengees are those specifically cherry picked by validators that's bad.

If anything your comment here suggests that the 0.9% might not be enough to prevent this "favoritism".

[timcooijmans]

In the light of yesterdays AMA discussion I'm a bit confused regarding validators and the terminology used in the HIP55: In the basic a non-staked validator (ie just running the validator software) is also a validator. So my question is; do the validators that light-hotspots connect to need to be staked?

My proposal would be to figure out a architecture where validators that light-hotspots connect to don't need to be staked. Light-hotspot operators should be able to select trust-worthy light-hotspot-serving-validators.

Additionally I think that there should be some thought around the direct-connection of light-hotspots to consensus-group members for delivering reports. I think this is a sub-optimal architecture and a way should be found to exchange those messages via gossip, removing a direct-connection requirement to CG members. It would be very easy to connection-starve a CG-member. By exchanging everything via gossip (which will be possible again as the network shrinks) it's much easier to run a staked validator and it's easier to scale out the light-hotspot-serving validators to handle incoming connections.

[Crisatian]

Adevarat 👍

[OrmEmbaar]

Additionally I think that there should be some thought around the direct-connection of light-hotspots to consensus-group members for delivering reports. I think this is a sub-optimal architecture and a way should be found to exchange those messages via gossip, removing a direct-connection requirement to CG members. It would be very easy to connection-starve a CG-member.

Agreed. @Vagabond, @PaulVMo and @anthonyra outlined a way to offload work to non-CG members above. Scroll up a bit.

So my question is; do the validators that light-hotspots connect to need to be staked?

Yes, they need to be staked. The language could be improved a bit to make the distinction between a validator and a chain-follower clearer.

[timcooijmans]

Yes, they need to be staked. The language could be improved a bit to make the distinction between a validator and a chain-follower clearer.

I understand that there's some trust placed in light-hotspot-connecting validators, but wouldn't it be better to have non-staked or less-staked light-hotspot-serving-validators? This would make it easier to scale out the light-hotspot-serving stack while not risking performing bad and getting penalties while in the CG because you still have to serve those light-hotspots.

[OrmEmbaar]

I agree that does sound like a pretty good idea. The 0.9% could be used to incentivise a new, small class of PoC challengers with a low stake, say 100 HNT.

[kellybyrd]

but wouldn't it be better to have non-staked or less-staked light-hotspot-serving-validators?
Agree with the less-staked part.

We have to be careful to not let the system be easily gamed. IMO, there has to be "friction" to spinning up a bunch of these "hotspot serving nodes" so that gamer can't spin up too many and control challenge creation. Does that friction have to be 10,000 HNT? I don't think so, it's certainly easier to make the existing validators do this, but a new class of node with a small stake (or some other source of friction) seems like a good way to let more folks spin these up.

[FreekHub]

So what does this actually mean for people owning a miner? How much less will we get? Because I recently acquired a hotspot and my placing is good, still rewards are pretty disappointing. Now they are getting even lower? I'm starting to think I'm better off selling the thing for a profit now.
Also just checked the votes, 99.6% in favor of this? How?
Are the hotspot owners even voting?
BTW they charge HNT to vote? I barely have 2 HNT after a month of "mining" so yeah looking at these odds I rather keep it than vote for jack...

And yeah all this "the people's network" stuff so you basically need to have or buy 10K HNT to becaome a validator and actually make anything from it and also if you are just a lowly hotspot owner with only a few HNT your vote doesn't really count?
So basically it's "the rich people's network".

[TXR72]

I continue to have a massive issue with the way these HIPs are developed amd then voted upon. Apart from yelling your thoughts into the forest on Github or Discord, not knowing if your ideas are even heard, the normal hotspot owner has no way of really influencing these HIPs. Then they suddenly go to take-it-or-leave-it votes with a few large wallets determining the outcome, despite many detail questions still being unanswered. This is a pseudo-democracy and a PERFECT setup for wallet-biased network development into the future.

On that note, why not allow hotspots to vote themselves into our out of the challenge creation process? Why render 500'000 mini-computers useless (plus the hundreds of thousands currently on order), especially with the current chip shortage? That's a massive waste.

If I have well-performing "heavy" hotspot with good backhaul bandwidth, I may not mind the workload and may want to share in the 0.9% HNT allocation. If I prefer to buy a cheaper hotspot or have issues with my cell backhaul data usage, I may forego that income and opt out.

Heavy hotspots that opt in should be equal to validators when it comes to challenge creation.

This gives hotspot owners a choice and helps to counteract all the centralization trends we've been seeing in the Helium network.

[cr9cristiano]

I continue to have a massive issue with the way these HIPs are developed amd then voted upon. Apart from yelling your thoughts into the forest on Github or Discord, not knowing if your ideas are even heard, the normal hotspot owner has no way of really influencing these HIPs. Then they suddenly go to take-it-or-leave-it votes with a few large wallets determining the outcome, despite many detail questions still being unanswered. This is a pseudo-democracy and a PERFECT setup for wallet-biased network development into the future.

On that note, why not allow hotspots to vote themselves into our out of the challenge creation process? Why render 500'000 mini-computers useless (plus the hundreds of thousands currently on order), especially with the current chip shortage? That's a massive waste.

If I have well-performing "heavy" hotspot with good backhaul bandwidth, I may not mind the workload and may want to share in the 0.9% HNT allocation. If I prefer to buy a cheaper hotspot or have issues with my cell backhaul data usage, I may forego that income and opt out.

Heavy hotspots that opt in should be equal to validators when it comes to challenge creation.

This gives hotspot owners a choice and helps to counteract all the centralization trends we've been seeing in the Helium network.

Quite a clever and fair suggestion to resolve/solve this whole .9% allocation dilemma. I can only hope that the ones responsible for this project are as reasonable when it comes re-envisioning the way we vote in this ecosystem, as well as exploring a new weighted system voting perhaps.
This idea certainly has true decentralized fairness in mind.

[edakturk14]

The HIP has been approved via heliumvote, with 96.3% voting For HIP 55.

On behalf of the DeWi, the HIP Editors, and the wider Helium community, I am marking this proposal as approved and recommending that the coredev team implement the necessary changes as soon as reasonably possible.

[prasad-yashdeep]

When will the HIP 54 and HIP 55 come in action and the hotspots will no longer be relayed @edakturk14 @hiptron

[jthiller]

Hardware is currently active on Testnet.
For most up-to-date timelines on light hotspot rollout, please refer to https://docs.helium.com/mine-hnt/light-hotspots/#development-timelines