Here’s what I’m guessing digging into EIP-706, mostly after a few days playing with
It was introduced as a means to reduce network load on “full nodes”. No consideration was given to CPU/RAM, because that wasn’t the dire issue to be solved; and it tried to be simple.
It applies compression wholesale, to all messages past DEVp2p’s
Hello, including to all sub-protocols past DEVp2p, - e.g., when doing sync, peer exchange, or other fully-validating node communication. This produces (substantial) net savings through compressing bulk data. The overhead for
Disconnect was not considered, likely because it’s minuscule in comparison to “bulk data” benefits; probably also due to reviewers’ time constraints.
There is no negotiation of compression; it is applied strictly according to advertised DEVp2p version. Consequently, there is no provision to turn compression off. This was not considered, because there were no sub-protocols in widespread use that would be harmed by compression.
To address this (general) ungracefulness, I’ve started pondering (vaguely) of opening an EIP, proposing a version 6 of DEVp2p, where compression (or any feature, for that matter) is optional, requires explicit negotiation, and (perhaps?..) applies to sub-protocols’ messages only.
(OTOH, I’m starting to feel like I’m re-inventing IRC capability negotiation, or something…)
My interest got piqued after hearing rumours (FUD, nonsense, apocryphal blasphemy) that “compression will become mandatory”. This might be a non-issue for machines that run “full nodes” these days, but is an additional stress for mobile devices, including IoT.
In fact, for an IoT device, should it want to communicate over some ultra-simple as-of-yet-unwritten Ethereum-native messaging protocol, compression might just be a deal breaker. If there is mandatory compression, we’re discouraging this protocol from being written.