The base networking protocol (DEVp2p) used by Ethereum currently does not employ any form of compression. This results in a massive amount of bandwidth wasted in the entire network, making both initial sync as well as normal operation slower and laggier.
This EIP proposes a tiny extension to the DEVp2p protocol to enable Snappy compression on all message payloads after the initial handshake. After extensive benchmarks, results show that data traffic is decreased by 60-80% for initial sync. You can find exact numbers below.
Synchronizing the Ethereum main network (block 4,248,000) in Geth using fast sync currently consumes 1.01GB upload and 33.59GB download bandwidth. On the Rinkeby test network (block 852,000) it's 55.89MB upload and 2.51GB download.
However, most of this data (blocks, transactions) are heavily compressible. By enabling compression at the message payload level, we can reduce the previous numbers to 1.01GB upload / 13.46GB download on the main network, and 46.21MB upload / 463.65MB download on the test network.
The motivation behind doing this at the DEVp2p level (opposed to eth for example) is that it would enable compression for all sub-protocols (eth, les, bzz) seamlessly, reducing any complexity those protocols might incur in trying to individually optimize for data traffic.
Bump the advertised DEVp2p version number from 4 to 5. If during handshake, the remote side advertises support only for version 4, run the exact same protocol as until now.
If the remote side advertises a DEVp2p version >= 5, inject a Snappy compression step right before encrypting the DEVp2p message during sending:
{Code, Size, Payload}Similarly to message sending, when receiving a DEVp2p v5 message from a remote node, insert a Snappy decompression step right after decrypting the DEVp2p message:
{Code, Size, Payload}Important caveats:
Note: Snappy supports uncompressed binary literals (up to 4GB) too, leaving room for fine-tuned future optimisations for already compressed or encrypted data that would have no gain of compression (Snappy usually detects this case automatically).
Currently a DEVp2p message length is limited to 24 bits, amounting to a maximum size of 16MB. With the introduction of Snappy compression, care must be taken not to blindly decompress messages, since they may get significantly larger than 16MB.
However, Snappy is capable of calculating the decompressed size of an input message without inflating it in memory (the stream starts with the uncompressed length up to a maximum of 2^32 - 1 stored as a little-endian varint). This can be used to discard any messages which decompress above some threshold. The proposal is to use the same limit (16MB) as the threshold for decompressed messages. This retains the same guarantees that the current DEVp2p protocol does, so there won't be surprises in application level protocols.
Alternative solutions to data compression that have been brought up and discarded are:
Extend protocol xyz to support compressed messages versus doing it at DEVp2p level:
Introduce seamless variations of protocol such as xyz expanded with xyz-compressed:
Other ideas that have been discussed and discarded:
Don't explicitly limit the decompressed message size, only the compressed one:
This proposal is fully backward compatible. Clients upgrading to the proposed DEVp2p protocol version 5 should still support skipping the compression step for connections that only advertise version 4 of the DEVp2p protocol.
You can find a reference implementation of this EIP in https://github.com/ethereum/go-ethereum/pull/15106.
There is more than one valid encoding of any given input, and there is more than one good internal compression algorithm within Snappy when trading off throughput for output size. As such, different implementations might produce slight variations in the compressed form, but all should be cross compatible between each other.
As an example, take hex encoded RLP of block #272621 from the Rinkeby test network: block.rlp (~3MB).
You can verify that an encoded binary can be decoded into the proper plaintext using the following snippets:
Copyright and related rights waived via CC0.