feat(cheatcodes): allow forge script to access wallet addresses with vm.getScriptWallets()

[superical]

Component

Forge

Describe the feature you would like

To have a feature where we can access in our foundry scripts the private keys input from --interactives mode or the resolved public addresses of those private keys. This way, we don't have to repeat the sender address in the --sender because we can decide which private keys to use as the sender and pass the intended address as the sender in vm.startBroadcast(sender).

For example:

uint256[] privateKeys = vm.interactives();
// Or, an optional index parameter to get from the list of input private keys
// uint256 privateKey = vm.interactives(0);   // gets the first private key entered from interactive mode

address sender = vm.addr(privateKeys[0]);

vm.startBroadcast(sender);
// ...
vm.stopBroadcast();

Additional context

Currently, when forge is run with --interactives, it doesn't seem like there is a way to access the private keys or the public addresses of those private keys provided through the interactive input in the foundry scripts. The only way (as far as I have tried) to run the foundry scripts with --interactives is:

• Provide the address of the private key through --sender on top of --interactives
• AND only use vm.startBroadcast(). I cannot use vm.startBroadcast(sender) since I cannot access the private key supplied through the interactive input and so I won't know the sender address.

Supplying the public address through --sender feels repeated because the address should already be resolvable from the private key.

Moreover, the --interactives parameter can accept more than one private keys which seems to suggest a script should be able to select one of the keys supplied to be the actual sender.

If there is a feature where we can access the input private keys or their translated public addresses in our foundry scripts, we wouldn't have to repeat the address in the --sender because our foundry script can decide which private key to use as sender and pass the correct address as the sender in vm.startBroadcast(sender).

[klkvr]

This should be very easy to implement with new ScriptWallets struct from #7141. We can add something like vm.getScriptWallets() returning all unlocked keys/keystores/hw wallet addresses.

We'd have to decide what the behavior of this cheat would be in scope of tests, afaik we don't have any script-only cheats rn.

And we can't really give any guarantees on the order in which senders will be returned. We can probably keep ordering for interactive keys being entered, but if script is ran with ledger + 1 interactive key, it's unclear how this should be handled.

cc @mattsse @Evalir @mds1

[mds1]

Can vm.getScriptWallets() could return an array of Wallet structs in scripts and tests? This way you can write tests for your scripts and do something like forge test script/MyScript.s.sol --private-key $DUMMY_PRIVATE_KEY to test your scripts

[klkvr]

We can't always get a private/public key for script wallets as such info is not available for hw wallets

[klkvr]

This should be solvable with pattern similar to the one discussed in #7012 (comment)

That way, the script will look like

contract Script {
    function run() public {
        address[] memory wallets = vm.getScriptWallets();
        // logic to determine which wallets to use for broadcasting
        run(wallet1, wallet2);
    }

    function run(address broadcaster1, address broadcaster2) public {
        // actual logic
    }
}

do something like forge test script/MyScript.s.sol --private-key $DUMMY_PRIVATE_KEY to test your

this is similar to dry-running a script I believe

Probably more often it's useful do determine broadcaster at runtime when testing script, by calling .owner() on some contract for example

[grandizzy]

going to close in favor of #8225 and track impl there