比特币网络里每个新块都要被几乎每台节点完整下载一遍，而这些交易里的绝大部分早就在节点自己的内存池里躺过了。区块传播优化的全部学问，就在于怎样不再把对方已有的数据重发一遍。比特币核心选择了 BIP 152 紧凑区块：收块方把自家内存池的交易编号清单原样发给对方，对方用集合减法只补缺失部分。XTHIN（全称 Xtreme Thinblocks，「极限薄块」）走的是另一条路：不发清单，改发一个用内存池内容播种的布隆过滤器。这个方案诞生于 2015 至 2016 年的扩容之争中，随后落地在比特币XT 这一替代实现里，比特币核心从未启用，后来的比特币 Unlimited 等实现沿用了同一套消息格式。
用布隆过滤器替代清单，赌的是什么
布隆过滤器是一种概率型集合摘要：把集合里每个元素过若干哈希，往一个位数组里点亮对应位。查询时如果某个位组合全部点亮，判定「可能在集合里」；只要有一位没亮，判定「肯定不在」。误差只朝一个方向——会漏报「没有」，不会漏报「有」。XTHIN 正是赌这个不对称：收块方把内存池装进过滤器随 GET_XTHIN 请求发出，出块方对照过滤器，凡是过滤器判定「可能在我的内存池里」的交易就只给 64 位短哈希，判定「肯定不在」的交易就发全文。收块方收到后本地能凑齐的凑齐；如果个别短哈希在本地撞不上唯一交易、或者复原出的默克尔根对不上，就走 GET_XBLOCKTX 二次请求补明细。正常路径一次往返收工，这是它相对早期两轮剪枝方案的核心卖点。
64 位短哈希与过滤器的两笔账
XTHIN 把交易标识从 32 字节砍到 8 字节，一块几万笔交易能省几百 KB。按生日悖论的粗算，要在随机集合里撞出一对 64 位截断哈希，集合规模得逼近二十亿这个量级；对应日常几十万笔的内存池，碰撞概率小到可以忽略——协议仍然规定撞上了就回退全哈希处理，而不是硬猜。另一笔账在过滤器大小上：内存池五十万笔级别的交易用千分之一误判率编码，布隆过滤器要占近一兆字节，和紧凑区块里「只发本块交易短编号清单」的做法相比更费带宽。实现因此做了折中——只把「更可能进下一个块」的交易装进过滤器来瘦身，误判带来的补发量则用二次请求兜底。把两笔账放在一起就明白：XTHIN 的带宽优势完全取决于双方的内存池重合度，网络通畅时它确实能把一个整兆的块压到几十 KB 量级；一旦内存池严重分叉，误判和补发会迅速吃掉省下的每一字节。
为什么它没能成为标准
技术上可以并列比较，历史上各有各的船票。比特币XT 当时绑定的是放大区块体积的议程，XTHIN 作为其旗舰特性，自然被核心阵营的实现路线排除在外；而核心的 BIP 152 紧凑区块用精确清单换确定性、用后续多轮补发换简单，最终被主流接受。后来的研究（Graphene 白皮书在效率对比里同时基准了两者）把三条路线摆在同一张图上：紧凑区块稳但多轮，XTHIN 快但吃过滤器体积，集合对账类方案则再省一个量级——这场竞争本身没有失败者，只是标准只签给了一个。今天你在比特币核心节点日志里搜不到任何 XTHIN 字样；它属于「存在过、验证过、被路线选择淘汰」的那类协议。
快速问答
问：XTHIN 和隔离见证时代说的「剪枝区块」是一回事吗？ 答：同一目标下的不同代际。剪枝方案要两轮往返先交换清单，XTHIN 用布隆过滤器把这一步压进首个请求。
问：它现在是某个正在推进的 BIP 吗？ 答：不是。XTHIN 从未成为活跃的 BIP 标准，可考的规范文本主要保存在比特币XT 与比特币 Unlimited 的源码文档里。
问：布隆过滤器误判会让节点收错块吗？ 答：不会静默收错。过滤器误判只导致多删或少发交易，最终必须过默克尔根校验，对不上就触发补发明细。
风险提示
本文是历史机制解读，不构成投资建议。不同比特币客户端实现的功能差异很大，选择节点软件请以官方仓库与版本说明为准；涉及协议行为的表述可能随实现修改，请以对应项目的文档为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。