Skip to content

bft: count only prepared nodes for the in-flight proposal - #743

Closed
pfi79 wants to merge 1 commit into
hyperledger:mainfrom
pfi79:inflight-prepared-votes
Closed

pfi79 wants to merge 1 commit into
hyperledger:mainfrom
pfi79:inflight-prepared-votes

Conversation

@pfi79

@pfi79 pfi79 commented Oct 31, 2026

Copy link
Copy Markdown
Contributor

CheckInFlight counted every view data that carried the in-flight proposal toward condition A2, even when its sender had not prepared it. A node that merely holds a proposal in flight has not committed to it, so a view change could decide to re-commit a proposal that no quorum ever prepared.

Count a view data toward A2 only when its sender reports the proposal as prepared. Condition A1 still counts unprepared holders as nodes that do not object, and condition B still counts them as supporting that nothing is prepared.

CheckInFlight counted every view data that carried the in-flight proposal
toward condition A2, even when its sender had not prepared it. A node that
merely holds a proposal in flight has not committed to it, so a view change
could decide to re-commit a proposal that no quorum ever prepared.

Count a view data toward A2 only when its sender reports the proposal as
prepared. Condition A1 still counts unprepared holders as nodes that do not
object, and condition B still counts them as supporting that nothing is
prepared.

Signed-off-by: Fedor Partanskiy <[email protected]>
@HagarMeir

Copy link
Copy Markdown
Contributor

I think this can stop a view change from ever completing. With n=4, if node 2 crashes while node 1 is prepared on p, node 3 has only pre-prepared it and node 4 has nothing, then the only view data any new leader can collect are those three. A2 now needs 2 prepared entries but only node 1 has one, and B fails because node 1 is prepared, so CheckInFlight returns no decision in every view until node 2 comes back. On main, A holds and the view change completes.

That's why PBFT's A2 counts pre-prepared rather than prepared: its liveness argument relies on "a request that prepares at a nonfaulty replica pre-prepares at at least f+1 nonfaulty replicas" (Castro & Liskov, TOCS 2002, §4.5.1).

(Drafted with Claude's help.)

@pfi79 pfi79 closed this Nov 1, 2026
@pfi79
pfi79 deleted the inflight-prepared-votes branch November 1, 2026 10:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants