Support EIP-7702 Delegations in Forge

[evchip]

Motivation

Adds initial support for EIP-7702 transaction delegation in Forge scripts.

Addresses #7128

Solution

• adds EIP-7702 support to forge scripts for transaction batching + delegation.
• new cheatcodes:

createDelegation: generates auth hash
signDelegation: signs auth with pk
attachDelegation: connects signed delegation to sender

Limitations:

• clunky sig handling - requires passing v,r,s separately bc passing raw sig bytes breaks tests
• only supports raw private keys, needs hardware wallet etc support

Questions:

1. best way to propagate delegation state from cheatcodes -> broadcast?
2. should we track delegations in ScriptSequence instead of ScriptResult?

looking for feedback on state handling and current api limitations before expanding functionality.

[klkvr]

I believe delegations would be attached to separate transactions vs broadcast blocks, so it would be something like

vm.startBroadcast();
vm.attachDelegation(implementation, nonce, v, r, s);
// this transactions would be broadcasted along with attached 7702 delegation
token.transfer(....);

[evchip]

thanks for the comment! looking at this closer - since 7702 makes the EOA itself the target of the tx, i think we need to route all calls through the EOA first.

right now we can do this with a raw call:

vm.startBroadcast();
vm.attachDelegation(implementation, nonce, v, r, s);
alice.call(abi.encodeCall(implementation.execute, (calls)));

but for better UX, maybe we could either:

1. change attachDelegation to take authority instead of implementation (since we have the implementation in the call itself):

vm.attachDelegation(alice, nonce, v, r, s);
implementation.execute(calls);

2. or add a helper like:

vm.delegatedCall(alice, implementation.execute, calls);

what do you think would be more ergonomic for users?

[klkvr]

best way to propagate delegation state from cheatcodes -> broadcast?

We should attach them to TransactionRequest here:

foundry/crates/cheatcodes/src/inspector.rs

Lines 1004 to 1016 in 17e0981

	self.broadcastable_transactions.push_back(BroadcastableTransaction {
	rpc: ecx.db.active_fork_url(),
	transaction: TransactionRequest {
	from: Some(broadcast.new_origin),
	to: Some(TxKind::from(Some(call.target_address))),
	value: call.transfer_value(),
	input: TransactionInput::new(call.input.clone()),
	nonce: Some(account.info.nonce),
	gas: if is_fixed_gas_limit { Some(call.gas_limit) } else { None },
	..Default::default()
	}
	.into(),
	});

should we track delegations in ScriptSequence instead of ScriptResult?

I think we need to track them in both. In ScriptResult as part of BroadcastableTransactions and in ScriptSequence as TransactionWithMetadata

[evchip]

@klkvr thanks for the detailed feedback! Will push an update soon that addresses your comments.

[evchip]

@klkvr thanks for the pointer on TransactionRequest. i've added the authorization_list field and i'm constructing 7702 txs (type=0x04) when that field is populated. however, the delegated calls don't seem to be executing properly - i suspect we also need to write the delegation designation (0xef0100 || address) to the EOA's code somewhere.

looking at the anvil tests, it seems revm supports 7702, but i'm not clear on where in foundry we should be handling the delegation setup. any guidance? thanks in advance.

[klkvr]

@klkvr thanks for the pointer on TransactionRequest. i've added the authorization_list field and i'm constructing 7702 txs (type=0x04) when that field is populated. however, the delegated calls don't seem to be executing properly - i suspect we also need to write the delegation designation (0xef0100 || address) to the EOA's code somewhere.

looking at the anvil tests, it seems revm supports 7702, but i'm not clear on where in foundry we should be handling the delegation setup. any guidance? thanks in advance.

right, we need to execute something similar to this https://github.com/bluealloy/revm/blob/346aa01398aa9b4e4e36776c21f6fe7169ed5d87/crates/revm/src/handler/mainnet/pre_execution.rs#L102 in call hook where we push to broadcastable_transactions

we can probably skip some of the steps as we will anyway execute this later during on-chain simulation, but I think nonce check and increase should be kept because those may affect contract deployment addresses

also we'll need to respect the authorization list here

foundry/crates/script/src/simulate.rs

Line 120 in d2ed15d

let result = runner

when configuring TxEnv for simulation, this might require small changes to executor

[klkvr]

let's remove authority argument from here. it's redundant as we are always recovering it from signature

also wdyt on adding signAndAttach method? I think common flow would be calling both of the cheatcodes

[evchip]

I'm not seeing how to construct the authorization without the authority's nonce, which we'd need to recover the authority from the signature. Can you clarify the flow you're thinking of?

[klkvr]

we can get the nonce from state

[evchip]

Right, but to get the nonce from state we need the authority's address to load their account - am I missing some other way to get their nonce?

[klkvr]

in signDelegation we can get authority address from private key, then get nonce, construct and sign delegation

and in attachDelegation we can just recover authority from the signed delegation. right now the passed authority address is anyway expected to be the same as recovered one making it redundant

[klkvr]

ah I see what you mean. didn't notice that attachDelegation doesn't accept nonce

let's make signDelegation return a new struct SignedDelegation which will contain v,r,s,nonce,implementation. And then attachDelegation would just accept this object

[evchip]

I've implemented a new cheatcode signAndAttachDelegation and refactored the existing cheatcodes to use struct SignedDelegation. Let me know what you think. Thanks!

[klkvr]

nice, lgtm!

[zerosnacks]

Thanks @evchip! Implementation looks good to me

[yash-atreya]

Can be merged @grandizzy