[Application Development] Trace the transactions from L2 to L1 || How to get confirmations on L1

[threetoeddinosaur]

Did you check the documentation?

• Yes
• No

Documentation Feedback (Optional)

No response

What type of issue are you experiencing?

• Error
• Feature Request
• General Question

Issue Description

I'm trying to see how I can get from an L2 transaction batch to a L1 tx confirming the inclusion of the block containing the L2 transaction into a batch which was submitted to L1. If I understand correctly, batches are constructed from a range of L2 blocks and the stateRoot of each block goes into the batch. That batch is then stored on the L1 as a blob where the transaction was made by the Batch Sender address. I can see the blobs sent by the batch sender, but I can find the link from a particular block on L2 to a particular batch, and/or the specific batch to the blob commitment relating to that batch? I need to be able to provably tie a specific L2 transaction to a specific piece of L1 data showing it happened. I am aware of the getBlockByNumber RPC call, but that is not sufficient, it only tells me that my L2 transaction is finalized on L1, and doesn't provide any information I can look at on L1 to prove that.

Steps to Reproduce

Not a bug, general question

Are you using a specific library or SDK?

• OP-SDK
• Viem
• Other
• Not Sure

Are you using the latest version of the library/SDK?

• Yes
• No

Environment Details

No response

Troubleshooting Attempts

No response

What type of support do you need?

• Technical support for issue resolution
• Feature implementation guidance
• General advice or consultation
• Documentation or learning resources

Additional Information

No response

Feedback

No response

[hash1go]

Hello!
Firstly, to clarify, the blob does not contain the L2 state root information. Please refer to this specification for further details.
https://specs.optimism.io/protocol/derivation.html#sequencing--batch-submission-overview

One key point to note is that L2 blocks are derived from L1 data, so the concept of directly linking an L2 transaction to L1 data can be misleading. Instead, to confirm that the transaction execution on L2 aligns with the commitments submitted to L1, you can check the output proposal submitted by the op-proposer. Since the OP Stack functions as an Optimistic Rollup, this output proposal is considered valid unless challenged, confirming that L2 blocks have progressed correctly based on L1.

[chahatjaink]

@joohhnnn, In that conversation, you mentioned using optimism_safeHeadAtL1Block to identify which L2 blocks or transactions correspond to a specific L1 block. The output I'm seeing indicates that, when calling the safeHeadAtL1Block RPC method with L1BlockNumber = 7061621, the response returned is L1Block = 7061600 and L2SafeHead = 17822075.

I'm getting this L1BlockNumber input from the setL1BlockValues function call within each L2 block(17822386). Could you please clarify what this input—specifically the L1BlockNumber—is intended to specify and why am I getting this response for the L1 Block that is way behind this one?

[threetoeddinosaur]

Hey @joohhnnn, So, I will explain what the issue I am facing is that I can get the L1Block for the L2 Block with the help of the setL1BlockValue method call in each L2 Block as the 0th index tx. For this L1Block I am calling the given optimism_safeHeadAtL1Block and getting back a response like the one described above, and safeHead for L2 Block is also less than my L2 Block (does this mean that my L2Block has not mined on L1 yet).

[joohhnnn]

@joohhnnn, In that conversation, you mentioned using optimism_safeHeadAtL1Block to identify which L2 blocks or transactions correspond to a specific L1 block. The output I'm seeing indicates that, when calling the safeHeadAtL1Block RPC method with L1BlockNumber = 7061621, the response returned is L1Block = 7061600 and L2SafeHead = 17822075.

I'm getting this L1BlockNumber input from the setL1BlockValues function call within each L2 block(17822386). Could you please clarify what this input—specifically the L1BlockNumber—is intended to specify and why am I getting this response for the L1 Block that is way behind this one?

Hello, the 'input L1BlockNumber' represents the L1 block of the most recent batch transaction sent by the batcher up to and including the current or previous input. Therefore, when you enter 7061621, it will return 7061600, which means that the most recent batch transaction before block 7061621 occurred at block 7061600 and corresponds to L2 block 17822075.

@chahatjaink

[joohhnnn]

Hey @joohhnnn, So, I will explain what the issue I am facing is that I can get the L1Block for the L2 Block with the help of the setL1BlockValue method call in each L2 Block as the 0th index tx. For this L1Block I am calling the given optimism_safeHeadAtL1Block and getting back a response like the one described above, and safeHead for L2 Block is also less than my L2 Block (does this mean that my L2Block has not mined on L1 yet).

When you use 'setL1BlockValue' to set the L1 block for L2, it does not mean that the L2 data is included in L1. Only when the batcher batches your L2 data to L1 does it correspond accordingly @threetoeddinosaur

[deqcjain]

I agree @joohhnnn, so can I conclude from this that the l1Block which contains my l2Block will be the one for which safeHead for L2 blocks is greater than the l2Block in which my l2 transaction is mined.
For e.g.
l2 block = 1751551 (l2 Transaction is mined)
Got l1Block at this state from setL1BlockValues
l1Block = 700429

Called safeHeadAtL1Block rpc for this l1Block
Response
l1Block = 700340
safeHead = 1751000

So, from this can we conclude that until this safeHead crosses our l2Block, the batch with our L2 block is not submitted and will be submitted in the l1Block for which the safeHead includes our l2Block (i.e. gt our l2Block).

Thank you for your patience and time.