feat(superchain): add GovernedByOptimism field to chain config

[edobry]

Description

This PR adds a boolean GovernedByOptimism field to the chain config, which indicates if a certain chain is subject to Optimism governance. It also adds a GovernedByOptimismTest test to the validation package, which ensures that any chain which has the governed_by_optimism field set to true in its config also has its ProxyAdmin address set to the Optimism multisig.

It also sets the new governed_by_optimism field on all chain configs as appropriate

Metadata

• In service of: add "Governed By Optimism" field to the chain lists #676
• Depends on: refactor(add-chain): refactor default command #717

[geoknee]

Two main questions:

1. If we declare a chain as governed by optimism, but it actually isn't, how would we tell?

I am wondering if this change be accompanied by some edits to this validation check:

superchain-registry/validation/key-handover_test.go

Lines 12 to 32 in c56b992

	func testKeyHandover(t *testing.T, chain *ChainConfig) {
	chainID := chain.ChainID
	superchain := OPChains[chainID].Superchain
	rpcEndpoint := Superchains[superchain].Config.L1.PublicRPC
	require.NotEmpty(t, rpcEndpoint, "no rpc specified")
	client, err := ethclient.Dial(rpcEndpoint)
	require.NoErrorf(t, err, "could not dial rpc endpoint %s", rpcEndpoint)
	// L1 Proxy Admin
	checkResolutions(t, standard.Config.MultisigRoles[superchain].KeyHandover.L1.Universal, chainID, client)
	rpcEndpoint = OPChains[chainID].PublicRPC
	require.NotEmpty(t, rpcEndpoint, "no rpc specified")
	client, err = ethclient.Dial(rpcEndpoint)
	require.NoErrorf(t, err, "could not dial rpc endpoint %s", rpcEndpoint)
	// L2 Proxy Admin
	checkResolutions(t, standard.Config.MultisigRoles[superchain].KeyHandover.L2.Universal, chainID, client)
	}

EDIT: just spotted the other PR #719. I think it would make sense to commit the changes in a single PR, if possible.

2. When does this boolean get written / updated? During the add-chain tool? Manually? During promotion to a standard chain? Do we need to update the .env schema / add-chain tool at all?

[edobry]

we already have a "key handover test" and I would like to understand how this new test relates to that one.

My understanding is that the existing "key handover test" is intended only for standard chains, while the Governed by Optimism field is a bit more loose:

(Note that superchainLevel requires that chains both have their ProxyAdminOwner role set to the 2/2 and that the chain uses permissionless FPs, e.g., that the chain is on the latest gov-approved version. "Governed by Optimism" should refer only to the key handover status.)

source: #676

More context here

It may be possible that the correct path of action could be to reuse the key handover test for this purpose and instead add logic to also run it for chains that have governed_by_optimism: true set, I'm not really clear on this. Would welcome some guidance here @geoknee @tessr

[bitwiseguy]

Looks like you'll need to run just codegen locally to propagate any changes from chain config *.toml files to the summary files. Then when you push the edits to the summary files, the codegen ci check should pass

[tessr]

Just chiming in to confirm that this can be the same logic as the key handover test. We are functionally checking the same thing (whether the proxy admin owner is set to the correct address).

[edobry]

I've updated this PR with several changes:

1. restructured the validation/standard/*.toml files to improve DevX
2. added the negative test case suggested here
3. added standard configs for the sepolia-dev-0 chain to account for newly-failing tests caused by 2.

I explored whether we can reuse the Key_Handover test for this usecase but this doesn't seem possible, as it doesn't check the configured address directly but rather calls a contract method; I tested this by making changes in the config file which should've caused it to fail, but it didn't, not fully sure why. Please LMK if I've misunderstood something here.

cc @bitwiseguy

[bitwiseguy]

LGTM