How to handle early Fault Proof VM exits

[karlfloersch]

Problem

MIPS can diverge from the x86 implementation of Geth. Examples of this include:

1. Filling up all MIPS memory,
2. Causing some kind of panic,
3. Infinite loops, etc

If this were to happen, Geth may continue on like nothing is wrong, but then the fraud proof would exit early. Because we must favor what the fraud proof determines, this would mean that Geth must reorg to behave in the same way as the MIPS fraud proof.

Mitigation 1: Detection

It is key that we detect these failures ASAP. This can be done by in parallel running the MIPS evaluation for every block that Geth produces before submitting it on chain. This allows us to detect these failures quickly & handle them.

Mitigation 2: Failure response

The simplest way to respond to a failure like this is to invalidate the block if we detect any MIPS failures. If the MIPS failure is detected then some governance system would propose a new fraud proof binary with that bug patched.

Notes about this approach:

• Even a small reorg can be costly.
  • This isn't a huge deal because consensus failures on L1 have the same property -- a small consensus failure can produce a whole lot of MEV, which is the same in this case assuming we are able to detect the MIPS failure in a short period of time (eg. before the block is submitted).
• There is the potential for a malicious sequencer to DoS the network.
  • If you throw away the blocks, then a sequencer which has captured network upgrade governance can perform the following attack: 1) propose a malicious binary to steal all the money on L2, and then 2) add MIPS failing tx to every sequencer block to block people from withdrawing from the chain.
    • Thankfully this attack has a mitigation -- because deposit blocks are separate from the sequencer blocks, it is possible for users to fill up L1 blocks with honest deposit transactions which withdraw their money from the chain. This would allows for a simple mass migration to a new non-captured system. So thankfully we can still preserve liveness even in the case of full governance takeover.

We'll want to combine these two mitigations to handle this failure mode. There may be other ways to improve the way that we handle these attacks -- any suggestions welcome 😄

[karlfloersch]

I'm currently considering that, long term, L1 hard forks may be the most elegant way to update the fraud proof program in cases like these. (somewhat spicy take)

[karlfloersch]

Will the L1 hard fork somehow be aware of the fraud proofs contract?

Yes, basically put the critical fraud proof logic inside L1 (put the ability to verify L2 state transitions in L1). It sacrifices diversity in what kinds of state transitions you can run in L2, but it means that if there is a critical failure we can recover quickly.

[yoavw]

I can see the appeal of a unified fraud proofs contract, but it introduces some centralization risk. A single bug would result in exploitation of all optimistic rollups at once. Not saying that it shouldn't be done, just a downside to consider.

[norswap]

Here's another spicy idea: we could enable a "L2 hard fork mechanism" directly in the L1 contracts. Each fork would have a unique ID, and would be associated with its own L2 chain derivation function.

For contracts on L1 interacting with L2, they could:

• Have a mutable chain ID reference if they are "upgradeable".
• If they're immutable:
  • Default to some default chain ID controlled by Optimism or some kind of governance (basically the same security/upgradeability model as we have currently).
  • Let users pass in the chain ID!

This adds some complexity at the top of the design, but it's the best solution to the problem of upgradeability that I've been able to come up with so far. (Upgradeability problem = the security assumption is that whoever can upgrade the chain won't be malicious / fuck up, which is markedly weaker than the ideal rollup security assumption of "one honest validator".)

(For this, forking should be permissionless!)

[karlfloersch]

I can see the appeal of a unified fraud proofs contract, but it introduces some centralization risk.

I think that each client should implement a fraud proof & if they do not agree there is a hard fork to fix it. It's the same logic that we use that justifies having multiple implementations of L1 clients. The main critique is that using L2 governance to resolve the inevitable disagreements between implementations is insufficient.

"L2 hard fork mechanism" directly in the L1 contracts

This works great until there are assets which are deposited into L2. Because there is only 1 copy of the asset which has been deposited in, you can't actually fork L2 without fractionalizing that asset. So the more realistic way to handle this is that L1 is what forks (and that would implicitly fork all the deposited assets as well).

[moonaigithub]

Alright so ETH2 is now still risky to implement ... I prefer POW