文件体积不能独自解释一次传播
讨论区块链区块大小时，容易把完整数据对象的大小与一次网络消息的大小混为一谈。BIP-152针对比特币提出紧凑区块转发：利用节点可能已经拥有的交易，减少在节点间再次发送的数据。这是通信表示方式的问题，不是重新定义有效区块的容量。
因此，一份性能报告若只写区块有多大，仍不足以回答接收方实际下载了什么。本文围绕读取资料的方法展开，不比较不同链的容量上限，也没有运行节点或测量传播速度。需要先分清完整区块、初次消息和后续补充消息，再讨论传输负担。
紧凑消息利用已有交易，但不假设人人都有
BIP-152的相关结构包含区块头、用于匹配的短交易标识，以及少量直接提供的交易。接收节点会将短标识与本地可用交易相匹配，缺少的部分则需要通过相应请求与响应补齐。因此，即使接收的是同一个区块，不同节点已有资料不同，后续通信也可能不同。
可以设想两个接收者：甲已拥有所需交易，乙缺少其中一些。这个假设只是说明资料条件的差异，并不是一次实际测试。若报告只展示甲的初次消息，就不能据此断言乙也无需补充通信；也不能把短标识当作包含整笔交易内容的微型压缩文件。
带宽目标与延迟结果不要混写
该规范把节省区块转发带宽作为明确目标，并说明减少延迟不是这项工作的主要目标。协议存在不同转发模式，缺失交易可能增加请求往返。由此阅读性能数字时，应核对采用的模式、接收方资料条件以及计时终点，而不是从“紧凑”二字直接推出固定加速倍数。
对自己的说明表，可以分别记录初次消息字节数、补充消息字节数和从接收开始到资料完整的时间。这个表格设计是本文建议，不是BIP要求的统一计分标准。没有实际采样的栏位应留空；规范写作时期的测试比例，也不能直接充当今天任意网络连接的表现。
数据收到之后还有执行与验证
传输完成与内容通过验证也不是一个时点。以太坊网络层文档的接收区块流程中，共识客户端接收和预检后，还需要把执行载荷交给执行层执行交易、核验状态，再返回验证资料。这里是另一协议体系的处理阶段示例，不能把比特币紧凑消息格式直接套用到以太坊。
复核一项“区块处理很快”的表述时，最后应问它测到的是消息到达、交易补齐，还是所声明的验证阶段完成。较少的传输数据本身不证明计算量同比下降，更不证明一笔交易已获得最终确认。把通信优化与完整处理过程分开，才能避免用一个漂亮数字替代整个流程。