---
title: "Архитектура узла"
description: "Введение в то, как устроены узлы Эфириума."
lang: ru
---

Узел Эфириума состоит из двух клиентов: [клиента исполнения](/developers/docs/nodes-and-clients/#execution-clients) и [клиента консенсуса](/developers/docs/nodes-and-clients/#consensus-clients). Чтобы узел мог предложить новый блок, на нем также должен быть запущен [клиент валидатора](#validators).

Когда Эфириум использовал [доказательство выполнения работы (PoW)](/developers/docs/consensus-mechanisms/pow/), клиента исполнения было достаточно для запуска полного узла Эфириума. Однако после внедрения [доказательства доли владения (PoS)](/developers/docs/consensus-mechanisms/pos/) клиент исполнения должен использоваться вместе с другим программным обеспечением, называемым [клиентом консенсуса](/developers/docs/nodes-and-clients/#consensus-clients).

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

![Diagram of Ethereum node architecture showing execution and consensus layers](node-architecture-text-background.png)

_Существует несколько вариантов клиента исполнения, включая Эригон, Незермайнд и Besu_.

Чтобы эта двухклиентская структура работала, клиенты консенсуса должны передавать пакеты транзакций клиенту исполнения. Клиент исполнения выполняет транзакции локально, чтобы убедиться, что они не нарушают никаких правил Эфириума и что предложенное обновление состояния Эфириума корректно. Когда узел выбирается в качестве производителя блока, его экземпляр клиента консенсуса запрашивает пакеты транзакций у клиента исполнения, чтобы включить их в новый блок и выполнить для обновления глобального состояния. Клиент консенсуса управляет клиентом исполнения через локальное RPC-соединение с использованием [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md).

## Что делает клиент исполнения? {#execution-client}

Клиент исполнения отвечает за валидацию, обработку и распространение транзакций, а также за управление состоянием и поддержку виртуальной машины Эфириума ([EVM](/developers/docs/evm/)). Он **не** отвечает за создание блоков, их распространение или обработку логики консенсуса. Это входит в компетенцию клиента консенсуса.

Клиент исполнения создает полезные нагрузки исполнения — список транзакций, обновленное дерево состояний и другие данные, связанные с исполнением. Клиенты консенсуса включают полезную нагрузку исполнения в каждый блок. Клиент исполнения также отвечает за повторное выполнение транзакций в новых блоках, чтобы убедиться в их валидности. Выполнение транзакций происходит на встроенном компьютере клиента исполнения, известном как [виртуальная машина Эфириума (EVM)](/developers/docs/evm).

Клиент исполнения также предлагает пользовательский интерфейс к Эфириуму через [методы RPC](/developers/docs/apis/json-rpc), которые позволяют пользователям запрашивать данные из блокчейна Эфириума, отправлять транзакции и развертывать смарт-контракты. Обычно RPC-вызовы обрабатываются библиотекой, такой как [Web3js](https://docs.web3js.org/), [Web3py](https://web3py.readthedocs.io/en/v5/), или пользовательским интерфейсом, например, браузерным кошельком.

Подводя итог, клиент исполнения — это:

- пользовательский шлюз к Эфириуму;
- среда для виртуальной машины Эфириума, состояния Эфириума и пула транзакций.

## Что делает клиент консенсуса? {#consensus-client}

Клиент консенсуса обрабатывает всю логику, которая позволяет узлу оставаться синхронизированным с сетью Эфириума. Это включает в себя получение блоков от узлов-однорангов и запуск алгоритма выбора форка, чтобы гарантировать, что узел всегда следует за цепью с наибольшим накоплением аттестаций (взвешенных по эффективным балансам валидаторов). Подобно клиенту исполнения, клиенты консенсуса имеют свою собственную P2P-сеть, через которую они обмениваются блоками и аттестациями.

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

## Валидаторы {#validators}

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

[Подробнее о стейкинге](/staking/).

## Сравнение компонентов узла {#node-comparison}

| Клиент исполнения                                  | Клиент консенсуса                                                                                                                                         | Валидатор                    |
| -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------- |
| Распространяет транзакции в своей P2P-сети         | Распространяет блоки и аттестации в своей P2P-сети                                                                                                        | Предлагает блоки             |
| Выполняет/повторно выполняет транзакции            | Запускает алгоритм выбора форка                                                                                                                           | Накапливает вознаграждения/штрафы |
| Проверяет входящие изменения состояния             | Отслеживает вершину цепи                                                                                                                                  | Создает аттестации           |
| Управляет деревьями состояний и квитанций          | Управляет состоянием Beacon (содержит информацию о консенсусе и исполнении)                                                                               | Требует стейк в размере 32 ETH |
| Создает полезную нагрузку исполнения               | Отслеживает накопленную случайность в RANDAO (алгоритм, обеспечивающий проверяемую случайность для выбора валидатора и других операций консенсуса)        | Может быть подвергнут слэшингу |
| Предоставляет JSON-RPC API для взаимодействия с Эфириумом | Отслеживает обоснование и финализацию                                                                                                                     |                              |

## Дополнительная литература {#further-reading}

- [Доказательство доли владения (PoS)](/developers/docs/consensus-mechanisms/pos)
- [Предложение блока](/developers/docs/consensus-mechanisms/pos/block-proposal)
- [Вознаграждения и штрафы валидатора](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)