Interactively debugging internal transactions

[scottbuckley]

Hi there. I've been trying to find a way to interactively debug the the bytecode of a transaction, including jumping to the bytecode (with appropriate calldata etc) of an external contract when the debug trace performs CALL or similar.

I am relatively new to using Foundry tools, but I have been running Anvil local archive nodes to play around with this kind of debugging, and used the in-terminal interactive debugger via Cast, which I'm enjoying. I was lead to believe that the interactive debugger in hevm would have the functionality i'm looking for, and I actually fixed (and had a PR accepted) the current release of hevm just to try it out, and it turns out that hevm has removed the interactive debugging feature, so I'm back to Cast. Remix does this in theory, but its debugger is extremely unreliable.

The example transaction I'm looking at is here on Holesky. It only has a single internal transaction. It appears that Cast breaks the bytecode trace into two "pages" - one for before the internal transaction, and one for after. It would be amazing if I could get Cast to jump to the bytecode trace of that internal transaction in-between those pages, either automatically, or via a key pressed when the CALL opcode is selected, or via a setting.

A secondary option would be some version of cast run which grabs the "transaction tree" (what BlockScout calls the "raw trace"), then lets me choose which sub-transaction I want to debug, before opening the interactive debugger. I was looking around to see if Cast returns this set of internal transactions somehow, but I also couldn't find this feature.

I am interested in developing this feature myself if something similar doesn't already exist, but I thought I'd first ask to see if there's something like this I don't yet know about. I couldn't find anything like this in the Foundry Book. If nothing like this exists, I'd be interested to hear the devs' ideas of what challenges I might face implementing it.

Thanks!

[zerosnacks]

Hi @scottbuckley thanks for your question / suggestion!

Foundry works with what we call "call frames" that we jump in and out of.

As an example:

cast run 0x5abe9e49541677cc3d7a70820aa5c86af3d5c24dcceb53478ea678290c55ca15 --rpc-url <MAINNET_RPC_UL>  --etherscan-api-key <MAINNET_ETHERSCAN_API_KEY> --debug

You can then press c to jump to the previous call (or first call) or C to jump to the next CALL

cast run 0x0eafea07d6fefde2f4f82de21de989474c670726207bb98f0f940711bc449708 --rpc-url https://holesky.drpc.org --json | jq

This gets you something like raw trace or to expand further you can use --decode-internal

cast run 0x0eafea07d6fefde2f4f82de21de989474c670726207bb98f0f940711bc449708 --rpc-url https://holesky.drpc.org --decode-internal --json | jq

If this is not what you mean, would you mind expanding on it further? Feel free to open a feature request ticket detailing your request, it is a bit easier to keep track off than in the discussions.

[scottbuckley]

Hi! Sorry for the slow response.

Yeah, I can see this concept of "call frames", that seems like a good way of doing it.

It's a good start that cast will extract the trace data for internal calls. But that's not quite what I'm looking for. I'll explain it here, but let me know if I should copy it over to a feature request too.

So, when I interactively debug the transaction 0x0eafea07d6fefde2f4f82de21de989474c670726207bb98f0f940711bc449708, there seem to be two call frames, if I'm understanding everything correctly. I am imagining three "call frames", but the middle one being an execution of a different contract's runtime bytecode. Imagine the following three "call frames" (if that's the right term here).

• "A1": execution of contract A's runtime bytecode from the beginning, with specific calldata, up until a CALL is made to contract B.
• "B1": execution of contract B's runtime bytecode from the beginning, with calldata provided by contract A, until return or revert (etc).
• "A2": execution of contract A's runtime bytecode, continuing after its CALL and now with access to return data provided by contract B's execution.

To me, these are the three blocks of execution I want to consider, but it seems to me that the debugger shows me only A1 and A2, but not B1. I would love a tool where all three blocks of execution are explored, in that order (the order they are executed).

I can imagine reconstructing a different debugging session that steps through B1, by reconstructing the appropriate calldata (easy, this is recorded in the trace), and state (harder - this might have changed if there are multiple calls to B). I can imagine writing a script that asked me which "call frame" or "block" i want to debug, and then opens the cast debugger with the right incantation to recreate that "internal debugging" context. However it seems to me like an intuitive feature for the interactive debugger to already jump between these debugging contexts for me.

Does this all make sense?