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 assume that we don't need all this information but only the current state and few before, so we remove many intermediates states.
On geth, the --fast method saves a state of the blockchain at block B[-1500] and all the states after this block (B[-1] is the last block, B[-2] is the before last block ...). So it is possible to rewind at the state of 1500 last blocks. With a full blockchain, you can do it for all blocks.
In parity, there are 4 pruning modes or journalDB algorithms:
- Archive (Archive): as geth Archive we keep all states
- Fast (OverlayRecent): as geth Fast we keep all the full states of the B[-i] blocks
- Light (EarlyMerge): we keep all the states of the B[-i] blocks but in differential (so it is smaller than fast but slower access)
- Basic (RefCounted): we keep all the states of the B[-i] blocks like with OverlayRecent but we remove states after x changes... so we have only the xth last changes
Benchmarks done on i7 3720QM 16GB ram with Geth 1.4.4 (Homestead with 1.6Mi blocks)
_____________________________________________
| Option | Disk Used | Time | Disk Written |
|--------|-----------|------|---------------|
| none | 19.GB | 5h00 | 1TB |
| fast | 3.7GB | 1h00 | 100GB |
---------------------------------------------
Benchmarks done on i7 3720QM 16GB ram with Geth 1.5.0 unstable (Homestead with 1.6Mi blocks found at https://gitter.im/ethereum/go-ethereum?at=574d26c010f0fed86f49b32f)
__________________________________________________
| command | Disk Used | Time | Disk Written |
|-------------|-----------|------|---------------|
| geth | 21GB | 5h00 | 150GB |
| geth --fast | 4.2GB | 21m | 35GB |
| geth export | 1.5GB | 10m | |
| geth import | 21GB | 3h30 | |
--------------------------------------------------
Benchmarks done on i7 3720QM 16GB ram with Parity 1.2 (Homestead with 1.6Mi blocks)
_____________________________________________
| Option | Disk Used | Time | Disk Written |
|--------|-----------|------|---------------|
| archive| 19.GB | 2h00 | 300GB |
| fast | 3.7GB | 1h30 | 20GB |
| light | 2.5GB | 2h00 | 130GB |
---------------------------------------------
Note: When you have a node with a blockchain, you can dump the chaindata of geth directory to use it with your other computers. I check it with Linux, Windows and OS X.
Note: if you use --cache with 1024, it could be faster. But it is not significant on my system. The same goes for the --jitvm
Note: the ethereum blockchain saved the final state after transactions but it is safer to replay the transactions to check them.
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 simply have to run the following in a terminal :
ps ux | grep geth
And the result should be something like that:
myuser 15745 2,3 3,2 573464180 530888 ?? S 1:16 0:38.72 /Applications/Ethereum-Wallet.app/Contents/Frameworks/node/geth/geth --fast --cache 512
Indicating your node is running in default mode which is fast mode.
or
myuser 15745 2,3 3,2 573464180 530888 ?? S 1:16 0:38.72 /Applications/Ethereum-Wallet.app/Contents/Frameworks/node/geth/geth --syncmode fast --cache 512
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.
Best Answer
Just tested with geth 1.5.6, the default is
full.Yes, mist uses (in most cases) geth as Ethereum node, so if you run
geth --fast, mist will work in fast mode. However, if you stop ageth --fastnode, and restart it, it will resume infullmode as far as I remember. This means, after shutting down geth, and starting mist, it will start a full node. But that terminology is misleading in some cases, and you should probably read on here:Light client was just very recently released and you should expect hiccups. The same goes for mist if you use a geth node in
lightmode. As if Ethereum Stack Exchange isn't awesome already, check out this post:Yes, that is possible. Running a full node, i.e.,
creates a full copy of the blockchain in
~/.ethereum/geth/chaindata/.Running a light node, i.e.,
creates a directory for the state in
~/.ethereum/geth/lightchaindata/. To run both clients at the same time, you need some additional adjustments such as IPC path, ports, etc.However, if you want to run a
--fastsync, this only works on the first run ofgeth. If you already synced the full chain, you will get a message like this if you run geth in fast mode:If you insist on keeping a full and a fast copy of the blockchain on the same device, you can use the
--datadirswitch.