Hyperledger Fabric如何处理部分Submitter Peer的Readset验证失败问题

First, a quick terminology note: I think you might have mixed up peer roles here—Submitter Peers are the ones that receive transaction proposals from clients, while the peers responsible for Readset validation and final transaction commitment are called Committer Peers. That said, let’s dive into exactly how Fabric handles this scenario:

When the Orderer has already validated a transaction (checking signatures, channel permissions, configuration compliance, etc.) and broadcast it to all peers, but some Committer Peers fail the Readset validation (verifying that data versions in their State DB match what was read during the proposal phase to prevent concurrent modification conflicts), Fabric follows these key steps:

• Failed peers reject transaction application: The Committer Peer that fails validation will mark the transaction as invalid and refuse to apply its Writeset (the set of data changes) to its local World State. However, the block containing this transaction will still be written to the peer’s blockchain ledger—Fabric just flags the transaction as invalid in the block’s metadata.

• Validating peers proceed normally: Peers that pass the Readset validation will commit the transaction as usual, updating their local ledger and World State. While this creates a temporary state discrepancy across the network, Fabric’s eventual consistency model ensures alignment over time.

Let’s break this down further:

1. Invalid transaction marking, no state update
   During the Validate phase, if a Committer detects that the version of a key in its State DB doesn’t match the version recorded in the transaction’s Readset, it skips applying that transaction’s changes. The block itself is still persisted to the ledger, so the peer maintains a complete record of all network activity—just with a clear marker that this particular transaction didn’t modify the state.

2. Eventual consistency via block processing
   Fabric relies on eventual consistency, not immediate consensus on state. For example, if two transactions target the same key, both might pass Orderer validation but conflict during Committer validation. Suppose Transaction A is packed into a block first: all peers will apply A, updating the key’s version. When Transaction B comes next, peers will check their State DB, see the key’s version has changed, mark B as invalid, and skip applying it. Over time, all peers will process blocks in the same order, so they’ll all end up with the same ledger and state (with B marked invalid).

3. Client-side retry options
   The client that submitted the transaction will receive feedback about the failed validation. In this case, the client can retry the transaction by submitting a new proposal: this will fetch the latest state versions, generate an updated Readset, and resubmit the transaction to the Orderer. This new proposal will avoid the version conflict that caused the initial failure.

4. Peer state synchronization
   If a peer falls behind on block synchronization (e.g., due to network downtime), once it catches up, it will reprocess all missed blocks in order. It will first apply valid transactions to bring its State DB up to date, then validate subsequent transactions against the correct state. This ensures the peer eventually aligns with the rest of the network.

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