Skip to content
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

Closed
jamiew opened this issue Oct 15, 2020 · 6 comments
Closed

HIP16: Random Consensus Group Election #55

jamiew opened this issue Oct 15, 2020 · 6 comments
Labels

Comments

@jamiew
Copy link
Contributor

jamiew commented Oct 15, 2020

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.

@jamiew jamiew changed the title HIP16: Randomly Elect Consensus Group HIP16: Random Consensus Group Election Oct 15, 2020
@maco2035
Copy link
Contributor

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.

@PaulVMo
Copy link
Contributor

PaulVMo commented Oct 20, 2020

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.

@maco2035
Copy link
Contributor

@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.

@PaulVMo
Copy link
Contributor

PaulVMo commented Oct 20, 2020

@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.

@jamiew
Copy link
Contributor Author

jamiew commented Oct 29, 2020

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

@evanmcc
Copy link
Contributor

evanmcc commented Nov 4, 2020

Proposed implementation for review: helium/blockchain-core#676

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants