Ascending bootstrap dependency resolution #4692
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: gr0vity-dev <[email protected]>
Co-authored-by: gr0vity-dev <[email protected]>
Co-authored-by: gr0vity-dev <[email protected]>
Co-authored-by: gr0vity-dev <[email protected]>
Co-authored-by: gr0vity-dev <[email protected]>
Co-authored-by: gr0vity-dev <[email protected]>
Co-authored-by: gr0vity-dev <[email protected]>
pwojcikdev
force-pushed
the
dependency-walking-rebased
branch
from
3ea0c51 to
9f44594
Compare
clemahieu
approved these changes
Aug 6, 2024
| @@ -211,6 +209,25 @@ nano::account nano::bootstrap_ascending::account_sets::next () | |||
| return result; | |||
| } | |||
|
|
|||
| nano::block_hash nano::bootstrap_ascending::account_sets::next_blocking () | |||
There was a problem hiding this comment.
Should this return optional rather than 0?
There was a problem hiding this comment.
Could and should be done. I didn't have too much time to cleanup everything though.
| @@ -241,22 +273,52 @@ nano::account nano::bootstrap_ascending::service::wait_available_account () | |||
| return { 0 }; | |||
| } | |||
|
|
|||
| bool nano::bootstrap_ascending::service::request (nano::account & account, std::shared_ptr<nano::transport::channel> & channel) | |||
| nano::block_hash nano::bootstrap_ascending::service::available_dependency () | |||
clemahieu
pushed a commit
that referenced
this pull request
Aug 6, 2024
* Dependency walking * Parallel database scan * Stats * Throttling & backoff * Dependency account scanning * Sync dependencies * Track source when throttling * Count tags * Priorities backoff Co-authored-by: gr0vity-dev <[email protected]> * Timestamps * Avoid reprocessing old blocks Co-authored-by: gr0vity-dev <[email protected]> * Max tags limit * Handle `gap_previous` Co-authored-by: gr0vity-dev <[email protected]> * Check timestamp * Tune initial priority Co-authored-by: gr0vity-dev <[email protected]> * Fix config * Verify response * Use filters * Remove random sampling Co-authored-by: gr0vity-dev <[email protected]> * Backoff adjustments * Insert genesis on start Co-authored-by: gr0vity-dev <[email protected]> * Fix timestamp check performance Co-authored-by: gr0vity-dev <[email protected]> * Adjust throttle size computation * Config improvements * Fix compilation * Extend test timeout --------- Co-authored-by: gr0vity-dev <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the first part of our (mine & @gr0vity-dev) work on improving ascending bootstrapper. This part contains a new dependency resolution strategy among a few other smaller improvements.
An example of how it dependency resolution process works: let's have three accounts A, B, C. A depends on a transaction sent by B, and B depends on a transaction sent by C. Let's now assume we have a ledger that is not synced 100%, might be because we're doing an initial sync or our node was offline for a while. If account A performs a new live transaction, we can't process it immediately, because we're still missing chains for B & C. In the previous version resolving these dependencies was slow, as it was relying on sequential sampling of the whole ledger. With this improved algorithm, we first add account A to the blocking set, resolve its dependency as account B, since B is blocked we repeat the same process for B, finally arriving at account C that unblocks all these chains.