Who is most legitimate to concisely explain a complex mechanism? Its creator himself, of course! We will therefore be quoting Dan Larimer’s article “DPOS Consensus Algorithm – The Missing White Paper“, which is certainly the most understandable one available on the web. If the reader is interested in the character, he ought to find many interesting and brilliantly written ideas in the article.
For this illustration, the number of block producers is reduced to three: producers A, B and C. Each block will therefore be produced randomly by A, B or C, and validated by all three delegates (this is a simplification, in reality there are 21 delegates and the blocks must be approved by two-thirds of the delegates plus one). Here, it is producer C who separates the borderline cases.
It should be noted that the above-mentioned problem of nothing at stake does not arise in the case of DPoS : token holders vote for validators, not for blocks. The number of validators is fixed and the order in which they produce blocks is also defined by the protocol: it is impossible for a minority of them to create a fork that could take over the “honest” chain.
Normal operating situation
When the network operates normally, the algorithm assigns a time interval of three seconds to each block producer, during which it can create a block and submit it to the other validators. Any block submitted to validators outside the time interval assigned to its producer will be rejected. If no producer misses his turn, the longest chain will always be produced in this way.
What happens if there is a minority fork?
In the case where a minority part of the actors – up to 1/3 of the block producers – produce a different chain of blocks (malicious behaviour or technical dysfunction), the time spent producing these blocks will always be higher than the time that the rest of the participants will spend building the majority chain (1 block every 9 seconds in this example, against 2 blocks every 9 seconds for the “honest” chain). It will therefore always be the “honest” channel that will be the longest, and the rest of the network will therefore consider the latter as valid.
Double production by a disconnected minority
Again, if a minority produces several forks, the time spent creating these blocks will always be greater than that required for the majority of producers to build a valid chain. These forks will therefore always be invalid.
Fragmentation of the network
In case of poor connectivity between producers, it is possible to end up with several channels.
If none of them has the majority of producers’ votes, the longest minority channel takes over.
If two majority channels are of equivalent length, at the time of reconnection, the producers having forged a minority channel will choose to join one of the majority channels, and only one of them will then take over.
Double production by a connected minority
In this case, a minority of producers decide to produce several blocks in the same time frame. In the next round, the next producer must then choose any of the proposed alternative channels, making the longest chain. The rest of the nodes will therefore choose the latter: this ensures that, whatever the number of “alternative” blocks produced by the malicious minority, they will only be part of the longest chain during a single time interval.
Finality: last irreversible block
The notion of purpose is specific to proof of stake – it is the point from which a block is considered irreversible, immutable, by the client software. In the case of proof of work, this notion of purpose does not exist: a block is valid as soon as the consensus of the nodes of the network has allowed its inscription on the blockchain. The additional confirmations will ensure that the fork risk becomes negligible.
In some cases of prolonged network fragmentation, several chains could continue to develop. As seen before, it will always be the longest chain that wins; but there must be a way for the observers (the nodes relaying the transactions) to determine with certainty the point where a block is finalized. It is here that the confirmation of two thirds of the validators plus one is required: once the vote is carried out, one can be assured that no alternative chain can be longer than the chain chosen by the block producers (to the extent, of course, where at least 2/3 of the participants are honest). This is similar to the rule of the “6 confirmations” on the Bitcoin network, from which we consider that the probability that a fork competing to the blockchain is being subjected to the network becomes totally negligible. The extreme case where, by very well coordinated collusion of the attackers, two different irreversible blocks could coexist -this would require total control of communications between the producers- can, in the long run, be mitigated by the rule of the longest chain. Dan Larimer considers this attack highly unlikely and its economic consequences would be insignificant.
No block producers quorum
In the unlikely event that there is no producer consensus, a minority channel may survive. It is then the token holders who will vote to select a new set of producers, thus restoring the maximum participation rate. It is then possible that it is the minority channel that finds itself with 100% participation, thus becoming the only valid channel. In this case, network observers should keep in mind that there is a small probability that the consensus validates a minority channel at given time “t”. This is equivalent to considering a transaction with less than three confirmations on the Bitcoin network valid.
Corruption of the majority of block producers
In the case where more than two thirds of the block producers would be corrupted, the latter could then make several forks coexisting, presenting blocks having identical confirmations. It will then be up to the minority to tip the balance in one direction. Token holders will vote to eliminate these corrupt producers.
Randomized producer processing order and transaction as proof of stake
Practically speaking, the selection mechanism that determines the “running order” of block producers is random. This “running order” changes all N blocks, where N is the number of block producers.
It should also be added that each time a transaction is signed and then released on the network, it presents a hash referring to a previous block. If this block does not exist on the longest string (for example, if the user signing his transaction has chosen a block status that has since been invalidated by consensus), this transaction will be rejected.