feat(flashblocks): Encapsulate Validation #313
Conversation
✅ Heimdall Review Status
|
meyer9
left a comment
meyer9
left a comment
There was a problem hiding this comment.
LG, makes the logic much more clear! Do you know if we check transaction order somewhere? If a canonical block reorders transactions compared to the flashblocks, that should count as a reorg I would think.
meyer9
left a comment
meyer9
left a comment
There was a problem hiding this comment.
LG! might want to wait for @danyalprout or @haardikk21 to review unless it's blocking something else since I'm not 100% familiar with this repo yet
Agree, will wait on their review :) TY |
| self.build_pending_state(None, &flashblocks) | ||
| } | ||
| ReconciliationStrategy::DepthLimitExceeded { depth, max_depth } => { | ||
| debug!( |
There was a problem hiding this comment.
I would make this a warn log, it's a sign the node is falling behind
There was a problem hiding this comment.
DepthLimitExceeded is not a sign of the node lagging. This occurs because the default Continue case doesn't clear pending state to avoid re-execution of transactions. When flashblocks regularly outpace canon blocks, eventually it will have a LOT of pending state which can cause slowness. The depth limit check ensures that after a certain threshold, we force clear the state and eat the cost of re-executing some (small) number of txns (< 1 block)
There was a problem hiding this comment.
Thanks for the context
refcell
dismissed stale reviews from danyalprout, haardikk21, and meyer9
via
d7d9806
Description
Fixes #310
Refactors validation logic from the
StateProcessorinto a new stateless typeFlashblockSequenceValidator.