celo-org / optimism

Optimism is Ethereum, scaled.
https://optimism.io
MIT License
3 stars 3 forks source link

Slash sequencer for double signing #26

Open karlb opened 1 year ago

karlb commented 1 year ago

The sequencer must be slashed if it sends different data to the L1 than it has sent p2p, otherwise the 1-block-finality can be broken without punishment.

stackman27 commented 1 year ago

hi @karlb from what i understand here there is 2 folds to this problem;

  1. Sequencers double signing a txBatch at same block height over L2 p2p nodes

    • i believe sequencers can be slashed based on how celo handles double signing today
  2. Sequencer sends "different data to L1 than it has sent over L2 p2p nodes" which is a case of consensus mismatch and leads to reorg (thus failing 1 block finality)

    • In this case can we check the EigenDA layer to see if the data about be sent to L1 is the same as what's propogated over L2 nodes? For ex: a. Celo Sequencer finalizes tx batch with 2/3 majority (propogates to the entire L2 sequencer network) b. op-batcher encodes & sends signed blocks to EigenNodes, and receives DA certificate c. op-batcher maps block height to DA certificate & sends data to L1 c. if the state root from (a) doesnot match what's being sent at (c) then the validator/sequencer get slashed

i'm new to Celo's design so i'm wondering if this solution has been proposed/scoped out, would really appreciate any feedback!

karlb commented 1 year ago

I would hope that we can handle both cases the same way, since the second case is also a case of double signing (both the data sent to L1/EigenDA and the one sent out via p2p must be signed to be considered). I imagine a contact that takes two sets of (txroot, L2 block number, signature over both) and if both have a valid signature by the same signer and have the same L2 block number, then the signer is slashed.

stackman27 commented 1 year ago

yea i think we certainly can, this is what i'm thinking

struct SeqData {
txRoot, BlockNumber, Signature
}

func ValidateAndSlash ([]SeqData) {
 // Validate txRoot for (1) 
 // Validate txRoot for (2)
 // check txRoot (1) and txRoot(2) for double signature using current methods 
 // if txRoot(1) != txRoot(2) (attempting to send different data to L1 thant it has sent over L2 p2p nodes) 
 //   slashSequencer()
 //  validate  Signature (1) and Signature (2) they must be the same
}
karlb commented 1 year ago

The high level design of the decentralized sequencer is still a work in progress, so it makes sense to wait a bit before planning this out in more detail. Right now, our focus is more on changes to the execution client, contracts and migration planning rather than than the decentralized sequencer. But that will change over time and we'll publish additional information as we go.

stackman27 commented 1 year ago

sounds good, i'd love to get involved and help out as well. Please lmk if thats possible