-
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
HIP16: Random Consensus Group Election #55
Comments
I think this a good idea. But I think there should be some weight to the hotspots. Like they must complete X% of there challanges, etc. So that hotspots that do challenges get some work done. And after that, you can randomly choose the hotspots. This would eliminate people from just having 1000 of them in their basement that do nothing and just submit challenges and get the occasional consensus group. But removing the score, and putting a percent of PoC would make it easier to track how your hotspot is doing, and filter non working ones out, and give people a more transparent way to see how it is going. |
I'm all for some sort of more meaningful score or a filter as you suggest @maco2035. The difficulty is coming up with one that measures CG performance and only CG performance. Measuring PoC % or anything related to coverage frankly, opens it to gamers or people with hotspots that don't provide meaningful coverage. Doing CG work, is a distinct function for the network. Until helium moves to a proof of stake model for CG, then I think it is better to eliminate any filtering or metric related to PoC performance from the election process. Randomly selecting among all "properly functioning" hotspots makes the most sense to me. For the purposes of this HIP, there is a filter to make sure a hotspot has issued a challenged within a certain number of blocks. This prevents an offline hotspot from being elected and hurting performance. Unfortunately, I don't think there is a way to otherwise exclude the "1000 hotspots in a basement" scenario you mention. And, to be fair, they are doing meaningful work, unrelated to coverage. This will at least reduce the share of the CG reward pool allocated to gamers with artificially high scores. And, hopefully some of the other proposals in the works around PoC help address gaming / closet hotspots. |
@PaulVMo I understand that, but again I would like hotspots that are able to do PoC or some other metric. Because even if you do a small X% in the last Y time. You will have a minimum. It is like saying you must be this old to go gamble. But I think your idea of saying the hotspot should be "properly functioning" is a good idea, I think that should be the min for this hip to be accepted. |
@evanmcc Can you provide some more detail in the HIP around what makes an active hotspot to maco2035's comment? I think we have discussed it in Discord that it is that a hotspot has issued a challenge in the last 120 blocks. |
Rough consensus among the community was discussed and ratified at the October 2020 community call: https://docs.google.com/document/d/1bMm2alBigBj3detA775Dn0Gz9UM5XczAeK9vnjBB3l0/edit#bookmark=id.1isrxrlxktk9 Next steps are writing an actual implementation, reviewing, testing and deploying |
Proposed implementation for review: helium/blockchain-core#676 |
Author(s): @PaulVMo
Initial PR: #54
Start Date: 2020-10-14
Category: Economic
Rendered view:
https://github.com/helium/HIP/blob/master/0016-random-consensus-group-election.md
Summary:
Changes to the election process for Consensus Group (CG) members to make all active hotspots equally likely to be selected to the CG instead of the current functionality that favors hotspots with a higher hotspot score.
The text was updated successfully, but these errors were encountered: