Overview
Erlay is a proposed improvement to Bitcoin's peer-to-peer transaction relay protocol, specified in BIP330. It replaces the current flood-based transaction announcement system with a hybrid approach that combines limited flooding with periodic set reconciliation between peers. The result is an estimated 40% reduction in the bandwidth consumed by transaction relay, which accounts for a significant portion of a node's total bandwidth usage. Erlay was designed by Gleb Naumenko, Pieter Wuille, Gregory Maxwell, Sasha Fedorova, and Ivan Beschastnikh, with the research paper published in 2019.
The bandwidth savings from Erlay have implications beyond simple efficiency. By making it cheaper to maintain connections to many peers, Erlay would allow nodes to increase their connection count without proportionally increasing bandwidth costs. More connections per node means better network connectivity, faster transaction propagation, and greater resistance to eclipse attacks, where an attacker isolates a node by surrounding it with malicious peers.
How Current Transaction Relay Works
Current Flood-Based Relay (INV announcements):
────────────────────────────────────────────────────
Node A receives a new transaction (TxID: abc123)
Node A ──INV(abc123)──→ Peer 1 (already has it)
Node A ──INV(abc123)──→ Peer 2 (requests full tx)
Node A ──INV(abc123)──→ Peer 3 (already has it)
Node A ──INV(abc123)──→ Peer 4 (already has it)
Node A ──INV(abc123)──→ Peer 5 (already has it)
Node A ──INV(abc123)──→ Peer 6 (requests full tx)
Node A ──INV(abc123)──→ Peer 7 (already has it)
Node A ──INV(abc123)──→ Peer 8 (already has it)
Result: 8 INV messages sent, but 6 were redundant
(~75% wasted announcements)
────────────────────────────────────────────────────
In the current protocol, when a node learns about a new transaction, it announces the transaction ID (via an INV message) to every connected peer. Each peer that does not already have the transaction requests the full data. In practice, because transactions propagate quickly through the network, most INV announcements are sent to peers that already know about the transaction. This redundancy wastes bandwidth, and the problem scales with the number of connections: doubling a node's peer count roughly doubles its announcement bandwidth.
How Erlay Improves This
Erlay Hybrid Relay:
────────────────────────────────────────────────────
Phase 1 — Limited Flooding (fast, for speed):
Node A ──INV(abc123)──→ Peer 1 (1 outbound peer)
Node A ──INV(abc123)──→ Peer 2 (1 outbound peer)
(Only floods to ~8 outbound connections)
Phase 2 — Set Reconciliation (efficient, periodic):
Every few seconds, Node A reconciles with each peer:
Node A: "Here's a sketch of my mempool txs"
Peer 3: "Here's my sketch"
(Minisketch set reconciliation identifies differences)
Result: Only genuinely missing transactions are exchanged
Bandwidth: O(difference) instead of O(total)
────────────────────────────────────────────────────
Erlay uses a two-phase approach. In the first phase, a node floods new transaction announcements only to a small number of outbound peers (approximately 8), ensuring that transactions still propagate quickly across the network. In the second phase, nodes periodically perform set reconciliation with all other peers using a technique called Minisketch, a library implementing the PinSketch algorithm for efficient set difference computation.
During reconciliation, two peers exchange compact "sketches" of their mempool transaction sets. These sketches are much smaller than the full lists of transaction IDs, and from the sketches, each peer can determine exactly which transactions the other has that it does not. Only the genuinely missing transactions are then requested and transferred.
Benefits for Network Security
The most significant benefit of Erlay is not just bandwidth savings but the security improvements those savings enable. Currently, Bitcoin Core nodes maintain connections to about 10 outbound and up to 125 inbound peers. Increasing the outbound connection count would improve resistance to eclipse attacks, but under the current protocol, each additional connection linearly increases bandwidth consumption.
With Erlay, the bandwidth cost of reconciliation grows with the size of the set difference (transactions one peer has that the other does not), not with the number of connections. This means a node could maintain 32 or more outbound connections with less total bandwidth than 10 outbound connections under the current system. More outbound connections make it exponentially harder for an attacker to isolate a node.
Implementation Status
Erlay has been under active development for Bitcoin Core since the research was published in 2019. The implementation has progressed through multiple stages, with the Minisketch library merged into Bitcoin Core's dependencies. Full Erlay support requires changes to the P2P protocol layer and has been implemented incrementally. Once deployed, the upgrade would be backward-compatible: Erlay-capable nodes would use set reconciliation with each other while falling back to flood-based relay when communicating with older nodes.
Related Concepts
- P2P — The peer-to-peer network layer that Erlay improves
- Node — The network participants that benefit from reduced bandwidth
- Broadcast — The current flood-based relay mechanism that Erlay partially replaces
- Mempool — The transaction pool that peers reconcile using Erlay
- Eclipse Attack — The attack vector that Erlay mitigates through more connections