Orphan Block

Попередній блок іноді називають батьківським. Для справжнього Orphan Block вузол Яни його не знає й не може завершити перевірку зв’язку. У Stale Block батьківський блок може бути відомим, а весь блок — чинним; просто вузол обрав іншу гілку як активну історію. Bitcoin Developer Guide прямо розрізняє ці значення. Побачивши orphan в оглядачі блоків, Яна спершу з’ясовує: бракує попередника чи блок лише не залишився в основному ланцюгу. [1]

Це розрізнення є й у Bitcoin Core — програмі для роботи вузла, який перевіряє блоки та транзакції за правилами Bitcoin. У Bitcoin Core 29 функція AcceptBlockHeader шукає попередника за hashPrevBlock, посиланням на його ідентифікаційний відбиток. Якщо запису в індексі немає, повертається prev-blk-not-found. Якщо батьківський блок відомий і позначений як нечинний, результат — bad-prevblk. Перше означає «мені бракує контексту», друге — «ти продовжуєш нечинний блок». Отримання відсутнього попередника дозволяє подальші перевірки, але саме по собі ще не гарантує прийняття цілого блоку. [2]

Блок має заголовок — короткий набір даних для ідентифікації та зв’язку — і тіло з транзакціями. Bitcoin Core 0.10.0 запровадив синхронізацію headers-first: спочатку отримують і перевіряють заголовки, потім блоки можна завантажувати паралельно. Тому вузол Яни може знати заголовок попередника, ще не маючи цілого блоку на диску. Відсутнє тіло блоку — не те саме, що невідомий попередник; інакше звичайне завантаження могло б здаватися загадковою несправністю. [3]

Команда getchaintips у Bitcoin Core 29 показує Яні, які кінці гілок знає вузол. active позначає активний ланцюг, valid-fork — повністю перевірену неактивну гілку. valid-headers означає, що блоки доступні, але не пройшли повної перевірки; headers-only — що деяких блоків бракує. invalid позначає гілку з нечинним блоком. Отже, це не перелік однакових проблем. Навіть вислів orphaned branches у довідці не стирає цих відмінностей. [4]

Уявімо два різні блоки A і B на висоті 900000. Це наш власний приклад, а не опис конкретної події. Висота — позиція в ланцюгу, тому конкуруючі блоки можуть її мати однакову. Яна розрізняє їх за hash, ідентифікаційним відбитком блоку, і previousblockhash, посиланням на попередника. При виборі між чинними гілками вирішує накопичена робота, а не сама висота. Інтерфейс RPC для передавання команд програмі називає її chainwork: сумарна очікувана робота, що відповідає складностям блоків. [1] [5]

Коли Яна запитує через getblock про блок поза основним ланцюгом, Bitcoin Core 29 може повернути confirmations = -1. Це спеціальна позначка стану, а не звичайна кількість підтверджень. Це не зворотний відлік і не від’ємна глибина реорганізації ланцюга. Значення також не доводить відсутності попередника. Його слід читати разом з ідентичністю блоку та станом гілки; вузол Яни до того ж може не мати всіх блоків, які будь-коли бачили інші учасники. [5]

Винагорода за блок виникає в особливій першій транзакції coinbase, не пов’язаній з однойменною біржею. Вихід транзакції — це запис певної суми біткоїнів та умов, які потрібно виконати, щоб її витратити. У Bitcoin Core 29 COINBASE_MATURITY дорівнює 100: вихід, створений на висоті H, уперше можна витратити в чинному блоці на висоті H+100. Важлива різниця висот, а не хвилини. Проте ця умова очікування не замінює належності до активного ланцюга. Поки блок із винагородою лишається на неактивній гілці, його виходу немає в активному наборі UTXO, обліку невитрачених виходів. Нові блоки в іншому місці самі грошей не повертають. [6] [7] [1] [8]

Яна зберігає hash блоку, його попередника, стан гілки та версію програми. Додає відповіді getchaintips і getblock та час, коли їх отримала. Його записує окремо від поля time у заголовку: час у блоці не є моментом, коли її комп’ютер його спостерігав. Такий запис допомагає порівнювати подальші спостереження, але сам не доводить атаки, конкретного збою мережі чи світової частки orphan-блоків. Передусім він описує стан одного вузла в певну мить. [4] [5]