Архитектура узла
Последнее обновление страницы: 26 февраля 2026 г.
Узел Ethereum состоит из двух клиентов: клиента исполнения и клиента консенсуса. Чтобы узел мог предложить новый блок, он также должен запустить клиент валидатора.
Когда Ethereum использовал доказательство работы, для запуска полного узла Ethereum было достаточно клиента исполнения. Однако с момента внедрения доказательства владения клиент исполнения должен использоваться вместе с другой программой, называемой клиентом консенсуса.
На диаграмме ниже показаны отношения между двумя клиентами Ethereum. Два клиента подключены к своим собственным одноранговым сетям (P2P) Отдельные P2P-сети необходимы, поскольку клиенты исполнения распространяют транзакции по своей P2P-сети, что позволяет им управлять своим локальными транзакциями, в то время как клиенты консенсуса обмениваются блоками по своей P2P-сети, что обеспечивает консенсус и рост цепочки.
Существует несколько вариантов клиента исполнения, включая Erigon, Nethermind и Besu.
Чтобы эта двухклиентская структура работала, клиенты консенсуса должны передавать пакеты транзакций клиенту исполнения. Клиент исполнения выполняет транзакции локально, чтобы убедиться, что транзакции не нарушают никаких правил Ethereum и что предлагаемое обновление состояния Ethereum является верным. Когда узел выбран в качестве производителя блока, его экземпляр клиента консенсуса запрашивает пакеты транзакций у клиента исполнения, чтобы включить их в новый блок и выполнить для обновления глобального состояния. Клиент консенсуса управляет клиентом исполнения через локальное RPC-соединение с помощью Engine API (opens in a new tab).
Что делает клиент исполнения?
Клиент исполнения отвечает за проверку, обработку и распространение транзакций, а также за управление состоянием и поддержку виртуальной машины Ethereum (EVM). Он не несет ответственности за создание блоков, их распространение или обработку логики консенсуса. Это входит в полномочия клиента консенсуса.
Клиент исполнения создает полезные нагрузки исполнения — список транзакций, обновленное дерево состояния и другие данные, связанные с исполнением. Клиенты консенсуса включают полезную нагрузку исполнения в каждый блок. Клиент исполнения также отвечает за повторное исполнение транзакций в новых блоках, чтобы гарантировать их действительность. Выполнение транзакций осуществляется на встроенном компьютере клиента исполнения, известном как виртуальная машина Ethereum (EVM).
Клиент исполнения также предлагает пользовательский интерфейс для Ethereum через методы RPC, которые позволяют пользователям запрашивать блокчейн Ethereum, отправлять транзакции и развертывать умные контракты. Вызовы RPC обычно обрабатываются библиотекой, такой как Web3js (opens in a new tab), Web3py (opens in a new tab), или пользовательским интерфейсом, например, браузерным кошельком.
Подводя итог, можно сказать, что клиент исполнения это:
- пользовательский доступ к Ethereum
- дом для виртуальной машины Ethereum, состояния Ethereum и для транзакций.
Что делает клиент консенсуса?
Клиент консенсуса отвечает за всю логику, позволяющую узлу синхронизироваться с сетью Ethereum. Это включает в себя получение блоков от узлов и запуск алгоритма выбора ответвления, чтобы гарантировать, что узел всегда следует цепочке с наибольшим накоплением аттестаций (взвешенных по эффективным балансам валидатора). Подобно клиенту исполнения, клиенты консенсуса имеют собственную одноранговую сеть, через которую они обмениваются блоками и аттестациями.
Клиент консенсуса не участвует в аттестации или предложении блоков — это делает валидатор, необязательное дополнение к клиенту консенсуса. Клиент консенсуса без валидатора поддерживает связь только с концом цепи, позволяя узлу оставаться синхронизированным. Это позволяет пользователю взаимодействовать с Ethereum, используя свой клиент исполнения, будучи уверенным, что он находится в правильной цепочке.
Валидаторы
Стейкинг и запуск программного обеспечения валидатора дают узлу право быть выбранным для предложения нового блока. Операторы узлов могут добавить валидатора к своим клиентам консенсуса, внеся 32 ETH в депозитный контракт. Клиент валидатора идет в комплекте с клиентом консенсуса и может быть добавлен к узлу в любое время. Валидатор обрабатывает аттестации и предложения блоков. Это также позволяет узлу получать вознаграждения или терять ETH из-за штрафов или урезаний.
Сравнение компонентов узла
| Клиент исполнения | Клиент консенсуса | Валидатор |
|---|---|---|
| Распространяет транзакции через свою P2P-сеть | Распространяет блоки и аттестации через свою P2P-сеть | Предлагает блоки |
| Выполняет/повторно выполняет транзакции | Выполняет алгоритм выбора ветвления | Накапливает вознаграждения/штрафы |
| Проверяет поступающие изменения состояния | Отслеживает начало цепи | Делает аттестации |
| Управляет деревьями состояния и «квитанций» | Управляет состоянием Beacon (содержит информацию консенсуса и исполнения) | Требует 32 ETH для стейкинга |
| Создает полезную нагрузку исполнения | Отслеживает накопленную случайность в RANDAO (алгоритм, который обеспечивает проверяемую случайность для выбора валидатора и других операций консенсуса) | Может получить урезание |
| Предоставляет API JSON-RPC для взаимодействия с Ethereum | Следить за действительностью и финализацией |