Practical Byzantine Fault Tolerance (PBFT) is a consensus algorithm designed to withstand Byzantine faults in distributed systems, such as blockchains and various decentralized platforms. PBFT ensures all non-faulty nodes (replicas) reach consensus despite the presence of faulty nodes. A critical aspect of PBFT is handling view changes, which are necessary when the primary (leader) node becomes unreliable or is suspected of faulty behavior.

Understanding PBFT & Committed Operations

Before diving into the view-change mechanism, it's useful to understand how PBFT processes requests under normal operation:

1. Pre-prepare: The primary node receives client requests and broadcasts a pre-prepare message to other replicas.
2. Prepare: Upon receiving the pre-prepare message, replicas broadcast prepare messages.
3. Commit: After a replica gathers 2f + 1 prepare messages (from other replicas, including itself), it broadcasts a commit message. Once 2f + 1 commit messages are received, the operation is considered committed.

Operations that reach the commit stage are assumed to be executed and permanently recorded in the system's log. This implies a guarantee that committed operations will be consistent across all non-faulty replicas, even in subsequent views.

PBFT View Change: Handling Snapshots After Committed Operations

A view in PBFT represents the perspective of a primary. When the current primary is suspected of being faulty, possibly due to timeout or erratic behavior, a view change is initiated to elect a new primary. The view-change process ensures that the stability and reliability of the system remain intact, maintaining all committed records up to the last stable checkpoint.

Phases of a View Change:

1. Trigger: A view change can be triggered by any replica that suspects the current primary is faulty. This is typically due to timeouts or received messages that contradict the protocol rules.
2. New View Message: Each replica sends a view-change message to all other replicas, which includes:
   • The current view number.
   • The prepared and pre-prepared messages it has logged.
   • A proof of the commit.
3. Preparation and Commitment in New View: The new primary, calculated as $(view number) \mod (number of replicas)$, collects these view-change messages. Once it has received 2f + 1 messages, it constructs a new-view message, proposing the updated sequence numbers and pre-prepared messages.
4. Committed Operations After the Snapshot: In any view-change, it’s essential to maintain a valid state that includes the results of operations that were committed before the view change occurred. This is where the concept of a snapshot becomes crucial. A snapshot represents a full-state image at a certain point, usually at the last committed point. Post-view, all non-faulty nodes begin from this snapshot, ensuring that any subsequent operations in the new view maintain the system's integrity and history consistency.

Example:

Imagine a scenario in a financial blockchain where during the processing of transactions, the primary node fails. To ensure continuity:

• Transactions that were fully committed are recorded in a snapshot up to the last completed sequence.
• As part of the view change, this snapshot is used to bring all nodes up to this last known good point before processing new transactions under the new primary.

Key Points in Table

To conclude, PBFT's handling of committed operations post-view change through the use of snapshots and rigorous message exchange ensures robustness and consistency of the distributed ledger, even in the face of Byzantine faults among the replicas. This mechanism is fundamental to maintaining the reliability and trustworthiness of the system over time.