On Handling the L2 Proxy Admin Owner

[tynes]

The goal is to remove all network specific configuration from the L2 genesis state so that there is a deterministic L2 genesis for all chains. This enables the authentication of a standard L2 chain by simply referencing the root hash. Each release of the L2 contracts would correspond to a hardfork. The network specific configuration would be pushed via deposit transactions to the L2 as the first transactions that the system processes via deposit transactions that are sent via SystemConfig.initialize. All of the getters for this configuration would be fetched from the L1Block contract. This follows the same design pattern for the L1 contracts where all immutables were removed in favor of storage so that the same contract implementations could be used by multiple chains.

There is an open question on how to handle the L2 ProxyAdmin owner. Right now, a standard stage 1 OP Stack chain should set the L2 ProxyAdmin owner to be the aliased account of the L1 security council/foundation multisig.

The following options explore the design spaces.

SystemConfig can set owner

This would follow the same pattern for all other network specific config, the SystemConfig would be able to deposit and set the owner in the L1Block contract. This would essentially mix roles in some cases unless we had more expressive RBAC in the SystemConfig as it would mix the security council and the chain operator in both having the ability to change the owner, since you can change the owner by calling transferOwner on the ProxyAdmin or have the owner of the SystemConfig initiate a deposit transaction that modifies the ownership. The way to solve this is only allow setting this value by the SystemConfig if the initial owner is address(0), and then only the existing owner would be able to modify the value in the L1Block contract.

Depositor Account is owner

Enshrine a new call path that emits a TransactionDeposited event in the OptimismPortal from the DEPOSITOR_ACCOUNT that calls the ProxyAdmin. The caller of this function could be fetched from the SuperchainConfig, allowing a single source of truth to be defined for which account can create an L2 ProxyAdmin action. This is a nice design because it enables both the protocol and the security council to take action on behalf of the L2 ProxyAdmin. Longer term we may want to remove this function as the OP Stack matures and only let the protocol act on behalf of the ProxyAdmin

[mds1]

Spoke with @tynes about this and we agreed that the "Depositor Account is owner" is our preferred approach. This lets us have a typical path of upgrading predeploys via hard fork, but also provides deposit transaction upgrade if needed (e.g. for incident response)