Deploy create2deployer in the next hardfork

[mdehoog]

Description

The pcaversaccio/create2deployer helper is not able to be deployed to Base mainnet due to a nonce-increment from a deposit tx to the deployer address (see pcaversaccio/create2deployer#128).

In the discussion in pcaversaccio/create2deployer#129 it was suggested that we could deploy this in the next op-stack hard fork. This PR implements this deployment, using a stateDb.setCode call.

The code can be verified here.

Tests

• TODO test E2E (will keep in draft for now)

[trianglesphere]

Do we want this to apply to base mainnet or all chains? I lean to just base because other deployed chains should already have this. For new chains, we're looking at options to reduce this footgun.

[trianglesphere]

I'm just confirming that you want the bytecode from create2Deployer at 0xF49600926c7109BD66Ab97a2c036bf696e58Dbc2. I looked at some of the xdeployer byte code (0x13b0D85CcB8bf860b6b79AF3029fCA081AE9beF2), and the xdeployer bytecode does not match, but it also varies across chains.

[mdehoog]

@trianglesphere thanks for checking. The primary reason for the bytecode difference is the removal of the Ownable and Pausable interfaces removed, see this comment for more context: pcaversaccio/create2deployer#129 (comment)

An alternative would be to keep the same bytecode and leave the owner set to 0x0, which is functionally equivalent. Happy with either option.

[trianglesphere]

@mdehoog I'm fine with it as long as you are & there's a good reason behind it.

[pcw109550]

@mdehoog May I ask we do not have to initialize the storage of create2deployer predeploy? This is because we are using the version which Ownable, Pausable removed(ref: pcaversaccio/create2deployer#129 (comment)) so storage is not used, right?

[trianglesphere]

@pcw109550 that is correct. The deployed contract does not touch any storage.