fix: Execute old slashing round if skipped during first round#17245
Merged
spalladino merged 1 commit intonextfrom Sep 25, 2025
Merged
fix: Execute old slashing round if skipped during first round#17245spalladino merged 1 commit intonextfrom
spalladino merged 1 commit intonextfrom
Conversation
spalladino
force-pushed
the
palla/slash-execute-lookback
branch
2 times, most recently
from
ccc03e2 to
885ef0a
Compare
While we keep slashing rounds for a long time (lifetime in rounds is currently defined as 100), we only attempt to execute them during the first round they become executable. If for whatever reason they don't get executed, they are just forgotten and never actually triggered. This PR adds a new config `slashExecuteRoundsLookBack` (defaults to 4) with how many execution rounds to look back from the latest executable round to see if there was any round pending execution. Each round is checked in sequence, so setting this value too high can introduce performance issues. Setting this value to zero keeps the same behaviour as we have today. This PR also fixes another issue: we were re-checking if a round was executable based on the isReadyToExecute flag returned from the contract. However, that flag was computed based on the current at the time of the call, and not based on the time in which the tx would land. This meant that we always failed to execute the slash payload on the first slot of a round.
spalladino
force-pushed
the
palla/slash-execute-lookback
branch
from
885ef0a to
5b1298a
Compare
PhilWindle
approved these changes
Sep 25, 2025
github-merge-queue
bot
removed this pull request from the merge queue due to no response for status checks
spalladino
added a commit
that referenced
this pull request
Sep 25, 2025
While we keep slashing rounds for a long time (lifetime in rounds is currently defined as 100), we only attempt to execute them during the first round they become executable. If for whatever reason they don't get executed, they are just forgotten and never actually triggered. This PR adds a new config `slashExecuteRoundsLookBack` (defaults to 4) with how many execution rounds to look back from the latest executable round to see if there was any round pending execution. Each round is checked in sequence, so setting this value too high can introduce performance issues. Setting this value to zero keeps the same behaviour as we have today. This PR also fixes another issue: we were re-checking if a round was executable based on the isReadyToExecute flag returned from the contract. However, that flag was computed based on the current at the time of the call, and not based on the time in which the tx would land. This meant that we always failed to execute the slash payload on the first slot of a round. These two issues combined were triggering the flakes in the `inactivity-slash` tests. Since we had small rounds (each round was 4 slots), and the first slot was consistently missed, it was a matter of being unlucky enough such that the inactive validator was picked 3 slots in a row as a sequencer. Given we have 6 validators, this happened roughly once every 216 runs. See [this run](http://ci.aztec-labs.com/3bff0b862dd4156f) for an example.
PhilWindle
added a commit
that referenced
this pull request
Sep 29, 2025
This PR is a backport of the following into V2. #17169 #17176 #17186 #17178 #17177 #17130 #17039 #17230 #17245 #17273 #17186 #17192 #17194 #17225 #17285 #17312 #17326 --------- Co-authored-by: Alex Gherghisan <alexghr@users.noreply.github.com> Co-authored-by: Santiago Palladino <santiago@aztec-labs.com> Co-authored-by: Santiago Palladino <spalladino@gmail.com> Co-authored-by: alexghr <3816165+alexghr@users.noreply.github.com>
spalladino
added a commit
that referenced
this pull request
Oct 13, 2025
In #17245 we changed the slasher client to check for older rounds pending execution, with a config variable that indicates how far to look back. However, the lifetime in rounds in staging ended up being smaller than the lookback, so we were picking rounds no longer valid. This PR checks that we do not look that far back.
github-merge-queue bot
pushed a commit
that referenced
this pull request
Oct 13, 2025
…17652) In #17245 we changed the slasher client to check for older rounds pending execution, with a config variable that indicates how far to look back. However, the lifetime in rounds in staging ended up being smaller than the lookback, so we were picking rounds no longer valid. This PR checks that we do not look that far back.
spalladino
pushed a commit
that referenced
this pull request
Oct 16, 2025
…17652) In #17245 we changed the slasher client to check for older rounds pending execution, with a config variable that indicates how far to look back. However, the lifetime in rounds in staging ended up being smaller than the lookback, so we were picking rounds no longer valid. This PR checks that we do not look that far back.
spalladino
pushed a commit
that referenced
this pull request
Oct 16, 2025
…17652) In #17245 we changed the slasher client to check for older rounds pending execution, with a config variable that indicates how far to look back. However, the lifetime in rounds in staging ended up being smaller than the lookback, so we were picking rounds no longer valid. This PR checks that we do not look that far back.
spalladino
pushed a commit
that referenced
this pull request
Oct 16, 2025
…17652) In #17245 we changed the slasher client to check for older rounds pending execution, with a config variable that indicates how far to look back. However, the lifetime in rounds in staging ended up being smaller than the lookback, so we were picking rounds no longer valid. This PR checks that we do not look that far back.
spalladino
pushed a commit
that referenced
this pull request
Oct 17, 2025
…17652) In #17245 we changed the slasher client to check for older rounds pending execution, with a config variable that indicates how far to look back. However, the lifetime in rounds in staging ended up being smaller than the lookback, so we were picking rounds no longer valid. This PR checks that we do not look that far back.
spalladino
pushed a commit
that referenced
this pull request
Oct 17, 2025
…17652) In #17245 we changed the slasher client to check for older rounds pending execution, with a config variable that indicates how far to look back. However, the lifetime in rounds in staging ended up being smaller than the lookback, so we were picking rounds no longer valid. This PR checks that we do not look that far back.
spalladino
added a commit
that referenced
this pull request
Oct 17, 2025
…17652) (#17749) Backport of #17652 In #17245 we changed the slasher client to check for older rounds pending execution, with a config variable that indicates how far to look back. However, the lifetime in rounds in staging ended up being smaller than the lookback, so we were picking rounds no longer valid. This PR checks that we do not look that far back. Co-authored-by: PhilWindle <60546371+PhilWindle@users.noreply.github.com>
ludamad
pushed a commit
that referenced
this pull request
Dec 16, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
While we keep slashing rounds for a long time (lifetime in rounds is currently defined as 100), we only attempt to execute them during the first round they become executable.
If for whatever reason they don't get executed, they are just forgotten and never actually triggered.
This PR adds a new config
slashExecuteRoundsLookBack(defaults to 4) with how many execution rounds to look back from the latest executable round to see if there was any round pending execution. Each round is checked in sequence, so setting this value too high can introduce performance issues. Setting this value to zero keeps the same behaviour as we have today.This PR also fixes another issue: we were re-checking if a round was executable based on the isReadyToExecute flag returned from the contract. However, that flag was computed based on the current at the time of the call, and not based on the time in which the tx would land. This meant that we always failed to execute the slash payload on the first slot of a round.
These two issues combined were triggering the flakes in the
inactivity-slashtests. Since we had small rounds (each round was 4 slots), and the first slot was consistently missed, it was a matter of being unlucky enough such that the inactive validator was picked 3 slots in a row as a sequencer. Given we have 6 validators, this happened roughly once every 216 runs. See this run for an example.