Slashing: keccak vs poseidon proof constraint, need a fault attribution approach that doesn't halt E3s

[hmzakhalid]

Context

Our current slashing design uses signed proofs with on-chain re-verification, if a node's signed proof fails verification on-chain, we slash them. On-chain verification requires proofs generated with oracle_hash: keccak.

However, keccak proofs cannot be verified inside recursive circuits. The recursive aggregation wrappers require proofs generated with oracle_hash: poseidon. @ctrlc03 reached out to Aztec and they confirmed, if we need both on-chain verification and recursive aggregation, we must generate two separate proofs per circuit (one keccak, one poseidon).

This would roughly increase total proof count per party by 33%. That's a significant performance hit on every E3, just to support a slashing path that fires <0.1% of the time.

Issue

If we only generate poseidon proofs (to keep recursive aggregation working), we lose the ability to directly re-verify proofs on-chain for slashing. So when a node sends a bad signed proof, we need an alternative way to handle it.

Approach A: Proposer Bond

When Node B detects a bad proof from Node A:

1. B submits a slash proposal on-chain with A's signed payload and posts a proposer bond
2. A is immediately expelled from the committee, E3 continues with N-1 nodes if still above threshold
3. The contract stores the hash of the public signals from A's signed payload
4. A has a defense window (e.g. 1 hour) to regenerate the same proof with keccak and submit it on-chain
5. If the keccak proof passes with the same public signals → A is innocent, B loses the bond
6. If it fails or A doesn't respond → A is slashed, B gets the bond back + a reporter reward

Pros:

• E3 doesn't halt, accused node is expelled immediately

Concern: rational apathy, why would B risk a bond to report A, when B could just let the E3 timeout and still get refunded for work done? To address this, B needs to be meaningfully rewarded for successful reports (e.g. a % of A's slashed stake), and slashed nodes should be excluded from the refund pool so honest nodes get a larger share.

Approach B: Committee Attestation

When Node B detects a bad proof from Node A:

1. B broadcasts a ProofFailureAccusation to all committee nodes
2. All other nodes independently verify A's proof and attest whether it fails
3. If a quorum of nodes confirms the proof is bad → B submits the attestations on-chain with proposeSlash
4. A is immediately expelled from the committee — E3 continues
5. A can then generate a keccak proof and submit it on-chain to prove innocence
6. If it passes → no slash. If it fails → A is slashed.

Pros:

• No bond required from the reporter (quorum replaces bond as anti-griefing)
• E3 doesn't halt

Cons:

• Requires gossip protocol for accusation voting
• Need to handle: what if A sent different proofs to different nodes (equivocation)?
• More complex implementation (vote collection, timeout logic, threshold counting)

cc @auryn-macmillan @ctrlc03 @ryardley @cedoor @0xjei

[auryn-macmillan]

I wonder if we could convince the Aztec team to make a version of the onchain verifier that uses this Poseidon2 library?

[auryn-macmillan]

Of the options above, I prefer A over B.

[hmzakhalid]

I wonder if we could convince the Aztec team to make a version of the onchain verifier that uses this Poseidon2 library?

That would be great

Of the options above, I prefer A over B.

Yeah, A is also the closest to our current implementation, We'd need to add a node defense path and also update the codebase to generate circuits with keccak + poseidon

[cedoor]

@hmzakhalid I'm not sure how onchain proof verification for slashing works exactly but I have a solution in mind that might work.. I tried to challange it with LLM and looks sound.

We could avoid generating a second Keccak proof for every circuit by using a dispute-only wrapper proof, where the wrapper per-circuit is what we already have (no need to build new circuits).

Normal flow:

• Nodes generate Poseidon-oracle proofs (recursion-friendly).
• Each proof is signed together with its public inputs (@hmzakhalid we are signing the public inputs right?).

Dispute flow:

• If a node B claims that A used the wrong public inputs, it builds a Keccak-compatible wrapper W_k that proves:

VerifyPoseidonProof(π_A, x_claimed) == true

On-chain we:

1. verify W_k
2. verify A’s signature on x_claimed
3. compute or pass somehow x_expected (not sure how this works)
4. slash if x_claimed != x_expected

So, since it is not possbile to verify a failing proof inside a circuit, we never really rely on a failing proof. We submit a valid wrapper proof (with target = evm) of what A actually proved (A proof is valid with their (wrong) inputs, othewrise they wouldn't have been able to generate it in the first place), and compare it with what the protocol or the node expected.

Also, the new bb has a new (imo clearer) option to handle types of proofs, which is --verifier-target ("evm" or "noir-recursive", etc). I think --oracle_hash is deprecated.

[hmzakhalid]

@cedoor This approach sounds really promising

Each proof is signed together with its public inputs (@hmzakhalid we are signing the public inputs right?).

Yes we are signing the public inputs, here's the decoded data we send

How much work do you estimate this would take? Specifically, building the keccak-compatible wrapper circuit W_k that wraps and re-verifies a Poseidon proof?

[cedoor]

@hmzakhalid does the onchain verification for slashing work like that? Like comparing the expected public inputs with the wrong one signed by the proof sender?

How much work do you estimate this would take? Specifically, building the keccak-compatible wrapper circuit W_k that wraps and re-verifies a Poseidon proof?

We already have most of the code implemented here: #1365, we just need to change some options and switch to noir-recursive poseidon is almost immediate. What we need to change for slashing is to generate a proof (by using the related wrapper) instead of using the proof directly, and replace the verifiers with new ones generated from wrapper verification keys instead.

[hmzakhalid]

@hmzakhalid does the onchain verification for slashing work like that? Like comparing the expected public inputs with the wrong one signed by the proof sender

no, the current on-chain slashing doesn't compare expected vs actual public inputs. It works by re-verifying the proof on-chain and requiring it to fail.

The flow is:

• Accuser submits the operator's signed proof + public inputs on-chain
• Contract recovers the signer via ECDSA, confirms it matches the accused operator
• Contract re-runs the ZK verification via staticcall to the verifier
• If the proof passes -> revert (ProofIsValid), no slash. If it fails -> slash.

So it only catches outright invalid proofs (garbage/malformed), not a valid proof with wrong inputs.

[auryn-macmillan]

Oh interesting. So perhaps we could have a simple wrapper proof that simple verifies onchain that a given off-chain proof is invalid?

[cedoor]

So it only catches outright invalid proofs (garbage/malformed), not a valid proof with wrong inputs.

Ok, this is harder to do then. We cannot verify invalid proofs inside a proof recursively currently.. If the proof is malformed or garbage we cannot even generate the wrapper proof bcs there's an internal assert on correct proof verification.

Oh interesting. So perhaps we could have a simple wrapper proof that simple verifies onchain that a given off-chain proof is invalid?

I'm afraid we can do that only for proofs valid with incorrect public inputs, which doesn't look like our case.

[0xjei]

read through all the conversation, thanks all - I lean towards A as well. I don't see any other thing we can do besides overcomplicating one side or the other. It's the classic tech trade-off that might need more time & effort on it, but we are lacking the former rn. Therefore, if this is blocking (seems yes given the halt of E3), I would go with A and accept the technical debt & compromise unless we came up with a better solution this week.