search

celo-org / optimism

Optimism is Ethereum, scaled.
https://optimism.io
MIT License
3 stars 2 forks source link

Fix l2 block older than l1 origin error #184

Closed piersy closed 1 week ago

piersy commented 1 week ago

We were encountering the following error when running op-node with a migrated datadir:

ERROR[06-25|16:53:24.779] Derivation pipeline not ready, failed to reset engine err="reset: cannot reset block derivation to start at L2 block 0xdf1dfd6566270260a33f4a33406358e93b8402d4bb6829bb35d685259cc1c3c2:23912612 with time 1714956104 older than its L1 origin 0xbbed3612407993e67f8ca7a423b181837ae164a531941e78f5ee48e766d39cad:1729797 with time 1718312256, time invariant is broken"

This pr fixes that by using time.Now for the time of the l2 transition block. We really do need a deterministic time for the migration block so that all parties that run the migration arrive at the same migration block but the problem is that op-geth requires that the L2 migration block (aka l2 origin) occurs after the l1 origin (I guess the point where you deploy the bridge contracts to the l1). When we migrate a partially synced datadir the block before the transition block will be very old, up to 4 years old! So of course it occurs before the l1 origin. So a fix just to get things working is to use time.Now(), but probably we should make this a configurable parameter.

piersy commented 1 week ago

Hey @alecps, I was thinking that we might want to use the flag for the actual migration, it would give us flexibility, for example if we defined the celo-blockchain end block but then had some problems deploying the contracts to L1 and ended up with the L1 contract deployment happening after the end block. The thing is you don't want to deploy the l1 contracts too far in advance since op-node will try to "catch up" to ensure that the time between l1 origin and now is filled with the appropriate number of l2 blocks.