feat(cast) Generate a vanity CREATE2 contract address

[iFrostizz]

Motivation

This PR aims to implement https://github.com/foundry-rs/foundry/issues/2359

And it would extend into

• Adding the --create2 flag into the cast wallet vanity command
• Adding the vm.mineSalt cheatcode in order to call it as a cheatcode from solidity

Solution

cast

With the deployer address and the init code hash, we are brute forcing the hashing function until having a match, just like the vanity command, but this one works with CREATE for now.

forge-std

Adding the cheatcode in Test.sol and make it call the function described before and return the salt as explained in the issue.

Note

I haven't got any green flag from the team to implement this feature so please tell me if I can continue.

[tynes]

I feel like mineSalt could be a library that wraps cast with this functionality

[iFrostizz]

I feel like mineSalt could be a library that wraps cast with this functionality

You mean a library called cast wrapping mineSalt ? Why so ? All cheatcodes are in forge-std/Test.sol if I'm not mistaken

[onbjerg]

Just as a general thought I don't think this should be on cast wallet vanity since you're not creating a wallet, should probably just be its own thing although it seems @mds1 disagrees, don't have any strong opinion on this, it might just be a bit odd

I haven't got any green flag from the team to implement this feature so please tell me if I can continue.

Feel free, you don't need to be greenlit to contribute :) Assigned you to the issue, let us know if something blocks you

[iFrostizz]

True, what about calling it cast create2 ?

Also, I thought that it would be great to display a progress bar along with an estimated time remaining by calculating the average of generated addresses in the last 5 sec or so and comparing it to all the possibilities. Although I can already see an issue which is that it's just an estimate and even though it should tend to be accurate if the randomness is good, it would lead to weird UI stuff if the bar gets over 100% or hangs for a long period of time.

Anyway I think that it would be more communicative than just a text saying that a vanity address is being created.

What about multithreading also !

[iFrostizz]

I just noticed that mining a salt for a create2 address is like 10x faster than mining a private key wallet, though it shouldn't be that significant, right ? It looks like that the slowness is due to the wallet creation, what if we create a raw private key by deriving the random number into a private key, rather than instanciate the full wallet, or maybe do it at the end only ?

[iFrostizz]

franfran@franfran:~$ cast create2 --deployer 0x1F2C452e6d63664bb6c602FAdA3c5501A2f44A6f --init-code 0x --starts-with dead
Starting to generate deterministic contract address...
Successfully found contract address in 0 seconds.
Address: 0xDeaD862e91B43c7e55eAfB20B696BEB72871691B
Salt: 16157366503150255834

Blazingly fast !

[mds1]

should probably just be its own thing although it seems @mds1 disagrees, don't have any strong opinion on this, it might just be a bit odd

Sorry missed this, but I'm totally ok with it being a separate command (as it currently is), I think that makes sense!

[iFrostizz]

I have a question regarding the --matching flag. If implemented, should we forget the --starts-with and --ends-with flags ? If so, we would need to validate the data by ensuring that matching hasn't been mentionned if either starts or ends flag have been used. I believe that starts and ends are more handy to type on the command line, whereas matching is more suited in the solidity code.

[iFrostizz]

as @gakonst stated, we'll use a cheatcode. Making it rn, but I cannot import foundry_cli as it's making a circular dependency because of cast which imports evm. The reason I wanna do that is because the create2 address generation is in cli and well I cannot import it because of that. Is there a simple fix for this circular dependency, like having to change a bit the tree of modules or should I copy and paste the function in the cheatcodes file ? (not what we want IMO)

[gakonst]

because the create2 address generation is in cli and well I cannot import it because of that.

I'd refactor this to the foundry-common crate and import it from there!

[iFrostizz]

because the create2 address generation is in cli and well I cannot import it because of that.

I'd refactor this to the foundry-common crate and import it from there!

Thanks for the advice boss :)

[iFrostizz]

because the create2 address generation is in cli and well I cannot import it because of that.

I'd refactor this to the foundry-common crate and import it from there!

Huh, importing cast from froundry-common also creates a dependency cycle

[joshieDo]

Should we make the forge's default CREATE2 deployer, the default address for --deployer ? I think it makes sense

[mds1]

Ah nice, yea I like that idea

[iFrostizz]

I've been struggling to find a valid refactor in order to implement the cheatcode here. What about merging the PR only with the cast create2 feature after that I've added the @joshieDo idea, just in case that might need a bigger refactor ?

[iFrostizz]

is it fine now ?

[sambacha]

Is this safe to use?

[iFrostizz]

Is this safe to use?

If you compare it to profanity recent issues well yes, the randomly generated number is not critical because salt is public. Even cast wallet which uses the same uses a "safe" random generator

[iFrostizz]

I have just pushed the last fix on my branch. Can we open this PR again please ?