术语表 /开发者参考
MSG_BLOCK
- MSG_BLOCK 是什么？
- MSG_BLOCK 是清单类型2，即节点在 getdata 消息中使用的代码，用于按哈希值向对等节点请求一个完整的区块。
四个字节的类型标记决定会收到几种区块格式中的哪一种。类型2指原始格式：一个80字节的区块头，后接全部完整交易，见证数据已剥离，总量最多为一个区块可容纳的四百万权重单位。正在追赶区块链进度的节点会发出成千上万个这类请求，几乎不发其他内容。
运作方式
MSG_BLOCK 是一个数字而不是一条消息，只有在由 inv 和 getdata 消息构成的36字节条目中才有意义。
一个条目由四字节的类型和32字节的哈希组成，类型告诉接收方该哈希指向什么。发送带有类型2条目的 getdata，意思是：我有这个区块的哈希，请把区块发给我。对等节点会以一条 block 消息作答，如果无法提供，则返回 notfound。修剪节点对已经删除的任何内容都返回 notfound，因此修剪节点对从零开始同步的人毫无用处。
如今单独的类型2所指的范围比过去更窄。自隔离见证于2017年激活以来，以这种方式请求的区块会以旧的序列化格式返回，并去除见证数据，这是为了让旧版软件仍能得到服务。任何要验证该区块的节点都需要这些见证数据，因此会设置0x40000000 位，改为请求带见证数据的版本。在两个现代对等节点之间，这个普通代码主要出现在无人更新的软件所发出的请求中。
区块的广播方式也有所变化。BIP130 引入了直接区块头广播，自 Bitcoin Core 0.12.0起，新区块通常用 headers 消息而不是 inv 来广播，因此这个类型代码现在主要出现在对话中请求的一方。
Bitcoin Core 在下载时不会无限制地向前推进。它在已验证的最后一个区块之后保留1,024个区块的窗口，因此单个停滞的对等节点不会让该节点持有一个无法连接的、无限增长的区块队列。
在哪里会遇到它
区块请求只在节点首次同步期间占据其流量的主要部分，此后几乎不再如此。
在2024年4月20日的减半时，区块链已超过840,000个区块，并且每天大约增加144个区块，因此一台从零开始的机器要获取近100万个区块才能同步到最新。您可以用 getpeerinfo 观察这一点，它会按消息类型统计每个对等节点的字节数，也可以在日志中使用 -debug=net 查看。节点到达链的最新区块后，这些计数器就会安静下来，由紧凑区块流量接手。
MSG_BLOCK vs MSG_CMPCT_BLOCK
MSG_BLOCK 和 MSG_CMPCT_BLOCK 的区别既在于获取的内容，也在于允许使用的场合。类型2可用于 inv 和 getdata，可以无需事先约定发送给任何对等节点，并且适用于任何区块龄的区块。类型4只能用于 getdata，只能发送给已通过 sendcmpct 消息提供紧凑区块的对等节点，并且在 Bitcoin Core 中仅对最近的五个区块提供服务。用类型4请求更早的区块，返回的仍是完整的 block 消息。