-
Notifications
You must be signed in to change notification settings - Fork 757
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
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files
Flags with carried forward coverage won't be shown. Click here to find out more. |
…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
…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
…to snap-sync-moving-root
…to snap-sync-moving-root
…to snap-sync-moving-root
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.