Standard-Block-Weiterleitung

Zwei Roundtrips und ein Megabyte oder mehr, bei jedem Sprung, für Daten, die der Empfänger größtenteils bereits hatte. Eine Messstudie aus 2013 ermittelte, dass der Node im Median 6,5 Sekunden nach dem Finden eines neuen Blocks davon erfuhr, bei einem Mittelwert von 12,6 Sekunden. Bitcoin Core lieferte die kompakte Blockweiterleitung in Version 0.13.0 am 23. August 2016 aus, und die Standard-Weiterleitung wurde zum Rückfallweg.

Wie es funktioniert

Die Standard-Block-Weiterleitung nutzt drei Nachrichten und setzt nichts darüber voraus, was der empfangende Node bereits hält.

Der Finder sendet inv mit dem Hash des neuen Blocks oder, seit BIP130 in Bitcoin Core 0.12.0 ankam, eine headers-Nachricht, die den 80 Byte großen Header direkt trägt, was dem Peer einen eigenen getheaders-Roundtrip erspart. Der Empfänger prüft, ob er diesen Block hat. Wenn nicht, antwortet er mit getdata. Dann überträgt der Sender die block-Nachricht: den Header, gefolgt von jeder Transaktion in voller Serialisierung, bis zu dem Budget von vier Millionen Gewichtseinheiten, das einen Block begrenzt.

Die Verschwendung ist offensichtlich, sobald man sie benennt. Ein Node, der seit Stunden läuft, hält fast jede Transaktion dieses Blocks bereits in seinem Mempool, weil er jede einzelne bei ihrer Verbreitung empfangen hat. Die Standard-Weiterleitung schickt sie alle ein zweites Mal. Bei einem Block voller gewöhnlicher Zahlungen sind das weit über ein Megabyte redundanter Übertragung, pro Peer, pro Block.

Die Folgen waren nicht bloß ästhetisch. Eine langsame Verbreitung erhöht die Rate von Stale Blocks, weil ein Miner, der noch nichts von einem neuen Block gehört hat, weiter an der alten Spitze arbeitet. Stale Blocks kosten kleine Miner mehr als große, denn ein großer Pool erfährt von seinen eigenen Blöcken sofort. Schnellere Weiterleitung war daher ebenso ein Dezentralisierungsargument wie ein Effizienzargument, und sie trieb sowohl BIP152 als auch die dedizierten Weiterleitungsnetzwerke voran, die große Pools untereinander betreiben.

Die Standard-Weiterleitung ist nicht verschwunden. Sie greift, wenn ein Peer kompakte Blöcke nie ausgehandelt hat, wenn die kompakte Rekonstruktion fehlschlägt und die fehlenden Transaktionen nicht ergänzt werden können, und während des gesamten initialen Block-Downloads, bei dem ein synchronisierender Node volle Blöcke per getdata von mehreren Peers gleichzeitig anfordert, in Bitcoin Core bis zu sechzehn gleichzeitig pro Peer.

Wo sie auftritt

Die Standard-Block-Weiterleitung ist vor allem sichtbar, während ein Node aufholt, nicht wenn er aufgeholt hat.

Während einer initialen Synchronisierung dominiert getdata für Blöcke den Verkehr, und die Zähler pro Nachricht in getpeerinfo zeigen es deutlich. Sobald der Node die Spitze erreicht, werden diese Zähler still und die Zähler für kompakte Blöcke übernehmen. Eine Maschine an einer langsamen Leitung oder mit wenigen Peers fällt häufiger auf die Standard-Weiterleitung zurück, und das Symptom ist eine Spitze, die ein oder zwei Minuten hinter dem zurückliegt, was ein öffentlicher Explorer zeigt.

Standard-Block-Weiterleitung vs. kompakte Block-Weiterleitung

Die Standard-Weiterleitung sendet den Block; die kompakte Weiterleitung sendet eine Beschreibung davon und lässt den Empfänger den Rest rekonstruieren. Ein cmpctblock trägt den Header, einen Nonce und je Transaktion eine sechs Byte kurze Kennung, sodass ein Block mit einigen tausend Zahlungen in unter zwanzig Kilobyte beschrieben werden kann statt in weit über einem Megabyte. Der Empfänger gleicht diese Kennungen mit seinem eigenen Mempool ab, fordert Fehlendes per getblocktxn an und setzt den Block lokal zusammen. Die anschließende Validierung ist identisch: Die kompakte Weiterleitung ändert, wie die Bytes ankommen, nie, was als gültiger Block gilt.