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