Plasma Docs - Build on Plasma

Кратко

Plasma разделяет валидирующие ноды (которые предлагают и финализируют блоки) и не-валидирующие ноды (которые обслуживают RPC и следуют за цепочкой, не влияя на консенсус). Это позволяет Plasma держать набор валидаторов небольшим и безопасным, давать RPC-провайдерам возможность масштабироваться независимо и избегать добавления риска для консенсуса или сети.

Высокоуровневая архитектура

Уровень	Роль	Модель доверия
Уровень консенсуса (CL)	Предлагает и финализирует блоки	PlasmaBFT
Уровень исполнения (EL)	Обрабатывает транзакции, управляет состоянием, обслуживает RPC	Полностью доверяет своему парному CL

Каждый валидатор запускает одну консенсус-ноду и одну ноду исполнения, напрямую соединённые между собой. За исключением своих партнёров, ноды не общаются вне пиров своего уровня (CL-to-CL, EL-to-EL). Это разделение делает систему предсказуемой, безопасной и простой для понимания.

Проблема масштабирования

По мере роста использования всё больше приложений и пользователей нуждаются в RPC-доступе для запроса данных цепочки или отправки транзакций. Но если каждая новая нода исполнения должна быть сопряжена с новой консенсус-нодой, масштабирование становится неэффективным и рискует раздуть набор валидаторов. Позволять RPC-провайдерам запускать дополнительные валидаторы только для удовлетворения спроса на чтение — нецелесообразно и не соответствует целям производительности Plasma.

Решение: не-валидирующие ноды

Не-валидирующие ноды ведут себя как консенсус-ноды, но не участвуют в консенсусе. Вместо этого они «следуют» за доверенным валидатором для финализированных блоков и обновлений fork-choice. Ключевые поведения:

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

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

Преимущества этого дизайна

Цель	Как не-валидирующие ноды помогают
Сохранить компактный набор валидаторов	Не-валидирующие ноды не голосуют; голосуют только валидаторы.
Неограниченное горизонтальное масштабирование	RPC-провайдеры могут поднимать сотни RPC-нод для чтения/записи, каждая со своей не-валидирующей нодой, без необходимости в новых местах валидаторов.
Поддержание корректности консенсуса	Каждая нода исполнения по-прежнему следует ровно за одним CL. Риска расхождения состояния нет.
Снижение риска	Не-валидирующие ноды доступны только для чтения и не могут влиять на сообщения консенсуса.
Упрощение отказоустойчивости	Следуя за несколькими валидаторами, если один уходит офлайн, они могут автоматически переключиться на нового.

Сравнительная сводка

Функция	Валидаторы	Не-валидирующие ноды
Участие в консенсусе	Полное (предлагают, голосуют, финализируют)	Нет (только получают)
Типы сообщений	Все сообщения консенсуса	Только сообщения о блоках
Сетевая роль	Активный участник	Пассивный последователь
Требования к ресурсам	Выше (полный консенсус)	Ниже (только сообщения)

Прогрессивная децентрализация

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

Централизованная работа

Во время testnet все консенсус-ноды управляются командой Plasma для обеспечения быстрой итерации и минимизации операционных рисков.

Доверенный набор валидаторов

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

Безразрешительное участие

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

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

Обнаружение пиров

Ноды Plasma обнаруживают и подключаются к пирам через два независимых механизма — по одному для каждого уровня стека.

Уровень исполнения (Reth)

Клиент исполнения использует стандартный протокол devp2p Ethereum для обнаружения пиров. При запуске нода Reth подключается к набору доверенных пиров исполнения, определённых в enodes.txt. Это enode URL, которые кодируют публичный ключ, IP-адрес и порт каждого пира. enodes.txt каждой сети предварительно настроен в репозитории non-validator-templates. После подключения к начальному набору встроенный протокол обнаружения Reth (discv4/discv5) автоматически находит дополнительных пиров. P2P-уровень исполнения работает на порту 30303 (TCP/UDP).

Уровень консенсуса (PlasmaBFT)

Клиент-наблюдатель консенсуса обнаруживает пиров через bootstrap-ноды, определённые в non-validator.toml. Каждая запись bootstrap-ноды включает API-хост, P2P-порт и libp2p peer ID:

[network.bootstrap_nodes.0]
api_host = "plasma-mainnet-observer-cs-1.plasmalabs.tech"
p2p_port = 34070
peer_id = "16Uiu2HAm4WdZmik6PVsRvcbCzc1eHuNfQHgj52CxUAjmdC7W5dXi"

Каждая сеть поставляется с 3 bootstrap-нодами. Ваш клиент-наблюдатель подключается к ним при запуске и при включённом обнаружении пиров (discovery.enabled = true) автоматически находит дополнительных пиров в сети. P2P-уровень консенсуса работает на порту 34070 (TCP).

Ноды за NAT

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

[network]
external_address = "node.example.com:34070"

--p2p.external-address node.example.com:34070

Если порт опущен, по умолчанию используется значение p2p_port. Убедитесь, что внешний адрес доступен и соответствующие порты проброшены через ваш фаервол.

Сводка

Уровень	Протокол	Порт	Метод обнаружения
Исполнение	devp2p	`30303`	Доверенные enodes + автоматическое обнаружение
Консенсус	libp2p	`34070`	Bootstrap-ноды из `non-validator.toml`

Для деталей по портам и фаерволу см. руководство Настройка не-валидирующей ноды.

Быстрый старт

Типы нод

Поймите роли валидаторов, не-валидирующих нод и RPC-провайдеров

Настройка не-валидирующей ноды

Разверните ноду с помощью Docker Compose

Требования к оборудованию

Минимальные и рекомендуемые характеристики ноды

Подключение операторов

Начните с безразрешительной эксплуатации нод

Установка и настройка

Обслуживание

Узел консенсуса

Обзор

Кратко

Высокоуровневая архитектура

Проблема масштабирования

Решение: не-валидирующие ноды

Преимущества этого дизайна

Сравнительная сводка

Прогрессивная децентрализация

Обнаружение пиров

Уровень исполнения (Reth)

Уровень консенсуса (PlasmaBFT)

Ноды за NAT

Сводка

Быстрый старт

Типы нод

Настройка не-валидирующей ноды

Требования к оборудованию

Подключение операторов

​Кратко

​Высокоуровневая архитектура

​Проблема масштабирования

​Решение: не-валидирующие ноды

​Преимущества этого дизайна

​Сравнительная сводка

​Прогрессивная децентрализация

​Обнаружение пиров

​Уровень исполнения (Reth)

​Уровень консенсуса (PlasmaBFT)

​Ноды за NAT

​Сводка

​Быстрый старт

Типы нод

Настройка не-валидирующей ноды

Требования к оборудованию

Подключение операторов

Кратко

Высокоуровневая архитектура

Проблема масштабирования

Решение: не-валидирующие ноды

Преимущества этого дизайна

Сравнительная сводка

Прогрессивная децентрализация

Обнаружение пиров

Уровень исполнения (Reth)

Уровень консенсуса (PlasmaBFT)

Ноды за NAT

Сводка

Быстрый старт