feat(cheatcode): `startDebugTraceRecording`, `stopDebugTraceRecording`, and `getDebugTraceByIndex` for ERC4337 testing
Motivation
ERC4337 (account abstraction) has several rules/restrictions on what the UserOperation can do (see: ERC7562). Specifically, it has rules on what opcodes it can access and limitations on certain storage access as well.
These limitations are quite implicit and might not be easily identified during contract development. We want to provide an easier way for developers and security researchers to check/test if the rules are being followed. We aim to enable these checks by running forge test after writing specific tests for that purpose.
Solution
To support this, we need new cheatcodes that can record the debug traces during EVM execution so we can know the opcodes and storages being accessed. With this cheatcode, we will be able to have a helper contract that checks whether the test executions comply with ERC4337 restrictions.
In this solution, we added two cheatcodes:
startDebugTraceRecording: This starts the recording of the debug trace data.stopAndReturnDebugTraceRecording: This stops and returns the recording of the debug trace data.
Test
- An ERC4337 checker tool and its tests are in the repo: https://github.com/boolafish/erc4337-checker/blob/main/test/ERC4337Checker.t.sol
This sounds related to https://github.com/foundry-rs/foundry/issues/6704, tagging it here
Would like to make sure this PR covers the design goals of #6704 as the proposed cheatcode name slightly differs
@DaniPopes @klkvr just tagging as I am not sure if re-open a PR from WIP will trigger notifications or not. This should be ready and has accommodated the previous review comments. Sorry for taken so long due to OOO and fixing some OOM bugs on my side.
Sorry for the failed CI, have fixed those and tested in my own repo workflow: https://github.com/boolafish/foundry/actions/runs/10535493491?pr=1
@klkvr thanks for the review, should have fixed all comments aside from the one re: more traces were filled than started.
we can try working around this by creating a fake trace node in this situation
Might need a bit more elaboration on this. Not exactly sure how to do this on my end. But will also wait to see if that is the preferred approach I guess.
Hi @klkvr @DaniPopes , just a slight nudge on the review or feedbacks 🙏
not exactly sure why clippy failed on places unrelated to the code change, likely to be flaky. Anyway, since the master branch got some updates, I rebased the branch and the CI has passed on my own repo's workflow
Hi team, a slight nudge for review again 🙏
bounce this PR again @klkvr @DaniPopes
Looks like the failed CI was from flaky one, I rebased to get the commit from this PR: https://github.com/foundry-rs/foundry/pull/8859.
bump again
bounce again for review 🙏 @klkvr @DaniPopes @mattsse @Evalir
thanks for the review! Have fixed for the comments.
Personally I think it will be great to have a way to specify like a --tracer flag to turn on, or, specify tracer config without -vvv. With current limitation, I would imagine project interested to use this will need to isolate the tests by folder and run those separately in CI as verbose mode indeed prints too many stuff.
bounce for review again 🙏
bounce for a review 🙏 @DaniPopes @klkvr
friendly ping again @DaniPopes @klkvr
thanks @klkvr have fixed for the comments. Please take a look when available 🙏
thanks @klkvr for a fast turn-around!!
Have fixed the comment regarding node-step issue. Please take a look when available again 🙏 Can @DaniPopes also help take a look as well for the requested change part 🙏
slight nudge for the review 🙏 (cc @DaniPopes @grandizzy which were tagged previously by @/klkvr )
Thanks @boolafish! Merging
Thanks all!!