[Core Protocol] Reason for the fault proof program

[ghost]

Issue Description

I see that outputRoot is submitted by a centralized authority and _outputRootProof object per each withdrawTransaction could be submitted by users.

My question roses that, 1. how the user could forge this, 2. what happens if outputRoot changes with the associated transaction already submitted and any possibilities that could happen 3. why do we have a challenge period 4. what is all the fault proof for.

Thanks!

Additional Information

No response

[ghost]

cc @sbvegan @refcell @clabby

[sbvegan]

Hey @kaliubuntu0206, thank you for showing an interest in what we're building! Can I please ask you to not tag our core devs, so we can keep their attention on building the protocol. I'm happy to triage and get answers for you in this discussion forum when its within all of our capacity.

[ghost]

So there is an upgradeability of the outputRoot https://github.com/ethereum-optimism/optimism/blob/84437125a7be518efd54e0ad87b1838f93bad073/packages/contracts-bedrock/src/L1/L2OutputOracle.sol#L140, I wonder why the function exists and when could the function being called?

[ghost]

I have found the likely answer from @ajsutton from the previous discord chat

Fault proofs are what enables you to challenge the proposed output root in a trustless, permissionless way. If anyone, operator or not, publishes an invalid output root, the fault proof system allows you to proof that its invalid and remove it so it can't be used for withdrawals.

So no one except the sequencer would be able to forge it right? Users wouldn't be able to post a falsify withdraw data with forged output proof right? https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L1/OptimismPortal.sol#L229

[sbvegan]

Yeah thats right, to answer your questions in reverse:

what is all the fault proof for

A fault proof, also known as fraud proof or interactive game, consists of 3 components:

• Program: given a commitment to all rollup inputs (L1 data) and the dispute, verify the dispute statelessly.
  - VM: given a stateless program and its inputs, trace any instruction step, and prove it on L1.
  - Interactive Dispute Game: bisect a dispute down to a single instruction, and resolve the base-case using the VM.
  - specs
• It is used to challenge and prove if the L2 state has been incorrectly submitted to the L1. If the fault proof succeeds, the rollup protocol re-executes the transaction(s) and updates the rollup's state accordingly.
• Additional information about our fault proofs can be found in our blog posts: https://blog.oplabs.co/

why do we have a challenge period

After a rollup batch is submitted on the L1, there is a time window during which the results of a rollup transaction can be challenged by computing a fault proof.

what happens if outputRoot changes with the associated transaction already submitted and any possibilities that could happen

I don't quite understand this question

how the user could forge this

At the moment, our sequencer is the only one that posts rollup data from L2 to L1. Enabling fault proofs allows the anyone to ensure the sequencer remains honest.