Securing DPOS
What is DPOS - Delegated Proof of Stake?
Delegated Proof of Stake (DPoS) is a consensus algorithm developed to secure a blockchain by ensuring representation of transactions within it. DPoS is designed as an implementation of technology-based democracy, using voting and election process to protect blockchain from centralization and malicious usage. Delegated Proof of Stake was developed by Daniel Larimer - American software developer, cryptocurrency entrepreneur and a founder of BitShares, Steemit and EOSIO software. Many blockchains use EOSIO code, such as Telos, WAX, Worbli and EOS. Daniel invented DPoS as an alternative to energy-inefficient consensus of Proof-of-Work blockchains and Proof-of-Stake consensus, that is poorly protected from malicious intentions of stakeholders. First implementation of DPoS was executed in cryptocurrency called BitShares. DPoS was also planned to be more scalable alternative to classic consensus algorithms. As every block is validated in avoidance of the need to use a lot of energy, progressing amount of computing power and other resources, all transactions can be performed relatively fast on every stage of network’s development. Famous examples of cryptocurrencies that use DPoS include Lisk, Steem, Waykichain, EOS and BitShares.
Source: https://en.bitcoinwiki.org/wiki/DPoS
That's a difficult description, which is one of the challenges with crypto, trying to understand how it works takes some time.
In order to push a fork through under our current deployment of DPOS it takes the top witnesses to run the new code. I've heard both 17 and 19 of them have to run the new code for the fork to be executed. I am unsure which one is true, but by giving each stakeholder 30 votes we are making it too easy for a handful of people to control the witnesses.
Since the beginning of the Softfork - Hardfork phase of the Steem and Hive my focus has been to wonder if the DPOS system is secure. Answer at this point from me is NO.
I think we can all agree that several changes have taken place that do not represent either the stake or community consensus. That's okay this is an experiment, but shouldn't we look to improve it now?
Humans are flawed and conflicts have 2 sides. People have been focused on who is right and wrong and while that is important it's not so much that these forks happened, it's that they COULD happen that makes it a problem. I no longer feel confident that our security is enough.
I don't know whose idea it was but I like the suggestion that each stakeholding account should have less than 20 votes. (since we have 20 consensus witnesses) I'm thinking somewhere around 9 votes would help a lot.
If Dev365 could only vote for 9 witnesses then that account would not have full control. Community votes would pick at least half of the witnesses.
While I have seen this discussed several times, I haven't heard an argument against it. To be clear it would still be possible to control witnesses by spliting stake, but it would be much more difficult.
Another contributing factor to the latest Hardfork is power down time. With the recent HF it was reduced to 4 weeks, which I am for. However, I think even 2 weeks would be plenty. Trapping people in a project they no longer wish to be in creates it's own security risk.
I am very open to other ideas, but I just can't see holding much stake in either project with the current deployment of DPOS.
What are your thoughts? Is our current DPOS system fine? How would you improve it?
Hi @whatsup we have chosen this post as our "In the Spotlight" post for our daily showcase. Thank you for initiating a great topic for us steemian to discuss.
-cryptokannon-
Yes, the only argument against it that I'm aware of is that someone could theoretically get around it by splitting their stake, so it's not a comprehensive solution to any problems.
I'm not sure exactly how I would improve it, but I would like to see multiple ideas considered and debated, in an effort to find things that work better for the long term.
One thing I am curious about is if downvotes for witnesses would be helpful. If, rather than voting in friendly witnesses Steemit had been able to downvote hostile witnesses I think I would have been more comfortable.
Getting a bit more complex, I also wonder if there could be a separate "ratification" step for which code versions are valid to run. For example, people vote for code version numbers like "23.0" or "23.1" independently of voting for witnesses, and if a witness runs code that hasn't been sufficiently upvoted by people then vote quantity giving them their position gradually decays. This would let witnesses run emergency code when necessary, but would encourage them to get buy-in on code changes before new versions. I haven't thought through all the implications of this, though, so there may be flaws I haven't considered.
One of the complaints I used to see occasionally was that "stale" witness votes would hang around, e.g. if someone does their vote may no longer be expected to track which witnesses are or aren't trustworthy.
The stake witness votes matter. It also matters that with 30 votes they can just all agree to vote for each other as we see on HIve.
I agree that it would be a good idea if the number of votes a person can cast for witnesses would be less then the number of votes needed for consensus, and I would support such a change (or some of the similar ideas, such as being able to break your vote into different percentages to different witnesses). I'm just acknowledging the reality that there is a strategy that could get around it.
Great post as always, the model need to improve from what we have learned from the fight. I agree that 2 weeks is sufficient but we have an improvement of 4 weeks instead of 13 weeks that is an interminable journey.
I agree 4 weeks is an improvement for sure.
I think we are on the way to 1 or 2 weeks. 4 weeks is the proposal previously discussed even before the JS drama, so it is a good intermediary step.
곰돌이가 @glory7님의 소중한 댓글에 시세변동을 감안하여 $0.017을 보팅해서 $0.025을 지켜드리고 가요. 곰돌이가 지금까지 총 7980번 $110.615을 보팅해서 $109.454을 구했습니다. @gomdory 곰도뤼~ 곰돌이 서비스는 6월 20일 11pm에 종료됩니다.
9 votes would still be too many because dev365 could split stake over two voting accounts, still allowing 20% only to control the chain.
You would have to drop as low as 3 votes, at which point around 80% (or more) would be required to centralize with 6 voting alts.
Well, to be fair the other stake holders did choose to abandon their stake... or it would have never happened.
Remember the stale mate?
I knew I shouldn’t have referred to dev365 lol. But it was the perfect example to highlight the impact of voting apathy in democracies where voting isn’t compulsory.
I'm not opposed to reducing the number of votes, but I think it's more important to increase the number of "top witnesses" from 21 to something much bigger, like 50 or 100. Part of the problem is that, once elected, 17 people were able to get together in a back room, make, and implement a major decision without any public discussion. (i.e. SF 0.22.2)
By itself, reducing the number of votes per stakeholder isn't going to fix that. If you increase the number of people who would need to be involved in the collusion, it would be much more difficult to sneak a change through without communicating it and gaining consensus from the community.
Yeah, I wonder about that also....
Maybe even 25 would have been enough, and also I think if it weren't such a tiny community it wouldn't have happened. A small group of people who know each other really well, can intimidate a group of others.
They were careful who they invited and who they kicked out.
But I do get your point and it is valid.
The question is if big stakeholders want to improve it.
My guess is that they don't want to give up power.
On both chains.
I almost included that in the post....
This change would require power holders to reduce their own power. Unlikely to happen
"Don't Piss Off the Stakeholders."
More accurate imo.
Probably you meant; big stakeholders.
There is a lot truth in that.. :)
To be clear it would still be possible to control witnesses by spliting stake, but it would be much more difficult.
As I've said for a looooong time. If it can happen, it will happen. DPOS is a flawed equation. Stake size is everything.
It can never be decentralized properly as it would necessitate people giving up power voluntarily to others, - and that never happens (except as an 'appearance exercise' - ie.e nepotism).Look at the steem train wreck right now.
After 4 years or so, we can see that it's not really happening.
The steem / hive split is proof of the 'might is right' ethos in DPOS.
That is not decentralized.(nor will ever be).
Imagine if Jeff bezos decided to take over steem or hive with stake? Nothing to stop him.
Imagine if the same bezo's decides to just down vote all posts and not post himself. There is nothing to stop him nullifying all upvotes.
(think bloom account with me, but on steroids).
IF the DPOS system was to take off, and serious money got involved - what do you think would be result?
A distribution mechanism that rewarded merit, or continuing nepotism and circle voting to take the inflation 'rewards' for themselves?
It has nothing to do with coding, but ethical codes, embedded in the coding - which can be done).
The problem with this is,of course, is that it would still take the witnesses to agree...aaaaaand we're back to DPOS, flawed equations, and people not giving up their power...
You can put lipstick on a pig, but....
Probably correct.
Exactly.