Delegated Proof of Stake: Features and Tradeoffs

A short overview is presented below. To download our full 19-page report, please click the PDF link.

Intro

Distributed ledgers don’t easily scale. That fact has become readily apparent in the last few years as Bitcoin, Ethereum, and others have faced serious challenges as they attempt to increase the speed and throughput of their platforms.

This problem can be best understood as a scalability trilemma (this idea was first formalized by Vitalik Buterin and Trent McConaghy). The scalability trilemma posits that any blockchain system in which every node validates every transaction can have only two of three potential properties: decentralization of block production (DBP), safety, and scalability. These properties can be defined as follows:

• DBP can be quantified as the number of block producers.
• Safety can be quantified as the cost of mounting a Byzantine attack that affects liveness or transaction ordering. Note that safety does not refer to the integrity of cryptographic signatures, or the ability of a 3rd party to derive a set of private keys from public keys.
• Scalability can be quantified as the number of transactions per unit of time that the system can process.

While projects like Ethereum, Dfinity, Polkadot, and Kadena are attempting to solve the scalability trilemma via sharding, alternative consensus schemes, and other techniques, we don’t yet have a live platform that has solved this trilemma. Even if one of these projects does manage to solve the scalability trilemma, the market may not care. It is entirely possible that users are willing to accept tradeoffs in decentralization of block production or safety in the name of better performance and easier user experience for certain use cases.

Decentralization is valuable to ensure that any given party cannot alter the database. More decentralization means it is harder to collude to alter the database. There are different levels of protection which are necessary for different use cases. Bitcoin, being censorship-resistant money, is designed for sovereign-grade protection; it is designed to withstand an attack by a large nation-state. However this isn’t necessary for most decentralized applications (dApps). These dApps need platform-grade protection; global, neutral databases uncontrolled by any one party.

Delegated Proof of Stake (DPoS) concentrates block production in the hands of just a few, known, semi-trusted entities in order to achieve orders of magnitude more scalability than proof-of-work (PoW) or other proof-of-stake (PoS) blockchains. In this analysis, we’ll examine the features and tradeoffs of DPoS.

Delegated Proof of Stake

Delegated proof of stake (DPoS) is a consensus algorithm invented by Dan Larimer in 2013. DPoS was originally invented to power BitShares, Larimer’s first blockchain project. He refined it in his second project, Steem, and is refining it further in EOS, which he’s been working on for about one year. While Larimer invented DPoS and continues to evolve the algorithm, several other projects have adopted DPoS and made changes.

In DPoS, those who hold the network token are able to cast votes to elect block producers; votes are weighted by the voter’s stake, and the block producer candidates that receive the most votes are those who produce blocks. Users can also delegate (“proxy”) their voting power to another user who can vote on their behalf. DPoS is a liquid, representative democracy with token holder suffrage. DPoS can also be thought of as a formalized, digital version of a traditional organizational hierarchy that operates in a completely transparent way. While there are problems with both democracy and corporate governance that are beyond the scope of this paper, one compelling features of DPoS is that the open-source nature of these protocols means that users can fork if they disagree with the majority. The same cannot be said of democracies, corporations, and other organizational structures. DPoS adopts ideas from many traditional governance models, but is ultimately far more flexible and transparent.

Block producers can be voted in or out at any time, so the threat of loss of income and reputation is one of the major incentives against bad behavior. Additionally, slashing conditions can be implemented in DPoS rather trivially. Most traditional PoS implementations allow users to produce blocks proportional to their stake in the network. DPoS allows users to cast votes proportional to their stake to decide who produces blocks. Block producers themselves do not necessarily need to have a large stake, but they must compete to receive votes from users.

DPoS can power entire blockchains, or it can be used as a consensus algorithm for child chains, sidechains, private blockchains, and more. DPoS could be used to power consensus within Ethereum Plasma chains, and DPoS bears many similarities to the “Proof of Authority” consensus mechanism formalized by Parity. It could also be a solution for application-specific chains like those in Cosmos zones.

DPoS recognizes that decentralization has a cost—both economically and in terms of performance—and it opts for semi-centralization in exchange for scalability. 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.

In this analysis, we’ll examine DPoS in-depth, looking at the features, tradeoffs, attack vectors, and use cases. Download the full report here.