Understanding Blockchain Fundamentals, Part 3: Delegated Proof of Stake
A while ago, we talked about how consensus works and went over the basics of Proof of Work (PoW) and Proof of Stake (PoS).
The gist is that PoW provides the most proven security to date, but at the cost of consuming an enormous amount of energy. PoS, the primary alternative, removes the energy requirements of PoW, and replaces miners with “validators”, who are given the chance to validate (“mine”) the next block with a probability proportional to their stake.
Another consensus algorithm that is often discussed is Delegated Proof of Stake (DPoS) — a variant of PoS that provides a high level of scalability at the cost of limiting the number of validators on the network.
In this article, we will go over how DPoS works, its benefits, its tradeoffs, and how we can mitigate those tradeoffs to achieve a higher level of scalability, while avoiding censorship and double-spend risks.
What is Delegated Proof of Stake?
DPoS is a system in which a fixed number of elected entities (called block producers or witnesses) are selected to create blocks in a round-robin order. Block producers are voted into power by the users of the network, who each get a number of votes proportional to the number of tokens they own on the network (their stake
Alternatively, voters can choose to delegate their stake to another voter, who will vote in the block producer election on their behalf.
A note on semantics compared to PoS, from Dan Larimer: [1]
- Block producers are those responsible for creating and signing new blocks. They are limited in number, and are elected by the voters.
- Block validators in DPoS refer to full nodes who verify that the blocks created by block producers follow the consensus rules. Any user is able run a block validator and verify the network. (This can be confusing, since in Casper’s PoS, the word “validators” refers to those who create blocks).
The number of block producers in a DPoS network is up to the consensus rules of that chain. Here are the numbers for some of the more well-known DPoS chains:
- EOS: 21
- BitShares: 101
- Steemit: 21
- Lisk: 101
- Ark: 51
A round in a DPoS blockchain with N block producers is as follows:
- N block producers get elected from the pool of block producer candidates.
- The ithblock producer signs the ith block, until i=N.
A block is finalized (i.e. cannot be reversed) when it is voted on by (2/3+1) of the block producers. Otherwise, the longest chain rule is followed. Finality is an extremely important property when aiming for interoperability between blockchains.
The block reward and inflation mechanism for each DPoS implementation depend on each project’s reward model, and are beyond the scope of this article. Dan Larimer has written in-depth on how DPoS operates under various conditions. [2]
Voters can also “fire” a block producer if they are found to be malicious (i.e. try to censor transactions or double spend) by not voting for them in the next round.
As a result of the limited number of block producers, DPoS is able to handle transaction throughput that is multiple orders of magnitude greater than today’s PoW.
Too Good to Be True?
As we have written previously, DPoS is a protocol that sacrifices decentralization for throughput due to the low number of block producers.
So while DPoS makes sense for many applications that require a high level of scalability, we (and most other serious blockchain developers) believe that DPoS is not decentralized enough to be a base layer that acts as a store of value and ledger of ownership for Web 3 applications.
The base layer of a blockchain that can transfer financial value must be fully decentralized and secure. The base layer must not be compromised.
Interestingly enough, despite heavy marketing from certain projects promoting DPoS as being “superior” to PoW blockchains like Ethereum, even 50% of 880 users in a recent Twitter poll realized that this comes at the expense of decentralization:
Many have written about the flaws of DPoS as a decentralized system, one being Vitalik Buterin, who argued that there are incentives for forming cartels and bribing voters. [3]
Given that we don’t accept anything less than full decentralization for the base layer and we can’t make assumptions about the honesty of network participants, DPoS doesn’t seem like a good fit for a blockchain that handles, among other things, financial transactions.
What about Using DPoS for Specific Use Cases?
We are not the first to think of this. As Myles Snider explains:
“If DPoS systems can still offer the requisite levels of censorship resistance, permissionless-ness, and trustlessness that decentralized databases require, then DPoS is better for a huge range of decentralized applications.
For certain use cases — absolutely censorship-resistant digital gold, peer-to-peer digital money, etc., a tradeoff in favor of decentralization at the expense of performance may make sense.
For the vast majority of applications, scalability is far more pragmatic.” [4]
For applications like a social network or game, every comment or in-game movement doesn’t require the full security of a fully decentralized network, but they do require high throughput. Thus, DPoS seems like a perfect fit for these kind of applications.
Even better — if we use a PoW network like Ethereum as a secure base layer and build our DPoS chain on Layer 2, we can run the majority of an application on the highly-scalable DPoS chain, while still using the secure base layer for parts of the application that require high security, like in-game currency or ownership of assets.
As Vitalik Buterin put it:
If you have an application which really requires very fast transaction confirmations, and for such fast confirmations to happen reliably, then IMO the correct domain in which to build such systems is level-2 platforms on top of secure base-layer platforms like Ethereum.
The level-2 platforms can be built in such a way that they depend on the second level for performance, but not safety (see: state channel hubs, Plasma operators). They can then have the incentive of reputation and expected future revenue to drive them to perform well in the present, and the negative costs of any failure are mitigated. [5]
That way, there is always the option of falling back to the secure PoW mainchain in case a black swan scenario occurs.
For example, if bad actors were able to take over the majority of block producers on a DPoS Layer 2, users’ tokens (potentially worth millions or billions of dollars) would still be secure on Layer 1.
This would not be possible in standalone DPoS blockchains that are not backed by a more decentralized Layer 1 — if the chain is compromised by bad actors, the tokens would be at risk along everything else on the chain.
Hard Forks on Layer 2 Chains vs. Layer 1 Chains
On a DPoS chain, if an adversary gained control of the network through acquiring a lot of stake, then the blockchain would be forced to hard fork in order to censor that adversary.
On a blockchain that contains a ledger tracking ownership of tokens or other digital assets (as most Layer 1 chains do), a hard fork could be catastrophic. It undermines faith in the network’s reliability as a long-term store of value (e.g. one that a person might invest their life savings in).
But in the case of a non-financial application running on Layer 2 that stores anything with value on a secure Layer 1, hard forking is not such a catastrophe.
In the case of an app or game running on Layer 2, as long as the integrity of the underlying data is maintained, hard-forking is a viable solution.