Enshrine new convention for Network Upgrade Transactions which deploy new contracts

[geoknee]

Currently, for transactions such as these (example https://specs.optimism.io/protocol/isthmus/derivation.html#l1block-deployment) we choose the from address to be a unique account which has nonce=0. The choice of from affects the deployment address of the contract. Using a fresh account means we can safely set nonce:0 in the upgrade transaction.

That unique account tends to be chosen in the 0x421... namespace. Choosing it correctly involves checking the entire spec history to ensure we aren't reusing an address. This is error prone, particularly when forks get reordered.

A better pattern is

take the first 20 bytes of the source hash as sender address. That way you have a guaranteed unique deployer address, and thus nonce 0, and thus a unique and deterministic deployed contract address. Without making it coupled to bytecode, so the proxy upgrade tx input stays stable on dev changes

h/t to @protolambda for this idea.

The source hash is defined here https://specs.optimism.io/protocol/deposits.html#source-hash-computation

Note: the idea of using a CREATE2 type deployment was considered, but discarded in favour of the above approach (in particular it would couple the deployment address and tx input to the contract bytecode, which is undesirable).

[protolambda]

Note on address collision resistance of the suggestion:

• CREATE addresses are computed as: keccak256(rlp([sender, nonce])) (the RLP never starts with many zeroes, and certain ranges of bytes, alike to legacy-tx-typing)
• CREATE2 addresses are computed as: keccak256( 0xff ++ address ++ salt ++ keccak256(init_code))[12:] (the 0xff separates it from the RLP)
• upgrade source-hashes are computed as: keccak256(bytes32(uint256(2)), keccak256(intent)) (and I assume the sourceHash[12:] as address here)

So the start of the keccak preimage always differs (non-zero RLP byte in legacy create case, 0xff in eth create2 case, 0x000...002 in this update case) and so there are no possible address collisions.

If we want to be extra-safe, we could use the CREATE2 computation, set the deployer address to a system-address, and the source-hash as salt. Then it fits in the existing address computation framework, and won't collide in the future in unexpected ways, and users are stopped from colliding with it by using an inaccessible system address as create2-deployer.