eth/tracers: implement trace live filter

[jsvisa]

Hi @s1na,

This is a poc version of the trace_xxx RPC. I primarily use the freezer database to store the block traces and register the RPC in stack with a callback (which may be refactored later). In this branch, I attempt to implement a simple version of the trace_filter, trace_block, and trace_transaction RPC methods. I then run these changes locally to verify the correctness of the data produced.

Here are some areas that need further refactoring:

1. Dependency Injection: We need to pass an eth.Backend or a similar object to the filter_tracer to fetch the chain’s inner services. For example, trace_transaction requires the transaction-to-block number mapping.
2. Tracer Compatibility: We need to adjust some aspects of the prestate and call tracers to be compatible with both live and debug traces. For instance, in live tracing, the block context is passed via the OnBlockStart hook, whereas in debug tracing, it is provided during the initialization of tracing.
3. RPC Design: I'm intending to maintain compatibility with Parity’s RPC. For example:

{
  "jsonrpc": "2.0",
  "method": "trace_block",
  "id": 67,
  "params": [
    "0x5990",
    {"tracer": "callTracer"}  // Added in our implementation
  ]
}

Should the default tracer be parity? In Parity’s case, the response should also be the same as Parity’s(need more redesign). For other tracers (e.g., callTracer, prestateTracer), the response format should be consistent with the debug_traceXXX methods.

Starting geth with filter live tracer:

geth
... # other arguments
--http.api=engine,web3,eth,debug,trace # append trace namespace
--vmtrace=filter # enable the filter live tracer
--vmtrace.jsonconfig="{\"path\": \"/data/trace-filter\", \"config\": {\"callTracer\": {}, \"flatCallTracer\": {\"includePrecompiles\": true, \"convertParityErrors\": true}}}"

Looking forward to your feedback and suggestions.

[s1na]

Myeah I thought we would just return the txhash? Is any other client returning full tx objects?

[jsvisa]

I'm following the RPC in https://github.com/manifoldfinance/rpc-eip-drafts/blob/master/eth_getTransactionBySenderAndNonce/README.md, so in reth, I return the full tx, ref paradigmxyz/reth#10540.

I think I might need to reconsider whether to return the txhash or full tx, I'll take a look at the behavior of other clients or providers again. Indeed returning the txhash is more simple and then sdk's side can fetching the tx body or receipt by calling the eth_getTransaction or eth_getTransactionReceipt.

[s1na]

Btw now that we are passing in the *node.Node handle we can use that to access databases.

[jsvisa]

Yes, but I don't want to put the temporary data into the chaindata, as the data we used here is temporary, and acts in the order: write-once, read-once, deleted(level merged), so the user can set a separate, and cheaper SSD for such temporary data needs.

[jsvisa]

@s1na maybe we can support this tracer after #30611