eth/tracers: add debug_traceCallMany method

[recursion128]

This PR introduces a new rpc method debug_traceCallMany which executes a series of transactions one after the other, collects the structured logs created during the execution of the EVM, and returns a number of possible traces for each transaction.

The debug_traceCallMany enhances the tracing capabilities of our API, allowing users to trace multiple transactions in a single call. This can be particularly useful for debugging complex interactions between multiple transactions.

The defining feature of debug_traceCallMany is its sequential execution of transactions, where each transaction is executed based on the final state of the preceding one, thereby creating a cumulative effect on the state.

The primary use case for this feature is pre-execution checks in wallets. When a user wants to understand the potential asset changes from interacting with an unauthorized contract, debug_traceCall requires the user to approve the contract before it can estimate the user's asset changes, which introduces potential risks. However, with debug_traceCallMany, there's no need for the user to approve the contract to make an estimate (the user's contract approval just needs to be passed in as a preceding transaction). In fact, the pre-transaction balance change feature in Rabby Wallet is based on this method.

[s1na]

Hey your PR is looking good at a glance. I do have to inform you that we're in the process of championing a new method eth_multicall together with Nethermind to be added to the JSON-RPC spec. You can find my implementation of it here: https://github.com/s1na/go-ethereum/tree/multicall and the spec here: ethereum/execution-apis#383. My plan was to add a debug_traceMulticall after this was merged and mimicing it's behavior (+tracing on top). If you look there you will see it will be more feature-rich than what you have implemented.

Would you be interested in adapting your implementation to look like eth_multicall?

[recursion128]

@s1na thank you for your feedback and for sharing your work. Your implementation looks promising and the eth_multicall method seems to be a significant addition to the JSON-RPC spec.I'm definitely interested in adapting my implementation to align with eth_multicall. I believe it could enhance the functionality and versatility of my current work. I'll start exploring how best to integrate this into my PR. Thanks again for your suggestion.

[holiman]

Hm. So we have #25743 based on https://github.com/s1na/go-ethereum/tree/trace/batch-call, and also https://github.com/s1na/go-ethereum/tree/multicall, and finally this PR.

I'm a bit curious about what the technical differences in these approaches are.

The defining feature of debug_traceCallMany is its sequential execution of transactions, where each transaction is executed based on the final state of the preceding one, thereby creating a cumulative effect on the state.

I thought that was the case for all of them.

[recursion128]

I agree that the core feature of the three, namely the sequential execution of transactions, is consistent. The difference between debug_traceCallMany and eth_multicall might be similar to the difference between debug_traceCall and eth_call, in that debug_traceCallMany offers an added benefit by returning a variety of possible traces.

[recursion128]

reimplemented based on multicall, and I'll mark this PR ready once multicall is merged.

[s1na]

@recursion128 Hey just want to let you know that your PR was closed. I'm not sure it was intentional since the reason stated by github is "closed by deleting the head repository" and in fact I see your profile is empty, everything is private.