Erlay 是一种在 Bitcoin P2P 网络中传播未确认交易的提案。它把常规通告与标识符集合比对结合起来，后者称为 set reconciliation。这能节省流量，但不会改变共识，也不会免除节点验证每笔收到交易的责任。
在常规传播中，相连节点通过 INV 消息发送 32 字节的交易标识符。邻居往往早已知道这笔交易。连接越多，这类开销越大；然而，多样化的连接又有助于防止节点被隔离和网络被分割。 [1]
Erlay 在少量连接上保留快速通告。在其余连接上，两个节点定期比对尚未向对方通告的交易集合。它们无需传输完整列表，而可以用名为 sketch 的紧凑数学摘要找出差异。BIP 330 描述了所需的 P2P 协议扩展。 [1]
每条连接都有独立的集合，每轮比对使用该集合的固定快照。双方各提供一个 salt，即从 wtxid 派生 32 位短标识符时使用的辅助输入。PinSketch 用于比对这些标识符的集合。sendtxrcncl、reqrecon、sketch、reqsketchext 和 reconcildiff 消息负责协商支持、交换摘要以及找出缺失的通告。 [1]
发现差异后，节点仍须请求完整交易，并按照自己的规则验证。Salt 增加了预先计算短标识符碰撞的难度；它不是密码，也不负责加密交易。如果摘要容量不足，可以请求扩展；比对失败时，协议退回常规通告。实现还必须限制计算量和内存占用，避免对端轻易耗尽资源。 [1]
2026 年 10 月检查时，BIP 330 的状态为 Draft，其流程相较原始论文已有调整。Bitcoin Core 第 34542 号讨论重新评估了流量节省、延迟和代码复杂度。这本身不能证明某个 Bitcoin Core 版本正在使用 Erlay。判断依据应是该版本的发布说明、实现，以及双方节点实际协商的支持情况。 [4]
2019 年论文在其试验条件下报告，总流量大约减少 40%，交易通告流量减少 84%。这些是模拟和原型的结果，并非对所有当前网络的保证。等待下一轮可能增加延迟；只接收而不转发交易的节点还可能进一步拖慢传播。因此，流量节省和传播速度需要一起衡量。 [2]
Erlay 减少未确认交易的重复通告。Compact Blocks 则利用节点大多已经知道的交易，减少重建新区块所需的数据。两者互补，但单靠其中任何一个都不能隐藏节点的网络身份。两者也都需要各自的失败处理和资源耗尽防护。 [3]
先确认 BIP 330 的版本以及节点实际运行的代码。检查支持协商、短标识符与 salt 的派生过程、各轮时间安排、摘要限制和 reqsketchext 的行为。还要检查如何退回常规通告，以及随后如何验证完整交易。仅凭 Erlay 这个名称，无法证明实际节省了多少流量或产生了多少延迟。 [1]
要获得更完整的理解，请将本词条与以下词条结合阅读： Mempool, Bitcoin Core, Compact Blocks, Full Node, Sybil Attack, Eclipse Attack. 反向关联还来自： Block Propagation.
01BIP 330 是否意味着我的 Bitcoin Core 已经使用 Erlay？+
不是。规范本身不能作出这样的保证。应检查具体版本、实现以及双方是否协商了支持。试验代码或研究论文不等于你的节点上已经启用的功能。
02Erlay 会取代交易验证吗？+
不会。它帮助发现对方缺少哪些通告。节点仍须请求完整交易，再按照自己的规则决定是否接收到 mempool 中并继续转发。