search

helium / HIP

Helium Improvement Proposals
Apache License 2.0
580 stars 408 forks source link

HIP xx: DC reward split #193

Closed PapaOwl closed 3 years ago

PapaOwl commented 3 years ago

HIP Template

Summary

The current reward structure incentivises companies too much to install a 50$ light hotspot for the use-cases they are installing even in well covered areas, since the following will always be true with the current structure: If it is profitable for any hotspot to be in the area, it is even more profitable for a company to bring in a new cheap hotspot 1m next to the use-case that they install. Thus I propose to change the DC reward from the fastest responder to all hotspots that could have performed this duty in a timely fashion.

Motivation

The price of Hotspots will see a drastical reduce over time due to Light Hotspots having much lower requirements and economics of scale factoring in. The latest estimation on this that I saw put it at 50$ for hotspots somewhere around 2022/23. As it currently stands most use-cases are very static in nature. From the parkmeters, to parking spot counters, various environmental sensors, water leakage things and so on.

As a company you have to worry about a central question: Will the coverage last. You cannot answer that for smaller cities, because you do not know the hotspot owners. Thus this alone is already a reason to install a light hotspot as you install the use-case. Unfortunately with how it currently runs it would also mean that all the DC rewards would go to the company. There is no reason to believe that another hotspot can challenge a hotspot literally built into the use-case on this.

The company has not added coverage, but it reaps the entire reward and thus disregards all others that were already there and furthermore might even violate hex-rules and punish the other miners. However they have a good reason to do and we should not prohibit that, but we should not reward it too much either.

We have to think of those that provide coverage even in areas that don't see as much action, because a network that reaches far and wide is worth much more to companies of all kinds, than a network that only exists on top of use-cases and major population areas.

For the customer it does not matter one bit who is rewarded unless he is also the one that decided to place a hotspot on himself to get a kind of cashback on his DC useage instead of using the coverage that is already provided.

This HIP does not have an affect to areas that have no other hotspots nearby.

Stakeholders

All those already providing coverage

Detailed Explanation

I am not a code guy, but with how it looks to me currently only the resolver of a DC packet is rewarded. Hotspot 2,3 or how many there are have no way of knowing that Hotspot 1 will be faster, so they aswell will at least have tried to resolve it. Currently only Hotspot 1 would be rewarded for resolving. All others would not receive anything.

Thus we could tie the reward to the blocktime, but preferably I would set 1-2s after the resolve as cut-off to give a bonus to those that provide good and fast services.

As an example we have a use-case sending out a ping and there is 6 Hotspots that receive and try to act. Hotspot 1 was the fastest, but Hotspot 2-5 all reacted in under 1s aswell. Hotspot 6 only responded after 2 seconds now the reward is going out to to Hotspot 1-5 in equal amount. Hotspot 6 failed and is thus not rewarded. Maybe he was too far, maybe its internet is too slow.

No new rewards or price increase is happening here. The reward that would go to one guy in full before would now be equally split to all that could have handled the request well. If there is no other hotspot to begin with, then this changes nothing.

Not a code guy, so I cannot say how this would end up being solved.

Now instead of the DC rewards going solely to the new hotspot they go to all those that could also have provided the service for the use-case.

I think gamey cases are covered as long as we tie the DC output to the reward scale.

Drawbacks

The drawback is that it isn't as profitable for companies to bring their use-case and a hotspot at the same time. However I would not call this a drawback to the network, but an advantage.

Honestly I see no reason. Good coverage is done by several miners and not by a single one on top of the use-case. If we want coverage to be widespanning, then we cannot have a system that rewards placements directly on top of use-cases the most.

Rationale and Alternatives

An alternative could be to lock out new devices out of DC earnings for a time if they are placed in already settled areas, but I feel simply sharing among all is simply better.

This is your chance to discuss your proposal in the context of the whole design space. This is probably the most important section!

I know that currently we have a huge incentive to provide cover, but eventually the Network will be rewarding DC only. If companies start to plant in a well-covered area it is a slap to those already covering. In this it doesn't matter if the coverage is provided by 10 individuals or a single guy, that made sure that the city he lives in is well covered. The use-case would finally appear and the reward would rarely go to those.

If we take the example of park meters, then a company would be well advised, to incorporate the LoRaWAN directly into the design, but they also should not be rewarded exclusively on the DC. Otherwise we undermine those that provided the possibility for it to be used.

In case the network surrounding the use-case breaks down the parkmeter would keep functioning as it comes with its own device.

So this is a very good compromise between protecting companies against the failure of coverage and protecting the interest of those that already provide coverage longterm.

Maybe discussion of this HIP brings it to light. Consider this HIP as a nudge. If someone can write it better, feel free to take this idea and develop it further, but I believe as it stands it should neither be too hard to implement, nor be unreasonable to do so.

Deployment Impact

Success Metrics

What metrics can be used to measure the success of this design?

As a final note I want to greet Tim and re-offer poffertjes to be guaranteed a purchase of 5 longaps.

amirhaleem commented 3 years ago

wouldn't this mean that the owner of the sensor has to pay for the packet 5 times in your example? or where does the $ come from to pay for the additional DC rewards?

PapaOwl commented 3 years ago

wouldn't this mean that the owner of the sensor has to pay for the packet 5 times in your example? or where does the $ come from to pay for the additional DC rewards?

I hope for the payment to remain the same. The customer should not notice any difference. I am however unsure how it currently works in detail, but to me it looks like that any hotspot that hears the ping is already trying to resolve it anyhow, since they have no way of knowing that it was resolved until they have been denied.

amirhaleem commented 3 years ago

I hope for the payment to remain the same. The customer should not notice any difference. I am however unsure how it currently works in detail, but to me it looks like that any hotspot that hears the ping is already trying to resolve it anyhow, since they have no way of knowing that it was resolved until they have been denied.

but the additional rewards for Hotspots 2-5 have to come from somewhere? right now Hotspots earn HNT on a 1:1 basis with the DC spent. so either the sensor owner has to pay for the same packet 5 times, or you have to take the rewards from the PoC pool - if you do that, then there's an incentive for Hotspot owners who hear the packet once to replay the packet across all their Hotspots n times to get rewarded more than they should.

PapaOwl commented 3 years ago

I hope for the payment to remain the same. The customer should not notice any difference. I am however unsure how it currently works in detail, but to me it looks like that any hotspot that hears the ping is already trying to resolve it anyhow, since they have no way of knowing that it was resolved until they have been denied.

but the additional rewards for Hotspots 2-5 have to come from somewhere? right now Hotspots earn HNT on a 1:1 basis with the DC spent. so either the sensor owner has to pay for the same packet 5 times, or you have to take the rewards from the PoC pool - if you do that, then there's an incentive for Hotspot owners who hear the packet once to replay the packet across all their Hotspots n times to get rewarded more than they should.

No new rewards, just a split if there was other devices that could have done the job in a timely fashion

lthiery commented 3 years ago

No new rewards, just a split if there was other devices that could have done the job in a timely fashion

There's nothing to stop me purchasing the packet and then claiming my own hotspots also gave me the packet so that I can get a discount then.

lthiery commented 3 years ago

That is to say, I would operate N colluding hotspots who always happen to sell me the same packets that I purchase. I purchase and claim they gave me the packet and I get a N/(1-N) discount

PapaOwl commented 3 years ago

No new rewards, just a split if there was other devices that could have done the job in a timely fashion

There's nothing to stop me purchasing the packet and then claiming my own hotspots also gave me the packet so that I can get a discount then.

I am not sure I understand you correctly. You say that if you use the Network you could (after this hip) place a hotspot and then get kind of a cashback on that DC useage. To this I only have to say, that this is already the case now, but much higher.

Various current use-cases are very static. Park-meters, parking spots, various sensors or even water leakage. In all those cases you would currently guarantee the entire cashback on the DC, while all other hotspots further away that might be well placed for coverage cannot compete with the hotspot that is planted ontop or even inside the usecase.

lthiery commented 3 years ago

In all those cases you would currently guarantee the entire cashback on the DC, while all other hotspots further away that might be well placed for coverage cannot compete with the hotspot that is planted ontop or even inside the usecase.

yes, of course I can route my own packets for free if I have my own gateway receiving the packets. But if it’s possible for me to split a constant price with everyone that delivered me the packet, with no real hardware in range, I can relay the packets l purchase to my own gateways and get a discount. You’re introducing a very easy loop hole for coverage users

PapaOwl commented 3 years ago

In all those cases you would currently guarantee the entire cashback on the DC, while all other hotspots further away that might be well placed for coverage cannot compete with the hotspot that is planted ontop or even inside the usecase.

yes, of course I can route my own packets for free if I have my own gateway receiving the packets. But if it’s possible for me to split a constant price with everyone that delivered me the packet, with no real hardware in range, I can relay the packets l purchase to my own gateways and get a discount. You’re introducing a very easy loop hole for coverage users

Maybe you mean something way more technical than I am. Keep in mind that I am not completely aware of how the private networks you mention operate. However:

If the package resolve is currently free when you e.g. connect your sensor to your own gateway and have it resolved strictly that way, then this HIP doesn't change that. It only changes anything if there is a reward involved.

Now if we have a reward involved in this case it wouldn't matter to how many private gateways you relay it to, because the grand total will always add up to 100%. If you have 3 total hotspots, then each earns 33% down from currently 100%. If you relay it to 10, then each would be 10% for a total of 100%.

Should you do it completely publicly though, now all others that could do the job will cut into the discount you previously had on lockdown, but you will of course also get a bit more actions from outside.

Do you by any chance mean this: A wild IoT-Device screams and one of your gateways catches it and 3 public ones. You now then proceed to route that packet to 2 more of yours and getting the final reward for yourself to 50% and 50% for the 3 public ones? Is that what you mean with additional discount? Although then more profits would make sense.

This HIP is nothing different than hip 15/17 just for DC rewards. Smoothing out across a larger number of devices

lthiery commented 3 years ago

Do you by any chance mean this: A wild IoT-Device screams and one of your gateways catches it and 3 public ones. You now then proceed to route that packet to 2 more of yours and getting the final reward for yourself to 50% and 50% for the 3 public ones? Is that what you mean with additional discount? Although then more profits would make sense.

Yes, this is a variant of the exploit that I’m trying to point out. In that sense, it has nothing to do with HIP15/17 because they did not introduce exploits.

I hope you don’t get my tone wrong - i believe we all want to reward those that provide coverage. But as it stands, your current proposal has too many holes for me.

PapaOwl commented 3 years ago

Do you by any chance mean this: A wild IoT-Device screams and one of your gateways catches it and 3 public ones. You now then proceed to route that packet to 2 more of yours and getting the final reward for yourself to 50% and 50% for the 3 public ones? Is that what you mean with additional discount? Although then more profits would make sense.

Yes, this is a variant of the exploit that I’m trying to point out. In that sense, it has nothing to do with HIP15/17 because they did not introduce exploits.

I hope you don’t get my tone wrong - i believe we all want to reward those that provide coverage. But as it stands, your current proposal has too many holes for me.

No the tone is super fine don't worry about it. To address this gamey behavior we have a chance to reduce the respond time. Every relay does take time, but also I think we should be able to distinguish an IoT-scream from an additionally relayed signal.

I will later update the HIP so that it remains on the radar. I don't have enough coding background to solve this, but hopefully a dev can. Not even sure if you can forcibly gate such things to others, but realistically such a relayed signal has to be identifiable.

jamiew commented 3 years ago

Discussion aside – if you'd like to continue with this, I humbly request this HIP be put into a .md file per the standard submission process.

I have a rough overview of how to do it here: https://jamiedubs.com/blog/how-to-submit-helium-manufacturer-application/

PapaOwl commented 3 years ago

Discussion aside – if you'd like to continue with this, I humbly request this HIP be put into a .md file per the standard submission process.

I have a rough overview of how to do it here: https://jamiedubs.com/blog/how-to-submit-helium-manufacturer-application/

I will attempt to correct the issue

PapaOwl commented 3 years ago

Discussion aside – if you'd like to continue with this, I humbly request this HIP be put into a .md file per the standard submission process.

I have a rough overview of how to do it here: https://jamiedubs.com/blog/how-to-submit-helium-manufacturer-application/

Just one question can I transform this thing here to a md file or do I have to make it fresh? Cause #194 should be correct or is that wrong aswell?

jamiew commented 3 years ago

@PapaOwl this is an issue rather than a pull request, so you'd need to start fresh and issue a pull request

I'm going to close this for now but feel free to comment or re-open if you need more help