4

I was looking at Optionality's clone-factory, which is based off EIP-1167, and wondering whether it can be ported to use CREATE2.

One concern is that a third-party could, in theory, "front-run" the deployment tx and deploy another contract with the user's salt, initialise it with their own constructor arguments and so on.

How can we mitigate this?

I thought about hashing the tx.origin with the user-provided salt, and passing the resultant hash as the salt to CREATE2. This way, clients can deterministically compute the contract address off-chain, and the deployment tx is not front-runnable, because tx.origin cannot be impersonated.

Would that suffice?

Paul Razvan Berg
  • 17,902
  • 6
  • 73
  • 143

3 Answers3

4

This is not really a concern because CREATE2 generates the deployment address based on a hash of the contracts creation code plus the abi encoded constructor parameters

Therefore a specific salt, combined with the creation code and constructor parameters for a contract, will always yield the same address (and the same identical deployed contract) regardless of who deploys it, and when.

Therefore 'front-running' isn't an issue because even if someone did front-run it would yield the exact same result as if you deployed the contract yourself.

If they choose different constructor arguments then their contract will be deployed to a totally different address.

See discussion here for more details:

https://github.com/ethereum/solidity/issues/13521

Shebla Tsama
  • 195
  • 7
  • The creation code contains the init code, runtime code and the constructor parameters. Check here https://betterprogramming.pub/solidity-tutorial-all-about-code-10889b88632f#c68c – Marc Loeb Jul 21 '23 at 16:12
1

This sounds like it would work.

However, CREATE2 naturally provides a fun and recommended remedy to this issue: The user can initialize the contract before it's created.

zeroknowledgetruth
  • 36
  • 1
  • Hi, thanks for chiming in. I suppose that by "this", you mean by idea to use the hash of tx.origin? If yes, could you explain how the "remedy" works, in more detail? – Paul Razvan Berg Aug 11 '22 at 06:48
  • As it’s currently written, your answer is unclear. Please [edit] to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center. – Community Aug 12 '22 at 11:28
0

You can prevent frontrunning using 0age's CREATE2 deployer. For details, see https://goerli.etherscan.io/address/0x179c98f5ccdb3bc7d7aefffa06fb7f608a301877#code

That said, CREATE2 frontrunning is a non-issue unless the contract being deployed is using tx.origin in the constructor. (Doing that would be weird and probably bad anyway.)

Everything else--msg.sender (= the CREATE2 deployer contract), constructor args, code--is guaranteed identical regardless of who sends the deploy transaction.

I guess there is a minor cosmetic reason, if you want to ensure the "deployer" displayed in Etherscan is your own. Even this is a theoretical concern; given the above, there is no incentive for anyone to frontrun your CREATE2 deployment, they are just paying gas on your behalf.

If anyone knows a real-world instance of CREATE2 frontrunning, I'd be interested to see it.

dcposch
  • 1