🐛 No Way to Avoid Salt Being Re-Hashed about createx

[pcaversaccio]

@Philogy this is a feature and not a bug. That's our design to implement safely a permissioned deploy protection and cross-chain redeploy protection (see here). The only way to not double hash the salt is by generating it pseudo-randomly by CreateX. We built on purpose our own cruncher createXcrunch to accommodate for these features, where you not only can mine for leading zeros, or containing zeros, but also pattern-matching addresses. If you don't like it, fair, I can offer my predecessor of CreateX, called Create2Deployer (that one is added as a predeploy in the OP stack fyi).

[Philogy]

I understand. I'm just wondering why you couldn't have had all these features without having to rehash the salt, what additional security does it provide?

[pcaversaccio]

I understand. I'm just wondering why you couldn't have had all these features without having to rehash the salt, what additional security does it provide?

I'm not sure I fully understand your question. We need to have a bytes32 salt, depending on whether you want different protections (as elaborated in the section I linked above), you need to transform the salt and the additional attributes msg.sender and/or block.chainid into another (pseudorandom) bytes32 salt value. And that's why we use keccak256.

For the non-pseudo-random cases here, the salt value salt is hashed as part of the _guard function to prevent the safeguard mechanisms from being bypassed. The reason is that if someone deploys on chain A with a preconfigured mechanism, anyone can calculate the inferred guardedSalt and reuse it on chain B otherwise (if we wouldn't hash it).

[Philogy]

Yeah specifically in the last case, not sure I fully understand the purpose of doing keccak256(abi.encode(salt)). What safety feature are you hoping people won't bypass?

The pre-image is still public and anyone else can still redeploy on other chains using the un-hashed salt by running it through the function themselves, I just don't understand this part, what's the value of the extra hash?

[pcaversaccio]

Yeah specifically in the last case, not sure I fully understand the purpose of doing keccak256(abi.encode(salt)). What safety feature are you hoping people won't bypass?

So let's make an example:

• On chain A I deploy a contract using a permissioned deploy protection. This will give me the final salt:

guardedSalt = _efficientHash({a: bytes32(uint256(uint160(msg.sender))), b: salt});

• Someone else sees this deployment, and can calculate the guardedSalt (or simply copy it from a transaction debugger). This person deploys on chain B the same initcode with the guardedSalt as input. Since the msg.sender doesn't match in the if else statement in the function _guard, the code would lead him to the final else statement. If we didn't hash here the salt, he would be able to deploy the same initcode from his address even though the original deployment configured a permissioned deploy protection (i.e. it's only me who can deploy it). Does this make sense?