ГЛАВНАЯ / ИНСТРУКЦИИ / EXECUTION CLIENT И CONSENSUS CLIENT: ЗАЧЕМ ETHEREUM НУЖНЫ ОБА
Execution client и consensus client: зачем Ethereum нужны оба
Современный узел Ethereum после перехода на proof of stake состоит из execution client и consensus client. Первый обрабатывает транзакции и состояние EVM, второй следит за консенсусом Beacon Chain и выбором канонической цепи. Чтобы исполнять обязанности валидатора, дополнительно запускают validator client.
Один узел связывает два клиента с разными обязанностями
Execution client и consensus client – отдельные реализации протокола, которые обмениваются данными через Engine API. У каждого клиента свой набор задач и отдельная P2P-сеть. Консенсусный клиент получает блоки и аттестации, а execution-клиент распространяет транзакции и проверяет исполнение их содержимого.
Разделение позволяет менять реализацию каждого слоя отдельно и снижает привязку к одному клиентскому приложению. Для полноценного узла Ethereum после Merge недостаточно запустить только execution-клиент или только consensus-клиент: они должны быть согласованы по сети и подключены друг к другу.
- установлены совместимые клиенты;
- оба используют одну и ту же сеть Ethereum;
- Engine API доступен только нужному локальному компоненту;
- состояние синхронизации проверено отдельно по каждому клиенту.
Execution client проверяет транзакции и обновление EVM
Execution client получает транзакции, ведёт локальный transaction pool, выполняет вызовы EVM, проверяет транзакции в новых блоках и хранит execution state. Он может предоставить приложениям JSON-RPC для чтения данных и отправки подписанных транзакций.
Он не определяет самостоятельно финальность proof-of-stake цепи. Execution client сообщает, допустим ли execution payload с точки зрения правил исполнения; консенсусный клиент объединяет этот результат с состоянием Beacon Chain и правилами fork choice.
- транзакция и execution payload проверяются правилами EVM;
- RPC относится к доступу приложений к execution данным;
- состояние execution-клиента нельзя приравнять к consensus state.
Consensus client ведёт Beacon Chain и выбор ветви
Consensus client принимает блоки и аттестации, поддерживает состояние proof-of-stake и применяет fork choice, чтобы определить, какую ветвь считать текущей. Он передаёт execution payload на проверку execution-клиенту и учитывает полученный результат.
Consensus client может синхронизироваться и поддерживать узел без активного validator. В таком режиме оператор может проверять цепочку и обслуживать локальные запросы, не подписывая аттестации и не предлагая блоки.
| Компонент | Основная задача | Что не следует ему приписывать |
|---|---|---|
| Execution client | Исполнение транзакций и EVM state | Fork choice Beacon Chain |
| Consensus client | Beacon Chain, fork choice и финальность | Исполнение EVM транзакций |
| Validator client | Подпись назначенных сообщений | Полную работу узла без двух базовых клиентов |
Engine API передаёт execution payload и результаты проверки
Engine API – внутренний RPC-интерфейс между execution и consensus клиентами. Через него consensus client предлагает payload для проверки, получает статус исполнения и обменивается информацией, нужной для построения или проверки блока.
В типовой конфигурации для аутентификации соединения используют общий JWT secret. Этот интерфейс рассчитан на связь двух клиентских компонентов, а не на публичный доступ приложений. Не путайте Engine API с обычным JSON-RPC, к которому подключается кошелёк или dApp.
Валидатор добавляет подпись и обязанности proof of stake
Validator client использует validator keys, чтобы выполнять назначенные протоколом обязанности: подписывать аттестации и иногда предложение блока. Для этой работы он взаимодействует с consensus client, а подготовка execution payload требует согласованной работы execution client.
Запуск двух базовых клиентов сам по себе не означает, что узел голосует или предлагает блоки. И наоборот, validator client не заменяет ни execution, ни consensus client. Секреты подписи и настройки защиты должны соответствовать конкретной схеме staking и документации операторского ПО.
- обычный узел и активный validator различены;
- ключи подписи не передаются RPC-провайдеру;
- обе части узла синхронизированы;
- варианты клиентов проверяются на совместимость.
Частые вопросы
Можно пользоваться Ethereum только с execution client?
Для локальной RPC-разработки отдельный execution endpoint может обслуживать некоторые запросы, но post-Merge узел должен быть связан с consensus client для актуального consensus состояния.
Нужен ли validator client каждому узлу?
Нет. Он нужен для участия validator в обязанностях proof of stake. Обычный узел может отслеживать цепь без валидатора.
Engine API – это публичный RPC?
Нет. Это интерфейс обмена между execution и consensus клиентами; его следует ограничивать и аутентифицировать.
Один клиент может выполнять все роли?
Установка может упаковывать компоненты вместе, но функции execution, consensus и validator остаются различными.
Чек-лист: execution client и consensus client: зачем ethereum нужны оба
- execution и consensus компоненты установлены;
- сеть и версия совместимы;
- Engine API соединяет правильные процессы;
- JWT secret доступен только нужным компонентам;
- JSON-RPC не перепутан с Engine API;
- validator client включён только если узел участвует в обязанностях;
- состояние синхронизации проверено по обоим слоям.
Материал подготовлен редакцией сайта и проверен 23 октября 2026 года. Условия бирж, кошельков и блокчейн-сетей могут меняться. Перед операцией сверяйте данные в интерфейсе выбранного сервиса.