op-node: Initialize L1State at driver startup

[trianglesphere]

Description

This avoids issues with the confirmation depth. If this returns an error, it exits via CLI.

Metadata

Fixes ENG-2920

[changeset-bot[bot]]

⚠️ No Changeset found

Latest commit: 517f130f568db7c84f244c10d60a72658f04f4ab

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[mergify[bot]]

This PR changes implementation code, but doesn't include a changeset. Did you forget to add one?

[trianglesphere]

Converted to draft b/c it looks like this is using the L1 client before it's fully available or the L1 client does not have a head block at startup.

[trianglesphere]

Can we not handle the initial zero values when we read them? It would be nice to instantly start up, without failure edge cases, by avoiding these RPC calls.

There is an underlying problem that this interacts with the conf_depth to reject valid getBlockByNumber which causes problems with the initial find sync start (particularly with large . On solution is to use a non-conf depth fetcher in the right places, another is to add a fourth condition here: https://github.com/ethereum-optimism/optimism/blob/e97a9adec87fbcd9f4326ee34edbd90b1a4d5e03/op-node/rollup/driver/conf_depth.go#L33-L36 It is possible to write code with the assumption that there is a zero value, but I think it adds a fair bit of complexity.