> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plasma.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Обзор

> Понимание модульной архитектуры нод 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 следует модели [прогрессивной децентрализации](https://a16zcrypto.com/posts/article/progressive-decentralization-crypto-product-management/). Вместо открытия набора валидаторов с первого дня изначальный фокус сделан на стабильности, производительности и удобстве для разработчиков. Этот подход отдаёт приоритет надёжности сети, пока основные компоненты протокола ещё развиваются.

Децентрализация остаётся долгосрочной целью, но будет вводиться постепенно. Набор валидаторов расширится через три этапа:

<Steps>
  <Step title="Централизованная работа">
    Во время testnet все консенсус-ноды управляются командой Plasma для обеспечения быстрой итерации и минимизации операционных рисков.
  </Step>

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

  <Step title="Безразрешительное участие">
    Со временем доступ к валидаторам откроется для публики, поддерживаемый протокольными гарантиями безопасности, живости и экономической согласованности.
  </Step>
</Steps>

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

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

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

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

Клиент исполнения использует стандартный протокол [devp2p](https://github.com/ethereum/devp2p) Ethereum для обнаружения пиров. При запуске нода Reth подключается к набору доверенных пиров исполнения, определённых в `enodes.txt`. Это [enode URL](https://ethereum.org/en/developers/docs/networking-layer/#enode), которые кодируют публичный ключ, IP-адрес и порт каждого пира.

`enodes.txt` каждой сети предварительно настроен в репозитории [non-validator-templates](https://github.com/PlasmaLaboratories/non-validator-templates). После подключения к начальному набору встроенный протокол обнаружения Reth (discv4/discv5) автоматически находит дополнительных пиров.

P2P-уровень исполнения работает на порту `30303` (TCP/UDP).

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

Клиент-наблюдатель консенсуса обнаруживает пиров через bootstrap-ноды, определённые в `non-validator.toml`. Каждая запись bootstrap-ноды включает API-хост, P2P-порт и [libp2p peer ID](https://docs.libp2p.io/concepts/fundamentals/peers/):

```toml theme={null}
[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-шлюзом или фаерволом, другие пиры могут не суметь связаться с ней по внутреннему адресу. Можно настроить внешний адрес, чтобы пиры могли обнаружить и подключиться к ноде:

<CodeGroup>
  ```toml non-validator.toml theme={null}
  [network]
  external_address = "node.example.com:34070"
  ```

  ```bash CLI theme={null}
  --p2p.external-address node.example.com:34070
  ```
</CodeGroup>

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

### Сводка

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

Для деталей по портам и фаерволу см. руководство [Настройка не-валидирующей ноды](./non-validator-node-setup#port-configuration).

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

<CardGroup cols={2}>
  <Card title="Типы нод" icon="chart-network" iconType="light" color="#307F61" href="/docs/node-operators/setup-and-configuration/node-types">
    Поймите роли валидаторов, не-валидирующих нод и RPC-провайдеров
  </Card>

  <Card title="Настройка не-валидирующей ноды" icon="gears" iconType="light" color="#307F61" href="../setup-and-configuration/non-validator-node-setup">
    Разверните ноду с помощью Docker Compose
  </Card>

  <Card title="Требования к оборудованию" icon="microchip" iconType="light" color="#307F61" href="/docs/node-operators/setup-and-configuration/hardware-requirements">
    Минимальные и рекомендуемые характеристики ноды
  </Card>

  <Card title="Подключение операторов" icon="rocket" iconType="light" color="#307F61" href="../setup-and-configuration/operator-onboarding">
    Начните с безразрешительной эксплуатации нод
  </Card>
</CardGroup>