Erlay

Erlay paper: https://arxiv.org/pdf/1905.10518.pdf

page 1:

Today, Bitcoin disseminates transactions by ensuring that every message received by a node is transmitted to all of its neighbors. This flooding has high fault-tolerance ... However, flooding has poor bandwidth efficiency: every node in the network learns about the transaction multiple times. Our em- pirical measurements demonstrate that transaction announcements account for 30–50% of the overall Bitcoin traffic.

Currently INV/TX messages are used in the flooding (36 bytes) and the actual transactions (a few 100s of bytes) are sent in an efficient way - without flooding/duplication where every node receives a given transaction just once.

What is meant by "transaction announcements"? INV/TX messages or actual transactions?

With some added counting, after running a listening node with ~100 connections for ~48 hours:

"totalbytesrecv": 1341343657,
"totalbytessent": 56168391051,
"totalbytesrecv_inv_tx": 661329290,
"totalbytesrecv_inv_tx_redundant": 613923732,
"totalbytessent_inv_tx": 706329175,
"totalbytessent_inv_tx_redundant": 111107520,
"totalbytessent_inv_tx_mempool": 0,

Sent+recv INV/TX is 2.4% from the total traffic (.totalbytesrecv_inv_tx + .totalbytessent_inv_tx) / (.totalbytesrecv + .totalbytessent) * 100.

From that 53% is redundant (.totalbytesrecv_inv_tx_redundant + .totalbytessent_inv_tx_redundant) / (.totalbytesrecv_inv_tx + .totalbytessent_inv_tx) * 100.

So, the redundant traffic is 1.2% (53% of 2.4%) of the total traffic.

Which part is Erlay aiming to optimize?

page 2:

The main idea behind our protocol is to reduce the amount of information propagated via flooding and instead use an efficient set reconciliation method

That is just 1.2%?

Repeated run over ~5 days, ending Oct 5 2022:

• redundant / total traffic: 3% (vs 1.2% measured before)
• average traffic speed: 120 KiB/s

On a non-listening node, over ~24h, ending Oct 5 2022:

• redundant / total traffic: 9%
• average traffic speed: 5 KiB/s