ETH 全节点Archive（归档）模式数据量增长图
上述图表可通过链接查看：https://etherscan.io/chartsync/chainarchive
通过上表，可以看到截止2019年8月12日，以太坊的全部区块数据已经高达2.8T，如果按照比特币的方式搭建全节点，会是一个很痛苦的事，毕竟云硬盘也不是那么便宜的。
做数字钱包或交易所的开发人员里，有聪明人可能会意识到一个问题，在处理用户账户充值时，我们所关注的数据仅仅是从当前开始到未来这段时间的区块数据，那么巨大体积的历史区块数据没什么用处。
有问题，自然会有更聪明的人解决问题，鉴于ETH庞大的区块数据，并且不断在增长，ETH提供了三种同步模式：
- –syncmode "fast" Enable fast syncing through state downloads
- –syncmode "light" Enable light client mode
- –syncmode "full"
在Geth1.6以前，fast与full模式的命令参数为 --fast与--full。Geth 1.6版本及以后，两种命令参数都可使用。
使用方法，启动命令如下：
./geth --datadir "D:Program FilesGethdata" --syncmode "fast" --rpc --rpcapi "db,eth,net,web3,miner"
上面的命令指定了区块数据与秘钥文件的存储目录：D:Program FilesGethdata
也指定了同步模式是： --syncmode "fast"
同时开启了RPC方式模式： --rpc --rpcapi "db,eth,net,web3,miner"
本文中，我们需要关注就是： -- syncmode，下面对三种同步模式做一个介绍：
Full同步步骤：
获取区块的header
获取区块的body
从创始块开始校验每一个元素
PS：下载所有区块数据信息，所以此种方式的数据量会十分庞大
Fast同步：
获取区块的header
获取区块的body
在同步到当前块之前不处理任何事务，然后获得一个快照，像full节点一样进行后面的同步操作。沿着区块下载最近数据库中的交易，有可能丢失历史数据。比如，你的账户地址A上面有10个ETH，但转入的的交易存在于较老的历史交易中，此同步模式无法获取到交易的详细情况。
使用此模式时注意需要设置–cache，默认16M，建议设置为1G（1024）到2G（2048）。
Ligth同步：
仅获取当前状态。验证元素需要向full节点发起相应的请求。
此外，启动ETH节点时还可以增加--gcmode=archive，这个模式称为归档Archive模式，即归档节点，这种模式保存了最最最全的Ethereum节点数据，占用硬盘空间也会更大。其数据量比单纯的full模式数量还要大。这个参数很多人不知道，大部分也没法用这个启动模式，因为需要的存储空间实在太大。启动命令一般如下：
./geth --datadir "D:Program FilesGethdata" --syncmode "fast" --gcmode=archive --rpc --rpcapi "db,eth,net,web3,miner"
那么，作为交易所与钱包服务商，如何选择合适的模式呢？如果对安全性要求极高，并且有充足的硬盘资源，自然是选择Full模式。而对于一般情况下，可使用Fast模式，因为Full模式同步区块数据需要很长时间。截止到本文发文时间2019-08-12，Fast模式需要同步数据大小为132GB，相较于Full模式的2.8TB而言，小了很多。Light模式对于轻量级的移动钱包比较适用。
附，当前Fast模式数据量大小变化：
数据查看链接：https://etherscan.io/chart2/chaindatasizefast
BIZZAN(币严) 数字货币交易所官方网址：
www.bizzan.com