feat(flashblocks): parallelize sender recovery #295
Conversation
✅ Heimdall Review Status
|
madisoncarter1234
force-pushed
the
fix/parallel-sender-recovery
branch
from
a2763d7 to
e839384
Compare
Addresses base#282 - reduces sender recovery overhead during flashblock processing. ## Changes - Add rayon for parallel iteration over transactions - Batch ECDSA sender recovery upfront using par_iter() - Add sender_recovery_duration metric for observability - Preserve cache lookup behavior (check prev_pending_blocks first) - Maintain original error handling semantics ## Technical Approach Follows upstream reth pattern (paradigmxyz/reth#20169) - recover all senders in parallel before the sequential transaction processing loop. ## Testing All 10 existing flashblocks tests pass. ## Note Benchmarks not included as benchmark infrastructure was removed from main. The new sender_recovery_duration metric can be used for production measurement.
madisoncarter1234
force-pushed
the
fix/parallel-sender-recovery
branch
from
e839384 to
41f678f
Compare
crates/flashblocks/src/processor.rs
Outdated
| // Sender already recovered in parallel phase | ||
| let sender = *sender_by_hash | ||
| .get(&tx_hash) | ||
| .expect("sender must exist from parallel recovery"); |
There was a problem hiding this comment.
To avoid the .expect statement here, we could just iterate over the txs in parallel as you've done earlier, but instead of constructing a map, produce a list of tuples that is (Transaction, Sender) so the sender is available in this for loop.
Switched from HashMap lookup to Vec<(&OpTxEnvelope, Address)> so the sender is directly available in the loop, no .expect() needed. Re: benchmarking, i can take a stab at it in this PR! |
Awesome work thank you @madisoncarter1234 !!! And yes if you could add benchmarks here that would be very helpful. |
Added sender recovery benchmark (crates/flashblocks/benches/sender_recovery.rs). Results on my machine below
parallel recovery scales well, larger batches showing larger gains |
Thank you, this is great. I added one more bench based off your work that also tests against a set of real transactions across 5 blocks from Base mainnet to introduce some variety. LGTM Note for @refcell: The large diff in the PR is now due to the |
|
Review Error for haardikk21 @ 2026-01-07 06:41:57 UTC |
4 participants
Addresses #282
Summary
What's included
✅ Parallel sender recovery (matches upstream reth approach)
✅ Timing metric for observability
✅ Proper error handling preserved
What's not included