Quorum中RAFT共识算法如何确保确定性链扩展及账本一致性？

Great question—let’s break down how Raft (and Quorum’s implementation of it) ensures ledger consistency during leader transitions, and address your specific concerns clearly.

How Raft Guarantees Unified Ledgers After Leader Switch #

Raft’s core design is built around log consistency guarantees, which directly translate to a synchronized blockchain across all nodes:

• Election Rule for Log Completeness: When a leader fails, followers trigger an election. For a candidate to win leadership, it must prove it holds the longest, most up-to-date log (including all fully committed blocks) in the cluster. Nodes will only vote for a candidate whose log is at least as complete as their own—this ensures the new leader starts with a fully authoritative, up-to-date ledger.
• Post-Election Log Sync: Once elected, the new leader immediately begins aligning all followers’ logs with its own. It checks each follower’s log progress, identifies gaps, and sends missing log entries (blocks included) to bring the follower’s ledger in perfect sync. Only after this synchronization finishes does the new leader resume processing new transaction submissions.

Can Followers Receive Blocks From Both Old and New Leaders? #

Short answer: No, this scenario is impossible—here’s why:

• Old Leader Automatically Degrades: When the old leader loses quorum (more than half the cluster stops acknowledging its heartbeats), it instantly switches to follower status. It stops processing new write requests and can’t commit any new blocks (since Raft requires majority approval for commits). Any uncommitted blocks the old leader was trying to send are invalid, as they never got cluster-wide confirmation.
• Uncommitted Entries Get Overwritten: If, in the split-second of a switch, some followers received uncommitted blocks from the old leader, the new leader’s sync process will overwrite these entries. Raft’s log matching rule ensures followers discard any uncommitted logs that don’t match the new leader’s authoritative log, replacing them with the correct, fully committed data.

Critical Synchronization Mechanisms Preventing Conflicts #

To avoid chain extension races and keep the cluster consistent, Raft (and Quorum) relies on these key safeguards:

• Heartbeat-Based Leader Liveness Checks: Followers constantly monitor leader heartbeats. A timeout without a heartbeat triggers an election, ensuring the cluster never stays in an inconsistent state for long.
• Quorum-Only Commit Rules: Every log entry (block) must be replicated to a majority of nodes before it’s marked as committed. This ensures no partial commits can persist across the cluster.
• Snapshot Catch-Up for Lagging Followers: For followers far behind the leader, Quorum’s Raft implementation uses state snapshots to quickly sync the ledger (instead of replaying every log entry)—this speeds up consistency while maintaining full correctness.

该链扩展逻辑具有确定性：集群中的每个节点都会执行完全相同的行为，从而保持区块链同步。

内容的提问来源于stack exchange，提问作者Vaibhav Saini