AZIP-7: Update slashing rules#16
Open
spalladino wants to merge 5 commits intoAztecProtocol:mainfrom
Open
Conversation
critesjosh
reviewed
Apr 29, 2026
|
|
||
| #### Attested Checkpoint Not Posted to L1 | ||
|
|
||
| A proposer received sufficient attestations for a checkpoint but failed to submit it to L1, causing a 1-slot reorg (or 2-slots under pipelining as defined in AZIP-6). This offense MAY be conditional on it happening at least `CHECKPOINT_NOT_POSTED_REPETITION_THRESHOLD` times, which resets as soon a checkpoint is successfully posted by the proposer or after `CHECKPOINT_NOT_POSTED_RESET_WINDOW`. A missed checkpoint MAY not be considered when the L1 base fee at the missed slot exceeded `CHECKPOINT_NOT_POSTED_L1_CONGESTION_BASE_FEE_THRESHOLD`. This is a slot-based offense, and it only applies if the proposer received sufficient attestations within `CHECKPOINT_NOT_POSTED_ATTESTATION_WINDOW` before the end of its slot. |
Co-authored-by: josh crites <jc@joshcrites.com>
aminsammara
reviewed
Apr 30, 2026
|
|
||
| #### Epoch Pruned replaced by Data Withholding | ||
|
|
||
| The _Epoch Pruned_ offense is removed in favor of checking _Data Withholding_ after a slot. After a checkpoint is published, nodes check if the data for all transactions in it is available. If not, the set of validators who attested to that slot is considered at fault for not making the data available to the network. Slashing MUST apply even if the epoch gets pruned, to prevent committees from striking side deals with specific provers by only releasing transaction data to them. |
There was a problem hiding this comment.
Does this mean to say "slashing MUST apply even if the epoch is proved" instead of "epoch is pruned"? Or maybe it's not clear to me why the emphasis on "even if pruned"
aminsammara
reviewed
Apr 30, 2026
| | Parameter | Value | Description | | ||
| | -------------------------------------------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | `CHECKPOINT_NOT_POSTED_REPETITION_THRESHOLD` | 2 | Number of repeated _Attested Checkpoint Not Posted to L1_ occurrences by the same proposer required to trigger slashing. Must be large enough to absorb isolated failures but small enough to deter griefing. | | ||
| | `CHECKPOINT_NOT_POSTED_L1_CONGESTION_BASE_FEE_THRESHOLD` | 300 gwei | L1 base fee above which an _Attested Checkpoint Not Posted to L1_ offense is suppressed, to avoid penalizing proposers who could not land their L1 tx under genuine L1 congestion. | |
There was a problem hiding this comment.
I would suggest changing this to some multiple of the ethPerFeeAsset in the FeeHeader of a previous checkpoint. My mind is not made up but the question I'm asking is: should validators be expected to post checkpoints at a loss?
There was a problem hiding this comment.
Late to the party just saw that this is being raised on the discussion page.
alexghr
reviewed
Apr 30, 2026
|
|
||
| #### Submitting Block Proposal After Checkpoint | ||
|
|
||
| A proposer sent a block proposal after the checkpoint proposal had already been issued for the same slot. Once a checkpoint is proposed, no further block proposals SHOULD be sent. The proposer MUST be penalized. This is a slot-based offense. |
There was a problem hiding this comment.
I think the SHOULD in no further block proposals SHOULD be sent. should be changed to MUST (ie. no further block proposals MUST be sent.) because IIUC there are no valid scenarios in which it is acceptable for a proposer to send a block proposal after the checkpoint proposal?
|
|
||
| #### Epoch Pruned replaced by Data Withholding | ||
|
|
||
| The _Epoch Pruned_ offense is removed in favor of checking _Data Withholding_ after a slot. After a checkpoint is published, nodes check if the data for all transactions in it is available. If not, the set of validators who attested to that slot is considered at fault for not making the data available to the network. Slashing MUST apply even if the epoch gets pruned, to prevent committees from striking side deals with specific provers by only releasing transaction data to them. |
There was a problem hiding this comment.
I think this is missing a negation (i.e. "Slashing MUST apply even if the epoch DOES NOT get pruned")
| | Parameter | Value | Description | | ||
| | -------------------------------------------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | `CHECKPOINT_NOT_POSTED_REPETITION_THRESHOLD` | 2 | Number of repeated _Attested Checkpoint Not Posted to L1_ occurrences by the same proposer required to trigger slashing. Must be large enough to absorb isolated failures but small enough to deter griefing. | | ||
| | `CHECKPOINT_NOT_POSTED_L1_CONGESTION_BASE_FEE_THRESHOLD` | 300 gwei | L1 base fee above which an _Attested Checkpoint Not Posted to L1_ offense is suppressed, to avoid penalizing proposers who could not land their L1 tx under genuine L1 congestion. | |
There was a problem hiding this comment.
I'm wondering if this should/could be running average over the last N blocks (times some multiplier) to account for changing gas landscape on L1?
Drops the offense and its associated parameters, rationale paragraph, security consideration, and abstract/stakeholder mentions. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Tighten "no further block proposals SHOULD be sent" to "MUST NOT" (alexghr). - Clarify the data-withholding rule: slashing applies even when the epoch is successfully proved, since the side-deal scenario is precisely the one where a chosen prover received the data and the epoch was not pruned (aminsammara, alexghr). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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
4 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.
Discussion at #9