Wie wirkt sich "Kopfzeilen zuerst" auf die Struktur von BLKxxxx.dat aus?

Angenommen, ein vollständiger Knoten, auf dem Bitcoincore v0.10 (mit txindex=1) ausgeführt wird, wie genau wirkt sich die neue Funktionalität „Header zuerst“ auf die Struktur der Blockchain-Daten aus? (Insbesondere die blkxxxx.datDaten, obwohl ich vielleicht andere Dateien nicht kenne, die der Datenstruktur untergeordnet sind).

Die README.md für die Version gibt an, dass es keine v0.9.x-Rückkompatibilität für v0.10-Blockchain blk-Daten gibt.

Da die Version 0.10.0 die Header-First-Synchronisation und den parallelen Blockdownload verwendet (siehe weiter unten), sind die Blockdateien und Datenbanken nicht abwärtskompatibel mit älteren Versionen von Bitcoin Core oder anderer Software:

Blöcke werden nicht in der richtigen Reihenfolge auf der Festplatte gespeichert (eigentlich in der Reihenfolge, in der sie empfangen werden), was sie mit einigen Tools oder anderen Programmen inkompatibel macht. Auch eine Neuindizierung mit früheren Versionen funktioniert dadurch nicht mehr.

Wie werden dann die Blk-Daten der Version 0.10 vom Client geparst? Und im weiteren Sinne, warum ändert „headers first“ überhaupt die Struktur, wenn man davon ausgeht, dass es logischerweise „eine Vorlage“ für die Tx-Daten zu erstellen scheint?

Antworten (2)

Nach Tests mit dem BlockStore von NBitcoin ist das Format dasselbe. Die BLK-Dateien sind fast nur Rohblöcke (sie haben einen kleinen zusätzlichen Header)

Jeder gespeicherte Block in dieser Datei hat das Netzwerk, zu dem er gehört, mit seiner Größe, gefolgt von den Blockdaten. Auf diese Blöcke wird von der leveldb-Datenbank durch ihre (fileId, offset) verwiesen.

Die Reihenfolge hat sich jedoch geändert, ich selbst habe die Tatsache, dass diese Blöcke in der Vergangenheit geordnet waren, genutzt, um die Header-Kette aus dem Bitcoin-Ordner zu erstellen. Ein solcher Code würde jetzt brechen. (Jetzt verbinde ich mich direkt mit dem Peer-Knoten, anstatt mich auf den Blockordner zu verlassen.)

Soweit ich weiß, werden die Blöcke nur in einer anderen Reihenfolge gespeichert. Die Header-First-Synchronisation nutzt parallele Downloads und die Blöcke werden außerhalb der Reihenfolge heruntergeladen (und dann gespeichert). Früher war es in älteren Versionen so, dass Blöcke heruntergeladen und dann der Reihe nach gespeichert wurden, also haben sie den Kommentar zur README hinzugefügt.

Ich glaube, es ändert nichts an der Struktur, wie ein einzelner Block gespeichert wird, nur dass sie jetzt wahrscheinlich nicht in der richtigen Reihenfolge sind.

Ja, das macht Sinn. Ich versuche, eine konkrete Antwort auf niedriger Ebene zu erhalten, damit sich vielleicht jemand, der sich mit dem Lesen der Github-Diskussionen auskennt, einschalten kann
Fair genug, ich erkenne, dass diese Antwort ein bisschen hochrangig ist. Aber ich vermute, dass es möglicherweise keine wirklichen Änderungen auf niedriger Ebene gibt. Die Blk___.dat-Dateien enthalten buchstäblich rohe Blöcke, also denke ich, dass Sie sie höchstens in einer anderen Reihenfolge speichern können
Ich melde mich wieder :) Ich weiß die Antwort zu schätzen, Kumpel. Ich bin nur frustriert, dass so viele Funktionen der Software – einschließlich Blk, Bitcoin-TX, Rest-Funktionalität usw. usw. – alle in Github verborgen sind.
Wie wirkt sich "Kopfzeilen zuerst" auf die Struktur von BLKxxxx.dat aus?
AntwortenHierDatenschutz-Bestimmungen1y, 0v