Beacon Chain — это слой консенсуса сети Ethereum, который управляет валидаторами, стейком, слотами и эпохами и решает, какая цепочка блоков считатьcя канонической.
После перехода Ethereum на Proof-of-Stake Beacon Chain отвечает за выбор пропоузеров блоков, сбор аттестаций валидаторов и финализацию истории. Исполнение смарт-контрактов и транзакций происходит на отдельном уровне — Execution Layer.
Роль Beacon Chain в архитектуре Ethereum
Архитектуру Ethereum можно упростить до двух слоёв:
- Execution Layer (EL) — транзакции, EVM, состояние аккаунтов, смарт-контракты.
- Consensus Layer (CL, Beacon Chain) — валидаторы, слоты, эпохи, финализация, выбор канонической цепи.
Beacon Chain:
- ведёт реестр валидаторов и их стейка;
- раздаёт валидаторам роли (пропоузер, комитеты для аттестаций, sync committee);
- агрегирует голоса и определяет, какие блоки EL входят в финализированную историю;
- применяет награды и штрафы за поведение валидаторов.
Execution Layer не решает, какая цепочка верна — это делает именно Beacon Chain.
Подробнее об общей схеме см. Архитектура Ethereum.
Валидаторы и стейкинг на Beacon Chain
Для участия в консенсусе Ethereum валидатор:
- вносит депозит (обычно 32 ETH) в стейкинг;
- генерирует ключи валидатора и вывода;
- подключает свои execution- и consensus-клиенты;
- после ожидания попадает в активный набор валидаторов.
Beacon Chain хранит:
- список валидаторов и их статус (pending, active, exited, slashed);
- размер эффективного стейка;
- историю наград и штрафов.
Связанные материалы:
Слоты, эпохи и финализация
Вместо «минут на блок» PoS-архитектура Ethereum опирается на слоты и эпохи:
- Слот — фиксированный шаг времени, в который может быть предложен один блок.
- Эпоха — последовательность слотов. На уровне эпох принимаются решения о финализации.
В каждом слоте Beacon Chain:
- выбирает валидатора-пропоузера, который должен предложить блок;
- распределяет остальных валидаторов по комитетам для аттестаций (голосования).
Аттестации валидаторов содержат:
- голос за «голову цепи» (те блоки, которые валидатор считает лучшими на данный момент);
- голос за контрольные точки (checkpoints) в начале/конце эпох.
Когда достаточно валидаторов подтверждают одни и те же контрольные точки, они становятся:
- justified — обоснованными;
- затем finalized — финализированными, то есть практически необратимыми.
Откат финализированных блоков потребовал бы согласованной атаки большого числа валидаторов и привёл бы к крупным slashing-штрафам.
Для будущих терминов можно будет использовать:
Награды, штрафы и slashing
Beacon Chain регулярно пересчитывает баланс валидаторов:
- Награды начисляются за:
- своевременные и корректные аттестации;
- предложение валидных блоков;
- участие в sync committee (отдельный набор валидаторов для «подписи состояния»).
- Штрафы применяются за:
- пропущенные аттестации (офлайн, проблемы с соединением);
- задержки и ошибки при предложении блоков;
- длительное бездействие (inactivity leak), особенно если сеть теряет финализацию.
- Slashing — усиленный штраф за серьёзные нарушения:
- двойное предложение блока для одного слота;
- конфликтующие аттестации;
- попытки атаки на финальность.
При slashing Beacon Chain:
- сжигает часть стейка нарушителя;
- выводит валидатора из активного набора;
- может дополнительно «наказывать» его соратников (корреляционный штраф), если атака координированная.
Подробно о рисках валидаторов см. Валидатор Ethereum и Proof-of-Stake.
Связь Beacon Chain и Execution Layer
Consensus-клиент (Beacon) и execution-клиент работают в паре:
- Beacon-клиент говорит execution-клиенту, какой блок EL нужно собрать или проверить;
- execution-клиент:
- исполняет транзакции;
- считает итоговое состояние, комиссии и награды;
- возвращает валидный блок или ошибку;
- Beacon-клиент использует этот блок как «полезную нагрузку» (execution payload) для очередного слота.
Через Beacon Chain проходят:
- ссылки на execution-блоки (их хэши и корни состояния);
- информация о blob-данных (после EIP-4844) и данных роллапов;
MEV, PBS и Beacon Chain
Beacon Chain задаёт календарь пропоузеров — кто и в какой слот имеет право подписать блок. Вокруг этого строятся:
- рынок MEV: поисковики и билдeры соревнуются, кто соберёт более прибыльный блок;
- инфраструктура PBS (Proposer-Builder Separation), где:
- билдеры собирают блоки и предлагают их пропоузерам;
- пропоузеры выбирают наиболее выгодный блок для подписи;
- отдельные сервисы (релеи) помогают безопасно обмениваться заголовками и payload.
Сам Beacon-протокол не «занимается MEV», но:
- через него происходит выбор пропоузеров на каждый слот;
- на его уровне обсуждается дальнейшая эволюция — ePBS и механизмы против цензуры (списки включения, inclusion lists).
Sync committee и лёгкие клиенты
Отдельный элемент Beacon Chain — sync committee:
- периодически выбирается подмножество валидаторов, которое подписывает «снимки» состояния Beacon Chain;
- эти подписи позволяют лёгким клиентам (light clients) следить за актуальной головой цепи без скачивания всех блоков;
- это важно для мобильных кошельков, браузерных расширений и других ресурсов с ограниченными ресурсами.
Sync committee — один из инструментов, делающих Ethereum более доступным для лёгких клиентов и Web3-приложений.
Перспективы развития Beacon Chain
Направления эволюции:
- ePBS — перенос логики разделения пропоузера и билдера в сам протокол, уменьшение доверия к внешним релеям.
- Danksharding — развитие модели доступности данных, увеличение пропускной способности за счёт blob-данных и более эффективной работы с роллапами.
- Улучшения PoS-логики — тонкая настройка наград/штрафов, снижение рисков централизации валидаторов и «супер-провайдеров» стейкинга.
- Оптимизация для лёгких клиентов — больше внимания sync committee, доказательствам состояния и удобным API для кошельков и dApp.
Beacon Chain остаётся ядром консенсуса Ethereum, вокруг которого будут разворачиваться основные изменения протокола.