Definition: Delegated Proof of Stake (DPoS) is a form of consensus algorithm, where voters vote for block producers (sometimes called witnesses) who then perform the block creation and enforce the consensus. In order to vote a voter needs funds. And the voting power is proportionally to the amount of tokens or coins a voter has (or stakes).
The idea behind delegated proof of stake is that voters only vote for trustworthy block producer candidates. If an elected block producer should misbehave or misses out on the block producing process it is expected that they get voted out.
Explanation/Principle of Work DPoS
There are different designs possible for a delegated proof of stake blockchain. Most differences in the algorithms are in:
- Voting and staking
- block creation and block producer selection
- changing the protocol
- chain selection and protocol enforcement
They are covered in the following sections. In our explanation we give an overview of how DPoS consensus blockchains work. A deeper scrutinization and explanation can be found in referred documents or other articles.
Voting and Staking
Since the voting power in delegated proof of stake depends on the funds a voter possesses, they need to stake their funds in a certain voting contract which gives them the right to cast a vote on one, two or more block producer candidates.
Voting can be continuously or periodically. In a continuously model the voter chooses its favorite block producer candidates and stakes its funds once. And as long as the voter keeps the funds locked in the voting contract, those votes are counted in every election round. There is also no starting point of when you can stake. However, the stakes will be counted in discrete time. In EOS votes are recalculated roughly every two minutes. [https://steemit.com/eos/@attic-lab/eos-io-consensus-algorithm]
It is also possible to withdraw and or re-stake staked funds every time. Although it can happen that some systems (like EOS) have a three day lock period until the funds are released to the holder.
Another approach would be to return the funds to every user after a certain number of block producing rounds automatically and require the voter to make a new decision, if he wants to vote again.
Both approaches have their benefits and disadvantages. The continuous voting scheme needs less interaction from the voters, once they have decided for a candidate. They stake it and forget it. Whereas the periodically voting scheme needs regular decisions and action to stake the tokens again.
While the continuous voting scheme is more convenient it has a major drawback. In some cases, block producer candidates leave the game or misbehave. If voters forget to update their decision it means that votes are casted for non-existent or untrustworthy candidates.
Usually there is not minimum stake in order to vote for a block producer. This lowers the entry barrier and contributes to a more democratic approach.
Voting decay (EOS)
In order to overcome the issue with lazy voters who forget to update their votes, EOS introduced voting decay. This means that the influence of a vote gets smaller over time. If a voter for example staked 1000 EOS it has an immediate voting power of 1000 EOS, but one year later it is reduced to only 500 EOS. The 1000 EOS are still there, they are just counted differently when counting the votes.
This reduction of voting power over time is called voting decay. In order to avoid a decrease in its voting power, a voter needs to re-stake its EOS from time to time.
Count of votes
This section deals with how voters can distribute their votes to candidates.
Unlimited number candidates vs. limited number of candidates
The easiest setup would be to allow each voter to vote for as many block producer candidates as he wishes. Another approach is to limit the number of candidates a voter can support. EOS for example limits the number to 30. So, if there are 100 block producer candidates and a voter likes 40 of them he could only cast his vote to 30 of them. In the strictest sense this number could be reduced to only one candidate.
Fractional voting vs. full voting
If it is possible to support more than one candidate there are two ways on how the votes are counted.
The most intuitive way would be to split the stake on the candidates. If you have for example 1000 token staked and you want to support three candidates A, B and C you could allocate 400 tokens to A, 400 to B and the remaining 200 to C. This is fractional voting.
In a full voting system a voter with 1000 tokens can allocate 1000 token to candidate A and 1000 token to candidate B and 1000 tokens to candidate C.
Both, fractional voting and full voting have their benefits and disadvantages.
In a full voting system minorities have difficulties in getting even one of their favorite candidates elected. In case few accounts contribute to more than 50% of the stake and they agree on a certain candidate list, they have no trouble in forcing other rivaling candidates out. Whereas the minority no matter how well they organize themselves has no chance in electing their candidate.
The following example clarifies this point.
We assume that there are ten voters and five candidates. From these five candidates the three candidates with the most votes become block producers. Among the ten voters voter one owns more than 50% of all staked tokens.
Voters 2 till 10 agree on voting for candidate D.
|1||1001||A, B, C|
Table 1: voters and their supported candidates.
Table 2: rank of the candidates after the election.
As you can see candidate D has no chance in winning a position among the first three selected candidates. EOS is one blockchain which applies this voting system.
In a fractional voting system voter 1 could not block out candidate C that easy. He would have to split its tokens among candidate A, B and C and the other voters could at least bring one candidate into the pool of block producers.
While this looks like a more proportional system. its creates another problem. If we assume block producer candidate A and B are very controversial but very popular among their followers and they want to see their favorite candidate in the pool of block producers they might allocate their votes completely to them. We can assume that voters don’t collude here.
Table 3: voters and their candidates
Table 4: results after voting.
Candidates C, D and E would receive no votes at all, because every voter would prefer either A or B and would want to make sure it gets elected. In the end not all slots of the block producer committee are filled and the consensus mechanism depends on only two candidates (or in the worst case even only one). This problem might be amplified by voting incentives paid by the winning candidates to their voters. Here, everybody would make sure to dedicate as much voting power to a candidate who certainly wins.
Registration as a block producer candidate is usually done in a smart contract. In TRON network users who want to register as a block producer candidate need to burn 9999 TRX tokens. [https://developers.tron.network/docs/mechanism]
Minimum lock time
Usually voters can change their votes anytime and the latest vote counts. EOS requires its voters to lock their funds for at least three days before they are entitled to count for a vote. [https://support.token.im/hc/en-us/articles/360005049833-EOS-Block-Producers-Voting-Guide]
A minimum lock time for the funds is necessary in order to avoid voters using multiple addresses by transferring their funds quickly from one address to another one.
In order to have an incentive to provide hardware an maintain it block producers are rewarded usually in coins or token which can be exchanged into coins. In most cases there are more block producer candidates then actual elected block producers. In EOS there are for example 21 block producers. They received the most votes. As a compensation for theirs service they get 0.25% of the block reward. But there are more candidates which didn’t make it into the top 21 list. The next 79 bock producer candidates are on stand-by. They also receive some compensation. They share 0.75% of the block reward.
But also the voters can be rewarded in order to stake. Otherwise, voters might not voluntarily lock their funds in the voting contract. This is called staking reward. EOS officially doesn’t pay any reward to the voters. But despite it is officially banned block producers pay rewards to those addresses which voted for them.
TRON for example offers voters a certain number of free transactions. Also, elected block producers can distribute a certain amount of their block producer rewards to their voters. This is possible in TRON. In EOS this is forbidden but is still done by some block producers.
In most cases voters don’t loose their stakes even if a block producer doesn’t comply to the network rules.
Changes of the protocol
In many DPoS blockchains block producers have to obey to the protocol. If they introduce new rules or deviate from the agreed behavior, they risk losing their votes in future election rounds.
But regular updates of the protocol are necessary and inevitable in order to maintain a secure and functioning system. Therefore exist special entities called delegates. They are allowed to make changes to the protocol. Delegates can be elected by the voters or determined centrally. Those delegates usually don’t produce blocks. But of course a block producer node and a delegate node can be controlled by the same person or company.
Typical decisions of delegates are among others:
- Transaction fees
- Block size
- Block producer selection algorithm
- Intervals of the network
In most DPoS blockchains delegates don’t get rewarded for their work. Hence, they need intrinsic motivation to dedicate time and resources.
Block producer selection
Typically, all elected block producers take turns in creating blocks. The simplest model is a round robin where block producers work in a predefined order. A round consists of each block producer signing one block each. After each block producer signed a block a round is over. EOS lets a block producer create 12 blocks every time before another block producer takes over. [https://github.com/EOSIO/eos/blob/master/libraries/chain/include/eosio/chain/config.hpp#L103]
If there are multiple rounds until a new election takes place the time between two elections is called epoch.
There is also a (pseudo) random ordering algorithm conceivable or a selection based on the ratio of received votes.
In the following figure we see three epochs with two rounds each. Block producer A and D are replaced by E and F in epoch 2 and 3 respectively. In each round the elected block producers are shuffled randomly. A random shuffling is supposed to impede collusion among block producers.
Block are assembled by the elected block producers. They collect the transactions, check their validity, build a block out of them and sign this block with their private key. After that they submit it to the network.
In EOS at least 2/3 of all 21 block producers (so minimum 15) need to agree on a block before it is considered irreversible. All block producers are allowed to sign all blocks. A block producer is not allowed to sing two (or more) blocks with the same timestamp or the same block height.
The time between every block is given by the protocol. We call this the interval time. In EOS this is typically 0.5 seconds.
If a block producer misses a block this slot remains empty. No block will be produced. The next block producer in turn will continue as normal. This means the network is hold up by the interval time.
Chain Selection or Fork Choice
The most common chain selection rule in delegated proof of stake to choose the canonical chain is the longest chain rule.
In a system where a non-responding block producer creates an “empty” block or a gap the chain with the most block producers creates the longest chain. In such a setting a block producer must not be allowed to create two conflicting blocks at the same block height. All other block producers would have to ignore such a block.
In the following figure we assume five block producers A, B, C, D, and E. C is creating its own chain (either by not following the protocol or by not being recognized by other block producers).Figure 2: block producer C tries to create its own chain. While the upper chain has eight blocks within two epochs the lower chain only has two blocks.
In EOS beside the longest chain rule another mechanism is applied – transactions as proof of stake (TaPoS). Here, each transaction needs to include a hash of a recent block. This makes a replay attack of a transaction in a fork impossible and also tells the network where a user wants its funds spent. That way an attack chain cannot include transactions from the original chain after the split and the users would refuse to chose the attack chain even if this should become the longest chain.
Advantages and Disadvantages of DPoS
In this section we discuss advantages and weaknesses of DPoS algorithms.
Weaknesses and Disadvantages
DPoS has also its critics:
- Centralization: There are usually only a few successful block producers. This means they can form cartels. If block producing generates sufficient funds they can maintain their position infinity by voting for themselves.
- Complex rules: In order to avoid attacks there are many rules necessary which can become very complex. Many of those rules are not enforceable on protocol level. Instead they require voters to vote a malicious block producer out.
- Vote buying: This is seen as a hardly inevitable thread to DPoS blockchains, since this manifests the power of current block producers.
- Exchanges and custodial wallets can vote in behalf of their customers. This gives those institutions a lot of influence.
- Voters must pay continuously attention to the behavior of the block producer candidates. A thorough research of all block producers is time consuming.
The most obvious advantage of delegated proof of stake is the energy efficiency. Theoretically it is possible for users with consumer grade hardware to participate in the block producing process. But it might be difficult for them to get enough votes.
Also, in many DPoS systems there are very low entrance barriers for voters. Some don’t require a minimum stake.
Another advantage is that users, depending on the governance model, can vote on improvement proposals either directly or indirectly by electing delegates.
List with blockchains and crypto coins utilizing DPoS
Here is an overview of blockchains using delegated proof of stake as consensus algorithm. The links either point to their website, GitHub page or white paper.
- EOS (technical documentation) [https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md]
- Steem (white paper) [https://steem.com/steem-whitepaper.pdf]
- Tron (white paper) [https://tron.network/static/doc/white_paper_v_2_0.pdf]
- BitShares (description, white paper like) [https://cryptorating.eu/whitepapers/BitShares/bitshares-general.pdf]
- Lisk [https://lisk.io/]
- NEO (white paper) [https://docs.neo.org/docs/en-us/basic/whitepaper.html]