Erlay 与交易集合对账：比特币节点想少发一遍广告的新协议

洪泛的账单：每笔交易乘以每个对端

比特币网络里未确认交易的传播方式是洪泛：节点收到一笔合法新交易后，向绝大多数对端发一条 inv 公告“我有这个 txid/tx 了”，对端没见过的就去取。这个机制简单可靠，代价是账单随连接数线性膨胀——你每多开一条连接，每笔热交易就多发一条公告。对个人节点，八条出站加若干入站的默认配置下，交易中继约占节点带宽的两成上下（Bitcoin Optech 专题引述的测量量级）。真正被卡住的是野心：想让节点多带几十上百条入站连接、成为更高效的公共中继的运营者，会先被交易公告的乘法拖垮上行。

Erlay：公告一次，对账一摞

Erlay 由 Naumenko 与 Wuille 在 2019 年的研究论文中提出（发表于 ACM CCS 2019），协议规范以 BIP330 编号，配套实现用 minisketch 库。核心思路是把“每笔都喊”改成“定期核对清单”。节点仍然保留少量洪泛：向少数出站连接立即发 inv，保证热路径传播速度不变；对其余对端则不再逐笔公告，改为每过固定间隔做一次集合对账——双方各自把手里未确认交易集合压成一个很小的“草图”（sketch，基于短交易编号的压缩表示），互换草图后各自解出两个集合的差集，只补缺失的那部分交易。交易两边都有？这一轮对账几乎不花带宽。因为带宽不再按连接数乘算，节点才可能支撑大得多的连接规模——这是该协议被看作“为公共节点铺路”的原因。

收益数字与失败回退

协议论文报告默认八出站配置下中继带宽约省四成；后续测量（Bitcoin Optech 引述的 2025 年研究）显示对 8 条出站洪泛约省 35%，扩到 12 条约省 45%，代价是传播延迟略增。对账并非百发百中：当双方集合差异比预估大、草图解不动时，协议明确回退—— initiator 报告对账失败，双方退回传统 inv 洪泛各扫各的，保证新交易不会因为省带宽而传不出去。这类“先尝试高效、失败即回老路”的设计是它能谨慎推进的前提。

比特币核心里的现实进度

截至比特币核心 v29.0，源码里的相关选项是 -txreconciliation，帮助文本注明按 BIP330 启用交易对账、默认值为关闭，且归类为仅调试类选项；握手层的 sendtxrcncl 协商消息已进主干，对账跟踪器的内部框架也已合入。翻译一下现状：地基全部就位，开关默认按死。它还没有成为主网节点的默认行为，任何宣称“Erlay 已全网生效”的说法都不准确。启用后的收益与验证还需要网络级的观察周期——中继类改动牵一发动全身，内存池不一致等问题都可能影响对账效果，这类细节 Bitcoin Optech 的专题页持续跟踪，值得以它为准随读随更新。

与相近概念的边界

别把它和几个邻居搞混：compact blocks 与短交易编号解决的是区块内交易的重传，与未确认交易中继无关；Weldnet 式方案改的是块发现路径；Erlay 只动“未确认交易怎么告诉朋友”这一件事，块传播、IBD 同步均不受触碰。也别把“对账”理解成节点间共享内存池清单——交换的是压缩草图，差集解算在本地完成，双方都不暴露自己内存池的完整列表。对普通用户，这个协议目前唯一需要注意的是：不要在别人的教程里被怂恿打开一个实验开关然后以为优化生效；节点默认配置的洪泛中继仍是全网共识级的稳定行为。另一个值得跟踪的方向是它与内存池一致性的互动：集合对账的前提是双方对“该传什么”有一致预期，而各节点策略差异（费率门槛、包限制）会让内存池天然不完全相同，差集解算偶尔变大时回退洪泛的频率也会上升——这正是它需要长观察窗口的技术原因之一。

风险提示：本文为网络协议科普，不构成投资建议；协议实现状态随版本演进，请以比特币核心官方发行说明与 BIP330 文本为准。