Summary
I downloaded the geth
source, modified the source code to specify the fast sync pivot block, compiled the code, removed the old chaindata and started the fast syncing. Once this is complete, I'll be back to running the regular geth
binaries.
UPDATE This experiment failed. There were a few different errors with my hack that prevented the blockchain to fast sync to the specified block and then normal sync after the specified block. Back to full archive node sync.
Anyone has any suggestions?
Details
I downloaded the source code for geth
and modified the source code for section that calculates the fast sync pivot point eth/downloader/downloader.go, lines 419-441:
case FastSync:
// Calculate the new fast/slow sync pivot point
if d.fsPivotLock == nil {
pivotOffset, err := rand.Int(rand.Reader, big.NewInt(int64(fsPivotInterval)))
if err != nil {
panic(fmt.Sprintf("Failed to access crypto random source: %v", err))
}
if height > uint64(fsMinFullBlocks)+pivotOffset.Uint64() {
pivot = height - uint64(fsMinFullBlocks) - pivotOffset.Uint64()
}
} else {
// Pivot point locked in, use this and do not pick a new one!
pivot = d.fsPivotLock.Number.Uint64()
}
// If the point is below the origin, move origin back to ensure state download
if pivot < origin {
if pivot > 0 {
origin = pivot - 1
} else {
origin = 0
}
}
glog.V(logger.Debug).Infof("Fast syncing until pivot block #%d", pivot)
I modified the last line above to change the Debug
into Info
and added the following two lines below the code above:
glog.V(logger.Info).Infof("Fast syncing until pivot block #%d", pivot)
if (pivot >= 2394190) {
pivot = 2394190;
}
glog.V(logger.Info).Infof("Fast syncing until modified pivot block #%d", pivot)
I recompiled and started off the fast sync process using the modified binaries:
Iota:go-ethereum user$ make geth
...
Done building.
Run "build/bin/geth" to launch geth.
I checked the version of the modified geth
:
Iota:go-ethereum user$ build/bin/geth version
Geth
Version: 1.5.3-unstable
I removed the old damaged chaindata:
Iota:go-ethereum user$ build/bin/geth removedb
/Users/bok/Library/Ethereum/chaindata
Remove this database? [y/N] y
Removing...
Removed in 35.242291ms
I started the fast sync:
Iota:go-ethereum user$ build/bin/geth --fast --cache=1024 console
I1120 23:44:44.870142 ethdb/database.go:83] Allotted 1024MB cache and 1024 file handles to /Users/user/Library/Ethereum/geth/chaindata
I1120 23:44:44.878926 ethdb/database.go:176] closed db:/Users/user/Library/Ethereum/geth/chaindata
...
I1121 08:33:51.340811 eth/downloader/downloader.go:441] Fast syncing until pivot block #2664150
I1121 08:33:51.340847 eth/downloader/downloader.go:445] Fast syncing until modified pivot block #2394190
After the fast syncing is complete, I'll go back to using the regular geth binaries.
geth --fast
has an interesting effect: geth
cannot provide any information about accounts or contracts until the sync is fully complete.
Try querying the balance again after eth.syncing
returns false
.
Why?
The "fast" sync looks nearly complete because the reported current block is based on the best header you have. But that doesn't give you any information about how much of the account state data you have downloaded.
geth
can sync the blocks much faster than it can download the state. An excerpt from @karalabe's explanation why:
This trie data structure is an intricate interlink of hundreds of millions of tiny cryptographic proofs (trie nodes). To truly have a synchronized node, you need to download all the account data, as well as all the tiny cryptographic proofs to verify that noone in the network is trying to cheat you. This itself is already a crazy number of data items. The part where it gets even messier is that this data is constantly morphing: at every block (15s), about 1000 nodes are deleted from this trie and about 2000 new ones are added. This means your node needs to synchronize a dataset that is changing 200 times per second. The worst part is that while you are synchronizing, the network is moving forward, and state that you begun to download might disappear while you're downloading, so your node needs to constantly follow the network while trying to gather all the recent data. But until you actually do gather all the data, your local node is not usable since it cannot cryptographically prove anything about any accounts.
Best Answer
EDIT: fast mode is now the default mode for Geth.
You can change the mode using the --syncmode parameter.
See Command line options documentation in ETHEREUM OPTIONS section or run
geth help
.To check a running node mode, on *nix systems like Linux or OSX, you simply have to run the following in a terminal :
And the result should be something like that:
Indicating your node is running in default mode which is fast mode.
or
If you explicitely indicated the fast mode using the --syncmode parameter.
If you run Windows you can have a look to this answer : https://superuser.com/questions/415360/how-do-i-find-out-command-line-arguments-of-a-running-program that shows the options passed when the app was started. But I don't have a Windows PC to check this answer, so take it with caution.
But in any case, remember, fast means sync in some hours or a day and full sync can take many days. So don't expect your wallet to sync in a few minutes even if you have a huge internet connection, it's still limited by what pears can do.