-
Notifications
You must be signed in to change notification settings - Fork 408
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HIP 10: Usage-based Data Transfer Rewards #32
Comments
I like the method of re-allocation and your first example (where DC throughput is very low) it seems appropriate yet doesn't overly reward challenge creation which is a concern for DIY (1% to ~1.4%). Thoughts on a reward above 1:1: One sample txn: CbJqCDWuuBIht-tWuHMPqK6XTZjXosOYFfwUef5UwDs the hotspot running the most amount of data (dapper-hickory-meerkat) sent 282,310 DC in a state channel (which I believe is 25 blocks long, roughly 1 epoch). This represents $2.82 in DC so other people performing a similar game as dapper-hickory-meerkat would be able to gain $0.28 per epoch per hotspot or $13.44/day, $408/week. This is a decent amount of money but not near the $21,000/week the gaming hotspot is currently earning and may not be motivation enough for others to implement such a sophisticated exploit (all other hotspots even with significant mining data are around 1/7th to 1/20th this volume of data). That said I am not sure what is gained by providing such a reward either. Other Notes
|
Upon first read I am in support of this as is. I think it creates opportunity for continued network growth in the US and EU while incentivizing the usage of DC to promote network usage. I’m going to continue to read the discord discussion and will edit if my position changes. |
I've also been thinking about this as a solution. It would indeed link network traffic to the reward for providing the network access to the traffic. (ie 1DC burnt to send data is earned by the hotspot who acquired the data packet to move) Which I feel is the intention of the DC Reward pool that's allocated each epoch. What I don't know is how having one of the chain variables being that fluid. If a hotspot for whatever reason didn't get the updated value how does it know? What will happen if it can't be validated in time? I remember the team pushing the urgency of making sure the blockchain was up to date with the variables week(s) before implementation. We would be effectively doing the same but every 30 mins instead of a one time off event. However, with the above proposal, it would mean that right now 14HNT would be distributed to the hotspots routing data. The one that brought this all to light would earn $145 worth of HNT which is the same amount spent on the DC themselves (if in fact, it's their own DC). The remaining allocation should indeed be pumped into Hotspot Structure Reward to return the focus to building the network out until network traffic really picks up (at which point the network should be there able and willing to provide the coverage) An addition that might be noteworthy is having a hardware cap per hotspot. Based on 1DC per 400ms on one of the 8 channels would result in a hardware cap of ~$0.462 (46,200 DC) transferred per epoch. However, this would be also depending on how long an epoch is... whitepaper wants it to be 30 mins but for example right now is 38.5 mins. Which the above example is based on the 38.5 mins. If it was an ideal cap it would be 36,000 DC or $0.36 per epoch. This cap would also ensure that no hotspot transferring legitimate data would drop any because it could be illegitimate due to its traffic as if an arbitrary low cap was set. But the truth is it's in NYC park and there's a dog show occurring for example. |
I am a strong supporter of leaving the system as is, or a completely different capping system. The network will correct. This HIP is a knee jerk reaction. There's been an evolution of hotspot owners disproportionately mining tokens since day 1. It all started with people who live in Austin. They raked in HNT as a group of just a couple hundred hotspots at the same 5M HNT/month as today. As the network grew to early adopters across the country, those who understood that being part of challenges was how to make the most HNT bought and arranged at least 3 HS and made a killing. Next it was the RF engineers that figured out that you could hide multiple hotspots in a closed location and spoof their locations. They made a killing. Next it was the social group that had lots of connections and were able to build expansive networks using personal and business contacts to place hotspots in many locations. They made a killing. Now, it's the coder / Arduino geeks that are leveraging the current token economics to turn DC purchases into HNT mining. They are making a killing. All of these types of people are important in building a strong network and they should all have an opportunity to make a killing if they invest the time and effort. I would argue that incentivizing people to learn about LoRa, build sensing/communicating devices and load test the network is an extremely important part of expanding the utility of the network. How many new business ideas will spring forth once when more hotspot owners dig in and learn more about LoRa and sensing devices. There are many hotpot owners that bought them and have no clue what LoRa even is or how it works. They just know they can hook it up to their home network and it mines crypto currency. From a capping standpoint, I am not in favor of changing the HNT payout ratios dynamically or staticly. Instead, I suggest maxing out the data credit transferred total for rewards to the total mined by the Nth highest uniquely-owned hotspot. 20 might be a good number. So if the top 20 hotspots range from 100K to 18K DC transferred in a epoch, they each receive HNT rewards as if they transferred 18K DCs. This prevents a few hotspots from taking the vast majority of HNT intended for data transfer, keeps the rewards system in place (changing makes the system seem unstable to the public), and, most importantly, continues to incentivize hotspot owners for investing their time and effort into LoRa devices. |
I agree with Tommmy-D. I'm worried that we are overturning a key tenet of blockchain/programmatic rewards structures because there is some unease over a short term arbitrage. The community debated these points extensively earlier this year and it was largely determined that holding to the structure was a good precedent to maintain. I do think that there is a considerable value that comes from large scale data transmission even if a significant portion of this isn't 'real' data. Over the last few weeks the system has been stress tested and improved massively as a result of the DC incentive. The incentive to dive into these issues is dramatically reduced with this current proposal and I think you'll see a corresponding reduction in the attention paid by the community to the underlying robustness of the network. I am a proponent of a cap on per epoch per hotspot earnings of, something in the 10 HNT range. That provides plenty of incentive for data transmission while removing the edge cases like the Dapper hotspot. I'd combine this with redistributing the additional HNT over the cap evenly to all hotpsots that participate in any data transmission that epoch. Some basic modeling showed that would result in approx a 20X increase in rewards for the long tail of data transmitters and those units pushing the majority of the 'real' data. This will also incentivize the development and adoption of smaller DC transmitting real-world devices like tabs and dog collars because the even distribution of DCs over the cap will benefit these hotspots the most. Furthermore, having a heavy DC incentive gives the community a wonderful tool for strategically promoting the development of key regions. I propose that there is a community-driven fund that places data transmitters in areas where we'd like to see development. That will encourage the rapid development of that city or area. I'd suggest this happens in key cities as well as along highways to promote the coverage of our roadways, which I believe is current weak point in the coverage mapping. There are enough benefits to a heavy DC incentive that I think it is worth keeping those in place while controlling for the edges. There are issues with a cap system, but they do not become meaningful until DIY mining comes into place, which gives the community time to figure out how to confirm DIY hotspots, to confirm large scale cloud device mining. Even if that does occur, the arbitrage will quickly be worked out of the market anyways. I strongly believe that the network will be better off keeping a controlled but aggressive DC transmission incentive. This was built into the initial framework with good reasoning that still holds. There are improvements that should occur, but I believe if we look past the next few months the system will be more robust by keeping the current incentive structure. In 5 years nobody will remember or care about this short blip on the map and I'd rather accelerate the development of the network in the meantime. |
Each hotspot doesnt know or care about this, its the consensus group that will calculate it when dividing up rewards so there is no risk of a hoptsot being confused because its a few blocks behind.
I am not sure that is accurate as a theoretical upper limit, first you can send a 242 byte payload in a LoRa packet which is 10DC worth. 242 bytes at SF7125K data rate will take ~400ms of on-air time so that may be where the 400ms comes from. So you could theoretically receive 10DC in 400ms = 25 DC / second per channel (45,000 DC / channel / epoch). So supposedly you could have 360,000 DC / epoch. That being said I do like the idea of a DC cap because even this theoretical limit would be INSANE in any real-world application. |
I'm not that familiar with the hardware but I knew a limitation existed. When asked I was informed that you could at max based on LoRA transmit 242bytes of data every 400ms per channel. Reading the documentation yes 1DC is 24bytes so I can see where 10DC = 242bytes payload. But I think a cap wouldn't be necessary if the 1:1 is implemented. Now a flag could be in place to help with issues / concerns of future use. |
@anthonyra agreed 1:1 eliminates any advantage to running data through your hotspot so no need to cap. Well there is a slight advantage if you assume HNT value will increase and you want to buy HNT for USD without going to a 3rd party exchange (I know, no talk of HNT markets but this is an important point). You an effectively buy HNT for USD by running data through your hotspot at the oracle price. So there may still be some people choosing to run data through their hotspot solely for the purpose of mining if they feel the oracle price is low, either due to expected future growth or if there is a secondary market buyer at a price higher than oracle. If this HIP is implemented it will be interesting to see if this ever occurs, as secondary market pricing could cause a rapid spike in data traffic if oracle is slow to react (another arbitrage situation) |
The example table with low data usage seems wrong, the percentages add up to 80% not 100% should be:
|
I think the above redistribution needs some work. The reason is how each reward pool above is distributed. Rural / Single Hotspot - Due to its location, it can't perform in PoC as a Challengee or Witness. These can be individuals that are trying to build out a hotspot for Agriculture or an individual that is investing in helium to claim their spot in the growing network. Grouped Hotspot - They have 2 or more hotspots within RF range of their location. Allowing them to take part in all aspects of PoC. Consensus Group - Are specific hotspots that are selected based on their score and geography. There are currently 4 groups consisting of 16 members each. https://developer.helium.com/blockchain/consensus-protocol The tables are based on the following example:
Current Proposed Distribution: Per Month The above distribution would incentives the abuse that some consider is occurring in Port Huron. It would also lower the incentive for new hotspots in areas that don't have coverage yet (which is currently active). In the US that would be mostly rural areas with agriculture, weather, or the like being the focus. However, when it comes to Europe there's a handful of cities that would fit that category for not having any hotspots. This isn't that big of a deal if you have companies or an individual that has the capital to start out the gate with the ideal number of hotspots to take part in all of the above PoC rewards. (2-3 hotspots) $1350 but probably not a hobbyist or individual looking at ROI. The following proposal heavily relies on the following HIPs to be eventually be implemented. Ideally, HIP 10 will be first with the below distribution followed by HIP 5 and then finally with HIP 9. HIP 5: https://github.com/helium/HIP/blob/master/0005-poc-fairness.md In regards to HIP 10 my proposal wants to redistribute the reward pool from Data Network Transfer to the PoC Challenger pool in preparation for my HIP 5 proposals. This distribution in the meantime before HIP 5 implementation (if implemented) would incentives the expansion of hotspots into virgin coverage areas while limiting the problem in Port Huron. New HIP 10 Proposed Distribution: Per Month My HIP 5 that builds off of the above redistribution scheme is as follows: It suggests a change to the Beneficiary for that reward pool and applying a restriction to what a Rural / Single Hotspot should be considered and splitting the Consensus Group into two individual parties. It also recommends a change in the limitation on a hotspot in regards to being a challenger. The current limitation for being a challenger is that each hotspot on the network can only be a challenger for a PoC proof once an epoch. Removing the grouped hotspots will drastically reduce the overall PoC proofs being submitted to the blockchain. To compensate I suggest allowing the Consensus Group Candidates (currently at 2528) the ability to fill in the rest. For Example: With the 33.45% each challenger will earn roughly 0.16 HNT per epoch. This will provide virgin coverage area hotspots (Rural / Single Hotspots) better incentives than currently and also provide known good hotspots (Consensus group worthy hotspots an additional incentive for having a high S word) New Definitions: New HIP 10 with HIP 5 Proposed Distribution: Per Month With the HIP 10 distribution and the new limitation on the beneficiary per reward pool in regards to PoC the max a grouped hotspot could acquire per month is now at 24.55% instead of 58%. Consensus Group and Rural/Single hotspots will have an increased reward pool in the interim where network traffic hasn't reached its max at 32.5%. However, once data traffic does catch up than those rural hotspots will become useless in terms of minting HNT. |
The gamification incentivizes hotspot owners to learn to create end node devices, and helps provide data for the network. The problem will resolve itself once data usage is more widespread. |
This is for discussion of HIP 10.
Rendered HIP view: https://github.com/helium/HIP/blob/master/0010-usage-based-data-transfer-rewards.md
The text was updated successfully, but these errors were encountered: