How does RAFT consensus algorithm in Quorum ensure deterministic chain extension?

1
votes

In Quorum's RAFT consensus docs it is mentioned that

This chain extension logic is deterministic: the same exact behavior will occur on every single node in the cluster, keeping the blockchain in sync.

In a case when there is leader change going on, how can the consensus algorithm ensure that all the follower nodes have the same ledger? Isn't there a possibility that some follower nodes get a new block from the previous leader first and some nodes get a new block from the new leader first? Is there any syncing mechanism to avoid this kind of behavior?

1
blockchainconsensusraftquorum

1 Answers

1
votes

It is possible for follower nodes to get a block from the previous leader during a leadership change; but they won't use it until the block is committed by the new leader which may not happen.

The raft replication takes place in two stages: a prepare phase and a commit phase. Both happen through the Append message, which has a committed watermark.

The first thing a new raft leader does repair the followers' logs. That is, it overwrites the uncommitted parts of the log so that it matches its own, and then it commits those.

Once a block's transition number is below the node's committed watermark it may be used for business; until then the node must assume that the block may be incorrect and could be deleted.

I strongly suggest playing with the visualization on https://raft.github.io/ :

  1. Turn off a majority of the nodes, but keep at the leader and one other node active;
  2. Request a value on the leader;
  3. Turn off the leader, turn on the other nodes;
  4. Timeout one of the nodes you just reactivated (not one with the value you requested.)
  5. See what happens.