先看输入输出，不急着比较谁更短
搜索区块链压缩算法时，常会遇到把序列化、压缩与哈希都叫作“数据变小”的介绍。它们的目标并不相同：序列化把带有类型与字段的数据组织成约定的字节表示，压缩把已有字节换成可还原的另一种表示，摘要则从输入计算出固定长度的核对值。
判断一项方案属于哪一类，可以先问它能否恢复原始字节、恢复后还需什么结构说明，以及留下的是完整数据还是核对依据。这比只看处理后的字符串长短更可靠。短字符串可能是编码后的摘要，并不是被压缩的数据文件。
以太坊请求响应中，SSZ和Snappy各做一层工作
以太坊网络层文档给出的共识层请求响应示例，是返回经过Snappy压缩的SSZ编码字节。SSZ负责约定结构怎样排列，Snappy负责压缩这份字节数据。因此，读取响应时不能只知道“这是SSZ”，也不能只完成解压就认为已经理解所有字段。
文档解释，SSZ使用偏移信息帮助定位消息的部分内容，并为与默克尔结构结合进行设计。这些是结构访问与表示规则的能力，不等同于通用压缩率。SSZ编码再经过Snappy处理，也不意味着可以随意替换其中一层而仍与原协议兼容。
浏览器的压缩接口说明了可还原边界
MDN对Compression Streams API的说明展示了gzip和deflate数据流的压缩与解压接口。这个例子有助于理解压缩前后仍代表同一份待还原数据，但它不是以太坊Snappy实现，也不能把gzip数据交给按Snappy约定读取的协议。
假设一份本地记录序列化后为一千字节，某次压缩得到六百字节，按这两个数字可以说压缩后大小是原来的六成，节省四成。这是虚构算例，不是网络实测。要复现结果，还需保留原始样本、格式和测量位置；不能把十六进制文本字符数与二进制字节数混在同一个分母里。
哈希承诺留下核对依据，不替代原数据
MDN的digest说明明确，摘要从可变长度输入生成固定长度输出；例如SHA-256输出二百五十六位，也就是三十二字节。这个固定长度不表示任意大文件都能压缩为三十二字节后再无损展开。摘要不是这种还原接口。
在使用哈希或默克尔根作为数据承诺时，必须说明被约束的是哪种表示，以及核对采用什么构造规则。不能默认“对压缩包做一次哈希”就等于协议定义的对象根。原始字节、压缩字节和结构化对象处于不同层次，相同的算法名称无法抹去这种差别。
报告节省量时，也要写清没有证明什么
一份清楚的技术记录应写明处理对象、序列化规则、压缩格式、压缩前后字节数及能否正确还原。如果还涉及摘要，应另列摘要输入与算法，不把摘要长度列入压缩后的存储容量。这些项目对应不同的核对问题。
单个消息变小，可以说明该样本的传输表示得到改善，却不能单独证明历史数据不再增长、节点验证工作消失，或整条链吞吐量按同一比例增加。本文解释处理层次，不给出任何客户端的压缩性能排名或网络容量承诺。