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. 👍
Sock puppets end run any account based mitigation.
Sybil attacks will nullify any limits one account has over two.
Lowering the 30 to 1 rule lowers the costs of attacks, and does nothing to change the ratios.
Your 30 votes to my three hundred is the same as your one vote to my ten.
This is there so the chain is more expensive to hijack.
I agree with the above comment. It is basically a tradeoff. Having less votes makes it much easier to get enough witnesses to block consensus, but more difficult to get all 20 (Community could focus all votes on 1-4 candidates).
I do like the "witness downvoting" potential. That could make things more interesting.
I agree that having fewer votes makes it much easier to get enough witnesses to block consensus.
But then let's stop false statements about decentralization. Recently almost every witness is using this word in his articles/talks. At the same time, the system is designed to consolidate power.
Downvotes could centralize governance even more.
I think something even better to discuss would be adding a slope with a cap for witness votes. Like, when you just power up your stake is only worth 10% the vote and it will go up to 100% within 30 days or so. This way anyone powering up would have to commit at least for 30 days + powerdown time.
What if we tie the Witness Votepower to some rules like:
I already tried to get this mechanic into a formula and when i have more time, i try to explain better how and why i think this is good.
Im not that good with maths. Its just about the idea and i would be happy if some people read this and think about how we could make the formula better or what problems this could cause. Thank you!
https://steempeak.com/steem/@remotehorst23/steem-blockchain-has-a-major-problem-and-maybe-the-solution-is-pretty-easy
ad.1 - Yes. 1 would be best, 3 would be quite good. But I'm afraid both are impossible.
ad.2 - good idea!
ad3. - reputation could be manipulated, could bring more problems.
ad4. - not possible without KYC, as STEEM owner can always split his stake between many accounts as needed.
As I have explained in the article, while it seems like this at first glance, that's not true. With 1 for 1 voting rule, recent attack by exchanges would not succeed in changing all 20 witnesses.
Well, I poke a lot of smot, and my math ain't as sharp as it was before, I took my argument on authority, perhaps @smooth would have time to enlighten us.
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