Problems of 30 votes per EOS

HarveyMengHarveyMeng Posts: 3 Brand New

by Harvey Meng, from EOS Union

I think that changing EOS from one vote per EOS to 30 votes per EOS is not a good decision.

It should ensure that the 21-node relationship is divided in order to achieve a greater degree of decentralization. After changing 30 votes per EOS, it is doomed that big EOS holders must unite to survive, that is, to vote each other.

For example, if A is a node, and holding 1 million EOS. Similarly, another node B, holding 1 million EOS as well. In order to increase the chance of selection, their best plan is not only to vote for themselves, and not to vote for anyone else. Instead, they should reach an agreement and vote only for themselves or their allies. If A and B are allies, A and B become 2 million votes per person, instantly surpassing other equally-sized nodes.

If the number of their allies reached 15, and only to vote with each other, do not invest in other than allies. Their winning percentage will be very high, and far more than other nodes.

At the same time, 15/21 is a very special number in the constitution of EOS. With more than 15 people agreeing, it means that they can change EOS code, constitution and blockchain data.

Maybe EOS was designed to prevent nodes from buying and selling votes, but 30 votes are really too much. Even if you can vote 2 or 3, it is better than 30 votes.

In this framework, only the alliance can win the election. Non-alignment means that the difficulty of the election will increase at a geometric multiple. Once alliances are established, decentralization will be even more distant.

Comments

  • thomasbcoxthomasbcox Posts: 148 Sr. Member - 1/5 EOS Tokens

    Harvey, you raise a reasonable concern. However, I want to first make sure we are working from the same set of facts.

    First, the "30 votes per EOS" is not new, it's been in the design since the first whitepaper in mid-2017. It has not changed.

    It's 30 votes per account

    Second, it's more accurate to say you have 30 votes, but that each of your 30 votes has a power equal to your staked tokens. You can vote for up to 30 block producers (BPs). I can vote for up to 30 BPs. A whale can only vote for up to 30 BPs. So, each person or account only gets 30 votes, and their votes are powered by the number of staked tokens.

    Each of us -- you, me, and the whale -- has a different power to our vote. So the math is similar to what you were describing, but not perfectly similar. I cannot vote twice for the same BP.

    Changing 30 to 1 won't help

    The math indicates to me that, if we switched from 30 votes per account to 1 vote, the issue of alliances would be completely unchanged. We would (I think) experience no benefit. I would be curious to see a mathematical proof to contradict my (unproven) belief that changing from 30 to 1 would not help suppress alliance formation.

    Alliances

    There absolutely could be collusion or alliances or cabals or consortia. This is true. The current token distribution doesn't seem to show many whales, but the top 100 Ethereum addresses do own a majority of tokens. If they are not quite whales, they are at least very large fish, and of course we don't know if one person controls two or more of those Ethereum addresses.

    What features are in place to prevent, not alliances generally, but alliances that might harm the chain?

    There are a few.

    Skin in the game

    First, the larger your stake of tokens, the more sensitive you will be, or should be, to token price. Doing things that actively harm the chain would likely reduce the price and thus harm you. The more tokens, the greater your exposure.

    Counter Alliances

    Second, the appearance of an alliance will be very hard to hide on the public blockchain, and harmful behavior by an alliance will almost certainly galvanize others into a counter-reaction. The alliance members, if they truly are harming the chain, can be brought before an arbitrator and could lose tokens or have their voting rights suspended for a time -- a big risk. If the alliance hasn't seized control yet, they risk losing their power. If they attempt to seize control, that very attempt will galvanize greater opposition.

    Hard Forking

    Third, no society can continue if a majority is corrupt. Remember that a united 51% of token-holding power can elect 100% of BPs, and if that 51% is in favor of fairness and good behavior, the chain is probably secure. If 51% become corrupt, the remaining 49% will have only one recourse that I am aware of: hard forking the chain and eliminating the accounts of the corrupt actors on their new chain.

    No Panacea

    There is obviously no panacea here. Humans are human and we play games with each other, often for very high stakes, and sometimes we cheat and lie. The blockchain will see the same human beings playing on a new game board.

    We who want an honest public blockchain must do everything in our power to ensure that honesty and openness prevail. Changing the votes per account from 30 to 1 will do (I believe) nothing to help secure honesty and openness. We can secure honesty and openness only through vigilance and a commitment to the rule of law.

    If this was helpful, please UPVOTE. If not, please REPLY so I can improve.

    Thomas Cox
    blockchain governance expert - active in the EOSIO ecosystem
    US: +1 503.516.3886

    (all opinions are my own)

  • tkaraivanovtkaraivanov Posts: 24 Jr. Member - 1/5 EOS Tokens
    edited April 22

    https://docs.google.com/spreadsheets/d/1E-aqp6bWPjIloZ_eu6vsw581zes5RylLcNywdrN8aWQ/edit?usp=sharing

    Here is a google sheet that I made recently that shows the effectiveness of a higher number of approval votes. The math shows that having only 1 vote per account (as opposed to X approval votes) doesn't improve the situation at all. The minimum number of approval votes that makes sense comes up to about 1/3 of the number of elected producers (with perfect strategy from the opposition of the cartel, or in other words the rest of the voters). Since expecting perfect strategy from the rest of the voters is unrealistic, I think it makes little sense to have less than 10 approval votes with 21 BPs.

    The "at least 1" column in the table shows how much of the staked tokens one would need in order to take control of one producer. I believe that this column best represents how well the voters are represented in system that has wide token distribution. Having a higher number in that column is always good. If we decide that we want to lower the amount of approval votes in order to decrease the chance of a cartel taking control of the network, we should at least try to balance it against the "at least 1" number.

    The "Imperfect strategy coefficient" is an imperfect variable that only vaguely represents the inability of the rest of the voters to vote perfectly against the cartel. Setting it to 1 implies perfect strategy. Setting it to 0.5-0.6 is more realistic in my opinion. (see the second sheet "formula" for more detailed explanation of the formula I've used)

    Let me know if you have any questions.

  • ZachZach Posts: 4 Brand New
    edited April 22

    @thomasbcox said:
    The math indicates to me that, if we switched from 30 votes per account to 1 vote, the issue of alliances would be completely unchanged.

    I think reducing the number of votes from 30 to a lower number will definitely help mitigate this issue. Since it take 15 BPs to take over the network, the number of votes per coins should be reduced to below 15. Anything over 15 (i.e 30) allows for easy alliances. Let me explain.

    1. Lets assume 20% of coins are used to vote.
    2. You would need 10% of the coin supply to control 50% of the voting power.
    3. Lets assume a group of 15 holders each have 0.66% of coins supply, which totals 10% of coin supply and 50% of voting power.

    Scenario #1: 30 votes for each coin (or any amount >15)

    1. Each holder users their 0.66% of coins supply to vote for every other member of their group (themselves and 14 others)
    2. This means that each member of their group has 10% of coin supply and 50% of voting power behind them, so all 15 win the election and become BPs.
    3. They have taken over the network.

    Scenario #2: 5 votes for each coin

    1. Each holder users their 0.66% of coins supply to vote for 5 other member of their group (themselves and 4 others)
    2. This means that each member of their group has 3.3% of coin supply and 16.5% of voting power behind them, which is not 50% so they are not guaranteed to win the election.
      * 0.66% * 5 votes each = 3.3% of coin supply
      * 3.3% of coin voting for each group member (divided by) 20% of coins supply voting in total = 16.5% of voting power
    3. They are unable to take over the network.

    If the number is reduced from >15 votes for each coin to only 5 votes for each coin, a group of 15 members, even if controlling 50% of the voting power would not be able to take over the network because they cannot vote for each of the 15 members of their alliance, so they cannot each achieve >50% of votes.

    In Scenario 1, a group of 15 holders controlling 50% of voting power could install 15 BPs.
    In Scenario 2, a group of 15 holders controlling 50% of voting power could install 5 BPs.

    Reducing the number of votes for each coin to less than 15 makes it much harder for a group of holders to take over the network.

  • EOSREALGraceEOSREALGrace Posts: 15 Jr. Member - 1/5 EOS Tokens

    Hi,

    This is Grace from EOSREAL team. Since I am in Melbourne, I suggest everyone takes a look of Australia election system. The system used in Australia is based partly on the British Westminster system and partly on the American system. The hallmark of the Australian election system is preferential voting. The US and Britain use the first-past-the-post method, in which voters can only make one choice and the candidate who gets the most votes wins, which means the winner may not get over 50% votes.

    But in Australia, preferential voting allows people to rank all the candidates in the order they’d like to see them elected. If their first choice is knocked out of the race, their vote “flows” to their second choice, their third, and so on, until one candidate has more than 50% of the vote, thereby securing their seat.

    Mr. Cox is very wise noticing the problem of US electoral system, and designs this 30 votes per account mechanism. Since we are electing 21 BPs, less than 21 votes per account is not good. 30 looks a good number.

    What I can suggest is we can go a further step, follow Australia model, preferential voting:
    To vote for a BP, you must choose 30 candidates and rank them in order of preference
    If you like the BP5 best, you rank BP5 as no. 1. If you like the BP9 second best, put them as no 2. You must rank every 30 candidate; if you do not, the vote becomes “informal” (spoiled) and does not count.

    Assuming we have 100 BP candidates, the candidate with the fewest votes is eliminated and the other preferences on his or her ballot papers are redistributed to the other candidates. This continues until only 21 candidates are left, and they are the winners.

    I give example in Australia parliament election:

    For example, let’s say that Anna, Brett, Christine and Daniel are candidates in an electorate where 100 votes are cast as follows: Anna 36, Brett 30, Christine 23, and Daniel 11.

    Candidate First preference
    Anna 36
    Brett 30
    Christine 23
    Daniel 11
    Total 100

    Daniel, with the least number of votes, drops out. His 11 votes are now given to their second preference: 3 votes had Anna at number 2, 6 had Brett at number 2, and 2 had Christine at number 2.

    Candidate First preference Reassigned votes Total

    Anna 36 3 39
    Brett 30 6 36
    Christine 23 2 25
    Total 89 11 100

    Because no-one has more than half the number of votes, another candidate is dropped. This time Christine has the least number of votes so her votes are distributed according to their second preferences: 8 to Anna, 13 to Brett, and 2 to Daniel. But Daniel has already dropped out, so those last 2 go to the third preference, one each to Anna and Brett. The two votes that previously went from Daniel to Christine are now given to their third preference, this time both go to Brett. So now we have:

    Anna 36 3 8 1 0 48
    Brett 30 6 13 1 2 52
    Total 66 9 21 2 2 100

    Brett now has more than half the total vote so he gets elected.

    You can refer to this website to understand better of Australia election system

    https://www.science.org.au/curious/everything-else/mathematics-voting

    In summary, Mr. Cox 30 votes per account in fact is a very wise design, I just recommend adding preferential voting mechanism in it.

  • thomasbcoxthomasbcox Posts: 148 Sr. Member - 1/5 EOS Tokens
    edited April 23

    My understanding of the literature on voting is that approval voting is slightly less effective than score voting, but both Score (aka Range) and Approval voting outperform Rank voting.

    I encourage the curious to enjoy the voting method simulator here.

    Problems with Rank voting date back to the 1950s; see Arrow's Impossibility Theorem.

    Eliminating Rank voting due to Arrow's findings, we can look at a Bayesian analysis of the remaining options -- scroll down until you see the graphic from page 239 of William Poundstone’s book Gaming the Vote:
    1. Pick someone at random
    2. Plurality voting (current US standard)
    3. Borda count
    4. Condorcet method
    5. Score (aka Range) voting
    6. Approval voting

    You'll see that Score is a bit better than Approval, but Approval is much simpler and outscores everybody else.

    This simulation is for single winner elections -- it gets a LOT harder with a ballot method that seeks to elect 21 BPs. Here, simplicity and effectiveness are on our side when we pick Approval voting.

    Which is why we're using Approval voting as the installed default method in EOSIO.

    If you'd like to see EOSIO use a different system, I encourage you to submit a Constitutional Amendment after the chain goes live, or persuade the majority of BPs and voters to install a different default at launch.

    Revisions

    23-Apr-2018: I mistakenly said "Preference" when I meant "Approval" voting. I've corrected the text above and I apologize for the error.

    If this was helpful, please UPVOTE. If not, please REPLY so I can improve.

    Thomas Cox
    blockchain governance expert - active in the EOSIO ecosystem
    US: +1 503.516.3886

    (all opinions are my own)

  • EOSREALGraceEOSREALGrace Posts: 15 Jr. Member - 1/5 EOS Tokens

    very well explained, Mr. Cox

  • tkaraivanovtkaraivanov Posts: 24 Jr. Member - 1/5 EOS Tokens

    I would only like to add that approval/ranked voting has been studied extensively in the context of 1 vote per person. To my knowledge, it has not been studied in the context of stake-weighted voting, where you have a much higher possibility of voting centralization.
    The google sheet I linked earlier is aimed to provide some research into approval voting in the context of stake-weighted votes. It is far from perfect, but I see it as a decent rough estimate.

    P.S. The conclusions I've come to from studying it is that 30 approval votes for 21 BPs is a very sensible number, and I don't see a compelling reason to reduce it.

  • unusunus Posts: 3 Brand New
    edited June 18

    I do not understand where tkaraivanov is wrong in that spreadsheet (argument) but I do understand Zach's argument and it seems to make sense.

Sign In or Register to comment.