HIP 69: Re-assertion Fee Reduction
edakturk14 opened this issue · 9 comments
HIP 69: Re-assertion Fee Reduction
- Author(s): @TheRealJohnMac50
- Start Date: 2022-07-24
- Category: Economy
- Original HIP PR: #453
- Tracking Issue: This
- Status: In Discussion
Summary
The average daily mining reward per hotspot is currently equal to around 50,000 DC; and it costs 1,000,000 DC to reassert a hotspot's location.
As a result, it would take nearly a month for the average hotspot to earn enough to pay for one location reassertion.
Therefore, if we are trying to expand the network and want hotspots in saturated areas to move into less saturated areas (or moreover in lone wolf-like areas), the current reassertion price is not viable and needs to be reduced.
Rendered View
https://github.com/helium/HIP/tree/main/0069-reassertion-fee-reduction.md
One could make the amount of the fee dependent on the ratio of the number of hotspots in the old hex to the number of hotspots in the new one.
two examples:
- old hex 10 hotspots , new hex 2 hotspots --> fee =1/5 of standard fee.
- old hex 5 hotspots, new hex 5 hotspots --> fee = standard fee
One could make the amount of the fee dependent on the ratio of the number of hotspots in the old hex to the number of hotspots in the new one. two examples:
- old hex 10 hotspots , new hex 2 hotspots --> fee =1/5 of standard fee.
- old hex 5 hotspots, new hex 5 hotspots --> fee = standard fee
This is one of many fantastic ideas. Just like the rest, it is truly a brilliant idea. However, the technical requirements to make this possible is on an extremely grand level, as opposed to simply cutting the current reassertion fee in half. Therefore, for the sake of technical implementation efficiency, it would be best to keep the proposed half reduction amount.
I agree that the technical implementation of this HIP is just a chain variable change. Specifically it's updating the value of staking_fee_txn_assert_location_v1 to 500000 (from current value: 1000000).
I'm concerned that halving the cost of assertion, however, with no other controls will only give arbitrageurs a cheaper way to adjust their asserted location (potentially more frequently) and increase the number of assert_location_v2 transactions on chain which increases chain load.
I'd be in favor of something aligned with what @BruggiR's recommendation. I think someone should do some more analysis but a framework like:
- First N location asserts paid for by the manufacturers as they are today. (1 or 2 is the case in the wild)
- Subsequent asserts are scaled based on recency of last assertion. (e.g., make it quadratically or geometrically scaled.)
- Subsequent asserts are also scaled based on number of gateways in the res N hex cell (some analysis would need to be done to evaluate whether or not this is res 5-8 but I'd lean to something in the middle)
- Make it super clear what the cost is before a Hotspot owner decides to issue the transaction. Update the explorer and tools like Hotspotty (and other planning tools) to give new owners some insight into deployment costs in a region they're considering.
I agree that the technical implementation of this HIP is just a chain variable change. Specifically it's updating the value of
staking_fee_txn_assert_location_v1to500000(from current value:1000000).I'm concerned that halving the cost of assertion, however, with no other controls will only give arbitrageurs a cheaper way to adjust their asserted location (potentially more frequently) and increase the number of
assert_location_v2transactions on chain which increases chain load.I'd be in favor of something aligned with what @BruggiR's recommendation. I think someone should do some more analysis but a framework like:
- First N location asserts paid for by the manufacturers as they are today. (1 or 2 is the case in the wild)
- Subsequent asserts are scaled based on recency of last assertion. (e.g., make it quadratically or geometrically scaled.)
- Subsequent asserts are also scaled based on number of gateways in the res N hex cell (some analysis would need to be done to evaluate whether or not this is res 5-8 but I'd lean to something in the middle)
- Make it super clear what the cost is before a Hotspot owner decides to issue the transaction. Update the explorer and tools like Hotspotty (and other planning tools) to give new owners some insight into deployment costs in a region they're considering.
Although all thought out and intelligent, your suggestions would be extremely grand technical accomplishments, that would require an unreasonable amount of work from the core dev team.
Since the core goal is to prevent any form of abuse as a result of the reassertion fee reduction, two community members (Groot and 619OTA) suggested the following, both of which would require significantly less technical work whilst achieving the same core goal.
Right now, I'm needing a core dev to advise on the possibility of excluding the reassertion fee reduction, for those inserting into a hex with 3 or more hotspots. (619OTA's idea.)
Additionally, waiting on a core dev to confirm that it would be an acceptable amount of technical work to implement a minimum 10km distance (from the original location) requirement for the reassertion fee reduction (Groot's idea.)
Finally, I'm also waiting for a core dev to confirm that it would be a reasonable amount of technical work to implement my original proposed method to prevent abuse/spoofing, which is by limiting the reassertion fee reduction to once per hotspot per year.
I agree that the technical implementation of this HIP is just a chain variable change. Specifically it's updating the value of
staking_fee_txn_assert_location_v1to500000(from current value:1000000).
I'm concerned that halving the cost of assertion, however, with no other controls will only give arbitrageurs a cheaper way to adjust their asserted location (potentially more frequently) and increase the number ofassert_location_v2transactions on chain which increases chain load.
I'd be in favor of something aligned with what @BruggiR's recommendation. I think someone should do some more analysis but a framework like:
- First N location asserts paid for by the manufacturers as they are today. (1 or 2 is the case in the wild)
- Subsequent asserts are scaled based on recency of last assertion. (e.g., make it quadratically or geometrically scaled.)
- Subsequent asserts are also scaled based on number of gateways in the res N hex cell (some analysis would need to be done to evaluate whether or not this is res 5-8 but I'd lean to something in the middle)
- Make it super clear what the cost is before a Hotspot owner decides to issue the transaction. Update the explorer and tools like Hotspotty (and other planning tools) to give new owners some insight into deployment costs in a region they're considering.
Although all thought out and intelligent, your suggestions would be extremely grand technical accomplishments, that would require an unreasonable amount of work from the core dev team.
Since the core goal is to prevent any form of abuse as a result of the reassertion fee reduction, two community members (Groot and 619OTA) suggested the following, both of which would require significantly less technical work whilst achieving the same core goal.
Right now, I'm needing a core dev to advise on the possibility of excluding the reassertion fee reduction, for those inserting into a hex with 3 or more hotspots. (619OTA's idea.)
Additionally, waiting on a core dev to confirm that it would be an acceptable amount of technical work to implement a minimum 10km distance (from the original location) requirement for the reassertion fee reduction (Groot's idea.)
Finally, I'm also waiting for a core dev to confirm that it would be a reasonable amount of technical work to implement my original proposed method to prevent abuse/spoofing, which is by limiting the reassertion fee reduction to once per hotspot per year.
Curious to know how you both feel about the final draft.
Update with this HIP (10/5), a community discussion in the Official Helium Community remains open in #hip-69-re-assertion-fee-reduction. We are holding on discussions of this HIP until a later time, but the consensus is that the core of the proposal is still valid and should be discussed later. The channel remains open for conversation.
@vincenzospaghetti as per your request, I'm confirming that Nova has agreed to do the work for this HIP, and we've reached out to vendors (via email) to ensure that they'll do the necessary work for their vendor apps.
Update: A majority of vendors have already responded to our emails, all of which confirmed that they are more than willing to do any necessary work pertaining to their vendor apps.
This has been implemented. Please see contracts on the Solana blockchain or visit this Repo: https://github.com/helium/helium-program-library.
HIP 69 was approved by the community on 9th Feb 2023 with a passing rate of 88.22%
https://www.heliumvote.com/13KaGoC2ED8kEh2sXLZ7eGWrqDUMyFH5k48VQ3LLjU5QoQidMV4
And was extended for a further 6 months from the implementation date by HIP 91
https://github.com/helium/HIP/blob/main/0091-data-driven-extension-reduced-iot-assertion-cost.md