Erlay

Announcing transactions is the largest single use of a node's bandwidth, and the cost grows with every peer added. Gleb Naumenko and Pieter Wuille wrote the design up as BIP330, where it remains a draft: no release of Bitcoin Core turns it on. It matters because it decides how cheap running your own node is allowed to get.

How it works

Erlay attacks a redundancy that becomes obvious once counted: a node currently tells every one of its peers about every transaction it hears, and most of those peers already knew.

The present method is flooding. Each new transaction is advertised in an inv message carrying a type code and a 32 byte identifier, so 36 bytes per announcement per peer. Bitcoin Core opens 8 outbound connections for transaction relay by default and will accept inbound peers up to a total of 125, so a well connected machine sends and receives the same short message dozens of times over for something it was going to learn about anyway. The waste is proportional to connection count, which punishes exactly the behaviour that makes the network harder to split.

Erlay keeps a little of the flooding and replaces the rest with set reconciliation. Each pair of peers tracks the announcements it has not yet exchanged with the other. Periodically one side requests a sketch of that set. A sketch is a fixed size algebraic summary whose length depends on how many differences are expected rather than on how many transactions either side is holding, and combining two sketches yields precisely the entries one peer has and the other lacks. The minisketch library, which Bitcoin Core has carried in its source tree for years while the relay protocol around it stayed unmerged, implements the construction and the decoding.

Guessing the sketch size wrong is not fatal. When decoding fails because the difference was bigger than estimated, the peers extend the sketch and try again rather than starting from scratch, so a poor estimate costs a little extra bandwidth instead of a full resynchronisation.

Where you see it

You do not see Erlay yet, and that is the honest answer for anyone hunting for it in a node dashboard.

What you can see is the problem it aims at. Call getnettotals on your own node and the byte counters show relay traffic dominating everything except the initial download of the chain. Operators on metered connections already respond by capping upload with maxuploadtarget or by cutting the number of peers they keep, and both choices weaken the network a little in order to lower a bill.

That is the tradeoff Erlay is meant to dissolve. If bandwidth stopped scaling with connection count, a node could safely hold far more peers, and a densely connected network is much harder to partition or eclipse. For someone whose only interest is verifying their own coins rather than trusting an explorer, the promise is narrow and real: the same verification over a cheaper connection.

Erlay vs compact block relay

Erlay concerns transactions before they are mined; compact block relay concerns blocks after. The two answer different bottlenecks and have been judged by different clocks. Block propagation is a latency problem, because every second a block spends in flight is a second some miner spends grinding on a tip that no longer exists, and the fix shipped in 2016. Transaction announcement is a volume problem, measured in gigabytes across a month rather than in milliseconds, so nobody has been in a hurry, which is why the proposal has sat as a draft for years.