-
Notifications
You must be signed in to change notification settings - Fork 1.7k
feat: run pipeline only if missing range is large #3059
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov Report
@@ Coverage Diff @@
## main #3059 +/- ##
==========================================
+ Coverage 69.75% 69.80% +0.05%
==========================================
Files 529 530 +1
Lines 71339 71451 +112
==========================================
+ Hits 49763 49877 +114
+ Misses 21576 21574 -2
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Is this correct? I.e. if I start the node and I am lacking like 90 blocks, will we be able to get these w/o the pipeline (is the tree p2p enabled yet?) |
yeah, this will currently queue downloads for the 90 block range one-by-one, and then execute them once they've all been downloaded |
yes we have this mode. when we receive a new FCU and we don't have the new head buffered yet, we will start downloading from this new head towards the local head and try to canonicalize the new head via tree this way. |
a test is timing out 🤔🤔🤔🤔🤔 |
d3c9cd4
to
1905dc1
Compare
696d893
to
2c28d8a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this likely needs a rebase because I think we renamed ShareableDB since
// get the latest valid finalized block or the tip (if we don't have the | ||
// finalized block set) | ||
let fork_ancestor_num = self.forkchoice_state_tracker.last_valid_finalized().and_then(|finalized| { | ||
// now we need to actually fetch these | ||
self.blockchain.block_number(finalized).unwrap_or_else(|err| { | ||
// TODO: store full headers (or BlockNumHash) in forkchoice | ||
// state tracker if valid, so we don't need to fetch at all | ||
error!(target: "consensus::engine", ?finalized, ?err, "Failed to get block number from validated finalized block hash"); | ||
None | ||
}) | ||
}).unwrap_or_else(|| self.blockchain.canonical_tip().number); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not immediately clear to me what we're checking here.
what exactly are we checking here?
this looks way too complex
this should be much easier imo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought the latest valid finalized block would be give a better heuristic for how long the new fork could be, but yeah it's too complex and using the head is much simpler, so switched to doing that
dc9ef84
to
588cf3a
Compare
need to fix another test post-rebase |
// compare the missing parent with the canonical tip | ||
let canonical_tip_num = self.blockchain.canonical_tip().number; | ||
|
||
// if the number of missing blocks is greater than the max, run the | ||
// pipeline | ||
if missing_parent.number >= canonical_tip_num && | ||
missing_parent.number - canonical_tip_num > |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is much easier to understand and should be sufficient
missing_parent.number - canonical_tip_num > | ||
self.pipeline_run_threshold | ||
{ | ||
self.sync.set_pipeline_sync_target(missing_parent.hash) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is a bit dangerous imo, because this is not necessarily part of the chain
so I think we should use the finalized block of the latest FCU here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
switched to setting the finalized sync target here, but would like some input on the edge case where the latest finalized block is None
:
https://github.com/paradigmxyz/reth/pull/3059/files#diff-6422221acf035d27429c58dd93438246d53b548efb00b9b3cfbd610c94f8c544R1059-R1064
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, we can ignore this else branch because I don't think this is even reachable since we only trigger pipeline on a FCU in the first placee
Is this still relevant with #2964 being merged? If it is, what is the path forward here? |
af1d4fa
to
361afbb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
very nice!
tests look good,
I also checked several scenarios on an outdated sepolia node with restarts etc. works as expected.
one thing we can consider is lowering the threshold because 128 blocks is ~25min and executing a lot of blocks in the engine has some perf drawbacks (unresponsive to CL requests) which is not ideal but also not very problematic during sync
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good to me too
Modifies the beacon engine to only run the pipeline if the missing range is larger than a set constant (currently 128)
should fix #2964