Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[pool] Explore local tracing with revm #840

Open
dancoombs opened this issue Oct 10, 2024 · 8 comments
Open

[pool] Explore local tracing with revm #840

dancoombs opened this issue Oct 10, 2024 · 8 comments
Assignees
Labels
enhancement New feature or request prevent-stale Prevent an issue from closure due to being stale
Milestone

Comments

@dancoombs
Copy link
Collaborator

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 dancoombs added the enhancement New feature or request label Oct 10, 2024
@dancoombs
Copy link
Collaborator Author

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 dancoombs added this to the v0.5 milestone Oct 23, 2024
@dancoombs dancoombs self-assigned this Oct 23, 2024
@dancoombs
Copy link
Collaborator Author

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
Copy link

ChiHaoLu commented Nov 19, 2024

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
Copy link
Collaborator Author

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

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

@dancoombs dancoombs added the prevent-stale Prevent an issue from closure due to being stale label Dec 13, 2024
@dancoombs dancoombs removed this from the v0.5 milestone Dec 13, 2024
@dancoombs dancoombs added this to the v0.7 milestone Dec 23, 2024
@dancoombs dancoombs modified the milestones: v0.7, v0.8 Feb 6, 2025
@ChiHaoLu
Copy link

ChiHaoLu commented Feb 11, 2025

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
Copy link
Collaborator Author

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
Copy link

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

@dancoombs
Copy link
Collaborator Author

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

If you can replicate this with a local Rundler, please open a separate ticket with a way to replicate. If this is an Alchemy specific question, please use the Alchemy Discord. The "MissingPrecompile" error that you have above does not come from Rundler, but form some unknown smart contract - so please include those details in the separate ticket if you can replicate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request prevent-stale Prevent an issue from closure due to being stale
Projects
None yet
Development

No branches or pull requests

3 participants
@dancoombs @ChiHaoLu and others