[Core Protocol] Question about preimage data uploaded by op-challenger

[yoshidan]

Did you check the documentation?

• Yes

Did you read the specs?

• Yes
• No

Did you check for duplicate questions?

• Yes

Issue Description

We are considering developing an application using Optimism and are looking into Fault Dispute Games for security research.

We are not sure from the documentation whether a fault op-challenger will always lose a game initiated by an op-proposer, so we would like to ask a question.

When op-challenger executes a step, it uploads a preimage.
How does FaultDisputeGame verify that this preimage is legitimate?

If op-challenger uploads an invalid clam and an invalid preimage, I am wondering if it is possible to create an arbitrary claim from prestate and terminate the game with a challenger_win.

Additional Information

No response

Feedback

No response

[hash1go]

Hello.
The absence of tampering with the pre-image is determined by calculating the hash of the pre-image onchain. Since data requests are made by hash, data that does not match this hash will not be supplied.

[yoshidan]

Thank you for your response.
Your answer confirms that the uploaded preimage is checked by hash at step.
https://github.com/ethereum-optimism/optimism/blob/45e1bd22b722703a3bf0523c58e815bb9a5c1696/packages/contracts-bedrock/src/cannon/PreimageOracle.sol#L105
https://github.com/ethereum-optimism/optimism/blob/45e1bd22b722703a3bf0523c58e815bb9a5c1696/packages/contracts-bedrock/src/cannon/PreimageOracle.sol#L330

However, I could not be sure that op-challenger will always lose if op-challenger uploads a malicious preimage (for example, a L2 block created by op-challenger by removing a specific deposit tx from L1). I could not be sure that op-challenger would always lose.

If you have a document or source that provides a mechanism where op-challenger cannot upload a malicious preimage or always loses even if it can upload it, that would be great.

[hash1go]

In reality, the op-challenger requests a preimage from the preimage oracle. During this process, it is not possible for a malicious preimage to be provided. This is because the L2 state is entirely verifiable by the data recorded onchain (L1).

The derivation process allows tracing the data from the L1 head block's hash through the data within L1, ensuring integrity and preventing manipulation.

[hash1go]

日本語でも解説しますと、

• 前提: オンチェーンにはL2のステートルートとトランザクションデータが保管されており、fault proofはこのステートルートに対して意義を唱えるプロセスです。
• preimage oracleのコントラクトはL1にデプロイされているので、L1のブロックハッシュの情報にアクセスできます。そんで、L1のブロックハッシュの情報がわかるということは、それまでのL1のトランザクションの履歴に関するproofを作成することができ、要求するpreimageのハッシュの正当性を担保することができます。
• 提供されたpreimageはオンチェーンで検証されます。

以上のことから、op-challengerが要求したpreimageが、不正なpreimageとなる可能性を潰しています。

[yoshidan]

@hash1go

提供されたpreimageはオンチェーンで検証されます。

Could you please tell us where the validation is being performed within Contract?

[hash1go]

Probably, this function performs that validation.
However, since I am not familiar with the code, I might need the help of other active members of the community to get a definitive answer.