[pool] Explore local tracing with revm

[dancoombs]

Describe the feature
Tracing is by far our largest latency performance bottleneck. Due to the complexities of getting custom native tracers installed on nodes (especially when using 3rd party RPCs), Rundler always uses a javascript tracer, causing the latency issue.

A different approach to this would be to do tracing locally using revm.

How this would work:

• Gather all of the required storage slot values using the native prestateTracer on the normal RPC. This should be supported by all 3rd party RPCs.
• Load the prestate into revm state builder on an empty database.
• Trace the call locally using a revm inspector.

Some caveats:

• Precompile support. Our local EVM would require all of the same precompiles as the network that we are simulating, and that we explicitly whitelist. Currently this is only RIP-7212, but the list might expand.
• Performance. Rundler is currently very light on CPU usage due to offloading all computation to nodes.
  • We could implement this tracing functionality as another server task within Rundler that exposes a gRPC interface and could be horizontally scaled independently of the rest of Rundler.

Another approach could be to attempt to use revm on top of alloydb and remove the prestate tracing, but that may require too many network calls to be high performance.

[dancoombs]

This would be made obsolete if Geth (and other major node providers) offer a native tracer and major RPC providers offer access: ethereum/go-ethereum#30546

[dancoombs]

Potential issue here: a degenerate case UO that doesn't use a ton of gas, but reads a bunch of large contracts. This would be limited by gas usage, but that doesn't seem to scale correctly with the amount of data retrieved by the prestate. Same with doing a ton of SLOADs. We'd have to analyze the data retrieval costs for these degenerate cases.

[ChiHaoLu]

Hello, may I kindly ask a question regarding this thread?

I am using the RIP-7212 in L2 like Arbitrum Sepolia or Optimism Sepolia, even these L2s support P256 precompiled, the Alchemy Bundler will return error for missing precompiled in validation step currently right?

[dancoombs]

Rundler's validation tracer will allow RIP-7212 if the node that is doing the tracing supports it

rundler/crates/sim/tracer/src/validationTracerV0_7.ts

Line 346 in 663a373

// MODIFICATION: allow precompile RIP-7212 through - which is at 256

[ChiHaoLu]

Hello, I’m still encountering an error related to the RIP-7212 precompile when using eth_estimateUserOperationGas on both OP and ARB. Current situation is the P256 precompiled can be used in execution step but failed in verification step with rundler.

• execution step means my userOp.calldata interacts with the P256 precompiled.
• verification step means my userOp.signature verified through the P256 precompiled.

Could you please share when Rundler is expected to support this feature?

Thanks a lot!

Error: {
  "jsonrpc": "2.0",
  "id": 0,
  "error": {
    "code": -32500,
    "message": "validation reverted: [reason]: AA23 reverted",
    "data": {
      "reason": "AA23 reverted",
      "revertData": "0x42b01bce0000000000000000000000000000000000000000000000000000000000000100",
      "parsedData": {
        "abiItem": {
          "type": "error",
          "name": "MissingPrecompile",
          "inputs": [
            {
              "name": "",
              "type": "address",
              "internalType": "address"
            }
          ]
        },
        "args": [
          "0x0000000000000000000000000000000000000100"
        ],
        "errorName": "MissingPrecompile"
      }
    }
  }
}

[dancoombs]

AA23 is coming directly from the entry point - so I don't believe this is a Rundler issue. It seems the validation step is trying to access a precompile that the node doesn't support.

[ChiHaoLu]

I am using the Alchemy Bundler directly instead of my local rundler.