In the Beginning, There Was DPoS

With recent events, DPoS (Delegated Proof of Stake) has received quite a bit of attention. It's become obvious to many people that voting for block producers is important.

Let's put on our blockchain designer hats and try to unravel some of the ideas behind DPoS. I'll also try to dive into blockchain design history, and share some of my own perspectives from that time, as others are doing.

A blockchain needs to decide, in a decentralized way, who will produce the next block. Bitcoin, the first blockchain, basically assigns it by a "lottery". The more computing power you have, the more lottery tickets you can print. This system is called Proof-of-Work. (There's also a difficulty adjustment system that controls the rate of winners over time, by decreasing/increasing the win probability of each individual ticket if there are more/fewer winners than the target rate.)

There's no reason we need to design our blockchain to base block production on computing power, though. We can use anything, as long as there's a way for a user to prove to the blockchain that they did some kind of activity. At the time BitShares was being designed, other chains (notably Peercoin) were already using proof-of-stake, where the thing you use is stake (specifically, holding coins over time). Proof-of-stake was much in vogue among blockchain designers as a superior consensus mechanism.

The idea of PoS, as it was conceived in early 2014, (or at least as I then understood it), was to actually transact your coins as part of producing a block.

This meant having an always-online wallet (not great security practice or UX).

It was also already becoming obvious that people wanted to centralize their block production in pools. This minimizes individual variance: It's much easier to run a Bitcoin mining business that reliably makes $2000 each month, rather than one that has a 4% chance of making $50,000 each month (and a 96% chance of making $0). Even though the average monthly EV is the same, most people would rather have their income be smooth than lumpy.

If you have to actually transact your coins to produce blocks, then in order to form a mining pool, users will have to give the mining pool operator custody of their coins.

So let's pretend it's early 2014, and put on our blockchain designer hats.

The hardest part of being a blockchain designer is predicting how users will behave.

Fortunately, we know something about how users will behave, by observing Bitcoin:

  • We know that, if they have a reason to do so, users will let someone else hang on to their coins (for example to trade them for dollars on Mt Gox).
  • We know that Mt Gox has just suspended its Bitcoin exchange and filed for bankruptcy.
  • We know users will try to form mining pools. They're doing it in Bitcoin, and there are clear economic incentives to encourage this.

We may wish users behaved differently. We may wish they wouldn't form mining pools. We may wish users who hold coins that belong to others, for example exchanges, always behaved competently and ethically. But we have to design our blockchain around the facts of how users actually behave, not how we think they should, or wish they would.

We can't stop users from forming pools. That's what the users want to do. But we can stop users from giving away their coins to form pools. We simply need to provide a mechanism for the user to give the pool operator control of the coins' PoS block production power without also giving the pool operator the ability to transfer the coins.

This is the core idea of DPoS: Allowing a user to delegate their stake-based power to produce blocks.

This core idea was suggested in a March 18, 2014 forum post. In my opinion, the author of that post deserves credit for being at least a co-creator of DPoS.

My opinion is biased, of course. I wrote that 2014 forum post.

The DPoS system used in Steem adds quite a few additional features and design decisions to the basic primitive we've arrived at in this post. I want to revisit some of those decisions in my next project.


Comments
Steemie currently dosen't allow you to make comments. If you want to write something, write it using another frontend (like Steemit)
Click there to view this post on Steemit.com
  • @buggedout

    How about a post outlining some of the flaws of DPoS that we have witnessed since 2014 and maybe some ideas on how to address them.

    1. More votes than top witnesses - Allowing a large stake to effectively centralise and control the blockchain (as we have witnessed here on STEEM)

    2. Bribery / Corruption of Witnesses - Where witnesses offer a kickback to voters as a bribe to vote them in (or than relying on merit). We have seen this on other DPoS chains, leading to unreliable block producers being elected and then poor performance of the overall network.

    I'm sure there is more....

  • @asimpleman

    ok got it

  • @ew-and-patterns

    So you are a co-creator of DPOS and you have seen the shitshow that is steem and how it morphed into what it is now. You know the technicals and you understand what's been proven to be good and bad about DPOS.

    With this knowledge, I will 100% check out your next project!

    I also would like to hear your ideas to make a 51% attack impossible in a DPOS system with 20 consensus witnesses and 30 witness votes per account. These numbers seem random to me. Can you explain why Dan Larimer chose 20/30 and what would be a safer choice? I am thinking about something like 25/9 (with the current distribution of steem in mind)...

  • @coinchaos

    lol do not be a quiter

  • @inertia

    We may wish users behaved differently. We may wish they wouldn't form mining pools. We may wish users who hold coins that belong to others, for example exchanges, always behaved competently and ethically. But we have to design our blockchain around the facts of how users actually behave, not how we think they should, or wish they would.

    As I understood it, Steem originally had some of these dangers in mind. Having a 2 year power-down with 100% yearly inflation (and reverse splits) disincentivized keeping liquid STEEM on exchanges, in theory. Also in theory, it would make exchanges think twice before actually committing to powering-up depositors stake.

    Setting aside this specific STEEM example, how do we express general design goals so that people not only understand their original purpose, but also stick to them when things get bumpy?

  • @argsolver

    @theoretical please have a look at the REDPOS protocol concept.