Delegated Proof of Stake (DPoS) derives its name from Proof of Stake (PoS) but is different in both concept and implementation. It is used in projects such as Lisk and the forthcoming EOS, and is designed to provide faster and cheaper transactions as well as allowing for increased scalability. 

 Instead of allowing all users on the network to validate transactions, DPoS allows token holders to vote (proportional to their holdings) to elect a small number of users to validate future blocks. By reducing the number of validators and requiring them to meet minimum performance requirements, DPoS makes the network quicker. 

 PoW or PoS are constrained, in part, by the network latency of having large numbers of nodes distributed worldwide. As the number of transactions per second needed by the network increases, the amount of information that must be synchronized by the entire network also increases. DPoS reduces this problem by concentrating the consensus of the network to only a few, well resourced, well connected nodes. This allows for more and larger blocks to be created, dramatically speeding up transaction times and overall network throughput. 

 Those elected are known by a number of terms depending on the network, including ‘Delegates’, ‘Witnesses’ or ‘Producers’, but take on similar responsibilities to miners and validators from PoW/PoS. Delegates must maintain a node 24/7 (in some DPoS implementations they also have to stake a number of tokens, similar to PoS), collate transactions from across the network into blocks and subsequently validate/broadcast them to the rest of the network. 

 This continuous real-time voting to elect delegates brings about several new aspects to consensus algorithms: It gives all token holders the ability to influence what is happening on the network; it also creates a need for delegate reputation. If you do not have a good reputation you are unlikely to be elected, as users will seek to elect those who operate according to the best interests of the network. Finally, it removes the competitive aspect of PoW/PoS and instead allows delegates to collaborate with each other to create new blocks. This removes some of the waste of PoW/PoS block creation, where unsuccessful work is simply discarded. 

 

DPoS solves the Byzantine Generals Problem in the following manner:

1. The Generals vote to elect trusted delegates. These votes are weighed in proportion to the amount of each of the Generals’ holdings of the platform currency. For this example, let us assume there are nine Generals who elect three Generals as delegates.
2. The DPoS algorithm randomly selects one of the three delegates to produce the next block, which the chosen delegate creates, and is then validated by the other two delegates.
3. A new block is created every three seconds, with none of the three delegates able to create a block when it isn’t their pre-assigned turn. Every new block builds upon the previous one and includes a reference to it.
4. To remain as a delegate, maintain their reputation, and keep their stake (if applicable), delegates must create their blocks on time, without missing their slot. As the chain continues to grow, all delegates confirm the majority chain which means counterfeit chains are hard to create- they would not have the transactions from the legitimate chain
5. DPoS is designed to not experience forks, as delegates are collaborating rather than competing. If there is a disagreement between the Generals then consensus automatically switches to the longest chain (in our example, if A and B both produced different chains then C would be the tiebreaker and whichever chain they chose would become the majority chain again. This is why there is an odd number of delegates – to prevent a stalemate
6. The rest of the Generals see the majority approved chain and know that all delegates are contributing to it. As a result, they can know that this is the agreed upon consensus and thus the order to follow

 It is important to remember that a consensus algorithm merely attains consensus – just not necessarily the ‘right’ consensus. It is possible for a DPoS chain to be taken over by malicious actors. If we assume A and B are both malicious, the chain they make would become the majority chain. In this event, C would continue producing their own minority chain until elections could be held to kick A and B off this chain. Once A and B were kicked off C’s fork and honest actors appointed, the combined three honest actors would quickly be able to overtake the malicious fork in length. The incentives for a delegate to act honestly returns to the rewards on offer and the threat of being removed from these lucrative roles. 

 DPoS brings with it a number of advantages. Besides allowing for more and faster transactions, with the likes of Steemit and Bitshares able to process a couple of thousand transactions per second, it also enables cheaper fees. No expensive mining equipment is required, and there is no competition between producers. It also avoids the energy wastage of PoW implementations. There are only a small number of delegates involved in the validation process, so minimal computing resources are required. 

 Furthermore, proponents claim that the ability for real time voting means that a malicious delegate can be removed immediately, securing the safety of the network. They also argue that DPoS offers a democracy, whereby all users get a voice in how the network is run and therefore can also vote on governance issues, unlike other implementations. 

 However, critics note a number of issues with DPoS.

Not all is rosy

Chief among the issues with DPoS is the need to trust a small number of delegates. This not only means users must trust those elected to act in the best interests of the network, but also that power is concentrated in a small number of delegates and therefore increases centralization. 

 As there are fewer delegates entrusted with securing the network and validating transactions, the network is also potentially more susceptible to a 51% attack. A malicious actor would need only possess 51%+ of the delegates, not a majority of the entire network. The small number of delegates also become a potential attack vector for other attacks such as DDoS, unlike PoW or PoS where there are thousands of full Nodes operating worldwide. 

 The implementation also creates a two tier hierarchy, divided between a ruling set of delegates and the wider user base. This sort of system necessitates active participation by voters to keep delegates ‘honest’, but voter apathy is as applicable to DLT systems as it is in real world politics. This lack of voter involvement also makes it easier for larger interests to control voting and therefore dictate who receives block rewards. These rewards also mean prospective delegates are incentivized to bribe voters and collude with others in order to secure a delegate role. 

 Similar to PoS, this trend of the largest being best-placed to receive the most rewards means that the network will trend towards an oligarchy inclined to collude, rather than compete. The largest actors will become richer and strengthen their position as delegates over time. As they earn more rewards, they will hold more tokens. As they hold more tokens, they will have a proportionally higher share of the vote. This means they will then be more likely to be elected, and the cycle repeats, consolidating supply in hands of a narrower and narrower minority. 

 One of the largest Lisk voting pools has 32 of the top 101 delegates. Another has 54. The 101st ranked delegate currently has an approval of 26.3% meaning that any ‘independent’ prospective delegate would have to secure over a quarter of the entire voting base to be eligible to be a delegate – effectively impossible. 

 These flaws are exaggerated when one considers the rapid price growth many DPoS systems have experienced recently. There are DPoS networks which have appreciated 50-500x from 2017, producing a clear imbalance. 

 As an example, Ark raised under $1m in its ICO 18 months ago in late 2016, for 93.75m tokens. Those 93.75m tokens would now be worth around $300m. This leads to the likelihood that a small number of users are in control of the network and would be very difficult to displace, given the share of the network they collectively control and the cost of achieving parity. This is not necessarily a problem confined to DPoS – some PoS projects suffer from the same issue – but it does make initial token distribution a more pressing concern, and weakens numerous existing implementations. 

 DPoS allows for more and faster transactions, but in doing so brings forward a new set of potential issues. It compromises on centralization in order to improve speeds, driven by inherent limitations of blockchain. It is for that reason that a number of teams began to move away from blockchain and towards other DLT implementations. 

Join The Radix Community

Telegram for general chat
​Discord for developers chat
​Reddit for general discussion
Forum for technical discussion
​Twitter for announcements
​Email newsletter for weekly updates
Mail to hello@radixdlt.com for general enquiries