[Core Protocol] When L2 reorgs happen and where can we find the reorg data?

[bap2pecs]

Did you check the documentation?

• Yes

Did you read the specs?

• Yes
• No

Did you check for duplicate questions?

• Yes

Issue Description

I want to figure out all the possible cases when a L2 unsafe or safe block can get reorged, apart from the one caused by L1 reorgs

I also want want to find sth similar to https://etherscan.io/blocks_forked because we want to 1) know the frequency of L2 reorgs; 2) find a way to get such data (we need to monitor those L2 reorgs) in our system

Additional Information

we are working on ethereum-optimism/specs#218 and need to understand reorgs better since it's fundamental to our system

For safe block, the spec says "The safe L2 head may only be reorged out due to L1 reorgs.". So I am more interested in learning how can a unsafe block gets reorged.

Feedback

No response

[imtipi]

https://specs.optimism.io/protocol/derivation.html?highlight=reorg#resetting-the-pipeline
you might find something you want here

[hash1go]

Hello!
unsafe blocks, like safe blocks, can also get reorged due to L1 reorgs.
As you know, the OP Mainnet is an Ethereum rollup, so L2 data is based on the data recorded in L1 and can be affected by L1 reorgs.

[hash1go]

Oh, unsafe blocks are not yet published on L1, so my explanation is incorrect.

[joohhnnn]

First, let's clarify the concept of "blocks_forked." I believe the "l1 reorg" you mentioned doesn't refer to uncle-blocks or forked-blocks. Instead, it refers to hard forks from L1, like the one that occurred during The DAO incident. Currently, all L2 data that comes from L1, such as deposits, are processed only after being confirmed in an L1 block. Therefore, there haven't been any reorganizations caused by L1 reorgs or hard forks yet. Since there is currently a single sequencer, uncle blocks or forked blocks do not exist either.

[hash1go]

I checked with the OP team, and it seems there are no tools available to find reorg data.

[opfocus]

In my test, when the batcher of our own L2 chain missed a submission in a sequence window and submitted in the next sequencing window, the L2 chain experienced a lengthy reorganization.

[bap2pecs]

thanks for sharing! @opfocus I am curious, how did your L2 chain miss a submission widow? isn't the window usually very long (3600 L1 block = 12 hrs)?

[sbvegan]

There's a lot of good pieces here so I'm going to tie them all together. A transaction can be:

• unsafe: not on L1, but gossiped by the sequencer
• safe: on L1, but in a block that has not been finalized on the L1 yet
• finalized: on L1, in a block that has been finalized. Cannot be reorged.

The derivation pipeline is what all L2 nodes use to derive the L2 state from Ethereum. If the sequencer window is passed and no batches are posted, which means also no new safe or finalized blocks are marked, all the unsafe blocks in that window are thrown out. This causes a large reorg and the nodes just start deriving state from only L1 blocks.

You could also get an unsafe reorg if there was some sort of offchain infrastructure issue with your sequencer. Lets say there were two active sequencers and they both were putting out unsafe blocks. This could cause race conditions and fork the blockchain too. If you're following sound practices, this doesn't happen.

[bap2pecs]

thanks @sbvegan! for "If the sequencer window is passed and no batches are posted", usually how can this happen?

[opfocus]

https://docs.optimism.io/builders/node-operators/management/metrics#important-metrics
op_node_default_refs_number: This metric represents the op-node's current L1/L2 reference block number for different sync types. If it stops increasing, it means that the node is not syncing. If it goes backwards, it means your node is reorging.
I think that's one way to look at reotg. I think setting an alarm is also okay.
At the same time, signs of reorganization can also be seen in the op node or batcher logs.

But all in all, I don't know all the details of the observational reorganization