Resume stalled balloting immediately on tx set arrival - #5346
Conversation
|
wrt ordering using c, should it be the other way around (b,p,p',c,h) ? -- maybe talk to @nano-o |
I asked @nano-o about this and the conclusion we came to was that either ordering would technically work, but that the @nano-o , please correct me if I'm wrong here. |
There was a problem hiding this comment.
Pull request overview
Enables stalled SCP balloting to resume immediately when its transaction set arrives.
Changes:
- Tracks stalled commits and transaction-set dependencies.
- Resumes safely when ballot state remains unchanged.
- Adds
nCto CAP-0083 PREPARE ordering and expands tests.
Reviewed changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
src/scp/test/SCPTests.cpp |
Tests immediate and guarded resume behavior. |
src/scp/Slot.h |
Declares transaction-set notification API. |
src/scp/Slot.cpp |
Forwards notifications to ballot protocol. |
src/scp/SCP.h |
Exposes SCP-level notification API. |
src/scp/SCP.cpp |
Routes notifications to existing slots. |
src/scp/BallotProtocol.h |
Defines stalled-commit state and API. |
src/scp/BallotProtocol.cpp |
Implements ordering and safe resumption. |
src/herder/HerderSCPDriver.h |
Declares stalled-slot registry. |
src/herder/HerderSCPDriver.cpp |
Registers, cleans, and resumes stalled slots. |
This change allows stellar-core to quickly resume balloting when a transaction set arrives, rather than waiting for a ballot timeout to resume. It creates a registry of stalled slots, and checks tx sets that arrive to see if they could potentially unstick those slots. A stall can only be resolved by a tx set if the ballot protocol has not undergone any changes since hitting the stall point. This prevents prevents us from resuming with a ballot when the node may have moved on to a different value. This change also adds `c` to the calculation of ballot ordering. This is necessary because without it, a node that exercises this quick-resume path has no way of informing the network as they will discard a ballot where the other variables are unchanged.
9131faf to
fca1d9b
Compare
|
what's our testing/validation strategy here? I'm having a bit of a hard time validating that this change is correct. For example, I also thought |
|
I think both orders are fine, but logically it is h that causes c to change (even if with a delay), so |
This change allows stellar-core to quickly resume balloting when a transaction set arrives, rather than waiting for a ballot timeout to resume.
It creates a registry of stalled slots, and checks tx sets that arrive to see if they could potentially unstick those slots. A stall can only be resolved by a tx set if the ballot protocol has not undergone any changes since hitting the stall point. This prevents prevents us from resuming with a ballot when the node may have moved on to a different value.
This change also adds
cto the calculation of ballot ordering. This is necessary because without it, a node that exercises this quick-resume path has no way of informing the network as they will discard a ballot where the other variables are unchanged.