Skip to content

feat: custom slashing design doc #61

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 12 commits into from
May 20, 2025
Merged

feat: custom slashing design doc #61

Changes from 1 commit
Commits
Show all changes
12 commits
Select commit Hold shift + click to select a range
90101c5
feat: custom slashing design doc
just-mitch May 7, 2025
41f1e4d
feat: expand slashing to allow variable amounts
just-mitch May 8, 2025
a734dbb
feat: use uint256 rather than enum for offences
just-mitch May 9, 2025
0e10601
chore: just use uint256 for slash amount
just-mitch May 9, 2025
76c1a3b
chore: add description of create payload
just-mitch May 9, 2025
e310075
chore: remove time from payload salt
just-mitch May 9, 2025
fff5358
feat: add the slashing conditions we actually want.
just-mitch May 13, 2025
bdf2bbb
chore: update slashing conditions
just-mitch May 14, 2025
74ad504
feat: more notes on full node re-execution
just-mitch May 14, 2025
271a278
chore: a note on implementation order
just-mitch May 14, 2025
a95b059
updates based on comments
just-mitch May 19, 2025
1cab686
updates based on comments
just-mitch May 19, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
83 changes: 83 additions & 0 deletions docs/custom-slashing/dd.template.md
View file
Open in desktop
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The file name is still called .template, probably should be renamed.

Original file line number Diff line number Diff line change
@@ -0,0 +1,83 @@
# Custom Slashing Design Document

- Owner: @just-mitch
- Approvers:
- @LHerskind
- @Maddiaa0
- Target DD Approval Date: 2025-05-09
- Target Project Delivery Date: 2025-05-16

## Executive Summary

The L1 contracts currently only "allow" slashing all validators in an epoch if the epoch is never proven.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not true.

The L1 contract allow any kind of slash that is address,amount pair based, BUT we only have a "detector" working for the epoch failed to be proven one.

There is an important distinction.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Was being blunt here for "executive summary". I will clarify.


We want to provide a mechanism for slashing specific validators for not participating in consensus.

## Requirements

The requirements with filled checkboxes are met by the design below.

- [x] There MUST be ready-made L1 contract(s) that can be used to slash specific validators for not participating in consensus.
- [x] The Aztec Labs node client software ("the node") MUST automatically slash validators for not participating in consensus.
- [x] It SHOULD be possible to slash more than one validator at a time.
- [x] Coordinating the slash SHOULD NOT require any coordination between the validators beyond the existing voting/signalling mechanism; each validator SHOULD be able to inspect L1 and its state to determine:
- If it agrees with the slash
- How/where to vote/signal on L1
- [x] Node operators SHOULD be able to configure their node to specify thresholds for what they consider "not participating".
- [x] The "offence" that triggers the slash MAY be specified on L1.
- [ ] The amount to be slashed MAY be configurable without deploying a new contract.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just pointing out here that NO slashing in our setup can happen without deploying as it is needing the payload to be deployed. I believe you might be talking about without deploying a new factory?

Unless you have a proxy or updatable payload this will be the case. And lord please smite anyone doing that.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, I will clarify that I mean without deploying a new factory.

- [ ] The threshold of number of validators (M/N) that need to signal/vote for the CustomSlashFactory payload MAY be configurable without deploying a new contract or a governance action.

## Overview

Rename the existing `SlashFactory` contract to `EpochSlashFactory` to denote that it slashes all validators in an epoch. Make a new `CustomSlashFactory` contract which creates a payload to slash a provided list of validators for an explicit offence. The amounts to be slashed for each offence will be provided in the constructor of the `CustomSlashFactory` contract. There will only be one explicit offence right now: "missing attestations". Creating the payload via the `CustomSlashFactory` will emit an event with the payload address, and the validator addresses.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not nuke the current factory? Slashing the members of a committe is just slashing a list of addresses, which is the same as for missing attestations just with a different "type" 🤷. No need to have an extra one just to have it.

Copy link
Collaborator Author

@just-mitch just-mitch May 8, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, I thought about it, but I figured this is a smaller change, and since we will probably want an "address book", having yet another address that nodes want to keep track of is less onerous. Happy to go either way.

Edit: your comment below on simplifying the ordering heuristic tipped me in favor of having a single factory 👍

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not nuke the current factory? Slashing the members of a committe is just slashing a list of addresses, which is the same as for missing attestations just with a different "type" 🤷. No need to have an extra one just to have it.


Aztec nodes will listen for these events, and then check if the validator is bad committed the alleged offence. If so, they will vote/signal for the payload on L1.

## Details

The SlasherClient will remain the interface that the SequencerPublisher uses to adjust the transaction it sends to the forwarder contract.

Internally, though, the SlasherClient will monitor two conditions:

- an epoch was not proven, so slash all validators via the `EpochSlashFactory` contract (i.e. the current state, rename the L1 contract from `SlashFactory`)
- a validator has missed X% (e.g. 90%) of attestations according to the Sentinel, so slash that validator via the `CustomSlashFactory` contract (this is new)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As above, would just have one path. Simpler to deal with.


Validators will need to have a way to order the various slashing events they observe.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest a different sorting.

Namely, alter the custom such that the event you emit is something like

event PayloadCreated(
    address payload,
    address[] memory attesters, 
    uint256[] memory amounts, 
    uint256[] memory offense,
    uint256 totalSlash
);

Then rely on the same factory for any kind of slash, e.g., missing attestations or whatever.

Have some idea of a deadline, e.g., how long since the payload was created will you still want to vote for it.

First your filter, a "candidate" payload is:

  • alive, current time is before its deadline
  • consistent with your view (your nodes state)

Then you sort by totalSlash and take the highest value. At this point, you cast votes for the biggest slash that you agree with, that you believe is not yet stale.

To reduce overhead, it is possible to just emit an event with the payload address and and then retrieve the inputs from the tx calldata.


Their first priority is to slash payloads from the `EpochSlashFactory`, sorted oldest to newest.

Their second priority is to slash payloads from the `CustomSlashFactory` for the "missing attestations" offence, sorted oldest to newest, but folding together payloads until one is found that they disagree with.

They will vote to slash any validator that has missed Y% (e.g. 50%) of attestations according to the Sentinel; there are two percentages to be configured:

- the percentage of attestations missed required to create a payload
- the percentage of attestations missed required to signal/vote for the payload

Node operators will configure their node to listen to the specific CustomSlashFactory contract and specify the percentage of attestations missed required to create a payload.

This will be done via CLI arguments or environment variables.

## Notes

The amount to slash should be high for testnet (e.g. the minimum stake amount). We can use a different amount for mainnet.

The threshold of number of validators (M/N) that need to signal/vote for the CustomSlashFactory payload will be the same as the number of validators that need to signal/vote for the EpochSlashFactory payload.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just making clear, that it is not the factories that are specifying N and M, it is the slashing proposer.


This requires that M/N validators are listening to the same CustomSlashFactory contract, and participating in the protocol.

If we do not have M/N validators participating, we will need to make a "propose with lock" on the governance to deploy a new rollup instance. If that is not palatable, we could update the staking lib to allow the governance (not just the slasher) to slash validators; then we could "propose with lock" to slash whatever validators governance decides.

## Timeline

Outline the timeline for the project. E.g.

- L1 contracts : 1 day
- Refactor SlasherClient : 1 day
- Review/Polish : 1-2 days

Total: 3-4 days

## Disclaimer

The information set out herein is for discussion purposes only and does not represent any binding indication or commitment by Aztec Labs and its employees to take any action whatsoever, including relating to the structure and/or any potential operation of the Aztec protocol or the protocol roadmap. In particular: (i) nothing in these projects, requests, or comments is intended to create any contractual or other form of legal relationship with Aztec Labs or third parties who engage with this AztecProtocol GitHub account (including, without limitation, by responding to a conversation or submitting comments) (ii) by engaging with any conversation or request, the relevant persons are consenting to Aztec Labs’ use and publication of such engagement and related information on an open-source basis (and agree that Aztec Labs will not treat such engagement and related information as confidential), and (iii) Aztec Labs is not under any duty to consider any or all engagements, and that consideration of such engagements and any decision to award grants or other rewards for any such engagement is entirely at Aztec Labs’ sole discretion. Please do not rely on any information on this account for any purpose - the development, release, and timing of any products, features, or functionality remains subject to change and is currently entirely hypothetical. Nothing on this account should be treated as an offer to sell any security or any other asset by Aztec Labs or its affiliates, and you should not rely on any content or comments for advice of any kind, including legal, investment, financial, tax, or other professional advice.