-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Conversation
crates/rpc/rpc/src/trace.rs
Outdated
// filter out traces that don't match the filter | ||
all_traces = all_traces | ||
.into_iter() | ||
.filter(|trace| matcher.matches(&trace.trace)) | ||
.collect::<Vec<_>>(); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
Signed-off-by: jsvisa <[email protected]>
Signed-off-by: jsvisa <[email protected]>
Signed-off-by: jsvisa <[email protected]>
Signed-off-by: jsvisa <[email protected]>
Signed-off-by: jsvisa <[email protected]>
…z#9722) Signed-off-by: jsvisa <[email protected]> Co-authored-by: Matthias Seitz <[email protected]>
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:
reth's can't produce any results, because https://etherscan.io/address/0x6b75d8af000000e20b7a7ddf000ba900b4009a80 is a contract, no exists in tx's from_address.