121 / 736IBD

Initial Block Download

Початкова синхронізація вузла

Новий вузол Bitcoin ще не знає минулого мережі. Перш ніж покладатися на власне уявлення про платежі, він має наздогнати й опрацювати цю історію. Initial Block Download пояснює, чому для першого запуску недостатньо лише швидкого інтернету.

Initial Block Download, або IBD, — це початкова синхронізація вузла Bitcoin. За звичайного підходу він отримує давніші блоки, перевіряє їх за правилами свого програмного забезпечення та створює поточний перелік ще не витрачених коштів.

Ви запускаєте вдома Full Node — програму, яка самостійно перевіряє блоки й транзакції Bitcoin. Блок об’єднує транзакції в пакет, який додають до спільної історії. Інші учасники вже мають довгу історію, а ваш новий вузол її ще не знає. Спочатку він отримує заголовки: короткі записи, що пов’язують блоки. Вони також містять Proof of Work — доказ обчислювальної роботи. Майнери шукають цей доказ повторними обчисленнями; інші можуть швидко перевірити знайдений результат. Перелік заголовків нагадує зміст книжки: він допомагає зорієнтуватися, але мати його — не те саме, що прочитати й перевірити всі сторінки. [1] [7]

Коли сусіди пропонують різні гілки історії, вузол не рахує голоси. Заголовки дають змогу порівняти накопичену обчислювальну роботу й вибрати перспективну гілку для подальшої перевірки. Більше блоків не обов’язково означає більше роботи. Навіть велика кількість роботи не звільняє недійсні транзакції від правил: вміст вибраної гілки ще треба перевірити. [1] [2] [6]

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

Вузол порівнює вміст блоку з відбитком транзакцій у його заголовку, сформованим за допомогою Merkle Tree. Також він перевіряє, наприклад, послідовність витрачання і те, чи не перевищує винагорода майнера дозволену суму. Застосовуються правила, чинні на відповідному етапі історії. Цифровий підпис підтверджує дозвіл на платіж за допомогою приватного ключа — секретного числового значення, яке при цьому не розкривається. Для давніх перевірок підписів та інших умов витрачання є окреме налаштування assumevalid, пояснене нижче. Заголовки чи файл від на вигляд надійного сусіда не замінюють цей комплекс перевірок. [2] [3]

Після обробки кожного блоку вузол прибирає витрачені виходи та додає нові. Вихід — це конкретна сума з умовами її подальшого використання. Якщо її ще не витрачено, такий вихід називається UTXO. Їхній набір дозволяє перевірити наступний платіж, не перечитуючи щоразу всю історію від початку. Це не перелік банківських рахунків і не копія всіх колишніх транзакцій. [2] [3]

За певних умов Bitcoin Core може пропускати давні перевірки скриптів, тобто підписів та інших умов витрачання. Налаштування assumevalid вказує на відомий блок із зовнішньо перевіреною історією; важливі також його зв’язок із попередніми блоками, достатня робота та довжина ланцюжка після нього. Інші необхідні перевірки залишаються, проте частина результату приймається як припущення. Тому хибне припущення не є безризиковим. assumevalid=0 вимикає цю оптимізацію, натомість додаючи роботи вашому комп’ютеру. [2]

Pruned Node видаляє старі файли блоків після обробки, зберігаючи актуальні UTXO та інші потрібні дані. Під час звичайного IBD він усе одно отримує й опрацьовує історію, лише не зберігає її всю назавжди. Це заощаджує місце на диску, але не обов’язково обсяг першого завантаження. Якщо пізнішому завданню знадобляться вже видалені блоки, їх може бути потрібно отримати знову. [2] [7]

Bitcoin Core v29.0 враховує, зокрема, давність останнього прийнятого блоку, мінімальну накопичену роботу та стан завантаження. Щойно цей службовий прапорець переходить у false (тобто початкову синхронізацію завершено), він більше не повертається до true (тобто вона ще триває) протягом того самого запуску. Він керує поведінкою програми, а не доводить, що ніде немає новішого блоку. Навіть подальша втрата з’єднання не робить його надійним показником актуальності. [2] [5]

Швидке з’єднання допомагає, але комп’ютеру також потрібно обчислювати й записувати на диск. Тривалість залежить від процесора, пам’яті, накопичувача та доступності сусідів. У технічній відповіді getblockchaininfo поле verificationprogress оцінює поступ перевірки. Це не обіцянка кількості хвилин до завершення і не просто частка завантажених байтів. Після коректного завершення роботи наступний запуск може продовжити зі збереженого місця, а не починати все спочатку. [5] [7]

AssumeUTXO дозволяє використати підтримуваний знімок UTXO — збережений стан на певному блоці. Програма порівнює його вміст з очікуваним відбитком і може швидше наздогнати сучасний стан, опрацьовуючи історію у фоні. Згодом вона порівнює також стан, отриманий шляхом цієї історичної перевірки. Це не довільна база даних від незнайомця і не спосіб ніколи не перевіряти минуле. Раніша готовність до роботи та завершена перевірка історії — різні етапи. [4] [8]

Для повної картини прочитайте також Pruned Node, AssumeUTXO, Block Propagation, Compact Blocks, Bitcoin, Bitcoin Core. На цю статтю також посилаються Block Propagation, Compact Blocks, Pruned Node, AssumeUTXO.

DOC · 001Bitcoin Developer Guide — Initial Block DownloadДокументація DOC · 002Bitcoin Core — validationДокументація DOC · 003Bitcoin Core — chainstateДокументація DOC · 004Bitcoin Core — AssumeUTXO designДокументація DOC · 005Bitcoin Core — getblockchaininfoДокументація DOC · 006Satoshi Nakamoto — Bitcoin whitepaperПервинне джерело DOC · 007Bitcoin.org — Running a Full NodeДокументація DOC · 008Bitcoin Core v29.0 — AssumeUTXO usageДокументація
Переглянуто: Спочатку джерела · Не інвестиційна порада