-
Notifications
You must be signed in to change notification settings - Fork 751
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
Snap sync moving root/healing implementation #3332
base: master
Are you sure you want to change the base?
Conversation
…orepo into snap-sync-moving-root
…orepo into snap-sync-moving-root
…/ethereumjs-monorepo into snap-sync-moving-root
…ly on protocol binding, small local refactor
…sendStatus for devp2p protocols
…to move from Sync -> Peer
…atest() call on peers in peer pool
…update' of https://github.com/ethereumjs/ethereumjs-monorepo into snap-sync-moving-root
…/ethereumjs-monorepo into snap-sync-moving-root
…orepo into snap-sync-moving-root
…orepo into snap-sync-moving-root
Update: Currently, with #3354 merged, I am working on implementing functionality for the snap sync fetchers to change the state root that they are using for fetching state data. In order to run the client manually for syncing Holesky using snap sync, use commands similar to the following:
In order to run the client manually for syncing the smaller, more manageable
In both cases, the |
…mjs-monorepo into snap-sync-moving-root
if (fetcher === null) { | ||
return | ||
} | ||
fetcher.updateStateRoot(latest!.stateRoot as Uint8Array) |
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.
no we don't need stateroot from peer, we already have latest stateroot coming in from CL
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 #3354 was for tracking and accessing the latest root/height from the peer latest
function. Are you suggesting passing down the latest root from FCU calls?
@@ -276,6 +277,8 @@ export class AccountFetcher extends Fetcher<JobTask, AccountData[], AccountData> | |||
} | |||
break | |||
case TrieNodeFetcher: | |||
// TODO update to check if heal phase completed successfully and then continue with next |
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 function with this case would/should anyway be called when heal phase completed successfully
@@ -435,6 +447,10 @@ export class TrieNodeFetcher extends Fetcher<JobTask, Uint8Array[], Uint8Array> | |||
return tasks | |||
} | |||
|
|||
updateStateRoot(stateRoot: Uint8Array) { |
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.
need to see that the root is not continually updated.
so the thing is: you start trie node fetcher with latest root, keep requesting data till peers give you, if they start replying with empty, then we restart the entire fetcher with the new root.
so this is to be implemented as a while loop in the account fetcher's fetch where we start and run the trie node fetcher (either fetcher resolves or errors with error "out of range root", which will cause account fetcher to spin a new trie node fetcher with new root)
…to snap-sync-moving-root
…d on a more granular level
…to snap-sync-moving-root
5fcd1dc
to
4058a27
Compare
This change will add the ability to the snap sync fetchers to have their target roots updated and will explore adding continual healing to the snap sync process.