Полный узел против валидатора: в чём реальная разница

Полный узел (full node) самостоятельно проверяет блоки и транзакции и хранит состояние цепи; валидатор делает всё то же самое, что и полный узел, а дополнительно предлагает свои собственные блоки и подтверждает (attests) блоки, предложенные другими. Вторая обязанность именно та, которая ставит под угрозу собственные средства валидатора, потому что вес валидатора в консенсусе определяется его депозитом. Роли часто путают из-за того, что одна машина может выполнять обе функции: валидатор почти всегда запускает полный узел «под капотом», и разница заключается не в установленном программном обеспечении, а в принимаемых на себя обязательствах.

Две обязанности, которые люди путают: обслуживание и валидация

Обслуживание цепи и валидация цепи – это две разные обязанности: узел отвечает на вопросы о цепи, которую он проверил, тогда как валидатор формирует блоки и голосует за те, которые он сам не создавал.

Узел (Node): процесс, который хранит копию цепи, проверяет каждый блок и каждую транзакцию в соответствии с правилами протокола и может отвечать на запросы о результате. Состояние (State): текущий набор балансов, кода и хранилища, который протокол нуждается в обработке для следующего блока, в отличие от истории блоков, которые привели к этому состоянию. Клиент (Client): программное обеспечение, реализующее протокол, которое в современных сетях proof-of-stake разделено на две части. Консенсус-клиент (consensus client) (также называемый beacon node): следит за цепочкой подтверждений (attestations) и решает, что является финальным. Клиент исполнения (execution client): исполняет транзакции и поддерживает состояние; эти два компонента общаются друг с другом через локальный канал, а не через сеть.

Узел, который только обслуживает, является читателем. Это важно, потому что кто-то должен хранить и проверять цепь без разрешения и без оплаты за это, что и составляет весь аргумент в пользу того, почему блокчейну нужны узлы.

• Обслуживание: проверка, хранение состояния, ответы на запросы, ретрансляция транзакций. Нет депозита, нет обязанности голосовать, нет вознаграждения.
• Валидация: предложение блоков, подтверждение блоков других участников, поддержание онлайн-статуса по требованию. Требуется депозит: 32 ETH для входа и до 2048 ETH эффективного баланса после EIP-7251, где эффективный баланс – это часть ставки, которая учитывается при определении веса в консенсусе. Обязанности строго контролируются, возможны штрафы.
• Оба варианта: запуск одного и того же консенсусного и исполнительного программного обеспечения, что именно и приводит к лёгкости потери различий между ними.

Полный узел, архивный узел, легкий клиент

Три типа узлов различаются тем, что они проверяют и что хранят: полный узел проверяет всё самостоятельно, архивный узел добавляет к этому историческое состояние, а легкий клиент проверяет заголовки блоков, запрашивая у провайдера всё остальное, а то, что каждый из них в итоге хранит, описано в справочнике по RPC.

Прунинг (удаление старых данных) – это место, где живёт большая часть путаницы. Полный узел хранит каждый блок и каждую транзакцию, но ему не нужно хранить каждое прошлое состояние: состояние удаляется за пределами окна хранения, тогда как история блоков остаётся. Архивный узел хранит и исторические состояния, что делает его большим и единственным типом узлов, способным ответить на запрос о балансе в произвольном прошлом блоке.

Режим синхронизации – это отдельный выбор от класса узла: узел может восстановить состояние, выполняя каждый блок начиная с генезиса, или начать с снимка состояния (snapshot), предоставленного пиром, и проверять данные вперёд от этой точки. Первый вариант медленнее и полностью самопроверяемый; второй быстрее и доверяет снимку, с которого начался, что представляет собой иную компромиссную ситуацию, чем та, которую делает легкий клиент.

Чем на самом деле занимается валидатор

Валидатор имеет две обязанности в каждой эпохе: предложить блок, когда он выбран, и подтвердить блок, который он считает каноническим; его влияние на результат пропорционально размеру депозита.

Клиент валидатора – это третий процесс. Он хранит ключи подписи и выполняет обязанности, тогда как подключённый к нему beacon node хранит цепь, а execution client хранит состояние. Такое разделение существует, чтобы ключи находились в максимально возможном изолированном процессе, и именно поэтому валидатор нельзя запустить как клиент на чужой инфраструктуре, не передав этому кому-то возможность подписывать данные: в обычной настройке ключ находится там, где выполняется обязанность, а отдельный подписант, к которому валидатор может обращаться, переносит проблему доверия, а не устраняет её. То, как голоса многих валидаторов превращаются в финализированный блок, является предметом отдельного справочника по консенсусу.

• Предложение: один валидатор на слот выбирается для создания и подписания блока, при этом выбор взвешивается по размеру депозита.
• Подтверждение: каждый валидатор голосует за голову цепи и за контрольные точки, которые он считает обоснованными.
• Комитет синхронизации: ротационное подмножество подписывает заголовки, которым следуют легкие клиенты, поэтому этим клиентам не нужно доверять провайдеру относительно самой цепи.

Слэшинг и стейкинг: откуда берётся риск

Риск запуска валидатора исходит от его собственного поведения, а не от атакующего: недобросовестное поведение, которое могло бы быть частью атаки на цепь, карается слэшингом, а изолированный инцидент наказывается гораздо мягче, чем массовый.

Первоначальный штраф представляет собой долю от эффективного баланса, а не фиксированную сумму: начиная с EIP-7251 это одна часть из 4096, что составляет около 0,008 ETH для валидатора с минимальным стейкингом в 32 ETH и около 0,5 ETH при максимальном значении в 2048 ETH. Затем валидатор помещается в очередь на выход примерно на 36 дней, и в середине этого периода применяется корреляционный штраф, размер которого масштабируется в зависимости от общего количества заблокированного стейка вокруг того же времени; если большое количество валидаторов блокируется вместе, этот штраф может достигнуть всего стейка.

Три нарушения подлежат слэшингу, и ни одно из них не происходит случайно:

1. Предложение двух разных блоков для одного и того же слота.
2. Подтверждение двух разных блоков для одного и того же слота.
3. Противоречие более раннему голосу за контрольную точку.

Нахождение в офлайне – это другая категория. Валидатор, который просто перестаёт отвечать, теряет вознаграждения, которые он мог бы заработать, и медленно теряет средства, а суровая версия этого штрафа наступает только тогда, когда сама цепь не может финализироваться и активна утечка неактивности (inactivity leak). Эта асимметрия преднамеренна: отсутствие – это затраты, конфликтующая подпись – это атака. Разница между двумя семействами консенсусов описана в статье proof of work versus proof of stake.

Сколько это стоит

Стоимость валидатора – это не только машина: пропускная способность, время синхронизации, толерантность к простоям и дисциплина обновлений – это те части, которые определяют устойчивость роли.

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

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

Из структуры затрат следуют два правила эксплуатации. Первое – никогда не запускать один и тот же ключ валидатора в двух местах, потому что дублирование подписи – это именно случай двойного голосования, за который слэшинг и наказывает. Второе – относиться к обновлению как к запланированному риску, а не к фоновому обслуживанию, поскольку пара клиентов должна оставаться синхронизированной с сетью.

Почему валидаторы редко открывают публичный API

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

Эти две функции имеют противоположные профили нагрузки. Валидатор выполняет несколько обязанностей за эпоху и нуждается в предсказуемой задержке; интерфейс запросов поглощает всё, что отправляет интернет, включая дорогие запросы и сканирования на наличие открытых ключей или методов отладки. Запуск их на одной машине превращает всплеск трафика в пропущенное подтверждение, а в худшем случае – в инцидент, связанный с ключом.

Более чистое решение – разделить роли и позволить валидатору быть единственным процессом с обязанностями: отдельный узел или точка доступа провайдера обслуживает запросы. Где именно проходит граница между узлом, точкой доступа и провайдером, описано в справочнике по RPC, включая причину, по которой точка доступа не является узлом. Разделение также делает режимы отказов отдельными: узел запросов можно перезапустить по желанию, тогда как процесс валидатора следует перезапускать только тогда, когда никто другой не может подписывать тем же ключом.

Частые вопросы

Может ли валидатор работать без полного узла?

Нет. Для предложения и подтверждения блоков валидатор должен самостоятельно проверять состояние цепи, что означает наличие консенсусного клиента и исполняющего клиента под ним.

Точка доступа провайдера может ретранслировать запросы, но не может самостоятельно выполнять обязанности валидатора.

Зарабатывает ли полный узел что-либо?

Нет. Полный узел не получает оплату от протокола за проверку блоков и хранение состояния, поэтому его доход – это независимость, а не деньги.

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

Небезопасен ли легкий клиент?

Он сильнее в одном аспекте и слабее в другом: он локально проверяет получаемые заголовки, но зависит от провайдера относительно состояния, на которое указывают эти заголовки.

Для кошелька, читающего баланс, эта сделка обычно приемлема; для чего-либо, что самостоятельно перемещает ценности, это неприемлемо.

Что вызывает слэшинг?

Поведение, которое могло бы быть частью атаки на цепь: предложение двух блоков для одного слота, подтверждение двух блоков или противоречие более раннему голосу за контрольную точку.

Длительное отсутствие наказывается иначе и обычно гораздо мягче, через потерю вознаграждений, а не уничтожение стейка.

Почему не стоит открывать API валидатора публично?

Потому что публичный трафик достигнет процесса, который подписывает блоки и отвечает за депозит, где цена ошибки измеряется не удобством.

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