rcstanciu
commented
1 year ago Comment from Optimism
Description: Reorg possibility during migration
Reason: It is true that L1 could reorg during the migration, however the likelihood of a 50 block reorg during the migration is extremely low. We would wait at least 50 blocks for the DTL to halt and process the last deposit. If such a reorg were to occur, it would break the existing system as well.
Action: No action
obront
high
Double spend of deposits is possible during migration due to re-org opportunity
Summary
During migration, the sequencer creates a new Genesis state and all derivation takes place from that point. Users sync off-chain to the produced genesis and validate from there. If the L1 re-orgs during the migration process, the old L1 state (including potential deposits) will be used to create the Genesis state for all blocks, while the L1 state will return to the state before these deposits were made.
Vulnerability Detail
The migration process is vulnerable to an L1 re-org. If the L1 snapshot used by the migration is re-orged, a deposit that was supposedly made just before migration could be counted to the depositor's credit, while the re-org would be to a chain without that deposit. In effect, user is achieving a double-spend of their deposit. Since the Genesis state is trusted, the double-spend will definitely reach consensus.
The condition for double-spend to be possible is that the l1Block fed to
MigrateDBis not finalized. This gives attackers potentially 64 blocks (duration from latest to finalized) to re-org and steal funds.Impact
Double spend of deposits is possible during migration.
Code Snippet
https://github.com/ethereum-optimism/optimism/blob/407f97b9d13448b766624995ec824d3059d4d4f6/op-chain-ops/genesis/db_migration.go#L37
Tool used
Manual Review
Recommendation
Duration migration, verify that the
l1blockused is finalized.