search

celo-org / optimism

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

Proposal for slashing conditions to punish malicious sequencer behavior. #18

Open eelanagaraj opened 1 year ago

eelanagaraj commented 1 year ago

High-level proposal has already been provided in the forum post. 

### Tasks
- [ ] design doc to more thoroughly spec out different implementation options and obtain feedback
- [ ] decision around which design to use
- [ ] implementation plan + create tickets/next steps for continuing this work
stackman27 commented 1 year ago

hi @eelanagaraj i would love to contribute on this! I'm fairly experience with op-stack and have high go-lang experience. Do you mind if i spec this out reading the forum? Or have you guys started the work already?

eelanagaraj commented 1 year ago

hey @stackman27, thanks for your interest! Feel free to share any design ideas directly here on the ticket :)

stackman27 commented 1 year ago

From what i understand there are 3 slashing conditions at sequencer layer rn

  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 propagated 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

  3. Sequencer fails to post the shared data within the sequencing window

    • We can break this into two folds
      1. Sequencer fails to post shared data given txBatch exists within a sequencing window
        • This could either be because consensus took unexpected time or DA layer took unexpected time.
        • i'm not sure about the design of sequencing window rn, but i think it can be dynamic?
    1. Sequencer fails to post shared data given txBatch doesnot exist within a sequencing window
      • in this case i dont think there is much we can do here. In OP Mainnet blocks are produced every two seconds, regardless of whether they are empty (no transactions), filled up to the block gas limit with transactions, or anything in between. But i'm not sure if pBFT is even necessary for empty blocks, this can just be an edge case to handle.

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

Glossary: Sequencing window = time it takes to produce blocks using pBFT by sequencers and publish it on L1 (eth) txBatch = txs sent to L2 network DA certificate = certificate that shows that the current operation (state change) is valid