# Challenges of PBFT-Inspired Consensus for Blockchain and Enhancements over Neo dBFT
## 5 Promising dBFT Extensions: Towards dBFT 3.0
### dBFT 3.0-WS2: Double Proposals on dBFT
#### Byzantine Attacks on dBFT 3.0-WS2: Towards dBFT 3.0+  
Byzantine nodes can be faulty up to \(f\), and systematically not replying to messages may cause undecided situations to arise, requiring a change view. This happens to likely be the worst action a byzantine actor can perform on dBFT 3.0-WS2 (shutdown its own replica), as discussed in the following paragraphs.  
Malformed proposals or responses are not smart attacks, since they are directly detected and will trigger a temporary _blacklist_ action on that replica. They cannot fake other identities as well, due to public-key cryptography. A byzantine primary can still propose a \"valid\" block, but including certain transactions that are not found on mempool (or does not even exist), according to (P.8). However, this byzantine action still cannot force nodes to commit to a bad proposal, as every non-faulty response to that proposal would require a non-faulty replica to actually have all the transactions (guaranteeing that block is valid after all).  
On the other hand, a tricky thing that a byzantine node can try to do is to respond _simultaneously_ to multiple proposals (also using network asynchrony in its favor), in the hope of committing other nodes to follow different proposals. There are two ways of circumventing this malicious attack, according to the global strategy of the network. One thing is certain: any detected double proposal will issue a _blacklist_ on that node, with all side effects it will have according to off-chain governance. Here are the options for a dBFT 3.0-WS2+:  
1. To detect double proposals efficiently (and blacklist faster), one can aggregate \(2f+1\)_pre-commits_ before issuing/following a commit (pre-commits should carry known preparations). This leaves no space for byzantine nodes to pass undetected (In empirical experiments this appeared to be true in all cases tested. Feeling up to now indicates that it will be nearly impossible for a byzantine node to pass unnoticed from double responses, thus certainly being blacklisted, and the spark prevented.)
2. To be more speculative, one may follow _pre-commits_ fast strategies (thus allowing the skipping of one phase in most cases), and issuing a blacklist on byzantine node only after it is detected (perhaps after issuing its own commit, which may cause a spark)  
The question is: what are the interests of a consensus node in issuing a double response, in trying to spark when values are at stake? This question does not need even to be fully resolved as a \(\{0,1\}\) matter. One node may be more speculative according to the responses of some _more trusted_ replica, while being more conservative according to other (perhaps towards an unknown guest node). Many _flavors_ are possible here (both for consensus and network nodes), according to the overall network policy and values at stake. We believe that this opens even more doors for academic discussions on the topic, allowing different solutions to different implementations of consensus node for dBFT 3.0-WS2.