Часть III · Глава 25 из 43 · Altair

Altair: sync-комитеты, или как телефон верифицирует Ethereum

Proof of stake защищён сотнями тысяч валидаторов — прекрасно для безопасности, безнадёжно для лёгкого клиента, который не может отследить их всех. Altair добавляет sync-комитет: небольшую, ротирующуюся группу из 512 валидаторов, подписывающую каждый блок, — так клиент с ограниченными ресурсами проверяет одну агрегированную подпись вместо миллиона аттестаций. Именно это делает возможными лёгкие клиенты, не требующие доверия, — и мосты, построенные на них.

Обновлено 24 июн. 2026 г. · 10 мин
Предполагается
  • proof of stake и beacon chain
  • доказательства Меркла

Altair, октябрь 2021 года — первый апгрейд beacon-цепочки и первая в этой книге глава, посвящённая исключительно консенсус-слою. До сих пор всё верифицировало Ethereum тяжеловесным способом: запускать полный узел, отслеживать всё состояние, проверять всё. Но большинство устройств на это не способны. Кошелёк на телефоне, клиент в браузере или другая блокчейн-сеть, желающая прочитать состояние Ethereum, должны убедиться в голове цепочки без скачивания всего мира и без слежения за миллионом валидаторов. До Altair это было невозможно — поэтому они доверяли RPC-провайдеру, незаметно возвращая посредника, ради устранения которого и существует блокчейн. Решение Altair — это sync-комитет. Давайте его выведем.

1 шаг Слишком тяжело для верификации

Проблема: лёгкий клиент не может проверить миллион валидаторов

При proof of stake блок становится каноническим благодаря аттестациям (attestations) Подписанные голоса валидаторов за голову цепочки и за оправданные/финализированные контрольные точки. Каждый активный валидатор аттестует раз в эпоху, так что верификация цепочки полным способом означает обработку голосов от всего множества валидаторов. от множества валидаторов — а это множество огромно (сотни тысяч, приближается к миллиону) и постоянно меняется. Чтобы верифицировать голову полным способом, нужно знать ключ каждого валидатора и обрабатывать гору агрегированных голосов каждую эпоху. Лёгкий клиент (light client) Клиент, который следит за цепочкой и верифицирует её с минимальными ресурсами — телефон, вкладка браузера или смарт-контракт в другой сети — не храня всё состояние и не запуская полный консенсус. — телефон, браузер, контракт в другой сети — просто не может. Поэтому ему остаётся довериться RPC-провайдеру, который скажет ему правду.

телефон не может проверить цепь с миллионом валидаторов лёгкий клиент телефон · браузер ~1 000 000 валидаторов аттестаций слишком много, чтобы проверить откат доверяет RPC ✗ доверенная третья сторона, которой блокчейн должен избегать
Верификация proof of stake означает проверку аттестаций от постоянно меняющегося множества из ~1 000 000 валидаторов — слишком тяжело для телефона или браузера. Поэтому лёгкие клиенты вынуждены доверять RPC-провайдеру, возвращая доверенную третью сторону, ради устранения которой и существует блокчейн.

→ Шаг 2: выбираем комитет, достаточно маленький для проверки.

2 шаг Небольшой подписывающий комитет

Sync-комитеты: 512 подписантов, одна подпись для проверки

Altair добавляет sync-комитет (sync committee) Случайно выбранное подмножество из 512 валидаторов, назначаемое на период примерно в 27 часов. В течение этого периода участники комитета подписывают заголовок каждого блока; лёгкий клиент проверяет их агрегированную подпись, чтобы убедиться в голове цепочки. : случайно выбранную группу из 512 валидаторов, фиксированную на период примерно в 27 часов. В течение этого периода участники комитета подписывают заголовок каждого блока. Поскольку Ethereum использует подписи BLS (BLS signatures) Схема подписи, чьи подписи можно агрегировать: подписи многих валидаторов над одним и тем же сообщением объединяются в одну, проверяемую по агрегату их публичных ключей за одну проверку. , все их подписи над блоком объединяются в одну агрегированную подпись. Так работа лёгкого клиента сводится к следующему: хранить 512 публичных ключей комитета и проверять, что супербольшинство из них подписало голову — одна проверка подписи против 512 известных ключей. Этого достаточно легко для телефона.

небольшой комитет подписывает каждый блок все валидаторы выборка 512 sync-комитет · 512 одна агрегированная BLS-подпись лёгкий клиент проверяет ОДНУ подпись против 512 известных ключей достаточно дёшево для телефона; RPC доверять не нужно
Sync-комитет — это 512 валидаторов, выбранных из полного множества на период примерно в 27 часов; они подписывают заголовок каждого блока, а агрегация BLS объединяет эти подписи в одну. Лёгкий клиент проверяет эту единственную агрегированную подпись против 512 известных ключей — достаточно дёшево для телефона, и никакого RPC, которому нужно доверять.

→ Шаг 3: пусть каждый комитет поручится за следующий.

3 шаг Прыжок вперёд без доверия

Итог: следим за головой с единственной контрольной точки

Изящная часть: sync-комитет следующего периода фиксируется в текущем состоянии beacon-цепочки. Так что лёгкий клиент, доверяющий текущему комитету, может получить ключи следующего комитета вместе с доказательством Меркла (Merkle proof) Короткое доказательство того, что значение (здесь — следующий sync-комитет) является частью состояния beacon-цепочки, проверяемое по корню состояния, который уже подписал текущий комитет. Оно позволяет клиенту принять следующий комитет без нового допущения о доверии. того, что они действительно находятся в состоянии, подписанном текущим комитетом, — и тем самым перескочить с периода N на период N+1 без нового доверия. Свяжите эти прыжки в цепочку, и клиент, стартующий с единственной доверенной контрольной точки слабой субъективности (weak subjectivity checkpoint) Недавняя доверенная отправная точка (корень финализированного блока), которую лёгкий клиент получает один раз, вне протокола. С неё он может дальше верифицировать всё самостоятельно. , может следить за головой Ethereum без доверия, вечно. Именно это делает возможными настоящие лёгкие клиенты (например, Helios) и, что особенно важно, мосты с минимизированным доверием — где одна сеть запускает лёгкий клиент Ethereum, чтобы верифицировать состояние Ethereum.

каждый комитет подтверждает следующий, клиент прыгает вперёд committee N ~27h period commits committee N+1 ~27h period commits committee N+2 ~27h period следующий комитет уже в текущем состоянии, подтверждён Merkle-доказательством от одной доверенной точки следуй за головой без доверия (512: меньше доверия, чем полный консенсус, но лучше RPC)
Каждый период комитета фиксирует следующий комитет в состоянии beacon-цепочки, так что лёгкий клиент перескакивает с периода N на N+1, верифицируя доказательство Меркла по корню, уже подписанному текущим комитетом. С одной доверенной контрольной точки он следит за головой вечно — никакой RPC не нужен.
04 Глубже Куда двигаться дальше