ethereum-optimism
validation: check genesis predeploys against standard config
Predeploy spec: https://specs.optimism.io/protocol/predeploys.html
[Genesis state should have] Only standard predeploys and preinstalls, no additional state.
https://github.com/ethereum-optimism/superchain-registry/pull/373 is a sketch at a solution for this.
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,
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.
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
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
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
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
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.
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.