validation: check genesis predeploys against standard config

[geoknee]

Predeploy spec: https://specs.optimism.io/protocol/predeploys.html

Standard config spec states

[Genesis state should have] Only standard predeploys and preinstalls, no additional state.

[geoknee]

#373 is a sketch at a solution for this.

[geoknee]

Q: with interoperable OP is it problematic if a chain enables the governance token on their chain?
A1: This OP token thing — there should be nothing deployed I think
A2: (Possibly) EAS predeploys — idk if chains other than OP Mainnet and Base have them. if they do, great, if not, I don’t think we need to require,

[geoknee]

From chat today with Seb:

Some predeploys (at least GasPriceOracle for Ecotone and Fjord, we can check for any others) have been upgraded during hardforks. So the test should switch on which fork is activated, and make the appropriate assertion pulling bytecode from the monorepo, or copying the codehash.

[geoknee]

Actually here is the source, it is also in the specs https://github.com/ethereum-optimism/optimism/blob/d510910381d99660295f99e4eccd553df5829df6/op-e2e/actions/fjord_fork_test.go#L24-L29

[geoknee]

Here are some results investigating the distribution of codehashes across the superchain registry. (For each predeploy implementation address, it shows a number of codehashes, each with a list of chains which use that implementation).

https://github.com/ethereum-optimism/superchain-registry/blob/3ff4a2d6e69d248c36a9a1fee8a9b7df461d7710/validation/results.toml

[BlocksOnAChain]

We should check with @blmalone about his approach for this check.

[bitwiseguy]

We are planning to leverage @blmalone script. The work for this ticket will be to make sure the script is fully automated and integrate it into the superchain-registry CI

[geoknee]

Latest plan here https://www.notion.so/oplabs/L2-Genesis-Predeploys-Verification-c1c6f0b5c38d406bbfe09854653dade4?pvs=4#fbe8b779b04d46b1b7d5b80f9c6f506e leaning on runbook here https://www.notion.so/oplabs/BHIC-L2-Genesis-Predeploy-Verification-Metal-Mode-Zora-f42ecf4dd0164b4d9303b933d9e98bf6#0a94fd37ca37474d998ab1668e655264

[geoknee]

We should take a look at the genesis tooling, and “save” any important metadata into a file which (along with the deploy-config.json) gets tracked in the SCR. The principle is we want to be able to run the tool in the future to produce the identical result.

[BlocksOnAChain]

just to increase visibility, I'm sharing a document with the current document for this implementation: https://www.notion.so/oplabs/Genesis-validation-update-f453b1b676d440efb0ac43adc05cab2f - we are thinking that approach 2 is what we will do to get this check done.