Stromkomprimierung spart Ethereum-Knoten ein Viertel des Gossip-Verkehrs
Serguey Asael Shinder2 Min. LesezeitEthereums Konsens-Clients komprimieren jede Gossip-Nachricht einzeln mit Snappy. Ein Beitrag im Ethereum-Research-Forum vom 24. September misst, was passiert, wenn der Kompressor stattdessen seine Historie über alle Nachrichten eines Streams behält: Bytes, die sich zwischen Nachrichten wiederholen, werden dann einmal gesendet und danach nur referenziert. Die Arbeit entstand bei der Netzwerkforschung für schnellere Finalität, bei der Attestierungs- und Aggregatverkehr voraussichtlich wächst; die Autoren vermerken, dass der Beitrag mit Claude geschrieben wurde.
Die Messung ist konkret. Das Team hängte einen Handler in die Gossip-Pipeline von Teku, direkt hinter den Protobuf-Codec von libp2p, und zeichnete jeden Frame eines Mainnet-Knotens auf, der alle Attestierungs-Subnetze abonniert hatte - etwa 45 Peers, rund 95 Minuten, davon 20 zum Trainieren und 60 zur Auswertung. Mit 64 KiB Historie im unveränderten Snappy-Blockformat würde ein Knoten mit den standardmäßigen zwei Subnetzen 72,8 Prozent der heutigen Bytes empfangen, mit allen Subnetzen 63,1 Prozent. Eine Historie von 1 MiB drückt den Wert für alle Subnetze auf 54,3 Prozent, zstd mit Kontext pro Stream auf 51,2 Prozent - daher die Überschrift "bis zu 2x". Data-Column-Sidecars, die ohnehin dicht sind, bleiben unter jedem Verfahren bei etwa 96 Prozent.
Zwei bekannte Ineffizienzen verschwinden ohne Protokolländerung: Der Topic-String an jeder Nachricht schrumpft zu einem Rückverweis von wenigen Bytes, und die AttestationData, die alle Attestierungen und Aggregate eines Slots teilen, wird effektiv einmal pro Stream übertragen. Von einer Attestierung bleiben etwa 117 Bytes, im Wesentlichen Signatur und Indizes. Ein Prototyp zwischen echten Mainnet-Knoten - einer mit normalem Gossip, einer mit dem neuen Protokoll /snappy-stream - sah über 40 Minuten in jeder Kategorie exakt dieselben Nachrichtenzahlen.
Was das bedeutet
Es handelt sich um einen Forschungsvorschlag, nicht um eine Spezifikationsänderung - es gibt kein EIP, und kein Client hat sich festgelegt. Attraktiv ist, dass die Einführung billig wäre: Der Decoder ist der heutige Snappy-Decoder plus Historienpuffer, mit derselben Grenze gegen Dekompressionsbomben, und das Verfahren lässt sich pro Verbindung aushandeln. Bandbreite gehört zu den größten Kosten eines Validators zu Hause, und ein Viertel weniger eingehender Gossip für einen Standardknoten ist spürbar.
Der Preis ist Zustand. Eine Historie pro Stream bedeutet, dass jede Peer-Verbindung einen synchron zu haltenden Puffer trägt, und ein verlorener oder vertauschter Frame ist schwerer zu verkraften als eine einzeln komprimierte Nachricht. Übereinstimmende Nachrichtenzahlen im Prototyp sind ein gutes erstes Ergebnis; als Nächstes zählt das Verhalten bei Paketverlust und wechselnden Peers - und ob Client-Teams den Ansatz für die Arbeit an schneller Finalität aufgreifen, aus der er stammt.