120 / 736CMPCT

Compact Blocks

Компактне передавання блоків

Сусідній вузол часто вже знає більшість транзакцій нового блоку. Compact Blocks передають підказки для його відновлення, а потім доповнюють відсутнє замість повторення всіх даних. Результат перевіряють так само суворо.

Compact Blocks — спосіб передавати блоки Bitcoin за BIP 152 з меншою кількістю повторюваних даних. Він не зменшує сам блок і не послаблює його правил: одержувач має відновити весь вміст і перевірити його перед прийняттям.

Анна хоче надіслати Петру новий блок, але багато його транзакцій у Петра вже є. Блок об’єднує транзакції в пакет, який додають до спільної історії. Надсилати всі означало б повторювати дані. Compact Blocks передають заголовок і перелік коротких позначок для пошуку знайомих транзакцій. Заголовок — це коротка частина блоку з основними даними, зокрема посиланням на попередній блок і контрольним відбитком транзакцій. Для технічного читача: позначки мають 48 бітів, тобто 6 байтів, і утворюються скороченням результату функції SipHash-2-4. Її параметри походять із заголовка й додаткового числа для передавання, яке називають nonce. Тож позначка не є постійним ім’ям транзакції для всієї мережі Bitcoin. [1] [2] [7]

Переліком можна замінити не все. Анна надсилає вибрані транзакції цілком разом із їхніми позиціями в блоці. Звичайний приклад — Coinbase Transaction, перша транзакція блоку, яка призначає винагороду за майнінг; вона не пов’язана з однойменною біржею. Її створюють саме для цього блоку, тому серед транзакцій Петра, що очікують підтвердження, її зазвичай немає. Повні записи й короткі позначки доповнюють одне одного під час відновлення. [1] [2]

Mempool Петра — місцевий набір відомих його вузлу транзакцій, ще не підтверджених у прийнятому ланцюжку. Для доступних транзакцій він обчислює такі самі короткі позначки й шукає збіги з переліком Анни. Він не припускає, що всі мають однаковий набір. Оскільки одна позначка зрідка відповідає кільком транзакціям, сам збіг ще не доводить остаточно, що вміст правильний. [1] [2]

Якщо позиції залишилися порожніми або неоднозначними, Петро запитує конкретні транзакції за їхніми позиціями. Запит називається getblocktxn, відповідь із транзакціями — blocktxn. Запам’ятовувати назви не обов’язково: важливо отримати справжні дані, а не вгадувати вміст. Додатковий запит і відповідь забирають час. Якщо відновити блок не вдається, можна завантажити його повністю. [1] [3]

Петро має відновити точні транзакції у правильному порядку й перевірити їхній зв’язок із заголовком. Merkle Tree зводить транзакції до контрольного відбитка й допомагає перевірити цей зв’язок. Але правильне складання не замінює перевірки правил. Full Node — це програма, за допомогою якої Петро самостійно перевіряє правила Bitcoin, зокрема право витрачати кошти та розмір винагороди. Цифровий підпис підтверджує дозвіл на платіж за допомогою приватного ключа — секретного числового значення, яке при цьому не розкривається. Компактне передавання не робить винятків для недійсного блоку. [1] [8]

Сусідні вузли узгоджують режим через sendcmpct. У швидкому варіанті повідомлення cmpctblock з даними для відновлення одразу оголошує новий блок. Після обов’язкових початкових перевірок відправник може передавати до завершення всіх перевірок транзакцій. Зокрема, він має перевірити зв’язок із перевіреним ланцюжком, Proof of Work як доказ обчислювальної роботи та зв’язок заголовка з транзакціями. Одержувач усе одно повністю перевіряє блок перед прийняттям до своєї історії. [1] [4]

Інший варіант спершу оголошує вже перевірений блок через inv або headers. Петро тоді запитує компактні дані, якщо вони потрібні. Так можна уникнути зайвого надсилання блоку, отриманого іншим шляхом, ціною додаткового кроку зв’язку. Обидва режими можуть заощаджувати дані порівняно з повторенням усіх транзакцій. Вони відрізняються часом надсилання й потребою попереднього запиту, а не вимогами до дійсності блоку. [1] [7]

Дві різні транзакції можуть отримати однакову коротку позначку. Це називають колізією. Як у двох людей з однаковими ініціалами: скорочення вже не дозволяє розрізнити їх. Залежно від місця проблеми програма запитує додаткові дані або завантажує весь блок. Колізія не зламує підписів Bitcoin і не перетворює недійсний блок на дійсний. Перевіряти потрібно справжній вміст, не лише збіг коротких позначок. [1] [2]

Версія 2 компактного протоколу підтримує SegWit, який відділяє підписи та інші дані перевірки в частину witness. Вона використовує wtxid — ідентифікатор із цими даними — замість txid, який їх не враховує. Повні транзакції передаються з потрібними даними witness за BIP 144. Їх не відкидають, щоб посилка здавалася меншою. Версія протоколу передавання також не є номером версії самого блоку. [1] [6]

Якщо Анна й Петро знають багато спільних транзакцій, блок передається зі значно меншою кількістю повторених даних. Це допомагає й домашньому з’єднанню під час раптового надходження блоку. За малого перетину наборів додаткові запити зменшують економію. Головна мета — скоротити передані дані; швидше доставлення є можливою перевагою, а не обіцянкою нульового очікування чи сталої довжини повідомлення. Нового обмеження розміру блоків Bitcoin це не створює. [5] [7]

Для повної картини прочитайте також Block Propagation, Initial Block Download, Eclipse Attack, vByte, Bitcoin, Coinbase-транзакція. На цю статтю також посилаються Stale Block, Eclipse Attack, Selfish Mining, Block Propagation.

DOC · 001BIP 152 — Compact Block RelayСпецифікація DOC · 002Bitcoin Core — BIP 152 implementationДокументація DOC · 003Bitcoin Developer Reference — P2PДокументація DOC · 004Bitcoin Core v29.0 — net processingДокументація DOC · 005Bitcoin Optech — Compact block relayДокументація DOC · 006BIP 144 — SegWit peer servicesСпецифікація DOC · 007Bitcoin Core — Compact Blocks FAQДокументація DOC · 008Bitcoin Developer Guide — Block ChainДокументація
Переглянуто: Спочатку джерела · Не інвестиційна порада