Архитектура Ethereum — как устроена сеть под капотом

Архитектура Ethereum — это связка нескольких уровней, которые вместе обеспечивают работу сети, выполнение смарт-контрактов и безопасность протокола.

На высоком уровне её можно разложить так:

Execution Layer (EL) — слой исполнения: транзакции, EVM, смарт-контракты и состояние аккаунтов.
Consensus Layer (CL, Beacon Chain) — слой консенсуса: валидаторы, Proof-of-Stake, слоты и эпохи, финализация блоков.
Клиенты и узлы — программное обеспечение, которое реализует эти слои, хранит блокчейн, ретранслирует транзакции и блоки.
Расширения сверху — роллапы и L2-решения, которые используют Ethereum как “слой консенсуса и доступности данных”.

Эта страница — техничский обзор, как всё это связано между собой. Базовое описание сети см. на странице Ethereum (ETH).

Execution Layer: EVM, аккаунты и состояние

Execution Layer (EL) — это часть сети, где живут:

аккаунты (EOA и контракты);
баланс ETH и токенов;
код смарт-контрактов и их переменные;
журналы событий (logs);
история транзакций.

Типы аккаунтов

В Ethereum есть два типа аккаунтов:

EOA (Externally Owned Account)

«Обычные» адреса пользователей, управляемые приватным ключом. Через них отправляются транзакции, подписываются сообщения, вызываются контракты.

Пример: адрес вашего кошелька.

Контракт-аккаунт

Адрес, за которым закреплён код смарт-контракта и его состояние (storage). Контракт сам не может инициировать транзакцию — он исполняется в ответ на вызов со стороны EOA или другого контракта.

EVM и состояние

EVM (Ethereum Virtual Machine):

исполняет байткод смарт-контрактов;
работает по строгим правилам gas-учёта;
может читать/записывать хранение (storage), отправлять сообщения, вызывать другие контракты.

Состояние сети хранится в виде дерева (Merkle/Verkle-структур):

глобальное дерево state содержит аккаунты и указатели на их storage;
отдельные деревья используются для хранения получателей, логов и др.

Нода не обязана держать все исторические состояния целиком, но должна уметь проверять корректность текущего (через корневые хэши в блоках).

Транзакции и блоки на Execution Layer

Любое изменение состояния начинается с транзакции:

пользователь подписывает транзакцию приватным ключом EOA;
транзакция попадает в mempool узлов;
валидатор/билдер выбирает набор транзакций для блока и их порядок;
EVM последовательно исполняет их, изменяя состояние сети.

Структура блока EL включает:

заголовок (header) с ссылкой на предыдущий блок, корнем состояния, временем, сложностью и др.;
список транзакций;
дерево логов и дополнительных данных.

Execution Layer отвечает за:

детерминированное исполнение кода и изменение состояния;
проверку валидности транзакций (подписи, nonce, баланс);
расчёт комиссий за газ, сжигание base fee и начисление наград.

Consensus Layer: Beacon Chain и Proof-of-Stake

После перехода на PoS архитектура Ethereum разделена:

Execution Layer — выполняет транзакции.
Consensus Layer (Beacon Chain) — определяет, какой набор блоков EL считать честной и финализированной историей.

Beacon Chain управляет:

списком валидаторов и их стейком;
выбором пропоузеров блоков для каждого слота;
агрегированием голосов валидаторов (аттестаций) и финализацией.

Ключевые понятия:

Слот — базовый шаг времени. В каждый слот назначается пропоузер блока.
Эпоха — набор слотов; на уровне эпох принимаются решения о финализации.
Финализация — момент, когда блок считается практически необратимым (для отката нужна координированная атака валидаторов и огромные потери стейка).

Связанные страницы:

Клиенты Ethereum: execution и consensus

Узел Ethereum обычно состоит из двух клиентов:

Execution client — реализация EL: парсит и исполняет транзакции, ведёт состояние, общается с EVM.

Примеры: Geth, Nethermind и др.

Consensus client — реализация CL: управляет валидаторами, слотами, аттестациями, участвует в PoS-консенсусе.

Примеры: Lighthouse, Prysm и др.

Клиенты обмениваются данными по стандартизированному интерфейсу (Engine API):

consensus-клиент сообщает execution-клиенту, какой блок нужно собрать/проверить;
execution-клиент возвращает валидный блок и состояние;
consensus-клиент уже решает, считать ли его частью канонической цепи.

Такой «двухклиентный» дизайн:

упрощает независимую разработку и аудиты;
снижает риск критических багов: разные команды поддерживают разные реализации.

Gas и комиссии в архитектуре Ethereum

Механизм gas соединяет архитектуру EL с экономикой сети:

каждая операция EVM имеет стоимость в gas — ресурсные требования;
транзакция указывает gas limit (максимум, который она готова потратить);
итоговая комиссия рассчитывается по фактически израсходованному gas и цене gas.

После EIP-1559 комиссия делится на:

base fee — базовая часть, одинаковая для всех транзакций блока и сжигаемая протоколом;
priority fee (чаевые) — доплата валидатору или билдеру за приоритет.

Полезные страницы:

Роль валидаторов и MEV в архитектуре блоков

В архитектуре PoS Ethereum валидаторы:

ставят на стейкинг ETH и получают слот пропоузера;
либо сами собирают блок, либо используют рынок билдов и MEV через PBS (Proposer-Builder Separation) и MEV-Boost;
подписывают блок и передают его в сеть.

Слои вокруг блок-продакшна:

searchers и боты ищут арбитраж, ликвидации и другие источники MEV;
builders собирают максимально выгодные блоки;
relays передают блоки валидаторам с защитой от кражи payload.

Это не меняет базовую архитектуру EL/CL, но добавляет рыночный слой поверх формирования блоков, который важно учитывать при оценке безопасности и децентрализации сети.

См. также: MEV, PBS.

Ethereum как “base layer” для L2 и роллапов

Современная архитектура Ethereum проектируется как слой исполнения и доступности данных для внешних систем:

Роллапы (rollups) — выносят основное исполнение за пределы L1, но публикуют данные/доказательства в Ethereum, опираясь на его безопасность и цензуроустойчивость.
Danksharding и EIP-4844 — увеличивают пропускную способность по данным (blob-данные) в пользу L2.

Роль Ethereum:

финализировать и хранить данные роллапов;
предоставлять единый экономический слой (ETH, стейкинг, MEV);
служить нейтральной «координационной плоскостью» для множества L2.

Полезные материалы:

Account Abstraction и развитие архитектуры

Архитектура Ethereum продолжает эволюционировать:

Account Abstraction (Account Abstraction)

Сближение EOA и контракт-аккаунтов: возможность реализовывать кошельки как смарт-контракты с кастомной логикой подписи, мультисигами, соц-восстановлением, спонсированным газом.

ePBS и встроенные механизмы против цензуры

Перевод PBS из «надстройки» в сам протокол (ePBS), внедрение списков включения и других механизмов для защиты от цензуры и централизации билдеров.

Дальнейшее масштабирование

Переход от классического шардирования к danksharding, оптимизация хранения состояния, использование новых типов доказательств и деревьев.

Все эти направления меняют внутреннюю архитектуру клиентов и протокола, но базовая модель «EL + CL + L2 поверх» остаётся.

Частые вопросы (FAQ) по архитектуре Ethereum

Зачем разделять Execution Layer и Consensus Layer? Разделение упрощает разработку, аудит и обновления. Execution Layer концентрируется на EVM и состоянии, а Consensus Layer — на валидаторах, слотах, финализации. Это повышает модульность и устойчивость протокола.

Почему Ethereum не использует одно «монолитное» приложение-нод? Исторически были монолитные клиенты, но разделение на execution/consensus позволяет:

иметь несколько независимых реализаций каждого слоя;
снижать риски общих багов;
легче внедрять изменения в конкретном слое.

Где в архитектуре находятся DeFi, NFT и dApp? На уровне Execution Layer: это смарт-контракты и dApp, которые работают в EVM, читают/записывают состояние и используют инфраструктуру gas/транзакций. Beacon Chain лишь обеспечивает, чтобы их история была согласованной и финализированной.

Что изменится для архитектуры Ethereum с ростом L2? Ethereum всё больше смещается в сторону роли «слоя консенсуса и данных» для L2:

основной трафик исполнения уходит в роллапы;
L1 сосредотачивается на данных (blob’ы), финализации и безопасности;
архитектура клиентов оптимизируется под эту роль.