[Core Protocol] If the DA is not accessible by the DisputeGames, how does the later differentiate between two equally valid states?

[DefiCake]

Edited for better wording.

Did you check the documentation and specs?

• Yes

Was there anything unclear or missing?

The sequencer is posting blobs / calldata to Ethereum, nodes are syncing from it and derive new states. The address were these blobs are being posted is void though, so the blobs are not being registered anywhere that is accessible by other smart contracts in the Ethereum network (example transaction)

OTOH, the state of the L2 can be proposed by anyone. The transition from the current state to the next state should be that given by the transactions posted on blobs.

But from the current state, there are virtually infinite new valid states, depending on how transactions were ordered (and included). If we imagine the current state of the L2 as a hole the wall of a dark room where a cone of light shines, and this cone of light is all the possible future states (blocks), only one thread of light inside that cone would be described by the blobs that are being / will be posted to the L1, but there is millions of possible future states that emanate from the current instant.

What stops me from building and proposing an alternative new state (like a fork of the network) on top of the latest valid state? Since the dispute games contract cannot reference the blobs that were posted, if the state I proposed is valid (as in no rules of the EVM were broken), I assume no one can dispute me. Further, I could leverage this chance to sneak in an invalid state, because no one has the transactions I used to generate the new state, and challenging the state without having the data is risky.

The only way I can think of is if the dispute games do check that blocks inside the proposed state are signed by the sequencer, but that feels a bit oracle-y to me. I guess that at certain points, you want to rotate the keys of the L2 sequencer / block producer (or maybe there is a specific special transaction for that, so key rotations could be proven on the L1). I have not been able to find any reference to how this connection between DA and posted state is made, and I have observed that other rollups do make smart contract calls along with their blob posts to "register" the data, a clear example of this would be Taiko or Arbitrum.

EDIT. I will paste something that is down below in the reply section:

I am not trying to verify if a specific transaction was included or not.

I 'll try to reword it like this. Typically EVMs are noted like state machines where you go from State A to State B by applying the transactions in a block following the EVM rules:

s -> f(txs) -> s'

Now, if the L1 contract that holds the state finds itself at s_1, and we apply the transactions that have been published in blob space, we should arrive at s'_1:

s_1 -> f(published_blob_txs) -> s'_1

So you can confidently post in the L1 that OPs state is s'_1, because all of these are valid transactions and valid state transitions.

Now, let's imagine that the above has not yet happened. If I start from s_1 and apply a different set of transactions, like this:
s_1 -> f(my_own_set_of_valid_txs_that_have_nothing_to_do_with_the_ones_at_blobs) -> s_2

Then technically, the new s_2 state is also valid, it just differs from the L2 state that has been defined by the blobs, but the L1 contract does not know about them, so I could go and post the s_2 state to the L1 contract. This would mark a disconnection between the state of the L2 (as defined the blobs) and the state posted at the L1 contracts. What I am asking is why I cannot do this, because I imagine that there must be something stopping me.

Did you check for duplicate questions?

• Yes

Similar Questions or Issues Found

No response

Please select the type of request

• Bug Report
• Feature Request

Steps to Reproduce

No response

Expected vs. Actual Behaviour

No response

Software Versions

No response

Operating System

No response

Hardware Resources

No response

Configuration Files, Startup Flags & Environment Variables

No response

Error Messages / Logs

No response

Feature Description

No response

Purpose and Benefits

No response

Relevant Context or Examples

No response

[opfocus]

I found this sentence on specs.optimism.io : "queries the rollup node for the latest output root derived from the latest finalized L1 block." Although this content is somewhat outdated, I believe it might still be valid.
Additionally, there's the following passage: "The [AnchorStateRegistry](https://etherscan.io/address/0x18DAc71c228D1C32c99489B7323d441E1175e443#readProxyContract) was designed as a registry where DisputeGame contracts could store and register their results so that these results could be used as the starting states for new DisputeGame instances. These starting states, called 'anchor states', allow new DisputeGame contracts to use a newer starting state to bound the size of the execution trace for any given game."
I think their root retrieval method is the same.

[DefiCake]

Hey, thank you for replying!

I do not think that address the original question though:

• To your first point "queries the rollup node for the latest output root derived from the latest finalized L1 block.", if I am not mistaken, it refers to the Proposer pushing states to the L2OutputOracle contract that is now deprecated, as anyone can propose new states.
• To your second point, there is no reference there regarding how these games are being resolved under the umbrella of the data posted in the blobs. I want to know what's stopping me from creating state that, being valid itself, diverts from what you would get deriving the state from blobs.

[opfocus]

the latest finalized L1 block.
Yeah I'm not sure. What I mean is that even if it deprecates L2OutputOracle, if there is no change in the way it queries root, then still the latest root is derived from L1
CC @joohhnnn could you help me check this question

[hash1go]

To verify whether a specific blob transaction was included in a past block, a proof can be generated from the block hash.
Therefore, I believe the issue you are concerned about will not occur.

I don’t have complete knowledge of all the specifications, but I think it would be beneficial to dive deeper into Cannon's DB hinting.

[DefiCake]

I'm actually going through similar questions @DefiCake, and I think the answer is that since the op-program is what is ran as the FPP in the FPVM, it indeed will run the chain derivation taking into account the blob transactions on the L1. Therefore, this exposes the ability for the dispute game to ensure the blob data is correctly read.

Thanks for joining the conversation! I understand that the fault proofs system must run the same chain derivation logic. But you have to input data (transactions) to that derivation system. How do the contracts know (or prove) that I am using the input from the DA, and not some other made up DA, is what I am trying to grasp. As far as I am concerned, the contracts do not have any direct way of reading the data that was posted.

[SleepingShell]

How do the contracts know (or prove) that I am using the input from the DA, and not some other made up DA, is what I am trying to grasp

I have not confirmed this directly, but my intuition is that since you have access to the L1 header (which exposes the transactions root), then you can validate a given blob-carrying transaction exists in the block.

[hash1go]

If published_blob_txs are finalized on L1, then s'_1 becomes a valid state.

[hash1go]

@SleepingShell
Please open a separate ticket (discussion) for questions regarding sequence epochs and sequence windows.

[DefiCake]

If published_blob_txs are finalized on L1, then s'_1 becomes a valid state.

Thank you for clarifying that @hash1go :) with that out of the way (and sorry if I am being obtuse), I need the answer to the second question: how do the state contracts in the L1 assert that we are using the published_blob_txs and not some other source? I have been trying to locate some sort of link between the contracts source code and the DA, but failed to do so.

@SleepingShell might be onto something here with the L1 header, but that would only last for 256 blocks (less than an hour), which would make a requirement that state is posted on the L1 before it losses access to that information. That would be terribly vulnerable to L1 congestion, so I have my doubts.

[smartprogrammer93]

Been looking for an answer to this also. would love if someone from the OP core team can shed light over this.

[joohhnnn]

Hi, I'm happy to answer your questions about fault proofs. First, let me clarify a key concept. Based on your description, it seems like you assume the fault proof game directly reads the data sent by the L1 batcher to participate in fault proofing. This is a common misconception. In reality, blob or calldata only indirectly affects fault proofs by influencing the L1 block hash.

To explain this further, let me address a specific question you raised. Before diving into the example, I want to emphasize another important concept: all L2 blocks that undergo fault proofing have already reached finalization. This means that the corresponding calldata or blob data has been submitted to L1 and has passed two epochs.

Now, let’s get into the example. Suppose an L2 sequencer node and a non-sequencer node diverge, creating a subjective fork. Your question is: if a non-sequencer also submits DA (data availability) data to L1, wouldn’t that data be valid for fault proofing as well?

Let’s analyze the flaw in this assumption. Regardless of whether it's a sequencer or a non-sequencer node, consensus is always formed based on the official batcher address as the batch source. This means a non-sequencer node cannot independently create a subjective fork and continue batching its own data to DA. Instead, it will eventually detect a mismatch with the L1 batcher DA data and roll back accordingly.

I completely understand that fault proofs can be tricky to grasp at first. I recommend checking out this fault proof series of articles for reference https://github.com/joohhnnn/The-book-of-optimism-fault-proof . If you have any further questions about the details, feel free to ask!

[smartprogrammer93]

And this is part of the FPVM i assume? So all in the proof?

[joohhnnn]

And this is part of the FPVM i assume? So all in the proof?

Yes, but FPVM can essentially be understood as an abstract and highly simplified node running within a virtual machine. Normally, we think of a standard rollup as a Go-based node, but in this case, it cannot retrieve L1 blocks and reprocess them like a Go node with Geth. This is why we need to feed it with the necessary data—on-chain, this mechanism is known as the pre-image oracle.

[DefiCake]

OH my YESSSS that's what I was looking for. THANK YOU.

One last question then, I guess that the pre image oracle has to load the blobs sent by the specific batcher address (and to the blob inbox address 0xFF00000000000000000000000000000000000010) and not some other address, correct? What if we want to rotate the keys of the blob sender?

[joohhnnn]

One last question then, I guess that the pre image oracle has to load the blobs sent by the specific batcher address and not some other address, correct? What if we want to rotate the keys of the blob sender?

Yes its a fixed address. umm I think it's Actively updated by the sequencer node, and other nodes are forced to update? not pretty sure.

[hash1go]

As I understand it, changing the batcher address requires modifying the onchain config contract, which would necessitate a hard fork of L2.

@joohhnnn
By the way, I assume that the hash requested as a pre-image is computed onchain before it is requested. How does the op-program determine the necessary pre-image hash?