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.