# Challenges of PBFT-Inspired Consensus for Blockchain and Enhancements over Neo dBFT
## 4 dBFT 2.0
### How Does PBFT Handles Consistency across Views?  
PBFT considers the task of totally ordering a given set of requests, sent directly by each client to the expected primary replica. If this first transmission fails, it will keep retrying, but now also send to other replicas. In PBFT, three-phase consensus happens at the level of _each independent request_, by attributing an unique sequence number \(n\) to each request, and guaranteeing that all non-faulty replicas will eventually agree to it.  
Please note that consensus may finish in different times, for different requests, due to network delays. That is why, from time to time, it is important to create _checkpoints_ that aggregate several past decisions into a _bigger package_, and guaranteeing that all non-faulty replicas also agree to that package. At this point, if some request was pending for too long, it needs to be resolved for the process to go on. Hopefully, these checkpoints only happen from time to time, and if this time is long enough, they would not interfere/lock the next consensus round.  
This is very different from a blockchain, by totally ordering bigger _chunks_ of _requests_, respectively called blocks and transactions. For dBFT, the primary selects a chunk of transactions and forms a block, with an unique hash identifier, including a nonce and timestamp. The task of backup nodes is to validate that information. However, what happens then, when somehow a commit is performed by some node, and only then a change view occurs?  
For PBFT, change views have the remarkable capability of keeping the sequence number \(n\) of any possible committed node in the past (non-faulty ones at least), so new views are not likely to change that number. To perform this, view change messages carry _all available information_ of each participant node, and just like magic, having \(2f+1\) nodes participating in the change view is enough to guarantee  
Figure 10: Request sent by replica 1 and \(2f\) PrepareResponse to replica 2 that becomes _Prepared for \(\#H\)_. Replica 3 is dead. Replicas 0 and 1 want to change view, but are unable due to recovery synchrony condition \(c^{\prime}+f^{\prime}>f\) (where \(c^{\prime}=1\) prepared replicas and \(f^{\prime}=1\) dead replicas). This prevents nodes from changing view, when next view would be unable to capture necessary \(2f+1\) signatures to form a block. In this case, system resolves naturally when the minimal number of messages arrive at destination (even with large delays).  
that a new (and honest) primary will keep that same number \(n\) for that same request. This guarantees that replicas in future views will commit at same sequence number that they could have committed before (and the same is valid for those who have already committed).  
This is not a trivial task on a blockchain. A faulty primary may propose transactions that do not exist, and because of that, a non-faulty primary may propose a valid block that gets rejected (by timeouts) if other replicas cannot get/validate that information quickly enough. Yet, although heavily non-deterministic, the _mempool_ typically spreads information quickly enough to give enough information for backups to validate any block sent by a non-faulty primary (within the time limit). However, if a new primary assumes the task of block proposal (after change view), it is currently _free_ to re-create the block in any way it wishes, thus possibly dropping all efforts made on a previous view.  
We argue that replicas could give simple, but important hints to a new primary, in order to reduce possible block proposal conflicts on higher views.