Новый узел по-прежнему проверяет proof of work и скачивает текущий State. Но ему больше не нужно загружать тела всех исторических транзакций и исполнять цепочку от генезиса. Исследование описывает аутентифицированную границу снимка состояния, установку через временную область на диске, сохраняемый суффикс и различие между постоянной стоимостью проверки доказательства и затратами, которые неизбежно масштабируются с числом заголовков или объёмом Live State.
Удалить повторное исполнение, а не проверку
Повторное исполнение истории объединяет несколько разных задач под общим названием «синхронизация». Узел читает заголовки, чтобы сравнить накопленную работу, и скачивает тела транзакций для восстановления State — аутентифицированного набора текущих непотраченных выходов и счётчиков консенсуса. Затем он заново применяет все исторические правила, чтобы проверить полученный State. Последняя задача усложняется с возрастом цепи, даже если размер текущего State не меняется.
ParanO(1)d заменяет повторное исполнение истории рекурсивным HistoryStep. Каждый принятый блок доказывает точный переход от аутентифицированного родительского State к дочернему State. Поэтому текущая граница несёт доказательство всей породившей её цепочки переходов.
Финализированная граница — блок, который уже находится за пределами допустимого протоколом окна реорганизации. Недавний суффикс — последовательность не более чем из восемнадцати полных блоков между этой границей и текущей вершиной цепи.
Подключающийся узел не скачивает и не исполняет каждое историческое тело транзакции. Он проверяет один рекурсивный терминал на финализированной границе, восстанавливает точный текущий State, зафиксированный криптографическим обязательством, и затем применяет ограниченный недавний суффикс.
Какие затраты остаются
Только проверка граничного доказательства имеет постоянную сложность относительно возраста цепи. Проверка заголовков и передача текущего State по-прежнему масштабируются с объёмом данных, которыми должен располагать полный узел.
| Фаза | С чем масштабируется | Почему остаётся |
|---|---|---|
| Проверка заголовков | Высота цепи | Необходимо проверять proof of work и сравнивать накопленную работу |
| Терминал HistoryStep | Постоянная проверка доказательства | Рекурсивная валидность на выбранной границе |
| Передача State | Текущий State | Узел должен получить данные, которые будет хранить и обслуживать |
| Недавний суффикс | Не более 18 полных блоков | Связывает финализированную границу с актуальной вершиной |
Архитектура удаляет журнал исполнения, растущий с возрастом. Она не утверждает, что proof of work можно сравнить без чтения заголовков или что текущий State размером в несколько гигабайт можно установить, не передав эти гигабайты.
Два пути синхронизации
Небольшое отставание
Каждый полный узел сохраняет последние восемнадцать полностью принятых блоков. Пир, отстающий в пределах этого окна, запрашивает атомарные пакеты, содержащие семантический блок и соответствующий терминал HistoryStep. До материализации записей он проверяет непрерывность заголовков, точные правила сложности и времени, хеш proof of work на основе Poseidon2b, обязательства транзакций и State, рекурсивную валидность, выбор ветви и финальность.
Глубокое отставание
При большом отставании узел выбирает финализированную границу снимка состояния (snapshot):
- скачивает и проверяет постоянные заголовки;
- выбирает каноническую финализированную границу;
- получает и проверяет соответствующий терминал HistoryStep;
- скачивает манифест State и указанные в нём сегменты;
- восстанавливает точный глобальный корень State и счётчики;
- транзакционно устанавливает подготовленный State;
- проверяет и применяет сохранённый полный суффикс.
Все объекты связаны с одной границей
Действительное доказательство для высоты h не должно аутентифицировать манифест от h − 1 или набор сегментов из другой ветви. Поэтому манифест снимка связывает высоту границы, корень State, геометрию слотов, число активных элементов, счётчик размещения, идентификаторы сегментов, их корни и длины. Рекурсивный терминал, канонический заголовок и манифест обязаны называть одну границу.
Реализация использует разные типы для подготовки заголовков, выбранного сеанса проверки доказательства, постоянных данных доказательства и точной привязки границы. Эти типы не позволяют пиру составить недействительный пакет снимка из объектов, каждый из которых по отдельности действителен.
Дисковая подготовка как граница консенсуса
Сегменты поступают в изолированную временную область на диске. Активная база не обновляется постранично. Только после проверки каждого сегмента, счётчика, корня, граничного заголовка и терминала узел атомарно заменяет установленный State.
Если процесс прервётся, при следующем запуске незавершённая временная область удаляется, а работа продолжается с последней канонической базы. Это исключает режим восстановления, в котором консенсусному коду пришлось бы решать, какая доля предоставленного пиром снимка стала канонической.
Подготовка заголовков и установка State используют диск и ограниченные выделения памяти. Пир управляет передаваемыми байтами, но не может вызвать неограниченное выделение памяти декодером или заставить узел разместить в оперативной памяти весь State, подготовленный к установке.
Пир — источник данных
DNS-сид или пир, предоставляющий снимок, не подписывает State и не становится доверенным источником контрольной точки. Он передаёт заголовки, терминалы, манифесты и байты сегментов. Подключающийся узел самостоятельно определяет каноническую цепочку по proof of work и проверяет рекурсивные обязательства и обязательства State.
В этом состоит главное отличие обычного снимка от бездоверительного: во втором случае смена источника данных не меняет State, принимаемый проверяющей стороной.
Недавняя реорганизация и финальность
Финализированная граница не может быть реорганизована. Выбор ветви рассматривает только кандидатов, сохраняющих её, а допустимая глубина отката меньше восемнадцати блоков. Недавние полные блоки и данные отката покрывают этот суффикс. Более глубокая конкурирующая ветвь отвергается, а не «исправляется» установкой другого снимка.
Это правило согласует границу снимка с рекурсивной валидностью. Без жёсткой границы узел мог бы аутентифицировать один текущий State, а затем получить запрос на восстановление глубокой альтернативной истории, тела которой он намеренно не хранит.
Четыре проверки без доверия к снимку
Первичная синхронизация разделяет четыре вида свидетельств:
- заголовки устанавливают допустимую цепь с наибольшей работой;
- HistoryStep устанавливает валидность на границе;
- манифест и корни сегментов устанавливают точный текущий State;
- сохранённый суффикс устанавливает актуальность вплоть до текущей вершины.
Пир предоставляет байты для всех четырёх стадий, но не управляет ни одним правилом их приёмки. Передачу и подготовку можно менять, не превращая кеш, DNS-сид или зеркало снимка в доверенный источник контрольной точки.