https://t.me/EOSproject/1561416
Aarin Hagerty, [30.10.20 14:48] [In reply to Luka Perrrcic] I would like to provide some historical context regarding this discussion of DPoS voting mechanisms.
BitShares ended up with an approval voting system (which one can think of as 1 token infinity votes) for voting for BP (block producer) candidates which then ranked them by approval vote and selected the top N as the set of active block producers. I don't remember the exact series of events and reasoning that led to that decision, but I am sure most of it can be found on the old BitSharesTalk forum (e.g. https://bitsharestalk.org/index.php?topic=5205.0).
There are some advantages of an approval voting system over cumulative voting (https://en.wikipedia.org/wiki/Cumulative_voting), which one can basically think of as 1 token 1 divisible vote, particularly in the case of single winner elections. For example it passes the favorite betrayal criterion (https://electowiki.org/wiki/Favorite_betrayal_criterion) whereas cumulative voting does not (https://electionscience.org/library/voting-systems-confused-with-approval-voting/). But remember this is for a single winner election, and BitShares uses it is for a multi winner election (to select multiple active BPs) where these criteria may not necessarily still be satisfied the same way. In fact, it appears that pretty much all these voting systems (ignoring ones involving randomness) do not satisfy the favorite betrayal criterion in multi winner elections (https://en.wikipedia.org/wiki/Comparison_of_electoral_systems). In addition, there is the question of which of the other valuable criteria (see prior Wiki link) are satisfied by the various multi winner election voting methods. Nevertheless, the approval voting nature of DPoS, originating from BitShares but spreading to other blockchains, stuck.
Then with STEEM a further complication was introduced to the election process. Sure there were still the top N (in that case either 19 or 20) BP candidates ranked by their approval vote that were selected as permanent active BPs. But there was also 1 (or 2) other slots available within the 21 BP slots that were reserved for a rotating BP. This BP slot was rotated frequently across the pool of BP candidates in a way that tried to match the frequency with which they found themselves in that rotating slot as an active BP to be proportional to their relative accumulated vote weight. So if a candidate BP that was selected as a permanent active BP had twice the accumulated vote weight as another non-permanent candidate BP, that first BP should be in the rotating spot roughly twice as frequently (and therefore get paid twice as much if they were actually always ready to produce) as the second BP. While an interesting (and complicated) mechanism to reward standby BPs and also allow them to prove themselves as actually ready with their nodes to produce blocks, it did introduce a Sybil vulnerability for that rotating spot due to the interaction it had with approval voting. Since there was no limit to how many candidates someone could vote for, it enabled someone to create a lot of sockpuppet accounts and vote with their limited stake for all of them to effectively expand their stake with no real limit and dominate the rotating spot thus preventing anyone else from getting their fair share of access to it (unless they play the same unfair game). Note that this wasn't a problem for selecting the top 20 because that selection inherently caps the number of BPs selected as winners whereas the rotating producer process does not. The patch for this problem was a mitigation: simply cap the number of votes that each voter has to find some balance between the expressiveness desires of approval voting and the "rotating producer Sybil attack prevention" desires. So a limit of 30 votes was imposed on the STEEM blockchain.
Aarin Hagerty, [30.10.20 14:48] [In reply to Luka Perrrcic] Then EOS inherited that 1 token 30 vote structure from STEEM. While EOS does not have the rotating producer mechanism of STEEM, it does have another mechanism that is also similarly vulnerable to Sybil attacks if it wasn't for the cap: the vote pay mechanism. The block pay mechanism could work just fine with true approval voting since only the top 21, which is difficult to get into, get paid. But a vote pay mechanism which pays nearly anyone in proportion to the accumulated vote weight of the BP candidate can again be gamed to allow a candidate to receive more than their fair share by creating a lot of sockpuppets and voting for all of them with their limited stake. The 30 vote cap puts a limit on how much of the vote multiplication someone could do. Clearly, it would be better to use a cumulative voting mechanism to allocate the accumulated vote weights that determine vote pay. One could still use true approval voting to determine the rankings that decide the top 21 though assuming there was an advantage of approval voting over cumulative voting in multi winner elections. I am not sure if that is the case, but there does seem to be some evidence from other blockchains that a 1 token 1 vote concentrates the accumulated vote weights further into fewer top ranked BPs. Nevertheless, the simpler path would be to just use one mechanism to accumulate vote weights and if there is a desired to keep a Sybil-resistant vote pay mechanism it does seem cumulative voting is the sensible choice.
Personally, I am not satisfied with any of these solutions because none of them address the proportional representation (PR) criterion. There are voting mechanisms that do satisfy proportional representation, for example: Proportional Approval Voting (https://en.wikipedia.org/wiki/Proportional_approval_voting), CPO-STV (https://en.wikipedia.org/wiki/CPO-STV), Schulze-STV (https://en.wikipedia.org/wiki/Schulze_STV), Single Transferable Vote (https://en.wikipedia.org/wiki/Single_transferable_vote), etc. The problem tends to be that they are actually very computationally intensive compared to the voting mechanisms that do not satisfy PR (especially for the first three I listed). For small numbers of winners and candidates it may be feasible (though this is still a difficult engineering challenge to build within smart contracts running on a blockchain), but if you go to even moderate numbers of winners and candidates it quickly explodes combinatorially and can even become infeasible to do off-chain. Of these, Single Transferable Vote (STV) seems the most feasible to achieve computationally to me but even then it would be a nightmare to try to make that work on a blockchain.
In summary, social choice theory is hard.
Luka Perrrcic, [30.10.20 15:40] [In reply to Aarin Hagerty] all these systems asumes sybil resistance
Luka Perrrcic, [30.10.20 15:43] once you have whales voting with ten millions votes at once, they can easily write scripts to optimize for the highest apr, split the accounts, and most importantly; respond to current outcome. The systems in links are all about one time voting, and making sure the vote is not wasted.. in eos it can't be wasted since you can always adjust
Aarin Hagerty, [30.10.20 15:44] [In reply to Luka Perrrcic] Sure. But some mechanisms are more Sybil resistant than others.
Luka Perrrcic, [30.10.20 15:48] [In reply to Aarin Hagerty] just to be clear, i meant the mechanisms discussed in wiki links. They asume you have one person with real ID voting, and tries to optimize so the votes are not wasted.
Aarin Hagerty, [30.10.20 15:48] [In reply to Luka Perrrcic] It is easy to adapt these theories to token based voting. Just treat each 0.0001 EOS as a person.