To accommodate for L2 chain reorgs (the pending chain reorging) we need to update the inbox and outbox.
Namely, instead of the inbox keeping track of the tree to consume, we can just have the rollup pass along the block number as pending chain is expanded. This means that when we extend the pending chain we will be "finishing" the trees to include. If there is a reorg, we simply go back and read these, but we don't need to overwrite them or anything. This makes L1 -> L2 messages fairly easy to handle.
For L2 -> L1, the approach depends on whether we have sequential proofs or not.
- Sequential proofs: Just move the insertion to time of proof verification.
- Non-sequential proofs: Store data for insertion as part of
BlockLog such that it can be inserted as part of _progressState.
Another approach is that we keep inserting in both cases, but have that the outbox itself take a look back at the rollup to figure out if the proven chain is further than what is being consumed.
To accommodate for L2 chain reorgs (the pending chain reorging) we need to update the inbox and outbox.
Namely, instead of the inbox keeping track of the tree to consume, we can just have the rollup pass along the block number as pending chain is expanded. This means that when we extend the pending chain we will be "finishing" the trees to include. If there is a reorg, we simply go back and read these, but we don't need to overwrite them or anything. This makes L1 -> L2 messages fairly easy to handle.
For L2 -> L1, the approach depends on whether we have sequential proofs or not.
BlockLogsuch that it can be inserted as part of_progressState.Another approach is that we keep inserting in both cases, but have that the outbox itself take a look back at the rollup to figure out if the proven chain is further than what is being consumed.