在比特币网络里，一笔交易的字节就是它的“体积”：体积越大，占的区块空间越多，手续费越高；在带宽层面，节点间转发交易也按字节计费。BIP-337 提出的问题很直接：交易的二进制格式里其实存着不少浪费，能不能换一种更紧的写法，把同一笔交易的序列化缩短一半甚至更多？这份提案（Draft，编号于 2024 年 2 月分配）给出了一个纯序列化层的压缩编码方案。
浪费藏在哪里
典型交易的冗余来自四类。第一，固定字段大多取极少几种值：版本几乎总是 1 或 2，锁定时间绝大多数是零，标志字节出现与否也就是有无分隔符的两面之一。第二，数字用宽写窄：输入输出数量、序列号、脚本长度这些值常常小到个位数，但格式固定要写满四字节。第三，签名与公钥：某些场景下签名可以被精简编码，公钥本身可以从签名中恢复出来。第四，也是最狠的一招：每个输入都要写一份 36 字节的“前一笔交易哈希加序号”（outpoint），而这些坐标完全可以用“区块高度加块内序号”这类短引用替代——前提是允许一定的信息损失，解压时靠上下文找回来。
四种手段
对应地，BIP-337 的规格由四组方法组成：其一，交易前放一个元数据字节，把“有没有版本字段、标志位是什么、锁定时间是不是零”这类结构性事实打包进一位位的标记里，被标记为默认值的字段直接从字节流中省略。其二，把所有 32 位宽的数值改成变长整数——提案定义了两套：沿用 Bitcoin 风格的 VarInt，以及新的 CompactSize（小于等于 253 一字节直存，更大才加两字节或四字节小端尾数）。其三，压缩签名并利用可恢复签名从签名还原公钥，省掉单独写公钥的字节。其四，把 outpoint 换成高度加索引的短引用；这一步是有损路径，解压必须依赖交易以外的信息，因此提案把它标成可选——不启用 outpoint 压缩时，压缩后仍可达到原始大小的约七成以下，启用后常规交易可以压到原始大小的约一半以下，提案声称覆盖九成常见交易。
它站在哪一层
关键定位：这只是一个序列化编码，不是新脚本、新地址或新共识规则。交易经过验证时，全节点内部仍以标准格式解析语义；压缩格式解决的是传输与存储时的字节效率，以及提案设想的一个附加用途——配合隐写术，把压缩后的交易藏进图片在社交渠道传递。规范同时明确不需要改变现有交易的兼容性：它定义的是可选编码而非替换编码。也因此，截至本文写作，它的状态停留在 Draft，主要作为一套公开的编码设计存在，主流节点实现是否采纳、何时采纳，均需以提案与实现的后续讨论为准，读者判断落地程度时应去查阅最新状态而非依赖本文。
与相邻概念的边界
顺带划三条线，避免混淆。与隔离见证的关系：见证隔离改变的是签名数据在区块里的存放结构与计价权重，BIP-337 只换传输时的编码外壳，两者动机与层次都不同。与地址复用的关系：压缩不改变地址、脚本或任何链上字节，同一笔交易无论用哪种编码描述，上链后的交易哈希一致。与号称能省费的工具的关系：任何声称能让交易瘦身的第三方软件，最终都必须在广播前回落到标准序列化——检查它是否按共识规则计算费用，是用户唯一必须做的验证。
快速问答
问：压缩会影响手续费吗？ 答：手续费按链上标准序列化占的空间计算；只有当压缩编码真正进入共识计价口径才会改变费用，而该提案并未修改共识规则。
问：有损路径损失了什么？ 答：损失的是 outpoint 的完整 32 字节交易哈希，解压时需要外部上下文重建它；纯有损场景无法独立解压。
问：为什么不用通用 zip 压缩？ 答：通用压缩对逐笔小交易开销大且需流状态；交易结构高度规则化，针对性编码更省也更可预测。
风险提示：本文仅介绍协议提案机制，不构成任何投资建议；任何自称能压缩交易费用的第三方工具都需先核验其与标准实现的一致性。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。