Блокчейн/Уровень III · Сеть/3.1 Ноды/Урок 3
Начальная загрузка блоков
Восстановление истории с нуля: цена независимой проверки
МатериалыКомпьютер с не менее чем 8 ГБ ОЗУ и SSDПрограмма Bitcoin Core (последняя стабильная версия)Доступ к терминалу с `bitcoin-cli`
Любопытство
- Почему новая нода загружает заголовки блоков раньше, чем сами блоки?
- Какие конкретные проверки пропускаются при включенном режиме ‘assumevalid’, и почему это безопасно?
- Если пропускная способность достаточно высока, чтобы заполнить диск за несколько минут, почему первоначальная синхронизация всё равно может занимать дни?
Исследование
- Только что установленный Bitcoin Core содержит лишь генезис-блок, жёстко прописанный в исходном коде. Он ничего не знает о длине и действительности цепочки. Подключившись к пирам, он начинает начальную загрузку блоков (Initial Block Download, IBD) — процесс, который восстанавливает всю историю с 3 января 2009 года до текущей вершины цепочки. Это не пассивное копирование, а активное восстановление: каждый блок, за исключением описанных ниже упрощений, проверяется на соответствие правилам консенсуса, прежде чем будет принят.
- Начиная с версии 0.10 (2015) IBD проходит в два этапа. Сначала нода загружает все заголовки блоков, которые компактны и быстро передаются. Она проверяет доказательство работы в этих заголовках, чтобы убедиться, что они соответствуют целевой сложности, и выстраивает цепочку работы, пока не проверяя действительность транзакций. Когда цепочка заголовков построена, нода параллельно запрашивает полные блоки у нескольких пиров и проверяет их последовательно по мере поступления.
- Проверка транзакций требует больших вычислительных затрат из-за проверки криптографических подписей. Чтобы ускорить синхронизацию, в версии 0.14 (2017) появился параметр 'assumevalid'. Он отключает проверку подписей для всех блоков, расположенных глубже жёстко заданного хеша широко проверенного блока. Всё остальное нода по-прежнему проверяет, включая доказательство работы, суммы и набор UTXO; для этой глубокой истории пропускаются только проверки скриптов и подписей. Пользователь может отключить эту функцию, чтобы проверить каждую подпись начиная с генезис-блока, ценой значительно более долгой синхронизации.
- В последних версиях есть экспериментальная функция 'assumeUTXO', позволяющая ноде начать работу с заранее вычисленного снапшота текущего набора UTXO. Нода быстро становится пригодной к использованию, а полная история проверяется в фоновом режиме. Пока эта проверка не завершена, нода доверяет снапшоту, хеш которого жёстко прописан в программе (сам файл можно получить откуда угодно); после этого она полностью независима.
- Продолжительность IBD сильно зависит от оборудования. На современном компьютере с быстрым SSD и 8 ГБ ОЗУ синхронизация может занять несколько часов. На маломощных устройствах вроде Raspberry Pi она может длиться несколько дней и дольше. Узким местом редко бывает пропускная способность сети; обычно это скорость записи на диск для кэша UTXO (dbcache) и процессорное время на проверку скриптов. Медленный жёсткий диск затормозит процесс даже при гигабитном интернете, поскольку нода должна постоянно читать и записывать состояние.
- После синхронизации нода достигает вершины действительной цепочки с наибольшим объёмом работы. Из наблюдателя она превращается в полноценного участника, способного ретранслировать транзакции и блоки своим пирам. Команда `bitcoin-cli getblockchaininfo` показывает ход этого процесса в поле `verificationprogress`, значение которого приближается к 1.0 по мере проверки исторической цепочки. В этот момент нода хранит полную, независимо проверенную копию истории денег.
Ключевые факты
- В Bitcoin Core версии 0.10 (2015) появилась синхронизация с предварительной загрузкой заголовков (headers-first), оптимизирующая начальную загрузку блоков.
- Параметр 'assumevalid' в версии 0.14 пропускает проверку подписей для блоков, расположенных глубже жёстко заданного хеша, чтобы ускорить синхронизацию.
- 'assumeUTXO' позволяет нодам начинать работу со снапшота UTXO и проверять историю в фоновом режиме; эта функция в экспериментальном виде появилась в последних версиях.
- Скорость записи на диск и выделение памяти для кэша UTXO зачастую являются более значительными ограничениями, чем пропускная способность, во время IBD.
- Новая нода проверяет блоки последовательно, даже если загружает их параллельно у нескольких пиров.
- Команда `bitcoin-cli getblockchaininfo` выводит `verificationprogress` — показатель того, какая часть цепочки уже проверена.
Упражнение девять, шесть, три, один
9СобратьПеречислите 9 различных конфигураций оборудования (CPU, RAM, тип накопителя), на которых запускают ноды Биткоина. Для каждой укажите типичное заявленное время синхронизации при новой установке.
6СгруппироватьСгруппируйте эти 9 конфигураций в 6 категорий по их основному узкому месту: процессор, оперативная память, дисковый ввод-вывод, пропускная способность сети или сбалансированная конфигурация.
3Выделить главноеСократите 6 категорий до 3 факторов, которые сильнее всего определяют продолжительность первоначальной синхронизации.
1КристаллизоватьНапишите одно предложение о компромиссе между скоростью синхронизации и криптографической независимостью при начальной загрузке блоков.
Проверка фактов
Даты, цифры и утверждения были проверены по приведенным ниже опубликованным источникам.