feat(reorg): Add support for possible l1 and l2 reorgs

[antiyro]

Is there an existing issue?

• [X] I have searched the existing issues

Motivation

Currently, on Starknet, reorgs can occur due to a bug in the sequencer that might invoke a manual reorg until a stable state is reached, or due to an L1 reorg affecting a segment of the state containing an L2 verification. In the event of a reorg, we need to revert the entire state to match the L2 state. Detecting a reorg involves verifying if the parent block hash equals the latest block hash sync. If it doesn't, we need to sequentially revert all elements stored in the database (n-1) and revert the commitments on the Bonsai lib.

Request

We need to implement support for handling possible L1 and L2 reorgs on Starknet. This includes detecting reorgs by checking the parent block hash against the latest block hash sync and performing necessary reverts on the database and Bonsai lib commitments.

A deep understanding of storage and its implications is necessary to resolve this issue. Some changes at the level of the Bonsai lib may come into play.

Solution

1. Detection: Implement a mechanism to check if the parent block hash matches the latest block hash sync. If they don't match, a reorg is detected.
2. Revert State: Sequentially revert all elements stored in the database (n-1) to match the L2 state.
3. Revert Commitments: Revert the commitments on the Bonsai lib accordingly.

Feel free to discuss this issue under this discussion.

Are you willing to help with this request?

Yes!

[antiyro]

fix: L1 reorgs should not happen since we'll check L1 events only on finalized blocks.

[notlesh]

Are there any test vectors or examples of on chain reorgs that could be useful for testing this?

[notlesh]

I have a WIP PR here: #296