Steem blockchain multivote security vulnerability
Steem blockchain has been purposefully designed with 30for1 or multivote security vulnerability.
In essence, multivote vulnerability centralizes blockchain and poses security risks, blockchain disruptions and loss of funds.
Description
Each steem power (SP) owner can cast 30 votes on witnesses, i.e. choose up to 30 representatives. Simplifying, 1 SP allows casting 30 Sp worth of votes. At first, it looks as it allows to cast votes on more representatives (witnesses) and helps to decentralize blockchain, but in fact, it allows for an individual or a small coalition to govern the blockchain with a minority stake.
Exploitation
The most distinctive use of the exploit was steem blockchain hijack carried out on the first week of February 2020, when apparently customers funds were used by Poloniex, Binance & Huobi exchanges to change all 20 top Steem witnesses; new witnesses run a new 0.22.5v software, freed ninja mined tokens purchased by the Tron owner, destabilized blockchain and disrupted hundreds of services. New witnesses also provided not up to date price feeds. We can assume multivote vulnerability was previously used by some established witnesses to their advantage, either willingly or unconsciously.
Mechanics
Let's assume A ownes stake worth 10, B stake 4, C stake 4, D stake 4, E stake 3, and F stake 1.
We choose 3 primary representatives {W1, W2, W3}, who hold the true power and a number of reserve ones. Each vote can be used 3 times, i.e. 3 representatives (witnesses) can be voted). The rule allowing to vote 3 times with each voting unit leads to centralization of the power:
Either dictator A or a coalition {B, C, D} takes all 3 primary witnesses. If B, C, D... cannot form a coalition, A takes all spots, despite B, C, D... having the majority of votes. If B, C, D... can find an agreement and form a coalition, A, despite having almost 40% of votes, will have no representatives. This holds true whether we choose 3 or 20 primary witnesses, as long as we have more vote uses than number of primary witnesses, i.e at least 3 (as in the above example) or 20 uses (as in steem blockchain, where we have 30 uses) for each vote.
Solution
A simple solution is to allow only one use for each vote (SP, voting power). This allows more parties to have representatives and promotes decentralization.
Now A can divide his stake into two parts, but, even if B, C, D... are in disagreement, he cannot take full control of the blockchain. (top table). If B, C, D... can form coalitions, they can choose a majority of representatives (witnesses), in line with the majority of stake they own. Still, A cannot be easily pushed out and can still have his representative.
Conclusion
Steem blockchain multivote security vulnerability allowed for serious disruptions of blockchain governance & functionality in February 2020. Removal of voting redundancy will prevent oligarchy or dictatorship ruling of the blockchain and will allow further decentralization. One account must be allowed to vote only one witness.
Something needs to be done. I doubt we will end up with one vote only but it needs to be shortened to 5-10.
@holoz0r suggested a nice system as well.
https://steemit.com/steem/@holoz0r/changing-the-witness-voting-system-by-introducing-witness-downvotes-could-this-work
Thank you for the link!
What do you think of concerns like this and this? There have been some models run on EOS (like what is mentioned here) as well.
I'm just not yet convinced 1t1v solves as many problems as people think. What examples do you have of projects doing well with 1t1v?
Thank you, very interesting.
On Twitter, they are just opinions, Syed Jafri states:
More casual users like me are unable to make educated votes on 30 candidates. JSun exactly knew his 20 candidates, being here for a while I'm willing to vote for maybe 5 people, and until recently I've used my little vote for only 2 candidates, which recently I found are inactive. I think the assumption is sound.
Edit: 12149 votes without overlap? - Mr Jafri?
Much more interesting is the link to simulation on eosauthority. As of now, only 2 in the top 21 would drop below, although the order in the top 21 would be significantly re-shuffled. Some producers, like truststaking would need just 5% more votes to make it to the top 21, but now he needs 150% more votes. Overall, in the simulation changes in the order are quite small, but I would expect them to be larger if 1t1v would be a real voting protocol.
1t30v amplifies the authority of big holders like A in my example, so they are and will be opposed to changes. The only drawback to governance I see is it would be more difficult to carry out forks/implement changes, as top producers/witnesses would act in a more decentralized environment.
Edit:
If I read this chart properly, only 3 colluded accounts decide on top 21 producers.
In the current model not all users are casting their full 30 votes, but if you cast all 30 votes, you increase your power and influence over the Witness ranking in a subtle almost unfair (unkown by most users) way. A smaller Witness vote number or even (1 SP = 1 Vote) would reduce this complexity but will make it maybe easier (less expensive) to get a veto power in the system.
Resteem
but Steem has no 51%-Attack vector (it is not Bitcoin), you need to fine tune your system to prevent a >1/3 (33%)- attack vector. This is not dPOS but dPOS+BFT which is based on a 2/3+1 safety assumption! So the main premise must be that no one can economically form a 1/3+ "majority". Maybe you already know? Consensus in Blockchain is not the same as in human terms like "majority decision" or "popular opinion". It is a technical term. Bitcoin other than the rest is not a node based consensus scheme.
30/1 voting rule exactly makes this attack vector easier.
But, in the meantime, I've found
you haveproposed very similar solution!, i.e. 1SP = 1 vote!Dividing vote power would have the same effect as reducing the number of possible witnesses to be voted by one account to 1, but still allows to cast votes from one account to more than one candidate (smaller votes, though). So a more flexible solution. 30 candidates are too many, 10 much better, I would go for an even smaller number, 3 or 5.
Steemits 51%-attack is having 51% of the top 20 witnesses. That is 11 witnesses with combining 51% of the voted steem power.
Ok, but the honest consensus is not made by >1/2 majority. Consensus in permissioned systems is made by at least 2/3! In Steems dPOS-BFT it is the longest chain rule, where the last irreversible block (LIP) is the block where >2/3< of the Witnesses have jumped on. With up to 1/3 byzantine Nodes you can "only" create a minority fork. In a round-robin scheduling like Steem where a block is added every 3 seconds (which is dertermined by network delay/speed of light) a malicious 1/3 minority can only add blocks every 9 seconds to their "wrong" chain, while the 2/3 honest majority adds blocks still every 6 seconds. When you get more than 1/3 it becomes undecidable. This is why the security assumption of permitted chains is
[(n-1)/3]or in other terms forffaulty nodes you need3 f + 1aka >2/3+1< honest nodes.So there is no 51% attack vector when you can violate the correctness with only >33%. When 51% of the stake can vote more than 1/3, then this is a dumb design decision and not a 51%-attack. The 51%-attack vector in open=asynchronous systems like Bitcoin is due to the laws of physics (Fisher-Lynch-Peterson Impossibility Theorem). When you want a synchronized system which is not subject to the FLP-problem you need a fixed direct or indirect quorum like Steem or Eos but then you have no >1/2 anonymous majority election.
Thanks for the explanations. That was quite enlightening and I learned something new. 👍
However, I'm more worried about the ability to make hard and soft forks and therefore change the rules. Including the rules you just explained.
The very real attack which we just had — twice. First the old witnesses locking @justinsunsteemit's funds. That was a bit hasty.
And then Justin by retaliating by taking over the whole chain with sock puppet witnesses. Which is even worse. And makes me wonder if I should retract me delegations and prepare for power down. Because if Justin gets his way and becomes “benevolent blockchain dictator for 6 weeks” I don't think I don't want to stay.
We all know how those “benevolent dictatorships” end each and every time.
yeah true the community has to react anyways. We are not here for centralisation. 👍
Hi @hotbit!
Your post was upvoted by @steem-ua, new Steem dApp, using UserAuthority for algorithmic post curation!
Your UA account score is currently 1.870 which ranks you at #21520 across all Steem accounts.
Your rank has improved 4 places in the last three days (old rank 21524).
In our last Algorithmic Curation Round, consisting of 78 contributions, your post is ranked at #48.
Evaluation of your UA score:
Feel free to join our @steem-ua Discord server
Hi, I got confused with the 2 posts you put in chat-upvoted this one instead of your Splinterlands post- next time it is better to place your Splinterlands post in the sm-post-promotion channel, thank you. ~@clove71