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?

3 Answers 3

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

1
  • The creation code contains the init code, runtime code and the constructor parameters. Check here betterprogramming.pub/…
    – Marc Loeb
    Commented Jul 21, 2023 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.

2
  • 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? Commented Aug 11, 2022 at 6: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 Bot
    Commented Aug 12, 2022 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.