Consensus

Implementations

PBFT

Stands for Practical Byzantine Fault Tolerance, based on Castro & Liskov's work.

We offer three modes: classic (one request per block), batch (multiple requests per block), and sieve (execute-verify on top of PBFT, makes a best effort to filter out non-deterministic transactions by having participants reach consensus on the result - details).

Use batch (see "How to use" section below) as it is the main area of development focus and provides higher throughput than classic.

Further development on sieve is frozen, and may not be necessary if the new architecture goes through, as the suggested MVCC+postimage scheme filters out non-determinism.

No-op

Referred to as noops in our code, this effectively disables consensus. It is the default mode while the code is in pre-release version. It is used for debugging the rest of the Fabric stack.

How to use

1. In peer/core.yaml set the peer.validator.consensus.plugin key to either noops (default) or pbft. noops will be used if an incorrect value is given.
2. If you chose pbft in Step 1, in consensus/obcpbft/config.yaml set the general.mode key to either classic, batch, or sieve. As suggested above, batch is the recommended mode. The rest of the settings in config.yaml allow you to fine-tune the performance the consensus mechanism.

Naming the validators

When using the pbft module, make sure the validators are named sequentially using the vpX naming scheme, where X is an integer that starts from 0 and goes to N-1. For example, with 4 validating peers, you would set the peer.id keys on your validators to vp0, vp1, vp2, and vp3. [For those wondering why we do this: every validator in PBFT needs to maintain the same sorted list of validators, so that in a view change from v to v+1, all validators point towards the same new primary. Until whitelisting is implemented (see "Roadmap" section below), the vpX naming scheme is the most effective --although admittedly flaky and arbirtray-- way of doing this on the fly.]

Roadmap

(Listed in order of expected delivery.)

1. Validator whitelisting. Every validator should maintain a whitelist of enrollment certificates. If a connecting validator's certificate does not belong to that list, it cannot join the network. This will remove the need for the arbitrary vpX naming scheme (see "Naming the validators" section).
2. Dynamically change the validator set. As things stand now, you cannot expand the validator set size beyond the original value N that you set in consensus/obcpbft/config.yaml when bootstrapping the network. Likewise, you cannot shrink the validator set size either.

Content to add to this Wiki

• Modifications to the PBFT protocol (e.g. periodic view-changes)
• The custodian mechanism to prevent censorship from primary
• Add more Roadmap items and link to Github issues for discussion
• etc.