search

paradigmxyz / reth

Modular, contributor-friendly and blazing-fast implementation of the Ethereum protocol, in Rust
https://reth.rs/
Apache License 2.0
4.01k stars 1.24k forks source link

Trace Filter support #4799

Open mattsse opened 1 year ago

mattsse commented 1 year ago

Describe the feature

tracking issue for trace_fitler which is very useful for indexing

ref https://github.com/paradigmxyz/reth/issues/3661#issuecomment-1735506192

trace_filter returns parity traces similar to eth_getLogs but for traces

https://github.com/paradigmxyz/reth/blob/7024e9a8e91e9546ffd20b5aae65e85888f591a6/crates/rpc/rpc-types/src/eth/trace/filter.rs#L9-L24

all filter fields can be checked via Transactions alone, if I understand the filter options correctly.

Supporting the block range shouldn't be too difficult, at worst this is essentially a batch of replay_block requests.

Not sure how to support address fields without limiting blocks, because atm we don't have indices for that

@tjayrush what is a usual trace_filter request?

Additional context

No response

tjayrush commented 1 year ago

Our use case is probably not all that typical (but no less useful).

We only need first_block and last_block because we scan the result ourselves for appearances.

I imagine that for others, though, the address filter is quite interesting.

Our use case is indexing all address appearances in the block range, not filtering for one (or a few) addresses.

We have a bunch of test cases for tracing that I'll run once I get my Reth node synced to mainnet. That will help with testing.

mattsse commented 1 year ago

what's a typical block range?

since this is quite similar to replay_block with some extra steps, I can at least add support for block filters

tjayrush commented 1 year ago

Again, no real typical value. We would probably adjust at whatever value is the fastest (after experimenting). We batch 5,000 blocks at a time, but I'm sure that's way too many, so I've been thinking of breaking it up into 100 50-block chunks. (Currently, we query each block separately with trace_block). But we'd adjust.

mattsse commented 1 year ago

sg! I'll implement it with some limitations: block range required block range limited (needs some testing)

tjayrush commented 1 year ago

I'll test it (once I'm synced...). Although, I have Sepolia synced, so I can test it there too.

github-actions[bot] commented 1 year ago

This issue is stale because it has been open for 21 days with no activity.

sambacha commented 1 year ago

Is this still an open issue?

paulmillr commented 6 months ago

This is still an issue. The merged implementation is limited to 100 blocks, which makes it useless, compared to Erigon.