Файлове blk.dat

Файловете blk*.dat пазят суровите данни на всеки блок, който нодът ви е получил. Bitcoin Core ги записва, щом блоковете пристигнат. Заедно файловете пазят целия блокчейн на диска ви, в реда, в който блоковете са пристигнали.

Къде са файловете?

Те са в папката blocks в директорията с данни на нода. Стандартните места са:

• Linux: ~/.bitcoin/blocks/
• macOS: ~/Library/Application Support/Bitcoin/blocks/
• Windows: C:\Users\[username]\AppData\Local\Bitcoin\blocks\ от Bitcoin Core 28.0 нататък. По-старите версии са ползвали AppData\Roaming.

Настройката datadir в bitcoin.conf мести папката на друго място. Ръководството за файловете на Bitcoin Core изброява всеки файл, който нодът записва.

Как блоковете се разпределят по файловете?

Един файл би растял без граница, затова Bitcoin Core разпределя данните в няколко. Първият файл е blk00000.dat. Когато се напълни, нодът започва blk00001.dat, после blk00002.dat и така нататък. Всеки файл е най-много 128 MiB, тоест 134,217,728 байта. Лимитът е зададен от MAX_BLOCKFILE_SIZE в изходния код на Bitcoin Core.

До тях са файловете rev*.dat, които пазят данни за отмяна (undo). Нодът ги ползва, за да отмени харченето на монетите при пренареждане на веригата.

Как изглежда един запис?

Всеки блок се пази като запис от пет части. Стойностите по-долу са показани без XOR, който ще разгледаме по-нататък.

1. Магически байтове, 4 байта. Те отбелязват началото на запис. В mainnet стойността е f9beb4d9, а magic bytes обяснява как мрежата я ползва.
2. Размер на блока, 4 байта, little-endian. Брои байтовете на блока, които следват. Размерът на генезис блока е 1d010000, което прави 285 байта.
3. Заглавие на блока, 80 байта. Това са шестте полета от структурата на блока.
4. Брой на трансакциите, цяло число във формат compact size. Генезис блокът има една трансакция, така че броят е 01.
5. Трансакции, суровите байтове на всяка трансакция в блока, една след друга.

Полето за размер казва на четеца къде свършва записът. 285-те байта на генезис блока са 80 за заглавието, 1 за броя и 204 за единствената му трансакция.

Първите байтове на генезис записа изглеждат така, след като XOR-ът е премахнат:

f9beb4d9 1d010000 01000000 0000000000000000000000000000000000000000000000000000000000000000 3ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a 29ab5f49 ffff001d 1dac2b7c 01 ...

Интервалите отбелязват полетата, а останалите байтове на трансакцията са отрязани тук. Целия блок можете да прочетете от собствения си нод с bitcoin-cli getblock 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f 0. Командата връща блока като шестнадесетичен низ, без магическите байтове и размера. Страницата на блок 0 в нашия explorer показва същия блок в четим вид.

Защо блоковете не са подредени?

Файловете пазят блоковете в реда, в който нодът ги е получил, а не по височина. Нодът сваля блоковете паралелно и изтегля прозорец от следващите блокове. Затова блок по-нагоре във веригата може да попадне във файла преди блок под него.

Ако четете файловете сами, възстановете реда от връзките за предишния блок. Не приемайте, че редът във файла е редът на веригата.

Защо данните са разбъркани от v28.0 нататък?

От Bitcoin Core 28.0 нодът прилага XOR върху суровите данни на блоковете, преди да ги запише на диска. XOR-ът ползва 8-байтов ключ, пазен в blocks/xor.dat. Pull request-ът дава причината. Антивирусните и други сканери можеха да поставят в карантина или да изтрият файлове с блокове, защото всеки може да сложи произволни байтове в трансакция. Разбъркването на байтовете пази файловете да не изглеждат като такива данни за сканера.

За да премахнете разбъркването, приложете XOR върху всеки байт с байта на ключа, който отговаря на неговата позиция от началото на файла. Ключът се повтаря на всеки 8 байта, така че байт N ползва ключов байт N mod 8. Броенето започва от първия байт на файла, така че и магическите байтове, и полето за размер са разбъркани.

Примерът по-горе показва първите осем байта от данните на генезис блока, на отместване 8 във файла. XOR на 16 с 17 дава 01, а всеки друг байт се XOR-ва до 00. Новият нод създава свой случаен ключ, така че файловете ви изглеждат различно от тези на друг човек. Нод, синхронизиран преди v28.0, пази ключ от нули, така че файловете му остават чисти. По-старите инструменти, които четат файловете blk*.dat, не разбират разбъркани данни и се нуждаят от ключа, за да работят.

Как да прочетете суровите блокове?

Използвайте bitcoin-cli, ако можете. Той връща блока вече без разбъркване и работи на всеки нод, който още има блока. Pruned нод изтрива по-старите файлове blk*.dat, така че не може да даде всеки блок. Можете да зададете blocksxor=0, за да изключите XOR-а, но само за нова директория с данни. Нод, който вече има случаен ключ, не може да го изключи.

Ако все пак четете файловете сами, следвайте разположението на записа по-горе, премахнете XOR-а, когато нодът е v28.0 или по-нов, и се справете с блоковете, които не са в ред.

Какво следва?

Това е последната страница от раздела. Върнете се на структурата на блока за пълния списък на полетата в реда на заглавието.