Trace Filter support

[mattsse]

Describe the feature

tracking issue for trace_fitler which is very useful for indexing

ref #3661 (comment)

trace_filter returns parity traces similar to eth_getLogs but for traces

reth/crates/rpc/rpc-types/src/eth/trace/filter.rs

Lines 9 to 24 in 7024e9a

	pub struct TraceFilter {
	/// From block
	#[serde(with = "u64_hex_or_decimal_opt")]
	pub from_block: Option<u64>,
	/// To block
	#[serde(with = "u64_hex_or_decimal_opt")]
	pub to_block: Option<u64>,
	/// From address
	pub from_address: Option<Vec<Address>>,
	/// To address
	pub to_address: Option<Vec<Address>>,
	/// Output offset
	pub after: Option<u64>,
	/// Output amount
	pub count: Option<u64>,
	}

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]

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]

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]

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]

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

[tjayrush]

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

[github-actions]

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

[sambacha]

Is this still an open issue?

[paulmillr]

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