Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standard L2 Genesis: Prevent start block misconfiguration #12579

Open
Tracked by #12302
maurelian opened this issue Oct 22, 2024 · 1 comment
Open
Tracked by #12302

Standard L2 Genesis: Prevent start block misconfiguration #12579

maurelian opened this issue Oct 22, 2024 · 1 comment

Comments

@maurelian
Copy link
Contributor

maurelian commented Oct 22, 2024

From @tynes comment:

Noticed something here: dcdf2b7/op-node/rollup/types.go#L43

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:

  1. Have the genesis generation script fill in start block - 1 into the rollup config
  2. 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.

@maurelian
Copy link
Contributor Author

maurelian commented Oct 25, 2024

Also:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant