Erlay

From Bitcoin Wiki
Jump to navigation Jump to search

Erlay is a proposed Bitcoin transaction-relay protocol, specified in BIP 330, that replaces most flooding of inv announcements with periodic set reconciliation. Peers exchange a compact sketch of the transaction identifiers each has seen and recover the symmetric difference, so that each transaction is not announced once per peer. The design was published by Gleb Naumenko, Pieter Wuille, and collaborators (ACM CCS 2019). Full Erlay is not enabled in a released Bitcoin Core version.

On the current gossip network, a node that accepts a new transaction sends an inv to most of its peers, who request the transaction with getdata if they do not already have it. The scheme is simple and latency-efficient, but the same transaction identifier is sent many times. Bandwidth per connection therefore grows with the number of peers. That cost discourages raising outbound connectivity, which is otherwise desirable for eclipse-attack resistance and for keeping the network well connected as it grows. Erlay's stated goals are to cut that redundant bandwidth (the original paper estimated on the order of 40% of announcement bandwidth in typical settings) and to make additional connections cheap enough that nodes can afford more of them.

BIP 330 introduces a reconciliation protocol. After the usual version handshake, peers that support Erlay send a sendtxrcncl message advertising parameters. Each peer maintains a reconciliation set of wtxid (witness transaction identifiers) that it would have flooded. At scheduled intervals the peers exchange a Minisketch sketch of that set. Minisketch is an efficient implementation of PinSketch-style set reconciliation over a finite field: a sketch of size proportional to the expected number of differences lets both sides recover the identifiers that only one of them has. Missing transactions are then requested with ordinary getdata and enter the mempool like any other relayed transaction.

Flooding is not eliminated. A small amount of fanout is retained so that a transaction still reaches the network quickly, after which reconciliation heals the remaining gaps. If a sketch is too small for the actual difference, an extension round can enlarge it, or the peers fall back to flooding that interval. The original “full Erlay” design folded flooding and reconciliation into every ordinary transaction-relay connection and tried to guess, per transaction, which mode to use. That policy logic became a large patch. In 2026 Bitcoin Core developers discussed a simpler alternative: leave existing full-relay connections unchanged and add a smaller number of reconciliation-only connections that carry little traffic unless the node's normal peers are unhelpful. Reconciliation-only links would then act as a partition-resistance backup rather than as a replacement for flood relay. Which of those shapes, if any, ships is not settled. Minisketch itself is merged as a library. The sendtxrcncl signaling message has also been merged. The remaining work is the reconciliation state machine, set management, and the associated tests.

Bitcoin Core does not reconcile transactions with Erlay in a stable release. Work is tracked in the Bitcoin Core repository (including the Erlay project tracking issue and draft pull requests for a full implementation). Other node software has not independently deployed BIP 330 as a production relay protocol. Compact blocks (BIP 152) remain the deployed bandwidth reduction for blocks; Erlay addresses transaction announcements. Related transport work such as BIP 324 (v2 P2P encrypted transport) is separate from Erlay's set-reconciliation design.

See also

External links