Superchain Config for Addresses

[ElliotFriedman]

Create a new superchain address object that tasks that are not chain specific can use. This will mean AddressRegistry will need to have an alternate key it tries to parse from the config.toml file

Conversation is here: #624 (comment)

Investigate tradeoffs and downstream effects of this configuration addition, specifically in regards to which chain id to pass and how to discover and save addresses in AddressRegistry.

What new considerations might this create for task developers?

[ElliotFriedman]

I'm running into a wall here trying to think through this superchainConfig toml file object and what it means for the AddressRegistry contract.

Everything in MultisigTask relies on the getChains function in AddressRegistry, which returns an array of l2 chains that particular AddressRegistry contract supports.

Everything in the AddressRegistry contract relies on the extra l2 chainId being passed to getAddress, and AddressRegistry requires the l2chainid array to know which contract addresses to read in from the superchain-registry.

The question this leads me to:

If the superchainConfig object looks like this:

superchainConfig = {name = "Eth Mainnet", chainId = 1}

Should the AddressRegistry contract then add the optimism chainId to its l2chains array so it loads up the addresses associated with what I would think goes with mainnet?

Everything in the MultisigTask contract relies on the l2chains array being populated in the _taskSetup function.

The safeAddressString and _taskStorageWrites functions return a single string aliases or an array of string aliases which the AddressRegistry should have loaded up. In the loop in _taskSetup to load up the allowed storage accesses, the l2chainid is needed to retrieve the address. The l2chainid is also needed in _taskSetup to fetch the multisig address from AddressRegistry.

Trying to break outside of this existing structure creates problems.