fix: avoid skipping checks for conduit chains

[mds1]

From https://github.com/ethereum-optimism/superchain-registry/pull/107#pullrequestreview-1998488407

Approving and merging this PR, but we'll later need to investigate the Genesis test failures that are currently being skipped for Metal Sepolia, Metal Mainnet, and Superlumio Mainnet

We also are skipping the L2OO tests for those chains + Mode Sepolia, and should confirm that's ok.

[geoknee]

https://www.notion.so/oplabs/Superchain-Genesis-Hash-checks-60e173e9fb0c43e88a81d0666cb3d582

[geoknee]

Helpfully, we have the raw JSON config files for these chains now https://github.com/ethereum-optimism/superchain-registry/pull/226 .

From a slack thread:

For both chains (Superlumio and Metal Sepolia) which fail the check at the moment, we are hardcoding "eip1559Denominator": 50 which doesn't match the value of 0 used in the supplied json files. I don't think this makes a difference to the genesis block hash validation check.

For Superlumio, it looks like you have hardfork times "missing". In the registry we allow chains to override superchain-wide hardfork times, but not with nil values. So by not specifying overrides for e.g. ecotone_time, the chain is inheriting the superchain-wide hardfork times (and a bunch of other values that are pinned to that hardfork time) when we reconstruct the genesis, and this affects the genesis block hash which we compute in the check.

On a local branch I hacked around with this by deactivating the hardfork times for the entire supechain, then the checks for these chains pass.

I can see two possible resolutions:

• ~We have to ensure canyon, delta and ecotone are activated on these chains and update the hardfork times as appropriate in the .yaml files to non-nil values.~ this isn't really an option, they would need to be activated at genesis.
• We could change the registry behaviour to allow overriding from non-nil to nil. I'm not sure if this is the behaviour we want though, I will check with the rest of the team.

[geoknee]

The key thing is if either canyon or ecotone is activated at or before genesis. this affects genesis block because of these lines https://github.com/ethereum-optimism/op-geth/blob/9617f2a7dd0ab80c468d6e474e3cc26be9572c97/core/genesis.go#L538-L552

Canyon implies Shanghai Ecotone implies Cancun

[geoknee]

Here's one way of fixing this https://github.com/ethereum-optimism/superchain-registry/compare/gk/skip-default-hf-times?expand=1.

The idea is to not specify hardfork times in a superchain wide way any more. Every chain has to specify their own hard fork times.

Pros:

• remove a lot of complexity in superchain registry Go code
• genesis hash checks pass again for all standard chains (can probably also extend to frontier chains too but I didn't check that yet)
• no downstream changes necessary, op-geth and op-node inspect the per chain values anyway

Cons:

• we may need to go back and get the correct values for chains, I don't think we can tell if we have them correct at the moment
• more repetition across configs (not a big deal, I think)
• no longer enshrining "upgrade together" flow into the data structures. But, we can probably still do that using other tooling, and write whatever checks and balances we want.

Here is the PR where the behaviour was added https://github.com/ethereum-optimism/superchain-registry/pull/101