The current validator network can handle one concurrent pBFT process created after a proposal is received and its parent block is known. This leads to failures building a pBFT majority in some circumstances on high latency networks, specifically in two cases:
Prepare/commit messages referencing an unknown proposal are dropped (if the proposal message gets delayed)
Prepare/commit messages referencing a buffered proposal are dropped. Buffered proposals are intrinsically valid but the micro block chain leading up to them isn't complete yet.
To solve this, the validator network is rewritten to track multiple concurrent pBFT processes for different macro blocks, like so: Map<Blake2bHash, PbftState>.
The PbftState can exist in three settings:
Valid: The referenced micro block chain is available and the proposed macro block would be valid on-chain. It is the only setting that can complete a view change, if a 2/3 majority of commits is reached.
Buffered: The proposal is available but can't be checked for validity yet. (Failure case 2) It gets to a valid setting if the micro block chain is available and the proposal checks out.
Weak: No proposal is available but there are votes for this block hash. (Failure case 1) It gets upgraded to a buffered or valid setting respectively when a proposal gets available. To prevent spam, the number of weak proposals must be limited.
At the end of each epoch, old valid and buffered proposals are pruned. Additionally, their macro block hashes are pushed to a blacklist LimitHashSet to prevent accidental re-creation of a PbftState by pBFT prepares/commits received after committing the macro block.
The current validator network can handle one concurrent pBFT process created after a proposal is received and its parent block is known. This leads to failures building a pBFT majority in some circumstances on high latency networks, specifically in two cases:
To solve this, the validator network is rewritten to track multiple concurrent pBFT processes for different macro blocks, like so:
Map<Blake2bHash, PbftState>.The
PbftStatecan exist in three settings:At the end of each epoch, old valid and buffered proposals are pruned. Additionally, their macro block hashes are pushed to a blacklist
LimitHashSetto prevent accidental re-creation of aPbftStateby pBFT prepares/commits received after committing the macro block.