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
The op-node starts deriving on the L1 block after what is in its config. This means we need SystemConfig.startBlock() - 1 rather than the start block itself. Two options on how to handle this:
Have the genesis generation script fill in start block - 1 into the rollup config
Make the starting L1 block be optional in the rollup config and use the startBlock() value as the starting point if its not present
I lean towards the second, it removes config overhead.
The text was updated successfully, but these errors were encountered:
I think the second is doable so long as op-node can load it from the latest L1 block reliably. Otherwise it doesn't know which block the system config first existed in. In most cases (probably not all) op-node walks along L1 from the start block forwards loading data from the block its up to so it has a consistent view. This would need to be a case where it always goes to the latest value. The start block has to be immutable so that seems reasonable to me.
From @tynes comment:
I lean towards the second, it removes config overhead.
The text was updated successfully, but these errors were encountered: