120 / 691CMPCT

Compact-Block-Relay

Der kompakte Blocktransport nach BIP 152 sendet Header, kurze IDs und ausgewählte vollständige Transaktionen. Der Empfänger nutzt Bekanntes und beschafft fehlende Daten.

Ein kompakter Block ist eine Transportkodierung, kein kleinerer Konsensblock. Ein Full Node muss die exakten Transaktionen in richtiger Reihenfolge herstellen und den ganzen Block prüfen.

Eine kurze ID hat 48 Bits durch Kürzung von SipHash-2-4. Die Schlüssel stammen aus Header und mitgelieferter Nonce; die ID ist keine globale Transaktionskennung. [BIP 152 — Compact Block Relay] [Bitcoin Core — BIP 152 implementation]

Einige Transaktionen werden vollständig vorausgefüllt übertragen, üblicherweise einschließlich Coinbase. Ihre Indizes bestimmen die Position im rekonstruierten Block. [BIP 152 — Compact Block Relay]

Der Empfänger ordnet kurze IDs bekannten Transaktionen zu, etwa im Mempool. Gleiche kurze IDs allein beweisen keine Transaktionsidentität. [BIP 152 — Compact Block Relay] [Bitcoin Core — BIP 152 implementation]

Fehlende oder mehrdeutige Einträge werden per Index mit getblocktxn angefordert. Die Antwort blocktxn liefert die benötigten Transaktionen zur Fertigstellung. [BIP 152 — Compact Block Relay] [Bitcoin Developer Reference — P2P] [Bitcoin Core v29.0 — net processing]

Rekonstruktion bewahrt die genaue Reihenfolge und prüft die Blockfestlegungen. Ein Full Node validiert vor Annahme weiter den Konsens; kompakter Transport ist keine Ausnahme. [BIP 152 — Compact Block Relay] [Bitcoin Core — BIP 152 implementation] [Bitcoin Core v29.0 — net processing]

Nach sendcmpct-Aushandlung kann der Modus mit hoher Bandbreite direkt per cmpctblock ankündigen. Nach Vorprüfungen darf dies vor vollständiger Sendervalidierung geschehen, ohne die Empfängerprüfung aufzuheben. [BIP 152 — Compact Block Relay] [Bitcoin Core v29.0 — net processing]

Der sparsame Modus nutzt zuerst inv- oder headers-Ankündigungen, dann fordert der Empfänger den kompakten Block an. Er kann mehr Kommunikationsrunden als direkte Ankündigung benötigen. [BIP 152 — Compact Block Relay] [Bitcoin Developer Reference — P2P]

ID-Kollisionen können Transaktionsanforderungen oder fehlgeschlagene Rekonstruktion mit anschließendem Vollblockabruf auslösen. Sie erlauben keinen falschen Block als konsensgültig anzunehmen. [BIP 152 — Compact Block Relay] [Bitcoin Core — BIP 152 implementation] [Bitcoin Optech — Compact block relay]

Version 2 leitet kurze IDs aus wtxid statt txid ab und überträgt Witness-Daten gemäß BIP 144. Die Version des Kompaktprotokolls ist nicht die Versionsnummer des Blocks. [BIP 152 — Compact Block Relay] [BIP 144 — SegWit peer services]

Der Nutzen hängt von Transaktionsüberschneidung und Netzbedingungen ab. Geringe Überschneidung erzeugt Nachfragen; Hauptziel ist Datenersparnis, keine garantierte Nachrichtengröße oder Latenz null. [BIP 152 — Compact Block Relay] [Bitcoin Optech — Compact block relay]

Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Blockausbreitung, Initialer Blockdownload, Eclipse-Angriff, Virtuelles Byte. Auf diesen Eintrag verweisen außerdem Blockausbreitung, Compact Block Filters, Compact Block Filters, Matt Corallo.

DOC · 001BIP 152 — Compact Block RelaySpezifikationDOC · 002Bitcoin Core — BIP 152 implementationDokumentationDOC · 003Bitcoin Developer Reference — P2PDokumentationDOC · 004Bitcoin Core v29.0 — net processingDokumentationDOC · 005Bitcoin Optech — Compact block relayDokumentationDOC · 006BIP 144 — SegWit peer servicesSpezifikation
Quellenbasiert · Keine Anlageberatung