Skip to content

View Change

In the event of a network stall, the core protocol falls back to a view change. This process occurs within the DS committee, and involves the selection of a new DS committee leader to pick the blockchain's progress back up at the point just before the stall.

The general steps are as follows:

  1. The DS committee consensus stalls for some reason
  2. The network enters into a view change state
  3. A candidate leader from the DS committee leads the view change consensus using PBFT
  4. The DS backups validate the candidate leader's announcement
  5. View change consensus is reached
  6. The DS committee resumes the stalled consensus

Terminology

  1. Candidate leader: The proposed leader who will lead the view change consensus round
  2. Faulty leader(s): The current leader prior to the stall, and any candidate leaders who could not successfully complete the view change consensus
  3. Ejection: Placement of all faulty leader(s) to the back of the DS committee. This means those nodes will be prioritized for removal from the DS committee after the next DS consensus

Trigger Conditions

These are the conditions that can cause a view change to occur:

  1. Node entered RunConsensusOnDSBlock() but DS block consensus did not complete within the time stipulated
  2. Node entered RunConsensusOnFinalBlock() but Tx block consensus did not complete within the time stipulated
  3. Node entered RunConsensusOnViewChange() but VC block consensus did not complete within the time stipulated

Procedure

  1. Any trigger condition is satisfied and view change begins
  2. DS nodes perform view change pre-check:
  3. Contact lookup to ask for new blocks (DS or Tx)
  4. If no new block is obtained, proceed with view change
  5. If a new block is obtained, rejoin as a DS node
  6. All nodes calculate the new candidate leader index using CalculateNewLeaderIndex(), which uses this algorithm
H(finalblock or vc block hash, vc counter) % size (or num of DS guard)

If a previous vc block (for current consensus) exists, use vc block hash. Else use Tx block hash. If new candidate leader index is current faulty leader, re-calculate using
H(H(finalblock or vc block hash, vc counter)) repeatedly till an index is not the current faulty leader.
  1. Candidate leader and backups proceed with view change consensus until completion or stall
  2. If stalled, wait for timeout and re-run view change consensus with a new candidate leader
  3. All nodes remove faulty leaders (found in the VC block header's list) from DS Committee
  4. All nodes add faulty leaders to the back of DS Committee (unless those are DS guards)
  5. All nodes recalculate m_consensusMyID and m_consensusLeaderID according to the updated DS committee
  6. All nodes store the VC block to persistent storage
  7. If stalled consensus is at Tx block consensus:
  8. VC block(s) is sent to the lookup and shard nodes
  9. Lookups and shard nodes use the VC block(s) to update the DS committee composition similarly
  10. If stalled consensus is at DS block consensus:
  11. DS nodes cache all VC block(s) generated during the view change(s)
  12. All nodes re-run the stalled consensus (DS block or Tx block consensus) prior to view change
  13. If the re-run consensus is for Tx block, the gas limit will be adjusted using exponential backoff algorithm
  14. Consensus runs to completion (or, fails and triggers another stall)
  15. If completed consensus is for DS block:
  16. DS nodes append the cached VC block(s) to the newly generated DS block
  17. DS block (together with the VC block(s)) is sent to the lookup and shard nodes
  18. Lookups and shard nodes use the VC block(s) to update the DS committee composition similarly