OP stack: slashing on equivocation

[bap2pecs]

@bap2pecs cloned issue babylonchain/pm-integration#6 on 2024-06-21:

Summary

we want to trigger slashing at equivocation

Me: when double vote happens, how should we trigger the slash in the cw contract? should this be MVP or post MVP? can we reuse the logic here? if yes, when do we expect it to be ready?

@SebastianElvis : typically this is sent from contract to Babylon via a IBC channel, however we cannot do that as the contract is on Babylon. My first idea is to add a new msg for slashing evidence in btc staking module. This will also be useful for other integrations where slashing happens off chain. I’d say post MVP

Tasks

• slashing design: CW event vs. gRPC Babylon msg (chosen). finalise the design with Babylon team

• contract: remove irrelevant TODO: Verify whether the voted block is a fork or not block as it's only for CometBFT chains

• contract: add our checks to detect equivocation

• contract: research whether we can execute gRPC msg to Babylon chain from the CW contract

• integrate with the BTC Staking Monitor program for slashing. research to see if there is any modification needed

• implement slashing for consumer FPs on the Babylon chain

• implement slashing for consumer FPs inside the BTC Staking Monitor program

[bap2pecs]

@bap2pecs commented on 2024-07-09:

https://github.com/babylonchain/babylon-contract/blob/main/contracts/btc-staking/src/finality.rs#L192-L229

@SebastianElvis @maurolacy please correct me if I am wrong. I think in our case, ^ logic is irrelevant b/c it's for CometBFT only

[bap2pecs]

@SebastianElvis commented on 2024-07-09:

No those are relevant. The logic checks whether the voted block is a fork or not, and if yes then slash

[bap2pecs]

@bap2pecs commented on 2024-07-09:

No those are relevant. The logic checks whether the voted block is a fork or not, and if yes then slash

I mean we can simply check this state var https://github.com/babylonchain/babylon-contract/blob/main/contracts/op-finality-gadget/src/state/finality.rs#L5 to see if there is signature for this FP at the specific height right?

[bap2pecs]

@SebastianElvis commented on 2024-07-09:

Ah I see your point. You are right that we can only check the contract state on the signatures. Babylon case is more complicated because it determines canonical chain and tallies blocks on-chain.

[bap2pecs]

@bap2pecs commented on 2024-07-09:

@SebastianElvis another q, for slashing, there are two designs: 1) throw error and emit event; 2) inside the contract, send a gRPC message directly to the Babylon chain to trigger a slash

I am leaning towards 2) b/c we can reuse the BTC Staking Monitor program to slash

what's your opinion?

[bap2pecs]

@SebastianElvis commented on 2024-07-09:

Agree with doing 2 as Babylon needs to be notified about this slash anyway. I did not remember whether Babylon supports slashing a consumer FP though, need double check with the babylon code base. If not then we will need to add this support (which is necessary in the next next Euphrates release anyway)