ETH节点同步时出现的问题
- 起初同步的速度很快， 在距离最新区块还有100个左右时，速度突然变慢，等待长时间，发现还是追赶不上
> eth.syncing
{
currentBlock: 5790584, // 同步到的区块高度
highestBlock: 5790660, // 所链接的节点的最高高度
pulledStates: 123621434,
knownStates: 123654211,
startingBlock: 0
}
- 明明
currentBlock显示已经同步到后面的区块，但是lastest区块依旧是0(创世区块)
> eth.getBlock("latest").number
0
- 查询某个地址的余额时，明明已经同步到的区块下应该是有余额的，但是通过
eth.getBalance()得到的还是0, 这个问题和上面的类似。
> eth.getBalance("0xa12d3......")
0
问题出现的原因
看似同步将要结束时，其实这只是完成了区块头信息下载的阶段，还需要等待状态下载完成，这个过程比获取区块要花费更多的时间。而且，状态的同步主要受磁盘IO限制，而不是带宽，所以才会有快要追赶上最新区块时，速度放慢，这是因为节点在做state下载。在同步未完成，是无法查询到过往的balance，合约中的state的。出现上述问题时，只有等待节点同步完成后，也就是:
> eth.syncing
false
就能正常获取过完的历史数据了。
解决方法
为了尽快同步完，建议：
同步时采用
fast模式，目前geth也默认采取fast模式同步。fast同步模式下，会先追赶上eth网络上的当前区块，然后对状态数据做一个快照，之后回像full节点一样进行后面的同步。full模式下的同步则会下载当前区块之前的每一条状态更变数据，整个同步的时间会持续很久。节点所在服务器采用更高的配置，内存最好16G或以上，硬盘选用SSD。这也是最行之有效的办法，笔者之前使用HHD硬盘，同步持续了2天都未结束，更换成SSD硬盘后，重新进行
fast模式下的同步，一个晚上就同步成功。为了加快同步速度，手动添加节点。在控制台可以通过``net.peerCount`查看当前节点连接的外部节点数量，如果已知有外部稳定的节点，可以执行以下命令添加：
> admin.addPeer("enode://0d1b9eed7afe2d5878d5d8a4c2066b600a3bcac2e5730586421af224e93a58cd03cac75bf0b2a62fd8049cd3692a085758cc1e407c8b2c94bb069814a5e8d0f0@209.9.106.245:30303")
true
- 在启动节点时设置缓存大小，有一定效果
# 最小16M，默认128M，可以根据内存情况适当扩大
geth --cache 1024
- 在第一次开启同步后，建议在同步完成(
eth.syncing显示false)之前，不要中断geth进程，否则建议删除此前的数据块，重新开始同步。
B计划
如果实在无法完成同步，可以使用第三方的节点服务。推荐infura提供的节点服务，稳定性不错，目前还是免费的。
