Compact Blocks

Anna möchte Peter einen neuen Block schicken. Ein Block bündelt Transaktionen, die in die gemeinsame Historie aufgenommen werden. Viele Transaktionen besitzt Peter jedoch bereits; sie alle zu senden wäre eine Wiederholung. Compact Blocks liefern stattdessen den Blockheader und eine Liste kurzer Kennungen zum Auffinden bekannter Transaktionen. Der Header ist ein kurzer Abschnitt des Blocks mit grundlegenden Angaben, darunter ein Verweis auf den vorherigen Block und ein Kontrollfingerabdruck der Transaktionen. Für technisch Interessierte: Die Kennungen umfassen 48 Bit, also 6 Byte, und entstehen durch Kürzen des Ergebnisses der Funktion SipHash-2-4. Deren Parameter werden aus dem Header und einer zusätzlichen Zahl für die Übertragung, der Nonce, abgeleitet. Eine Kennung ist deshalb kein dauerhafter Transaktionsname für das gesamte Bitcoin-Netz. [1] [2] [7]

Eine Liste ersetzt nicht alles. Anna sendet ausgewählte Transaktionen vollständig samt ihrer Position im Block. Üblich ist etwa die Coinbase Transaction, die erste Transaktion des Blocks, die die Mining-Belohnung zuweist; mit der gleichnamigen Börse hat sie nichts zu tun. Sie entsteht eigens für diesen Block und liegt deshalb normalerweise nicht in Peters Vorrat wartender Transaktionen. Vollständige Einträge und kurze Kennungen ergänzen sich beim Zusammensetzen. [1] [2]

Peters Mempool ist der lokale Bestand bekannter Transaktionen, die in seiner akzeptierten Kette noch nicht bestätigt sind. Er berechnet für vorhandene Transaktionen dieselben kurzen Kennungen und sucht Treffer zur Liste von Anna. Er setzt keinen identischen Bestand bei allen voraus. Da eine kurze Kennung gelegentlich zu mehreren Transaktionen passen kann, beweist ein Treffer allein noch nicht den richtigen Inhalt. [1] [2]

Bleiben Positionen leer oder uneindeutig, fordert Peter die betreffenden Transaktionen anhand ihrer Positionen an. Die Anfrage heißt getblocktxn, die Antwort mit den Transaktionen blocktxn. Diese Namen muss man sich nicht merken: Entscheidend ist, echte Daten anzufordern, statt Inhalte zu erraten. Eine weitere Anfrage samt Antwort kostet Zeit. Scheitert die Rekonstruktion, kann der vollständige Block heruntergeladen werden. [1] [3]

Peter muss die exakten Transaktionen in der richtigen Reihenfolge wiederherstellen und ihre Bindung an den Header prüfen. Ein Merkle Tree fasst Transaktionen zu einem Kontrollfingerabdruck zusammen und hilft, solche Bindungen zu prüfen. Doch richtiges Zusammensetzen ersetzt nicht die Prüfung der Regeln. Ein Full Node ist ein Programm, mit dem Peter die Bitcoin-Regeln selbstständig prüft, etwa die Berechtigung zum Ausgeben von Mitteln und die Höhe der Belohnung. Eine digitale Signatur weist die Berechtigung zur Zahlung nach. Sie wird mit einem privaten Schlüssel erzeugt, also einem geheimen Zahlenwert, der dabei nicht offengelegt wird. Die kompakte Übertragung erlaubt keine Ausnahme für einen ungültigen Block. [1] [8]

Benachbarte Knoten vereinbaren den Modus über sendcmpct. In der schnellen Variante kündigt eine cmpctblock-Nachricht mit den Rekonstruktionsdaten den Block direkt an. Nach vorgeschriebenen Vorprüfungen darf der Sender übertragen, bevor sämtliche Transaktionsprüfungen beendet sind. Er muss unter anderem den Anschluss an die geprüfte Kette, Proof of Work als Nachweis der Rechenarbeit und die Bindung des Headers an die Transaktionen prüfen. Der Empfänger prüft den Block dennoch vollständig, bevor er ihn in seine Historie übernimmt. [1] [4]

Die andere Variante kündigt einen bereits geprüften Block zunächst mit inv oder headers an. Peter fordert die kompakten Daten dann bei Bedarf an. So kann er eine unnötige Sendung vermeiden, wenn er den Block schon anderswo erhalten hat; dafür kommt ein Kommunikationsschritt hinzu. Beide Modi können gegenüber dem erneuten Senden aller Transaktionen Daten sparen. Sie unterscheiden sich im Zeitpunkt und darin, ob vorher eine Anfrage nötig ist, nicht in der Gültigkeit des Blocks. [1] [7]

Zwei unterschiedliche Transaktionen können dieselbe kurze Kennung erhalten. Das heißt Kollision. Wie bei zwei Menschen mit denselben Initialen reicht die Abkürzung nicht mehr zur Unterscheidung. Je nachdem, wo das Problem auftritt, fordert die Software weitere Daten an oder lädt den ganzen Block. Eine Kollision bricht keine Bitcoin-Signaturen und macht einen ungültigen Block nicht gültig. Geprüft wird der tatsächliche Inhalt, nicht nur die Übereinstimmung kurzer Kennungen. [1] [2]

Version 2 des kompakten Protokolls unterstützt SegWit. Diese Änderung trennt Signaturen und weitere Prüfungsdaten in einen Witness-Teil ab. Verwendet wird wtxid, ein Bezeichner, der diese Daten einbezieht, statt txid, der sie nicht einbezieht. Vollständige Transaktionen werden nach BIP 144 mitsamt den erforderlichen Witness-Daten übertragen. Diese werden also nicht einfach weggelassen, damit die Sendung kleiner wirkt. Die Version des Übertragungsprotokolls ist außerdem nicht die Versionsnummer des Blocks selbst. [1] [6]

Kennen Anna und Peter viele gleiche Transaktionen, erreicht Peter der neue Block mit deutlich weniger wiederholter Datenübertragung. Das entlastet auch einen Heimanschluss beim plötzlichen Eintreffen eines Blocks. Bei geringer Überschneidung kommen Nachfragen hinzu und die Ersparnis sinkt. Hauptziel ist weniger Datenverkehr; schnellere Zustellung ist ein möglicher Vorteil, keine Garantie für Wartezeit null oder eine feste Nachrichtengröße. Bitcoin erhält dadurch kein neues Größenlimit für Blöcke. [5] [7]