Stream compression cuts an Ethereum node's inbound gossip by a quarter
Serguey Asael Shinder2 min readEthereum consensus clients compress each gossip message with Snappy on its own. A post on the Ethereum Research forum on 24 September measures what happens if the compressor keeps its history across the messages on a stream instead, so that bytes repeated between messages are sent once and referenced afterwards. The work came out of networking research for faster finality, where attestation and aggregate traffic is expected to grow; the authors note the post was written with Claude.
The measurement is concrete. The team hooked a handler into Teku's gossip pipeline, right after libp2p's protobuf codec, and recorded every frame from a mainnet node subscribed to all attestation subnets with about 45 peers for roughly 95 minutes, using 20 minutes to train and 60 to evaluate. Keeping a 64 KiB history in the unmodified Snappy block format, a node with the default two attestation subnets would receive 72.8% of today's bytes; with all subnets, 63.1%. A 1 MiB history brings the all-subnets figure to 54.3%, and zstd with a per-stream context to 51.2% - the source of the headline "up to 2x". Data column sidecars, already dense, stay at about 96% under every scheme.
Two known inefficiencies disappear without protocol-level fixes: the topic string attached to every message shrinks to a back-reference of a few bytes, and the AttestationData shared by a slot's attestations and aggregates is effectively transmitted once per stream, leaving an attestation at about 117 bytes, mostly signature and indices. A prototype between real mainnet nodes, one on plain gossip and one on a new /snappy-stream protocol, saw exactly the same message counts in every category over 40 minutes.
What it means
This is a research proposal, not a specification change - there is no EIP and no client has committed to it. Its appeal is that it is cheap to adopt: the decoder is today's Snappy decoder plus a history buffer, with the same bound against decompression bombs, and it can be negotiated per connection. Bandwidth is one of the main costs of running a home validator, and a quarter off inbound gossip for a default node is material.
The trade-off worth watching is state. A per-stream history means each peer connection carries a buffer that must be kept in sync, and a lost or reordered frame becomes harder to recover from than an independently compressed message. The prototype's matching message counts are a good first result; the next evidence to look for is behaviour under packet loss and peer churn, and whether client teams pick it up for the fast-finality work that motivated it.