A better UX about wallet management

[Osneue]

Component

Forge, Cast

Describe the feature you would like

Description

I import my private key (from Ganache local blockchain) by typing

cast wallet import gan-wall --interactive
Enter private key:
Enter password:
`gan-wall` keystore was saved successfully. Address: 0xdcc0ed94411272c1eb99067f34dfb0aefc511709

then I try to deploy my smart contract using script by typing

forge script script/DeploySimpleStorage.s.sol --rpc-url $GANACHE_RPC_URL --broadcast --account gan-wall

I got an error

Error:

You seem to be using Foundry's default sender. Be sure to set your own --sender.
No associated wallet for addresses: {0x1804c8ab1f12e6bbf3894d4083f33e07309d1f38}. Unlocked wallets: [0xdcc0ed94411272c1eb99067f34dfb0aefc511709]

I add --sender, and it works

forge script script/DeploySimpleStorage.s.sol --rpc-url $GANACHE_RPC_URL --broadcast --account gan-wall --sender 0xdCC0eD94411272c1eB99067F34dFb0AEfc511709

Expected Behavior

I think specifying --account should automatically select the corresponding address as the sender because technically --account is the replacement for --private-key, and when you use --private-key you don't have to explicitly specify --sender as it automatically defaults to it, same should be the case with --account.
-- from @usmanfarooq91

Additional context

• original discussion: [Lesson 6] A better UX about wallet management Cyfrin/foundry-full-course-cu#945 (comment)
• @PatrickAlphaC will be happy to sponsor this work.
• forge version: forge 0.2.0 (8c1a569 2023-09-19T00:25:23.149586075Z)
• cast version: cast 0.2.0 (8c1a569 2023-09-19T00:25:23.141846282Z)

[rplusq]

Happy to take on this one, as I already did the original work for cast wallet import

[Osneue]

@PatrickAlphaC Please provide further details regarding the sponsorship.

[rmcmk]

Happy to take on this one, as I already did the original work for cast wallet import

Also having this problem. Does not happen with forge create @rplusq

[klkvr]

It seems that nobody has took this yet because the spec is not quite clear.

The problem is that it is impossible to extract a wallet address from keystore without knowing the password. The same applies for all other wallet types except for private keys passed via CLI arg (for which auto-fetching of sender is already done)

Another reason why it is unclear how to fix that is because for Trezor, Ledger and AWS wallets we need a chain_id to be able to use wallet and fetch it's address. But, the chain_id might only be known when the script is ran and newly created fork is started via createFork cheatcode.

Thus, those concerns are rising two questions

1. Would we accept such relatively big change to user's UX as always prompting for passwords/private keys rather than only when --broadcast flag is on? We could make it easier to use by not auto-fetching wallet when --sender arg is provided, thus keeping backwards compatibility
2. Are we OK with still not supporting auto-fetching of sender address for some of the wallets (which require chain_id knowledge). Or maybe we could come up with some workaround for this? For example always using Ethereum chain_id to prefetch address initially.

I believe that nice support of keystores is a very important feature as in my opinion it is one of the best key management methods in terms of balance between convenience, availability and security (less secure than hardware wallets but much better than storing keys in .env)

@mattsse what do you think about this?

[rmcmk]

@klkvr From my team's perspective, both approaches seem workable.

Regarding option (1), if possible, introducing a flag such as --skip-pw that bypasses the password prompt when --broadcast isn't active could be a nice touch. This would help keep UX disruption minimal.

As for option (2), defaulting to Ethereum's chain_id to prefetch the --sender is a clever solution that stays clear of any ugly ambiguity that would only allow a subset of wallet types to utilize --sender prefetching.

[hiendaovinh]

I was very confusing for me at first when running the deploy command with/out "--broadcast".
In my opinion, the sender should be inferred the same way whether it's broadcast or not.