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 · 4 comments
Open

[pool] Explore local tracing with revm #840

dancoombs opened this issue Oct 10, 2024 · 4 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
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