feat(cheatcodes): support access lists and storage slot state manipulation

[0xDiscotech]

Describe the feature you would like:

I propose adding the following cheatcodes to Foundry to facilitate accurate testing of contracts that utilize access lists and logic related to cold or warm storage slots:

• vm.accessList: Enables the inclusion of access lists in subsequent test calls, facilitating accurate testing of contracts utilizing EIP-2930 access lists.

• vm.makeStorageWarm: Marks a specific storage slot as warm, simulating a prior read.

• vm.makeStorageCold: Marks a specific storage slot as cold, simulating no prior read.

Motivation:

Currently, Foundry lacks support for specifying access lists and manipulating storage slot states for testing purposes. This limitation makes it challenging to thoroughly test contract functionalities involving access lists and storage slot access patterns, often requiring complex workarounds that can compromise test quality.

Additional context:

• EIP-2930: Optional access lists

• Example of a project currently adding access list functionalities to its codebase:

  • Optimism access list logic on smart contracts

  • Optimism Design Docs: Add interop access list

  • Optimism Specs: Interop access-list spec and RPC

[grandizzy]

hey @0xDiscotech so for making storage slots cold / warm is pretty straightforward, to be inline with the other cheatcodes I propose following sigs (have an impl for it in #10112)

    /// Utility cheatcode to mark specific storage slot as warm, simulating a prior read.
    function warm(address target, bytes32 slot) external;

    /// Utility cheatcode to mark specific storage slot as cold,  simulating no prior read.
    function cold(address target, bytes32 slot) external;

could you please expand on how the vm.accessList should look like (should be applied for specific target, for all subsequent calls, etc., providing a sig should help too)
Thank you!

[0xDiscotech]

Hey @grandizzy! The warm and cold cheatcodes look really good! We'll be able to write cleaner tests with them.

Regarding the accessList functionality, I'll suggest implementing both approaches:

• vm.accessList: Applies the specified access list to the next call only.​
• vm.startPrank(accessList): Applies the specified access list to all calls made during the prank session— This would be more a NIT since it sounds more complex, and a workaround using the previous one could be enough.

Those cheatcodes would be very useful for E2E or integration tests.

What do you think?

[grandizzy]

I think this makes sense, I'd suggest though an vm.accessList to be applied for all txes since cheatcode called and a vm.noAccessList to remove its effect

[0xDiscotech]

I really like that approach 👍

[clabby]

Doesn't foundry already support a cheatcode for making slots cold again?

foundry/crates/cheatcodes/src/evm.rs

Lines 577 to 586 in f12f8a2

	impl Cheatcode for coolCall {
	fn apply_stateful(&self, ccx: &mut CheatsCtxt) -> Result {
	let Self { target } = self;
	if let Some(account) = ccx.ecx.journaled_state.state.get_mut(target) {
	account.unmark_touch();
	account.storage.clear();
	}
	Ok(Default::default())
	}
	}

[grandizzy]

Doesn't foundry already support a cheatcode for making slots cold again?

foundry/crates/cheatcodes/src/evm.rs

Lines 577 to 586 in f12f8a2

impl Cheatcode for coolCall {
fn apply_stateful(&self, ccx: &mut CheatsCtxt) -> Result {
let Self { target } = self;
if let Some(account) = ccx.ecx.journaled_state.state.get_mut(target) {
account.unmark_touch();
account.storage.clear();
}
Ok(Default::default())
}
}

Yep, but that's for all slots / entire account. The new cheatcodes are for specific slots

[0xDiscotech]

Hey @grandizzy!
I've been trying to use the new cheatcodes for the tests, but the input storage keys passed on vm.accessList is not getting warm. Here's is where I'm trying it: https://github.com/defi-wonderland/optimism/pull/350/files#diff-d7dfdf2c624779960d7328b11121292fd058aafc05c56e20c984dca5441bce1eR50-R58 -- We perform a gas cost calculation afterwards and this cheatcode has no effect, the same with warmSlot.

In addition, I've checked this tests and I found that the storage keys are always an empty array, what could lead to an uncovered branch.

[grandizzy]

hey @0xDiscotech will check the tests for accessList asap (btw, they should be performed with isolate true to have effect). Re warm/cool slot, the tests I added shows different gas (614 when warm slot vs 2614 when making the slot cool, see https://github.com/foundry-rs/foundry/pull/10112/files#diff-d0ed72756e57739d550012e9ec8643e5a156a9bf7db6ae0542537d4259db652eR18) , mind to explain what's expected? Thanks

[0xDiscotech]

@grandizzy Yes, I tried it on isolated mode and it worked, so, nvm.
Thank you very much!