Blocks-first 同步

如今已无人采用这种方式同步，原因在于算术：严格按顺序下载，最多只能利用一个对等节点的上传速度，而到2015年时，区块链已大到无法在合理时间内完成同步。这种技术作为协议中的后备手段保留下来，同时也成为旧文档中令人困惑的来源。

运作方式

状态：blocks-first 同步已被 Bitcoin Core 0.10.0中的 headers-first 同步取代，该版本发布于2015年2月16日。它所使用的消息仍是点对点协议的一部分，也仍会得到响应，但当前没有任何客户端依靠这些消息来追赶同步。

这一交换是两台机器之间的循环。您的节点发送 getblocks 消息，其中带有自己已有区块的哈希。对等节点回复一份清单，列出随后最多500个区块的哈希。您的节点用 getdata 请求这些区块，收到后对每个区块进行完整验证，然后再发送一条 getblocks 询问接下来的区块。如此重复数千次。

这一设计带来三个问题。第一，没有并行：向第二个对等节点请求尚未得知其存在的区块没有意义，因此整个同步只能以您恰好连接的那个对等节点的速度推进。第二，无法知道还有多远：区块链每次只透露500个哈希，因此旧版客户端无法显示有意义的进度条。第三，速度慢或怀有恶意的对等节点可以只是一点一点地喂给您数据，而您的节点没有低成本的办法得知别处有更好的区块链可用。

Headers-first 把廉价的证据和昂贵的证据分开，解决了这三个问题。先获取并验证区块头链（截至2014年12月，整个历史的区块头仅约27 MB），您就能在下载任何一笔交易之前，知道最佳区块链的形态和长度。随后可以同时向多个对等节点请求区块主体。其副作用是区块开始乱序到达、乱序写入磁盘，因此版本0.10.0创建的数据目录无法被更早的任何版本读取。

在哪里会遇到它它它

您遇到 blocks-first 同步的地方，是文档而不是软件。

2015年之前写成的参考资料，包括至今仍在流传的大量开发者资料，把这种顺序循环描述成比特币的工作方式。事实并非如此，把初始同步描述为从单个对等节点顺序下载的页面已经过时。Bitcoin Core 仍会响应 getblocks 请求，以照顾古老或特殊的客户端，因此这些消息会出现在抓包记录和协议规范中。

对于如今运行节点的人来说，没有需要配置的内容，也没有需要选择的项目。您的客户端先获取区块头，因为所有仍在维护的实现都是这样做的。

Blocks-first 同步 vs headers-first 同步

Blocks-first 同步和 headers-first 同步的区别在于最先请求什么，其余差异都由此而来。Blocks-first 按顺序请求完整区块，边下载边了解区块链的形态，因此发现最佳区块链和下载它是在同一次缓慢的过程中完成的。Headers-first 则把任务拆开：先用每个区块80字节的区块头，确定哪条区块链累积的工作量证明最多，再从任何愿意发送的节点并行收集区块主体。两种方式对每个区块所做的验证完全相同。改变的只是操作顺序，仅此一点就把初始同步从数周缩短到数小时。