EIP-7620: EOF - Contract Creation Instructions

EIPs EIPs core
, , ,
8

Ahh, TXCREATE solves that problem pretty neatly. I hope it goes in at the same time as the rest of EOF to enable that use case. To explain in more detail my specific use case, I have 2 considerations:

  1. How do we permissionlessly, trustlessly deploy the same contract to the same address on all chains? CREATE2 and EOFCREATE obviously enable trustlessness by deriving the contract address from the hash of the initcode. However, permissionlessness is more difficult. Using TXCREATE in combination with Nick’s method for deployment gives us permissionlessness. We can imagine an EOF replacement for the Arachnid deterministic deployment proxy that uses TXCREATE instead of CALLDATACOPY ... CREATE2 to obtain the same effect.

In my specific use case, I rely on the Safe{Wallet}'s stack, which in turn depends on a CREATE2 factory toehold contract. This toehold contract can be either the Arachnid deterministic deployment proxy (permissionless, somewhat more fragile) or the Safe singleton factory (not permissionless, but more robust). I’ve been bitten by the lack of permissionlessness in the Safe singleton factory, which is why I care about using Nick’s method in combination with TXCREATE. Of course, on chains with extreme gas rules (e.g. Mantle), this isn’t foolproof, but we’re not letting perfect be the enemy of good.

  1. How do we factory-deploy user-supplied initcode to an address NOT derived from the hash of that initcode? Basically, how can we “CREATE3” from calldata? This is halfway satisfied by TXCREATE, but we would still need a non-salted contract creation opcode to make it work without doing something really crazy. TXCREATE solves the problem of being able to factory-deploy from initcode not known to the factory at deploy-time, but the problem of non-salted deployment (i.e. CREATE; deployee addresses derived from the deployer address and its nonce) remains unsolved.

This pertains to the Deployer contract for 0x’s DEX aggregation router. This router contract is iterated rapidly to accommodate the shifting liquidity landscape; each iteration requires redeployment. This Deployer factory contract uses a “CREATE3” pattern to deploy the router to an address derived only from a feature identifier (there’s more than 1 router, each with a different feature set) and a nonce specific to that feature identifier. This lets 0x’s integrators precompute future router contract addresses for their own on-chain properties. Obviously, even though the router is trust-minimized, deployment is permissioned. I can sort of vaguely imagine a solution involving the abuse of ecrecover to compute addresses based on a feature++nonce and a secp256k1 pubkey and then deriving the deployed contract from that. That would also sacrifice a degree of trustlessness, unless you want to throw some MPC into the mix, which is not very satisfactory.

1 Like