[后羿聊以太坊]从以太坊源码分析geth中 full和fast之间的关系

软件环境

go:1.9.2

ethereum&GETH：v1.8.11-unstable

名词解释：

以太坊有三种同步的模式，full, fast, light

full 模式

从开始到结束，获取区块的header，获取区块的body，从创始块开始校验每一个元素，需要下载所有区块数据信息。速度最慢，但是能获取到所有的历史数据。

//命令：
geth –syncmode full

fast模式

获取区块的header，获取区块的body，在同步到当前块之前不处理任何事务。下载的数据大小约为50GB（截止2018-02-04）。然后获得一个快照，此后，像full节点一样进行后面的同步操作。这种方法用得最多，目的在不要在意历史数据，将历史数据按照快照的方式，不逐一验证，沿着区块下载最近数据库中的交易，有可能丢失历史数据。此方法可能会对历史数据有部分丢失，但是不影响今后的使用。

//命令：
//使用此模式时注意需要设置–cache，默认16M，建议设置为1G（1024）到2G（2048）
geth –fast –cache 512

light模式

仅获取当前状态。验证元素需要向full节点发起相应的请求。

//命令：
geth –light

重点说明：

> geth help

DEPRECATED OPTIONS:
  --fast   Enable fast syncing through state downloads (replaced by --syncmode)
  --light  Enable light client mode (replaced by --syncmode)

在Geth1.5以上版本，--fast参数已经改为--syncmode=fast，当然--fast依旧有效。 大家应该注意到没有--full选项，因为以太坊同步区块默认是full。

  --syncmode "fast"                               Blockchain sync mode ("fast", "full", or "light")

注意：默认情况下full模式，在以太坊源码中，如果本地当前块是number 0 （创始区块），不管指定的哪种模式都默认是 --fast模式，当geth第二次启动的时候，默认情况下full模式同步。
因此很多小伙伴在没有指定同步模式的时候，在同步区块的前期非常快，当再次重启机器或者断掉geth再启动发现更新区块速度非常慢，就是这个原因

==此判断代码片段位置==

handler.go 代码中 新建以太坊子协议管理器

func NewProtocolManager()

    // Figure out whether to allow fast sync or not
    if mode == downloader.FastSync && blockchain.CurrentBlock().NumberU64() > 0 {
        log.Warn("Blockchain not empty, fast sync disabled")
        mode = downloader.FullSync
    }
    if mode == downloader.FastSync {
        manager.fastSync = uint32(1)
    }