标准区块中继

每一跳都要经历两次往返，传输一兆字节或更多的数据，而其中大部分接收方早已拥有。2013年的一项测量研究显示，节点得知新区块的时间中位数为区块被找到后6.5秒，平均值为12.6秒。Bitcoin Core 于2016年8月23日在0.13.0版本中推出了紧凑区块中继，标准中继随之成为备用方式。

运作方式

标准区块中继使用三种消息，并且不对接收节点已持有的数据做任何假设。

发现区块的一方发送 inv 消息，给出新区块的哈希；自 BIP130 在 Bitcoin Core 0.12.0中引入以来，也可以发送 headers 消息，直接携带80字节的区块头，从而为对等节点省去一次单独的 getheaders 往返。接收方检查自己是否已有该区块。如果没有，则回复 getdata。随后发送方传输 block 消息：区块头之后是每一笔完整序列化的交易，总量不超过限定一个区块的400万权重单位上限。

这种浪费一经说明便一目了然。运行了数小时的节点，其内存池中已有该区块中几乎全部的交易，因为每笔交易在广播时都已单独收到。标准中继把它们全部再发送一遍。对于一个装满普通支付的区块，这意味着每个对等节点、每个区块都有远超一兆字节的重复传输。

其后果并非只是不够美观。传播缓慢会提高过期区块的比例，因为尚未得知新区块的矿工会继续在旧的链端上挖矿。过期区块给小型矿工造成的损失大于大型矿工，因为大型矿池能立即得知自己挖出的区块。因此，更快的中继既是效率问题，也是去中心化问题，它既推动了 BIP152，也推动了大型矿池之间运行的专用中继网络。

标准中继并未消失。当对等节点从未协商使用紧凑区块、紧凑区块重建失败而缺失的交易无法补全时，会采用标准中继；在初始区块下载期间也一直如此，此时同步中的节点会通过 getdata 同时向多个对等节点请求完整区块，在 Bitcoin Core 中每个对等节点最多可同时有十六个请求在途。

在哪里会遇到它

标准区块中继最明显的时候，是节点追赶进度期间，而不是已经同步完成之后。

在初始同步期间，用于请求区块的 getdata 占据了大部分流量，getpeerinfo 中按消息统计的计数器对此显示得很清楚。节点追上链端之后，这些计数器趋于平静，改由紧凑区块的计数器接手。网络连接较慢或对等节点较少的机器更常退回到标准中继，症状是链端落后于公共区块浏览器显示的状态一两分钟。

标准区块中继 vs 紧凑区块中继

标准中继发送区块本身；紧凑中继发送对区块的描述，由接收方重建其余部分。cmpctblock 携带区块头、一个随机数，以及每笔交易的六字节短标识符，因此包含几千笔支付的区块可以用不到二十千字节来描述，而不是远超一兆字节。接收方将这些标识符与自己的内存池比对，用 getblocktxn 请求缺失的部分，并在本地组装区块。之后的验证完全相同：紧凑中继改变的是字节到达的方式，而不是什么算作有效区块。