The Flood That Nobody Talks About
Your node just received a transaction. Before you've finished processing it, forty peers are already queuing the same forty-byte fingerprint to send back out into the network, each one triggering its own cascade of identical announcements, none of them coordinating with the others, all of them doing the same redundant work at the same moment. Nobody calls this a problem. It's just how Bitcoin has always moved transactions around.
Erlay is Bitcoin's answer to that weight. Instead of announcing every transaction to every peer, a node using Erlay announces to a small number of peers directly and reconciles the rest using a compact mathematical sketch. Bandwidth use for transaction relay drops by an estimated 40 percent on a well-connected node, and the savings compound as connectivity grows. That asymmetry between inbound and outbound peers is exactly where the two approaches diverge most sharply.
How INV-Based Relay Actually Works
The current system is simple to the point of bluntness. When your node receives a transaction it hasn't seen, it queues an INV message for each peer that, as far as your node knows, doesn't have it yet. The peer replies with a GETDATA if it wants the full transaction, and you send it. Done.
The elegance is in the simplicity. The problem is the redundancy.
A reasonably connected node, say one with fifty peers total, will receive the same INV announcement from multiple peers before it has even finished processing the first one. Those duplicates are almost entirely wasted bandwidth. The node tracks which peers announced what (to avoid sending back to the source), but there is no coordination between peers about who is announcing to whom. Everyone shouts the same message into the same room.
Under asymmetric connectivity, this gets lopsided fast. Inbound connections are initiated by other nodes; your node didn't choose them, and they may themselves be highly connected. A single popular transaction can arrive via dozens of inbound peers within milliseconds of each other, each one triggering a queued INV announcement back outward. The node is simultaneously receiving redundant announcements and preparing to send redundant announcements. The work scales with the number of connections, not with the number of new transactions.
The Sketch at the Heart of Erlay
Erlay, specified in BIP-330 by Gleb Naumenko, Pieter Wuille, Gregory Maxwell, Sasha Fedorova, and Ivan Beschastnikh, replaces most of that flooding with set reconciliation, specifically a data structure called a PinSketch built on BCH codes.
The concrete mechanism runs as follows. Two peers each hold a set of transaction IDs they believe the other might not have. Instead of listing every one, each peer computes a compact sketch of its set. The sketches are exchanged, XOR'd together, and the result can be decoded to reveal the symmetric difference: the transactions one peer has that the other doesn't, in either direction.
Work through a small example. Your node knows about transactions A, B, C, D, and E. Your peer knows about A, B, C, and F. The symmetric difference is {D, E, F}. A sketch sized to handle three differences takes roughly three times sixty-four bits, around twenty-four bytes total, regardless of how many transactions both nodes share. Compare that to five separate INV announcements at forty bytes each. The sketch behaves like a phone bill charged per new item rather than per item owned: the larger the overlap between peers, the cheaper reconciliation gets relative to flooding, and overlap between peers is almost always large.
The reconciliation round happens on a schedule, roughly every eight seconds per peer, rather than immediately on receipt. That delay is a real tradeoff: latency increases slightly compared to pure flooding. Erlay compensates by keeping low-fanout direct announcements for a small number of outbound peers, preserving fast propagation for the network's critical paths while reconciling the rest.
Where Asymmetric Connectivity Changes the Math
This is where the two approaches separate most visibly.
Under INV relay, adding more inbound peers is almost purely a cost. Each new inbound connection means more duplicate announcements arriving and more outbound INV messages queued. A node that goes from eight inbound peers to forty sees its relay bandwidth scale close to linearly. The node doesn't get smarter or faster. It just does more of the same work.
Under Erlay, inbound connections participate in reconciliation. The sketch exchange cost grows slowly with the number of differences to resolve, not with the total number of shared transactions. A node with forty inbound peers and eight outbound peers doesn't pay forty times the announcement cost; it pays forty small sketch-exchange costs, most of which resolve near-zero differences because Bitcoin's mempool converges quickly.
Consider two node operators, both running full nodes on residential connections with modest upload caps. Call them Tariq and Mina. Tariq runs the current INV-based software with fifty peers. Mina runs the same hardware with Erlay enabled and the same fifty peers. Over a busy month, Tariq's node burns significantly more upstream bandwidth on transaction announcements alone, because every announcement fans out as a separate message to each peer. Mina's node sends the same transactions but batches the announcements into periodic reconciliations. Her node stays within her upload budget. Tariq's starts throttling.
Inbound peers are the majority for most nodes, the connections you didn't negotiate. Under INV, they're a cost center. Under Erlay, they're closer to a break-even.
One Honest Caveat
Erlay is not free. The reconciliation sketches introduce real implementation complexity, and the eight-second batching interval measurably increases transaction propagation latency compared to pure flooding. For the median transaction the delay is small enough to be irrelevant. For a miner racing to include a high-fee transaction before a competing block arrives, every second matters, and I'd argue that Erlay's decision to preserve direct-announcement fanout on outbound peers specifically for those cases is the right call, not a compromise.
The bandwidth savings are also most dramatic on high-connectivity nodes. A node with eight peers total will see modest gains. That's not a flaw in the design; the protocol was built with the network's future in mind, where higher default peer counts become feasible precisely because the bandwidth cost stops scaling so aggressively.
So ask yourself: if connectivity itself is the bottleneck on how robust the network can get, what's the cost of leaving that bottleneck in place?
The real argument for Erlay isn't that it makes today's nodes cheaper, though it does. It's that it breaks the link between connectivity and cost entirely, making a denser, more resilient network achievable without requiring every participant to pay for a data center uplink. The flood was always a tax on connection. The sketch is how you stop paying it.