I'll take my shot. Experts, please correct me.
"Full" Sync: Gets the block headers, the block bodies, and validates every element from genesis block.
Fast Sync: Gets the block headers, the block bodies, it processes no transactions until current block - 64(*). Then it gets a snapshot state and goes like a full synchronization.
Light Sync: Gets only the ...
There's a lot of detail on this PR on github. Here's a quote:
Instead of processing the entire block-chain one link at a time, and replay all transactions that ever happened in history, fast syncing downloads the transaction receipts along the blocks, and pulls an entire recent state database.
As --fast is often the only thing associated with a fast sync, don't forget --cache too.
From the Homestead Guide:
Below are some flags to use when you want to sync your client more
This flag enables fast syncing through state downloads rather than
downloading the full block data. This will also reduce the size of
Why Does Fast Sync Restart
As stated in Péter Szilágyi's comment above, you will have to wait for --fast syncing to complete, otherwise you will have to restart the process again. The message you should see on your console when --fast syncing has completed is "fast sync complete, auto disabling" as shown below:
I0416 17:16:12.631667 30629 ...
geth and parity have differents methods to save the ethereum blockchain in their internal format. I made many benchs because i find it so long just to use a Wallet.
The pruning mode is how the block data are saved. With the archive mode, all states are saved. So, you know the state at each moment without to reload all the blockchain. With fast and light, we ...
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.
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 ...
It's difficult to give an answer without just re-hashing the explanation on the Parity wiki...
The pertinent part is as follows:
These snapshots can be used to quickly get a full copy of the state at a given block. Every 30,000 blocks, nodes will take a consensus-critical snapshot of
that block's state. Any node can fetch these snapshots over the
geth 1.5 is way faster but there are problems to keep connections with peers. When there is a high latency, it removes agressively the peer connection. I use the patch 2630 from Péter Szilágyi in the 1.5 version.
benchmarks done on OS X with 37320qm 16Go ram 1To SSD with geth 1.4.4 (stable):
To remove your blockchain with geth, run: geth removedb
Use --fast but you probably also need --cache=1024 (and --jitvm may also help). Without it, you are running with the default which is --cache=16.
A 50% speed increase is possible just by increasing the cache.
If you are starting from the beginning, use: geth --fast --cache=1024 --jitvm
With each block state (contracts storage and balances) is changing.
By default (archive) we keep in database full state of every block.
With different pruning algorithms we are ditching state data for old blocks maintaing only the parts that are needed. basic/fast/light are just various approaches to that problem with different trade-offs.
geth --fast is ...
The default datadir is:
Delete the chaindata subdirectory that you find.
Run geth --fast --cache=1024 for a recommended way to sync the chain quickly (don't forget to use a bigger --cache with a value like 1024, otherwise the default is 16, and it won't sync as quickly).
you can use flag --syncmode fast instead
they already update the wiki document https://github.com/ethereum/go-ethereum/wiki/Command-Line-Options
--fast Enable fast syncing through state downloads (replaced by --syncmode)
--light Enable light client mode (replaced by --syncmode)
EDIT: fast mode is now the default mode for Geth.
You can change the mode using the --syncmode parameter.
--syncmode "fast" Blockchain sync mode ("fast",
"full", or "light")
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 ...
Yes. But you won't get the debug.traceTransaction(...) for the part of the blockchain that is fast synced.
Here is the chaindata size from my fast synced blockchain:
Iota:Ethereum bok$ du -hs chaindata/
And here is the chaindata size from my non-fast synced blockchain:
bok@Rasterbator:~/.ethereum$ du -hs chaindata/
If you have your blockchain partially or fully imported while starting geth, then using the --fast flag is ignored (the flag is disabled). To use the --fast flag you have to remove all of the data from your chaindata folder.
The behavior has changed with the release of geth v1.8.0
Fromt the release notes
Tracing and pruning: By default, state for the last 128 blocks kept in memory. Most states are garbage collected. If you are running a block explorer or other service relying on transaction tracing without an archive node (--gcmode=archive), you need to trace within this ...
As per geth help document there are 3 ways you can do sync to network:
--syncmode full: Geth client will download Block header + Block data + full Validation [Is called eth full node]
--syncmode fast: Geth client will download Block header + Block data + validate for last 1k transactions.
--syncmode light: Geth client will download Current state + Asks ...
As long as you see in the logs INFO [xx-xx|xx:xx:xx] Imported new state entries .... the network is syncing.
You can check progress with command eth.syncing(from the geth console), if syncing is on going you must see:
"pulledStates": xxxxxxx, ...
I have the same understanding as you - the fast synced node will have all blocks, but the state only for last 64 blocks and onwards. Maybe what the author meant is "This allows a fast synced node to act as a full archive node from all intents and purposes, except there will be no state data for blocks earlier than the pivot block" :)
In geth 1.8 pruning is ...
If you kill the geth instance or it crashes, it won't write the latest status of the cache, and will be forced to drop the "fast" sync state and fall back to the last "full" state on next startup.
Graceful shutdown options: SIGINT, SIGTERM, Ctrl+D (if run with a console), Ctrl+C1
Unsafe shutdown options: SIGQUIT, SIGKILL, Windows' [X] button
First make ...
Yes, you can restart a syncing the chain with the --fast flag as many times as you like but you have to ensure that it is used every single time. When you synced only for a few seconds without the fast flag, you cannot restart it in fast mode (well you can but it will get auto-switched off).
Maybe you can remove your blockchain with geth removedb and do a --fast again. If not faster, it will for sure spare some diskspace. Worth a try I think. Let us know.
It could be interesting if you are more than 1500 blocks late, because --fast takes a pivot at minus 1500 blocks from now and then downloads all the blocks from there (and only headers of the ...
FYI: --fast is default if you start geth the first time with no blocks downloaded. If you restart geth after initial start, --fast doesn't work anymore (it only works starting from scratch).
If you have an SSD, it's expected to take 3-6h. If you have a spinning HDD, it might take days (so i wouldn't recommend it).
Try adding --cache 2048 or --cache 4096 ...
Imported new state entries count=384 flushed=0 elapsed=1m51.659s processed=2507 pending=20431 duplicate=0 unexpected=227
Important part: Imported new state entries
Those are the number of "state entries", rather than blocks themselves. You can think of them as items in Ethereum's state database.
Each block can contain many transactions. ...
You can know the latest block your node has processed by:
You can also know that whether your node is downloading blocks by:
Edit to answer the question asked in a comment:
These commands are to be typed into geth console ( not windows/linux command prompt). If you are already running geth, you can open another command ...
More than a day is definitely not usual with your configuration. I would advise you to use the flag --warp-barrier NUM to specify a minimum block you want to warp sync to
Note that some flags you use for Parity are the default ones and therefore not needed --mode active --tracing off --pruning fast.
I did a few bench by myself and found as well that there is no significant impact of --jitvm. And I agree that geth 1.5.0 with patch is way faster.:)
Note: the 1.4.6 version has these patchs and synchronize quickly
"fast" is the default value for --syncmode key
It means, that there are no different to use --syncmode fast or do not use it.
The information from https://github.com/ethereum/go-ethereum/wiki/command-line-options
--syncmode value Blockchain sync mode ("fast", "full", or "light") (default: fast)
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 ...