BIP152介绍

Bitcoin BIP152-Compact Block

摘要

在比特币网络中传输压缩区块主要是为了节约带宽.

动机

从历史上看，比特币P2P协议对于区块转发的带宽利用效率并不高。即使邻居节点已经拿到了区块中的很多交易,在区块转发过程中每一笔交易都会被包含在转发的区块中.这导致了节点在接收区块的时候,出现接收带宽高峰,对于一些比其邻居节点更早收到区块的节点来说,这导致了它发送带宽高峰.当出现带宽高峰时,节点的缓存急剧增大,这使得消费者级的网络连接暂时处于不可用状态,也会增加该节点转发区块的延迟,等待区块的节点只能等待区块, 而不能向其他空闲节点请求区块.

因此,降低区块转发的带宽占用对于许多独立运行的节点是非常必要的.

BIP152的主要目标并非减少区块转发的延迟,但它在某些方面确实能够降低区块转发的延迟.另外,bip152的工作为未来降低区块转发延迟奠定了基础.

版本一规范

预期的协议流程

这个协议的使用方法有两种方式,这依赖于邻居节点的带宽,具体后续会讨论. "高-带宽"模式(“high bandwidth relaying”),节点可能只允许与少部分节点进行这种区块转发模式, 启用这种模式,需要将 sendcmpct消息的第一个字节标记为1. 在这种模式下, 节点广播包含short transactions ID的区块(发送消息是 compctblock). 甚至可能在完全验证完交易之前就会转发该区块. 在一些情况下,不需要更多的round trip, 接收节点可以重建区块然后立即进行处理. 如果接收节点发现一些交易不在本地的mempool(交易池)中时,则发送 getblocktxn/blocktxn 以请求缺失的交易.这可以降低带宽使用量,但是区块转发的延迟也会达到如今节点所用的1.5 * RTT最小时间.(本人注解: 如今所用指的是一般情况下比特币对区块的转发方式,参考比特币区块转发方式

“低带宽”("low-bandwidth)模式,启用的方式是把sendcmpct消息的第一个字节设置为0. 在这种模式下, 节点广播新的区块时采用通常的inv/headers的方式(BIP130中的叙述,完全验证完毕区块后再进行转发).接收方然后会发送 MSG_CMPCT_BLOCK getdata的请求, 后续会收到区块头和short transaction ID. 在一些情况下,不需要更多的round trip, 接收方可以根据区块头和short transaction ID直接构建区块然后进行处理, 虽然减少了带宽使用,但是传播区块花费的时间仍然是现在传播区块使用的1.5RTT. 当一些交易不在接收方本地的mempool中时,会发送 getblocktxn/blocktxn, 这需要额外的一个round trip,这使得区块转发的延迟成为2.5RTT,但是这仍然降低了区块转发的带宽使用情况. 因为TCP本身对较大的数据会有较大的延迟(通常是RTT的倍数), 因此即使2.5RTT的延迟下,这种模式整体延迟仍然可以有望降低传输延迟.

具体的实现细节参考bip152.