Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: vm.sign for scripts #7454

Merged
merged 5 commits into from
Mar 28, 2024
Merged

Conversation

klkvr
Copy link
Member

@klkvr klkvr commented Mar 19, 2024

Motivation

Closes #7446

Solution

Adds vm.sign(bytes32 digest) determining signer in a similar way vm.broadcast() and vm.startBroadcast() do.
Adds vm.sign(address signer, bytes32 digest) similar to vm.broadcast(address)

Also added more docs to explain the way we choose signer for vm.broadcast() and it seems pretty complicated tbh. Afaik we still don't even have a reliable way to fetch signer address besides vm.broadcast() -> vm.readCallers(), perhaps we should reconsider and document that?

Also those cheatcodes are not compatible with tests right now. We can probably allow that by running tests with empty ScriptWallets. That way tests will be able to inject private keys via vm.rememberKey

Copy link
Member

@onbjerg onbjerg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

let r = B256::from(sig.r.to_alloy());
let s = B256::from(sig.s.to_alloy());

Ok((v, r, s).abi_encode())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we synchronize the v,r,s encoding?

let recovered = sig.recover(digest.to_ethers()).map_err(|err| fmt_err!("{err}"))?;
assert_eq!(recovered.to_alloy(), signer);

let v = U256::from(sig.v);
Copy link
Member

@DaniPopes DaniPopes Mar 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should v be like above? sig.v().y_parity_byte_non_eip155...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this sig is still from ethers and we've just returned a sig.v earlier

https://github.com/foundry-rs/foundry/blame/ae0ef191bb9fe144af6736bf56a4fa25f781d39a/crates/cheatcodes/src/utils.rs#L172

Looking at sig.v().y_parity_byte_non_eip155().unwrap_or(sig.v().y_parity_byte() I am wondering if this is correct actually

Isn't ecrecover expects v to be 27 or 28? and here we might end up with 0 or 1

signer: Option<Address>,
digest: &B256,
) -> Result {
if let Some(script_wallets) = &ccx.state.script_wallets {
Copy link
Member

@DaniPopes DaniPopes Mar 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let Some() = ... else { return Err() } or .as_ref().ok_or("")?

///
/// Raises error if none of the signers passed into the script have provided address.
#[cheatcode(group = Evm, safety = Safe)]
function sign(address signer, bytes32 digest) external pure returns (uint8 v, bytes32 r, bytes32 s);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we also have sign(string) for EIP-712-prefixed messages? (not for this pr necessarily)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you mean bindings for Signer::sign_typed_data and Signer::sign_message?

Copy link
Member

@DaniPopes DaniPopes Mar 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, message seems more doable than typed data

Copy link
Member

@mattsse mattsse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm
pending conflicts

Copy link
Member

@DaniPopes DaniPopes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Feel free to merge whenever

@mattsse mattsse merged commit 345d000 into foundry-rs:master Mar 28, 2024
19 checks passed
ZhangZhuoSJTU pushed a commit to MEDGA-eth/foundry that referenced this pull request Mar 29, 2024
* feat: vm.sign for script wallets

* more tests

* clippy

* if let some else

* review fixes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support keystores in vm.sign
4 participants