Configuration design for un-named networks

[trianglesphere]

There are roughly two ways networks are configured.

1. Using --network=... flag which specifies the network (& where the network is baked into the source code)
2. Using a rollup.json and params.ChainConfig to define the network for networks which are not baked into the source code.

Right now, the superchain registry is where configuration for named networks lives & is shared between op-node and op-geth.

There is not a great solution for un-named networks. The op-node can require a rollup.json which should be updated with the latest forks, but configuring op-geth is trickier. The initial chain config is set at genesis with geth init, but is tricky to update. There are override flags, but their purpose is to move the date of a hard fork without having to re-release or recompile software.

The current best flow for updating config in non-named networks for op-geth is as follows:

1. When setting a network upgrade, modify the genesis.json to include the new chain config
2. For existing nodes, have an override value for every single option (& these must be set on every single node)

I'm thinking about requiring either a --chain_config=cfg.json or --op-network=... flag in op-geth. The config flag's shape is very much rough & we'd have to flesh out what goes into it.

Now, the new flow for updating op-geth with new forks mirrors op-node (side note we may want to change op-node to require either the --network= or --rollup= flag).

The remaining question is about what the role of the deploy config (which has parameters that overlap with rollup.json and params.ChainConfig).

I'm looking for feedback on this design & to see if it adequately addresses the needs for configuring un-named networks.

[kahuang]

I think the file approach seems cleanest to me vs needing to mess with genesis jsons!