# Consensus mechanism
# Practical Byzantine Fault Tolerant
Practical Byzantine Fault Tolerant, in short PBFT, “presents a new, practical algorithm for state machine replication that tolerates Byzantine faults."  The Zarb consensus algorithm is highly inspired by Practical Byzantine Fault Tolerant (PBFT) algorithm.
# The algorithm
There are replicas. where is the maximum number of replicas that may be faulty or byzantine. For example, if there is one faulty replica, the resiliency of the algorithm is optimal if we have at least 3 non-faulty replicas. So the minimum number of replicas should be .
In each round, one replica is the proposer and the others are validators. The normal case operation of Zarb consensus algorithm includes these three steps: propose, prepare and precommit
# Propose phase
A proposer () collects transactions and creates a proposal block. It signs and broadcasts a proposal message with block piggybacked to all the validators.
Proposal message has this form:
- is proposed block
- is proposal's digest or hash
- indicates the block height
- is an assigned round number, which is zero for the first round
# Prepare phase
If validator accepts the proposal, it enters prepare phase and signs and broadcasts prepare message to all other validators. Otherwise, it does nothing.
Prepare message has this form:
If validator received prepare messages from other validators (possibly including its own), it is prepared and enters to precommit phase.
# precommit phase
In precommit phase, validator signs and broadcasts precommit message to the other validators.
Precommit message has this form:
Each validator executes and commits block after receiving precommit messages (possibly including its own) and becomes committed.
All the messages in the above steps are cryptographically signed and all replicas know the others’ public keys to verify signatures.
The picture below shows the operation of the algorithm in the normal case of no primary faults. Replica 0 is the proposer, replica 3 is faulty.
# Block announcement
Each validator that receives a valid proposal and with precommit messages can make a certificate and broadcasts block_announce messages with the block and certificate piggybacked to the network.
- is the block certificate
Validators can move to the next height and clear the message logs after receiving valid block_announce message.
# Change proposer
The change-proposer protocol provides liveness by allowing the system to make progress when the proposer fails. change-proposers are triggered by timeouts that prevent validators from waiting indefinitely for the proposal to execute.
If the timer of validator expires in a round, the validator starts a change-proposer phase to move the system to round . It stops accepting messages (other than change-proposer and block-announce messages) and broadcasts a change-proposer message to all validators.
The change-proposer message has this form:
If the proposer for round receives valid change-proposer messages for round from other validators, it goes to next round and broadcasts proposal message.