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. |
3 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