-
Notifications
You must be signed in to change notification settings - Fork 20k
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
[Question] Snap/Fast sync vs. Full sync for Archive nodes? #24413
Comments
There are two different notions: In fast/snap sync, the "current" state of the network is downloaded directly. As such, any state before it (not block, just the state) will not be available for serving. If you are running with In
That statement is wrong (I guess I messed it up at the time). I was meaning to write it "retains it's status a a full node".
Archive mode retains all the state that gets generated during block processing. If you reprocess all the blocks from genesis - with archive flag set - you will have all that state. If you do the initial sync without block processing, the state for that segment will not be available.
Depends on the behavior you want. If you want everything since genesis, then |
@karalabe -- Thank you so much for the response. I just have one more followup to help me understand -- What would happen if we ran an archive node with We manage some archive nodes will |
Then it would store every state from genesis to until you shut it off.
It would ignore the new syncmdoe and continue. I guess what would be desireable for you would be this:
This is possible, but would require a bit of coding, and some special setup. For example, you would run nodes The way to create a "archive node from
I guess the one thing lacking to script up such a scenario right now is that we don't have a way to stop at a certain block, e.g. Another useful option would be to extend |
Thank you! 🙏 |
@holiman Thanks for your replay. |
I mean |
Thank you very much, I will figure out what this command do. |
@holiman Hi, I have another question about the state and the snapshot. As I know, every block has its state(accurately, the world state MPT) which contains the account (also the contract) info, for full sync mode + full node, it will use the downloaded transactions to generate the state, and for fast(now is snap) sync + full node, it will not download the state until the pivot block and after that it will work as full sync, right? So the full node actually save the state for every block after the full sync, right? But from some documents and my test, the full node(either snap sync or full sync), it will only preserve state for the latest 128 blocks. Otherwise, it will return error with And what's the snapshot? what's the differences between state and snapshot? Thank you very much. |
A follow-up question: Is it possible to reprocess blocks from a certain block height to retain that state? E.g. Say I ran my node with Can this be done with some reprocessing of blocks without having to do a full sync from scratch? |
Only if you reprocess everything from genesis (i.e. a sull sync). |
an old documentation told me to use Geth with pruning to get a copy of only the newest blocks. to do this I should have used the "--fast" flag, I understand this is deprecated. currently it seems there are "full" "snap" "light" flags. Can you tell me the difference between "snap" and "light" ? full I think it's obvious. |
The documentation describes that there are 3 sync modes
{fast, snap, full}
and different types of nodes includingarchive
andfull
.What is the difference between using snap/fast sync for archive nodes versus if full sync is used for archive nodes? Are archive nodes using snap sync not able to serve the same requests that archive nodes using full sync can serve?
Running:
I tried to find some documentation but not clear what the verdict is:
eth/63 fast synchronization algorithm #1889 -- Introducing fast sync, author notes: "This allows a fast synced node to still retain its status an an archive node containing all historical data for user queries (and thus not influence the network's health in general), but at the same time to reassemble a recent network state at a fraction of the time it would take full block processing."
[Ethereum Stackexchange] Do we have a full archive node after a geth fast sync? -- Author speculates that the node is not able to serve requests prior to a "pivot block".
[Ethereum Stackexchange] does --gcmode=archive require --syncmode=full? -- Answer is not known.
Would love to receive some clarification on this! Many thanks.
The text was updated successfully, but these errors were encountered: