Automate the process of passing the create2Salt

[andreivladbrg]

The current version of the deterministic deployment scripts requires manually passing the create2Salt which is a slow procces and prone to errors:

v2-core/script/DeployDeterministicCore.s.sol

Lines 22 to 43 in 7819a3b

	function run(
	string memory create2Salt,
	address initialAdmin,
	uint256 maxSegmentCount
	)
	public
	virtual
	broadcast
	returns (
	SablierV2Comptroller comptroller,
	SablierV2LockupDynamic lockupDynamic,
	SablierV2LockupLinear lockupLinear,
	SablierV2NFTDescriptor nftDescriptor
	)
	{
	bytes32 salt = bytes32(abi.encodePacked(create2Salt));
	comptroller = new SablierV2Comptroller{ salt: salt }(initialAdmin);
	nftDescriptor = new SablierV2NFTDescriptor{ salt: salt }();
	lockupDynamic =
	new SablierV2LockupDynamic{ salt: salt }(initialAdmin, comptroller, nftDescriptor, maxSegmentCount);
	lockupLinear = new SablierV2LockupLinear{ salt: salt }(initialAdmin, comptroller, nftDescriptor);
	}

To automate this process, I've developed a utility that builds the salt using the ffi cheatcode, which allows you to execute an arbitrary shell command and capture the output:

string memory chainId = block.chainid.toString();
string[] memory inputs = new string[](4);
inputs[0] = "jq";
inputs[1] = "-r";
inputs[2] = ".version";
inputs[3] = "./package.json";
bytes memory result = vm.ffi(inputs);
string memory version = string(result);
string memory create2Salt = string.concat("ChainID ", chainId, ", Version ", version);

Note: it would require to import and use a library to convert uint256 to string

I've personally tested this and it works. https://app.warp.dev/block/5564ry0K2Lxbq9seHWJKsx

The most appropriate place to implement this is in a function named getCreate2Salt within Base_Script.

wdyt @PaulRBerg @smol-ninja ?
I believe you are going to like it 😁

[smol-ninja]

Nice! I love your approach of ffi. However, comparing with the current implementation, I do not completely agree with the statement:

manually passing the create2Salt which is a slow process and prone to errors

While it might have been prone to errors in the past, we've since resolved those issues. Right now, it simply involves passing the version ID (manually), albeit at a slightly slower pace compared to utilizing ffi.

Additionally, what if, in the future, we consider to change to the salt structure? My interpretation is that a salt is intended to be a source of external randomness. As such, I still think we should keep it outside the foundry to maintain flexibility in case any adjustments are needed down the line.

[andreivladbrg]

While it might have been prone to errors in the past

it still is

it simply involves passing the version ID (manually)

doing something manually ⇒ prone to errors

also, we would not even need to declare manually the chain ids

[smol-ninja]

we would not even need to declare manually the chain ids

That's a good point. Less number of lines in the bash script ftw 🎉.

doing something manually ⇒ prone to errors

OK, but any additions to the .env.deployment also involve manual intervention. We can also extract version from package.json in the bash script itself. But I agree that it would still require us to have chain id manually added in the script which is an advantage that ffi has.

[PaulRBerg]

we've since resolved those issues. Right now, it simply involves passing the version ID (manually)

Only if using the deploy-multi-chain script.

My interpretation is that a salt is intended to be a source of external randomness

Quite the opposite - we use it to provide deterministic differentiation.

in case any adjustments are needed down the line

For rapid deployments, we can use the non-deterministic deployment scripts.

[smol-ninja]

Agree to all your points.

[PaulRBerg]

I like the proposal a lot, @andreivladbrg. Feel free to go ahead with implementing it.