Nicht angeforderter Block-Push

Ohne Einladung zu senden ist in den meisten Protokollen unhöflich und in diesem richtig. Jeder Roundtrip, den ein Block unterwegs verbringt, ist Zeit, die ein Miner damit verbringt, an einer Chain-Spitze zu arbeiten, die es nicht mehr gibt, deshalb hat BIP152 die Abkürzung formalisiert: bis zu drei ausgewählte Peers dürfen Ihnen einen Block in dem Moment senden, in dem sie ihn haben. Ihr Node validiert ihn ohnehin von Grund auf neu und schuldet dem Absender nichts.

Wie es funktioniert

Unter der Bezeichnung nicht angeforderter Block-Push laufen zwei verschiedene Dinge, eines alt und informell, eines spezifiziert.

Die alte Form ist schlicht eine block-Nachricht, die ohne passende getdata-Nachricht eintrifft. Das Protokoll hat sie nie verboten, und Empfänger haben solche Blöcke immer verarbeitet, allerdings mit Bedingungen. Bitcoin Core prüft den Proof of Work im Header, bevor irgendetwas Aufwendiges geschieht, gibt den Block erst weiter, wenn er vollständig validiert ist und an die beste Chain anschließt, und behandelt einen Block, der an nichts anschließt, was er kennt, als etwas, das zu verwerfen ist, statt als Rätsel, das zu lösen ist. Diese Regeln bestehen, weil nicht angeforderte Daten für den Absender kostenlos und für den Empfänger teuer sind, und das ist die Form jedes Denial-of-Service-Angriffs im Protokoll.

Die spezifizierte Form ist der High-Bandwidth-Modus von BIP152. Ein Node sendet seinem Peer eine sendcmpct-Nachricht, deren erstes Byte 1 ist, was bedeutet: nicht ankündigen, einfach senden. Dieser Peer darf dann ein cmpctblock übertragen, sobald er von einem neuen Block erfährt, möglicherweise bevor er ihn fertig validiert hat. BIP152 setzt eine harte Obergrenze von drei solchen Peers, und Bitcoin Core setzt genau das durch und führt eine Liste mit höchstens drei Nodes, die dafür ausgewählt werden, weil sie aktuelle Blöcke als Erste geliefert haben. Drei ist ein Kompromiss: genug Redundanz, damit ein langsamer Peer Sie nicht aufhalten kann, und zugleich so wenige, dass Sie nicht denselben Block über jede Ihrer Verbindungen erhalten.

Da eine High-Bandwidth-Ankündigung der Validierung vorausgehen kann, behandelt der empfangende Node sie als Behauptung und nicht als Tatsache. Der Proof of Work wird zuerst geprüft, da er der einzige Teil eines Blocks ist, der sich nicht billig fälschen lässt, und alles andere folgt dem normalen Weg. Die Protokollversion 70015 existiert genau deshalb, damit ein Node signalisieren kann, dass er einen Peer nicht dafür bestraft, einen Block anzukündigen, der sich später als nicht vollständig geprüft erweist.

Wo Sie es sehen

Nicht angeforderte Pushes konzentrieren sich dort, wo Sekunden Geld wert sind.

Mining-Pools halten direkte Verbindungen untereinander und zu Relay-Netzwerken wie FIBRE, die gebaut sind, um Blöcke zwischen Kontinenten mit so wenig Handshake zu bewegen, wie die Physik erlaubt. Auf einem gewöhnlichen Rechner meldet der Aufruf getpeerinfo zwei Flags pro Peer, bip152_hb_to und bip152_hb_from, die zeigen, welche Peers Sie gebeten haben, Ihnen Blöcke zu senden, und welche dasselbe von Ihnen verlangt haben. Drei der ersten Art zu sehen ist normal, und drei ist die Grenze.

Nicht angeforderter Block-Push vs. standardmäßige Block-Weitergabe

Standardmäßige Block-Weitergabe und ein nicht angeforderter Push unterscheiden sich darin, wer entscheidet, dass Bytes übertragen werden. Bei der standardmäßigen Weitergabe fragt der Empfänger, deshalb steuert er seine eigene Bandbreite und kann alles ablehnen, was er bereits hat. Bei einem Push entscheidet der Absender, was einen Roundtrip spart, aber einem Außenstehenden einen Hebel auf Ihre Ressourcen gibt. Die Antwort von Bitcoin ist, sich nicht für eines zu entscheiden: den Push erlauben, ihn auf drei Peers begrenzen, die Sie selbst ausgewählt haben, den Proof of Work prüfen, bevor irgendetwas aufgewendet wird, und den Block unabhängig davon vollständig validieren, wie höflich er angekommen ist.