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

fix(rpc/trace): trace_filter filting with trace's address #9722

Merged
merged 8 commits into from
Aug 2, 2024

Conversation

jsvisa
Copy link
Contributor

@jsvisa jsvisa commented Jul 23, 2024

waiting for alloy-rs/alloy#1090 to be merged first.

Currently, we're filtering the trace result by transaction's from and to address, but indeed this API should filtering with trace {action, result}'s address, the latter is more useful and meaningful.

eg I want to fetch the traces with the below RPC:

{
  "jsonrpc": "2.0",
  "method": "trace_filter",
  "id": 67,
  "params": [
    {
      "fromBlock": "0x134FD29",
      "toBlock": "0x134FD29", 
      "fromAddress": ["0x6b75d8af000000e20b7a7ddf000ba900b4009a80"],
      "toAddress": ["0x420690b0736e88ea43373a6dd7e1c8f225050e7b"]
    }
  ]
}

reth's can't produce any results, because https://etherscan.io/address/0x6b75d8af000000e20b7a7ddf000ba900b4009a80 is a contract, no exists in tx's from_address.

Comment on lines 318 to 322
// filter out traces that don't match the filter
all_traces = all_traces
.into_iter()
.filter(|trace| matcher.matches(&trace.trace))
.collect::<Vec<_>>();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to be a bit more careful here now that we no longer prefilter blocks because this has now all the blocks in memory

perhaps we can apply the filter in the trace_block_until( call instead so we only buffer traces that we need?

also no longer sure about the self.calculate_base_block_reward( should we only do this for blocks that have at least one match?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, inside the tracing should be more efficient.

And for the block rewards, I think it's similar to normal traces, simple match should be sufficient.

Btw, do we have any plans to indexing the trace from/to address, similar to erigon's TraceFromIndex and TraceToIndex?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Btw, do we have any plans to indexing the trace from/to address

nothing final yet, but we're considering it either with or without breaking the db, need to figure out if it's possible to introduce this without requiring a resync

perhaps you can open an issue for this, don't think this is tracked

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, if we are planning to implement it, I want to have a try

@mattsse mattsse added S-blocked This cannot more forward until something else changes A-rpc Related to the RPC implementation labels Jul 27, 2024
@mattsse mattsse requested a review from gakonst as a code owner August 2, 2024 12:03
@mattsse mattsse enabled auto-merge August 2, 2024 12:17
@mattsse mattsse added this pull request to the merge queue Aug 2, 2024
Merged via the queue into paradigmxyz:main with commit 340c95e Aug 2, 2024
33 checks passed
@jsvisa jsvisa deleted the trace-filter branch August 2, 2024 13:41
martinezjorge pushed a commit to martinezjorge/reth that referenced this pull request Aug 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-rpc Related to the RPC implementation S-blocked This cannot more forward until something else changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants