DPOS (aka Delegated Proof-of-Stake) was invented by Daniel Larimer as a replacement for the Proof-Of-Work consensus algorithm used by Bitcoin and most other cryptocurrencies at that time. All the blockchains developed by Dan (including BitShares, Steem, and EOS) use DPOS to select their block producers.

In this post, I’m going to discuss the history that led to the invention of DPOS. I was working closely with Dan at the time of its invention, and this is how it happened, to the best of my recollection.

Before I get into the details of DPOS history, however, I’ll need to go over some background material on how blocks get added to a blockchain network.

Ordering transactions (e.g. a transfer of money) in a blockchain network

One of the most important functions of a blockchain network is to create a time-ordered list of transactions, with groups of these transactions being stored in a sequence of linked blocks called a blockchain. This time-ordering is important, because it prevents someone from spending their cryptocurrency more than once (an attack known as a “double-spend”).

In order to process new transactions, one of the computers in the blockchain network needs to decide a valid ordering for new transactions it has received, put them in a block, and then broadcast that block to all the other computers in the blockchain network. The other computers in the blockchain network can then check that block, and if it passes the rules of the blockchain network, they add it to their local copy of the blockchain. Then after some time delay (often referred to as the block interval), another computer will repeat the steps above, and another block will get added to the blockchain.

Problems with a blockchain network that uses a single computer to generate all the blocks

In theory, the rules of a blockchain could assign a single computer in the network that generates all the blocks. But there are several problems with this idea.

For one thing, it makes for a very fragile network: if that one computer crashes or loses its connection to the internet, no one’s transactions could be processed as long as that computer was unable to communicate with the other computers in the network (in other words, no one could make money transfers).

Another problem is that a single computer making all the blocks can block all transfers of anyone it pleases, effectively “freezing” money stored in an account. This is because the computer that makes a block gets to choose which transactions it puts in a block. If it doesn’t want to include a transaction, it can just pretend it never saw it. However, even this computer could only freeze funds, it can’t actually steal them (because it can only block transactions, it can’t make a fake transaction that moves money from an account it doesn’t own, because that’s against the rules of the blockchain).

Whose computer makes the next block in the blockchain?

But the ability to arbitrarily freeze funds in the network is a lot of power and you also don’t want your financial network to depend on the health of one computer, so Bitcoin, the first cryptocurrency, was designed with a feature called “mining” that allows computers in the network to compete for the right to generate the next block in the blockchain.

How Bitcoin mining (also known as “Proof-of-Work” or POW for short) works

With “mining”, each computer that competes for the right to make the next block (a miner) races against the other computers to find a brute source solution to a math problem. Because the computers must solve this math problem and prove they have the correct solution, mining-based cryptocurrencies are also known as “Proof-Of-Work” (POW) cryptocurrencies.

Generally speaking, the miners with the fastest computers will be the first to find the solution, then broadcast a block to the blockchain network that includes their solution. If the other computers in the network agree that the solution is correct, this becomes the next block in the blockchain.

At first, mining was seemingly a great solution to the problem of selecting who would produce the next block. Any miner in the network could produce the next block, so even if one miner decided not to include a user’s transactions, the transactions would likely get included by the next miner. So in the worst case, a user’s transactions might get delayed a few blocks.

But computers doing mining consume a lot of power solving those math problems, which costs money. To enable miners to cover their expenses (and to even profit from their mining), miners are paid block rewards when they successfully produce a block. This leads to an arms-race among miners, and ultimately Bitcoin miners resorted to using very specialized and expensive equipment to gain a mining advantage. Unfortunately, this made it too expensive for most people to mine Bitcoin, and over time most bitcoin blocks started getting produced by a very few people with very expensive equipment.

Steps leading to the invention of Delegated Proof-of-Stake (DPOS)

In 2013, I was working with Dan Larimer to create a new cryptocurrency called BitShares. BitShares was being designed as a blockchain-based decentralized exchange (i.e. a place where users could do peer-to-peer trading of cryptocurrencies and other commodities). My team was mainly working on the peer-to-peer network code and the command-line wallet, and Dan’s team was working on the blockchain code, including the method for determining which computer in the network gets to make the next block. Despite the separation of work, perhaps not surprisingly, we would often discuss implementation ideas, and sometimes people from my team would help out on the blockchain side when there was a problem.

Why not go with tried-and-true Proof-of-Work?

Proof-of-work consumed a lot of computing resources (so the blockchain had to pay a lot to the miners) and was relatively slow for our needs as a trading platform. The Bitcoin network had a block time of 10 minutes and we were aiming for a block time of 10s (ultimately we set the block time to 3s). So Dan ruled out using proof-of-work for selecting the next block producer.

A single block producer? A single failure point and too much trust

For fastest speed, Dan’s first idea was to just a single block producer. This does actually have some performance advantages, because everyone could send their transactions to that single block producer which allows for transactions to be included into a block faster. But having a single point of failure made this seem unworkable and you’re really placing a lot of power in one person’s hands.

What about a group of “trustees”? Still requires too much trust

Dan’s next idea was just to have a set of trustees: trustworthy individuals in the newly-born BitShares community who would be assigned to produce blocks in round robin order. The idea was that even if one trustee didn’t include a transaction, the next would. So the only way a transaction would be blocked was if all the trustees decided to block the transaction. One of the big attractions of this idea was it’s utter simplicity, which meant it could be coded very quickly, and we were under serious time pressure to get a functional blockchain network operating before funding ran out.

While the trustees idea was very feasible from a technical perspective and very attractive because of it’s easy implementation, it was also somewhat fragile in that it relied on a fixed set of computers in the network and it didn’t have any mechanism for how to change that list of users over time, except by hardforking in a new set of trustees.

It also placed a lot of trust in the trustees, and crypto-anarchists generally don’t want to place too much trust in anyone. So I and others argued that it required too much trust, and wouldn’t be acceptable by the crypto community. After a day or so, Dan conceded the point and went looking for a new method to
quickly select the next block producer.

Proof-Of-Stake (POS): an alternative way to select the next block producer based on coin stake

Dan next started looking at proof-of-stake systems. Proof-of-stake (POS) was the new up-and-coming method of selecting block producers at that time and the most well-known implementations were Peercoin and NXT. NXT was of particular interest, because it was also being designed to support a decentralized exchange similar to BitShares.

Proof-of-Stake consensus algorithms select the next block producer based on a combination of how many coins a block producer has, how long he has held the coins (a factor called “coin age”), along with some randomization.

Probably the most interesting idea about POS consensus algorithms was that they relied on the self-interest of the block producers to prevent them from colluding to block transactions. The idea is simple: by design of POS-based blockchains, the block producers hold a large proportional share of the coins. The value of those coins is supported by people who are willing to accept those coins for other goods. And if users decide that the block producers might stop processing their individual transactions, the coins will likely lose value, so block producers are incentivized to process the transactions of other users in the general case.

I honestly don’t recall why Dan chose not to implement a POS consensus algorithm. It had its detractors, including claims that it was subject to “nothing-at-stake” attacks. I do have a vague memory from the time when I was reading the POS algorithm for NXT that it seemed quite complicated (for example, use of randomization in the block producer selection process sounds a bit messy and computing coin-age would have added computational complexity), and I suspect this weighed heavily in his decision to avoid implementing a POS consensus algorithm, especially given the time pressure to get a functional consensus algorithm working quickly with limited funding.

The invention of Delegated Proof-of-Stake

But Dan has always been a strong proponent of economic analysis, especially when it comes to blockchain design, and I believe this was his main attraction to Proof-of-Stake systems.

Yet, at the same time he also liked the design simplicity of the trustee model discussed earlier (easy to implement, predictable block production, works great as long as you can trust the trustees).

So DPOS was essentially a synthesis of these two ideas, combined with a twist: instead of large stake holders directly producing the blocks, the stake holders would elect the block producers to make the blocks. Here the block producers fulfill a role similar to the trustees in his original plan for the consensus algorithm. But under DPOS, they don’t need to be trusted quite as much and the system has a defined mechanism for how the trustees are chosen and replaced, requiring no hardfork to replace them.

A final note on “freezing funds” on a blockchain

It always amazes me how business men who act as “thought leaders” and “influencers” often don’t understand the basics of the technological revolution that they purport to be leading.

One thing that inspired me to write this post was a recent tweet by Changpeng Zhao, the CEO of Binance, aka CZ Binance on twitter, that me laugh. CZ said: “Blockchains should NOT have freeze features.”

CZ was apparently upset that the Steem blockchain could freeze the funds of an account and thought that this was some special feature of a DPOS-based blockchain. Yet, as I hope you’ve learned from this post, every existing blockchain network, including the Bitcoin network, can freeze the funds in an account, as long as all the block producers on that network agree to do so. All they have to do is agree not to include the transactions into their blocks.

Note that this isn’t really a “feature” of blockchain technology, in the sense that blockchain developers didn’t all conspired to design their blockchains to work this way. It’s mostly a limitation of the technology, at least as far as we’ve been able to design blockchains so far.

The fewer the number of block producers on a blockchain, the easier it is to achieve the necessary coordination to freeze an account’s funds. This means, for example, that the top bitcoin mining pools could likely freeze an account’s funds for a very long time assuming they decided it made sense. But generally it’s assumed this won’t happen, because they are paid in Bitcoin and arbitrarily freezing someone’s funds is generally not going to be viewed favorably by the people that support the value of Bitcoin.

So a blockchain’s economics have to be designed so as to discourage the chain’s block producers from freezing an account without a good reason. I’ll probably talk about some ways to do this in my next post.

More to come

As mentioned previously, I wrote this post mainly to lay the groundwork for my next post, which will look at the economics and philosophy of DPOS, explore its advantages and weaknesses, and ideas for how to improve it. Unfortunately, I’m pretty busy lately, so it may take a while before I write the followup post on this topic. I’m publishing this one now as it was mostly written when I wrote my earlier posts, and finishing it up today was a nice way to relax and focus my thoughts.