You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
Revert State: Sequentially revert all elements stored in the database (n-1) to match the L2 state.
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!
The text was updated successfully, but these errors were encountered:
Is there an existing issue?
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
Feel free to discuss this issue under this discussion.
Are you willing to help with this request?
Yes!
The text was updated successfully, but these errors were encountered: