2

Archive nodes are only necessary if you're going to be querying historical nodes that are no longer on the state trie. That said, even fast-pruned nodes allow you to inspect some (configurable) depth of history on the state trie, so whether it's sufficient depends on your use-case. A cheat sheet: https://dev.to/5chdn/ethereum-node-configuration-modes-cheat-...


2

I can't speak to this specific chart but if you fast sync a Geth node the final result does include the state. So, I assume that this chart does include the state. It only includes the most recent state though.


1

USE PARITY instead of GETH We started geth many times but it stucked after sometime and we have need to restart ever but in parity case it's working fine.


1

For Geth v1.9.0, look here for some new details on sync time. Describes all three modes and times including some changes that one should know about. https://blog.ethereum.org/2019/07/10/geth-v1-9-0/ As of Aug 2, 2019 the size on disk for me was 356 GB and state entries went to 370 million. Takes a couple of days to sync with a ssd drive. Be patient. ...


1

I wrote a tiny python script to overview the process. It's here https://github.com/hayorov/ethereum-sync-mertics My output: 2019-05-06 01:00:32 avg: 1827 max: 1938 min: 1378 states/s remain: 136604075 states 4 peers eta@ 20:46:28.165828 2019-05-06 01:00:37 avg: 1864 max: 1938 min: 1378 states/s remain: 136595500 states 3 peers eta@ 20:21:14....


Only top voted, non community-wiki answers of a minimum length are eligible