Skip to main content
Узлу, входящему в сеть, надо ответить на два вопроса: как добраться туда, где блокчейн сейчас, и как там удержаться. Синхронизация состояния отвечает на оба, и компромисс между ними сделан явно, а не спрятан.

Два способа догнать сеть

Начальная загрузка — выход на текущую версию с нуля — делается одним из двух принципиально разных способов. Воспроизвести историю. Начать с генезиса и идти вперёд, либо выполняя каждую транзакцию заново, либо применяя выходные данные, которые исполнение уже произвело. На выходе узел держит всю историю: каждую версию, каждое доказательство, каждую транзакцию. Это ещё и медленно — и с каждым днём работы блокчейна медленнее. Скачать текущее состояние. Пропустить историю и забрать ключи и значения состояния такими, какие они на последней версии, с проверкой по зафиксированному корню. Узел оказывается на актуальной версии за долю этого времени и ничего не знает о том, как блокчейн к ней пришёл.
Новый узел
Режим начальной загрузки
Воспроизвести историювыполнить заново или применить сохранённое, с генезисамедленно, и с каждым днём медленнее
Скачать текущее состояниеключи и значения на последней версии, с проверкой по корнюактуально за долю времени
Текущая версиядалее непрерывная синхронизация
Пути не равнозначныУзел, скачавший текущее состояние, не может обслуживать исторические запросы и сказать, как позиция пришла в своё состояние. Узлу для индексатора или аудита нужна пропущенная история.
Внутри пути с воспроизведением есть ещё один выбор: выполнять транзакции заново, применять сохранённые выходные данные или дать узлу самому брать то, что быстрее в каждой точке. Повторное выполнение — более сильная проверка: оно воспроизводит результат, а не доверяет записанному; применение выходных данных быстрее. Смешанный режим существует потому, что правильный ответ меняется в зависимости от того, насколько узел отстал.
Это эксплуатационное решение, а не умолчание, которое принимают не думая. Узел, скачавший текущее состояние, не может обслуживать исторические запросы и не может ответить, как позиция пришла в своё нынешнее состояние: истории для чтения у него нет. Узлу, обслуживающему индексатор или процесс аудита, нужна ровно та история, которую он пропустил.

Как остаться на текущей версии

Выйдя на текущую версию, узел держится на ней, потребляя зафиксированные блоки по мере их поступления, — снова либо выполняя транзакции, либо применяя выходные данные, с тем же разменом: строгость проверки против скорости. Отличие от начальной загрузки в том, что разрыв малый и постоянный, а не большой и сокращающийся. Узел, отставший достаточно сильно, снова уходит на путь начальной загрузки, а не пытается закрывать произвольный разрыв по кусочкам.

Как движутся данные

Синхронизация устроена не как запрос диапазона блоков у одного соседа. Она разделена на слои так, чтобы ни один пир не был зависимостью и ни один отказ не останавливал продвижение. Следствие, которое стоит понять: синхронизирующийся узел не доверяет пиру. Каждый фрагмент приходит с доказательством, привязанным к корню, который зафиксировала сеть, а пира, отдавшего что-то несогласованное, отклоняют, а не принимают на веру. Выбор пиров — решение о производительности, а не о доверии.

Проверка

В синхронизации состояния ничто не принимается на основании того, кто это прислал. Значения состояния сверяются с зафиксированным корнем состояния. Транзакции и выходные данные — с аккумуляторами. Узел, который закончил начальную загрузку, получает состояние с корнем, совпадающим с тем, что подписал кворум валидаторов. Именно это делает быстрый путь безопасным: скачивание текущего состояния пропускает историю, но не пропускает проверку.

Что дальше

Хранение и доказательства

Структуры, благодаря которым синхронизация проверяема.

Запуск узла

Роли узлов и как спросить о запуске своего.

Топология сети

С каким ярусом узлов разговаривает синхронизирующийся пир.

Индексатор

На какие вопросы отвечает история и не может ответить текущее состояние.