HIP 60: Entity-Weighted Voting

[edakturk14]

HIP 60 : Entity-Weighted Voting

• Author(s): @cvolkernick
• Start Date: 2022-04-28
• Category: Governance
• Original HIP PR: HIP xx: One Miner, One Vote #395
• Tracking Issue: this
• Status: In Discussion

Rendered view

Read the HIP:

https://github.com/helium/HIP/blob/main/0060-entity-weighted-vote.md

Summary

Currently HIP votes are conducted via wallet signatures at heliumvote.com; this proposal suggests further improvement
by allowing/constraining a given wallet's voting power to equal the total number of hotspots (unique b58 addresses) in said wallet.

[jamiew]

@cvolkernick I updated title here as well for your latest PR #407

[westonkershaw]

This looks like a great proposal!

[gtelnet]

The first sentence in this HIP states "voting power to equal the total number of network entities", but in no way does the quantity of entities someone has, indicate how much value they bring to the network. i.e., you can have hundreds of poorly placed hotspots in NYC with a TSR of .02 and bring less value to the network than someone who has a few dozen optimally placed hotspots with a TSR of 1.0. Same for validators - if someone runs 10 poorly managed validators that constantly run out of disk space and crash, they bring less value to the network than someone who runs 5 properly maintained validators with 100% uptime.

While it may have its own struggles, the truest form of how much value someone brings to the network on a daily basis is already in place - the HNT rewards system.

Perhaps there's a way to use the "Actuals" emission schedule from Helium Analytics to allocate the percentage of votes across entities and then weight the votes within each entity, based on how much HNT you've mined or how much DC you've burned over the last 30 days.

HST owners comprise 33% of total voting power
Validators - 8% (as of May 11th)
Hotspots - 33% (until DC burn increases)

For each of above groups, the total weight of each vote is prorated amongst all those who choose to vote, based on how much HNT each of them has mined over past 30 days.

Customer voting power could be based on the percentage of rewards given for DC usage, as shown on Helium Analytics - currently .05%. The weight of their votes would be prorated amongst each voting customer, based on how much DC they each burned over the past 30 days. Until DC burn reaches the target, their voting power could be evenly distributed amongst the Miners/HST/Vals, thus not giving any one of these groups more voting power than the other two combined, until DC burn increases.

Something along these lines accomplishes a few things:

1- Distributes the voting power across the three interested parties - Miners/Investors/Customers. I personally think giving customers the ability to vote is great for protecting their investment in DC as well as their investment in developing technologies to utilize the network. When I build a network for a paying customer, they certainly have a say in the design, as we need to design it in a way that supports what they want it to do. Customers are People. Without customers, there is no need for the People's network. Customers will most certainly propose HIPs down the road, so they should also be able to vote on those HIPs.

2- By using HNT mined over the past 30 days in the pro rata calculation, it future proofs voting, by giving the power to those who, at the time of the vote, provide the most utility to the network, as opposed to those who got in early, or those who provided utility in the past, or those just purchasing HNT as an investment. i.e., if your 5 hotspots produce 1 HNT per day and mine produce .5 HNT, I get half the voting power of you. That is a very measurable/accurate method of how much utility each person/device brings to the network and its customers.

3- Gamers only have voting power until they are identified/shutdown, at which point they stop mining HNT and lose voting power.

4- Encourages HNT holders, who wish to vote, to stake their holdings so that they can mine HNT and gain voting power. The more you stake, the more you mine, the more voting power you have.

5- For validator operators who feel that 8% of total power might be too low, consider for a moment that many HST holders are likely to stake their HNT earnings to validators, so would most likely vote similar to validator operators.

6- Using a political analogy, this creates 3 parties - Miners/HST/Customers - none of which can individually win a vote, thus requiring each HIP to have support from at least two of the parties.

[waveform06]

The first sentence in this HIP states "voting power to equal the total number of network entities", but in no way does the quantity of entities someone has, indicate how much value they bring to the network. i.e., you can have hundreds of poorly placed hotspots in NYC with a TSR of .02 and bring less value to the network than someone who has a few dozen optimally placed hotspots with a TSR of 1.0. Same for validators - if someone runs 10 poorly managed validators that constantly run out of disk space and crash, they bring less value to the network than someone who runs 5 properly maintained validators with 100% uptime.

While it may have its own struggles, the truest form of how much value someone brings to the network on a daily basis is already in place - the HNT rewards system.

Perhaps there's a way to use the "Actuals" emission schedule from Helium Analytics to allocate the percentage of votes across entities and then weight the votes within each entity, based on how much HNT you've mined or how much DC you've burned over the last 30 days.

HST owners comprise 33% of total voting power Validators - 8% (as of May 11th) Hotspots - 33% (until DC burn increases)

For each of above groups, the total weight of each vote is prorated amongst all those who choose to vote, based on how much HNT each of them has mined over past 30 days.

Customer voting power could be based on the percentage of rewards given for DC usage, as shown on Helium Analytics - currently .05%. The weight of their votes would be prorated amongst each voting customer, based on how much DC they each burned over the past 30 days. Until DC burn reaches the target, their voting power could be evenly distributed amongst the Miners/HST/Vals, thus not giving any one of these groups more voting power than the other two combined, until DC burn increases.

Something along these lines accomplishes a few things:

1- Distributes the voting power across the three interested parties - Miners/Investors/Customers. I personally think giving customers the ability to vote is great for protecting their investment in DC as well as their investment in developing technologies to utilize the network. When I build a network for a paying customer, they certainly have a say in the design, as we need to design it in a way that supports what they want it to do. Customers are People. Without customers, there is no need for the People's network. Customers will most certainly propose HIPs down the road, so they should also be able to vote on those HIPs.

2- By using HNT mined over the past 30 days in the pro rata calculation, it future proofs voting, by giving the power to those who, at the time of the vote, provide the most utility to the network, as opposed to those who got in early, or those who provided utility in the past, or those just purchasing HNT as an investment. i.e., if your 5 hotspots produce 1 HNT per day and mine produce .5 HNT, I get half the voting power of you. That is a very measurable/accurate method of how much utility each person/device brings to the network and its customers.

3- Gamers only have voting power until they are identified/shutdown, at which point they stop mining HNT and lose voting power.

4- Encourages HNT holders, who wish to vote, to stake their holdings so that they can mine HNT and gain voting power. The more you stake, the more you mine, the more voting power you have.

5- For validator operators who feel that 8% of total power might be too low, consider for a moment that many HST holders are likely to stake their HNT earnings to validators, so would most likely vote similar to validator operators.

6- Using a political analogy, this creates 3 parties - Miners/HST/Customers - none of which can individually win a vote, thus requiring each HIP to have support from at least two of the parties.

Trying to get my head around what you propose: Till then some questions/points
(1) Confirming who you referring to as "Customers", do you mean Sensor owners and you are counting DC burned as their power (not DC purchased)
(2) Hotspots - 33% (until DC burn increases) .... well that's 59% (until DC burn increases) when it decreases to 33% or even less
(3) There seems be an assumed relationship between HNT distribution and ownership. What about a HST owner with lots of validators. Your point 2 would seem to indicate that HST owners would still have overall control as 33% of 30 days worth of HNT "mined" would be concentrated in a handful of people., who could easily swing a vote (note that only 1 HST holding account (in 100 richest HNT holders) seems to vote)
(4) on your (4) I don't think it would encourage staking unless they have over 10K as under 10K and the validator owner controls what it votes for.
(5) on your (5) - seems to indicate that the ability to control 8% of the vote can be improved by getting HST owners to invest I validators..... but HST already control 33% I think is what you say. Why change from one to another or dilute?
(6) Not sure why HST owners are now one of 3 parties, HST is an ability to earn HNT just like a hotspot/validator is an ability to earn HNT. Again as previous, why give 33% of the vote to a handful of people who are (a) mainly not voting now (b) can wildly swing a vote if they do.

[gtelnet]

Who is it you're referring to when you write: "a handful of people who are (a) mainly not voting now (b) can wildly swing a vote if they do." ?

[waveform06]

Who is it you're referring to when you write: "a handful of people who are (a) mainly not voting now (b) can wildly swing a vote if they do." ?

HST holders

[gtelnet]

Who is it you're referring to when you write: "a handful of people who are (a) mainly not voting now (b) can wildly swing a vote if they do." ?

HST holders

Based on conversations in this HIP's discord channel, the OP believes (most likely, correctly so) that the HST holders and early adopters currently control all votes, because votes are weighted on HNT holdings, and HST owners/early adopters hold the most HNT. They seem to differ on your point of "mainly not voting now" and rather, feel that they already "wildly swing the vote". The author also elaborated in discord on the portion of the HIP summary that reads, "rather than by the balance of a voting wallet", where they don't feel votes should be weighted based on how much HNT someone holds, as this gives the voting power to the wealthy, the HST holders, and early adopters. I agree with those points.

The author also wrote "The vote should be weighted accordingly to incorporate the relative network utility value contributed by a given entity respectively.", which I also agree with. However, I don't feel that simply buying/asserting a hotspot brings value to the network, so I don't feel that every hotspot asserted on the blockchain deserves an equal vote (see my original post for why). My original post was simply trying to point out that an actual metric for his desired "utility value contributed by a given entity" already exists - the HNT rewards system (see example in first paragraph of my op). HNT rewards differ dramatically from one hotspot to the next, so I thought the weight of each vote should be based on that same metric.

Here's some clarification on your questions:

(1) Confirming who you referring to as "Customers", do you mean Sensor owners and you are counting DC burned as their power (not DC purchased)

Correct, anyone who burns DC to utilize the network. Yes, was saying to use their burned DC as the metric for weighting their vote. I was trying to come up with a way for the customers to be represented, which some people feel strongly against. Was also trying to mitigate someone simply buying DC to increase their vote's weight (we'd be right back where we started). The thinking was that it would be too much trouble for them to try and burn that much DC, simply to increase their vote's weight. And once DC burn has reached target, with tens of thousands of paying customers, it would be pretty difficult to game the system just by buying/burning DC. Those are assumptions, and would need a lot more input from people who are much more knowledgeable about that.

(2) Hotspots - 33% (until DC burn increases) .... well that's 59% (until DC burn increases) when it decreases to 33% or even less

Correct on all accounts. I referred to this when I wrote "Until DC burn reaches the target, their [the Customers] voting power could be evenly distributed amongst the Miners/HST/Vals, thus not giving any one of these groups more voting power than the other two combined, until DC burn increases."

(3) There seems be an assumed relationship between HNT distribution and ownership. What about a HST owner with lots of validators. Your point 2 would seem to indicate that HST owners would still have overall control as 33% of 30 days worth of HNT "mined" would be concentrated in a handful of people., who could easily swing a vote (note that only 1 HST holding account (in 100 richest HNT holders) seems to vote)

Using the Target Emissions as the max cap that any group of voters makes up eliminates any one group from controlling the vote. i.e., HST voters make up 33% of the total weight of the vote (not they qty of the total votes cast). Perhaps the other HST holders are voting with their validator wallets and not their HST wallets.

(4) on your (4) I don't think it would encourage staking unless they have over 10K as under 10K and the validator owner controls what it votes for.

Correct. I was referring to large HNT holders. And perhaps there will eventually be a non-custodial partial staking service that would allow smaller HNT holdings to stake and earn rewards directly, so they can vote.

(5) on your (5) - seems to indicate that the ability to control 8% of the vote can be improved by getting HST owners to invest I validators..... but HST already control 33% I think is what you say. Why change from one to another or dilute?

HST wouldn't change from one to the other. The HST holders would simply stake their HNT earned, from their HST holdings. In effect, if HST holders and validator operators voted together on something, it would amount to 41% of the total vote's weight.

(6) Not sure why HST owners are now one of 3 parties, HST is an ability to earn HNT just like a hotspot/validator is an ability to earn HNT. Again as previous, why give 33% of the vote to a handful of people who are (a) mainly not voting now (b) can wildly swing a vote if they do.

See above. And HST are already at the party. Heck, they were some of the first people at the party :)

In summary, I agree with the author's goal, just not with their ideal vision of "Ideally voting should at a minimum use a 1:1 correlation between participant stake in the network (i.e. each hotspot purchased / onboarded...", so I was simply chiming in with some more ideas that might help fine tune the HIP. I feel that if any change to voting will ever be made, it needs to take everyone in mind who is involved in the project, not just the people who the author feels are important to the project, as they too will be voting on this HIP. EDIT: The last sentence is referring to the Stakeholders as defined in the HIP as: "-Hotspot Owners -Validators -Routers / Console Operators / Service Companies", which clearly excludes the original investors, a.k.a. HST holders and future Customers.

[cvolkernick]

In summary, I agree with the author's goal

Just curious -- what is the perception of what the goal is? How would you summarize it? I'm interesting in what the general understanding is as far as the axiomatic principles are in other peoples minds.

I feel that if any change to voting will ever be made, it needs to take everyone in mind who is involved in the project, not just the people who the author feels are important to the project, as they too will be voting on this HIP.

I would say that this is at the core of the HIP....deciding who is and who isn't "important to the project".

I would never argue that my idea of who is and who isn't is the only one that matters. But it certainly seems up for debate.

[gtelnet]

In summary, I agree with the author's goal

Just curious -- what is the perception of what the goal is?

The one you wrote in the HIP: "There is a need to further constrain the HIP voting process such that influence in vote cannot be "bought" by holding large balances in wallets"

[cvolkernick]

In summary, I agree with the author's goal

Just curious -- what is the perception of what the goal is?

The one you wrote in the HIP: "There is a need to further constrain the HIP voting process such that influence in vote cannot be "bought" by holding large balances in wallets"

The simplest solution would be to require KYC to participate in voting, but that in and of itself is highly contested, both in terms of privacy maximalism and how KYC would even be implemented.

Discernable / identifiable "unique identities" (i.e. hotspots, validators, routers) seem to be the next closest available thing to KYC. There's really no other way to "enforce" limitations on votes as far as I can tell.

[liamgibbins]

It would be a community driven voting system and more fair than the current hnt based system.

They will never go for this as it doesn't fit the business model or strategy

[syuan100]

@cvolkernick why not a decentralized identity attestation service? There's some potential solutions that do zk-KYC cryptographically and allow users to prove their identity without revealing it.

OnRamp by Bloom is a good enterprise example, though there may be others in the DIF that might provided similar services that can be evaluated.

[vincenzospaghetti]

It looks like this HIP is stale and we are moving to close it. It also proposes a new voting mechanism incongruent with HIP 70 and vote escrowed tokens (veHNT) as in HIP 51-53. We've archived the corresponding channel in Discord. Thank you to everyone who participated and contributed to this HIP! You make the network great. Post-HIP 70 implementations, the authors have said they may bring this back (or something like it). Thank you!