Gasper: консенсус Ethereum 2.0

15 сентября 2022 года Ethereum совершил The Merge - переход с Proof of Work на Proof of Stake. За одну ночь сеть, обрабатывающая транзакции на миллиарды долларов, заменила свой механизм консенсуса. Ни одна транзакция не была потеряна. Как 400,000+ валидаторов (а сегодня уже 900,000+) координируются каждые 12 секунд, чтобы сеть с капитализацией в сотни миллиардов долларов работала без единой секунды простоя? За этим стоит Gasper - гибрид двух протоколов, которые по отдельности решают разные задачи, а вместе создают систему, которую практически невозможно взломать.

• **Ethereum The Merge** - крупнейшая в истории миграция консенсуса production-системы с сотнями миллиардов долларов на кону, работающая именно на Gasper
• **DeFi и stablecoins** - Uniswap, Aave, USDC полагаются на finality Gasper: после finalization транзакцию невозможно отменить, что критично для финансовых операций
• **Liquid staking (Lido, Rocket Pool)** - протоколы, позволяющие участвовать в Gasper-консенсусе без 32 ETH, контролируют более 30% всего stake
• **L2 rollups (Arbitrum, Optimism, Base)** - Layer 2 решения наследуют безопасность Gasper, "якоря" к L1 finalized блокам обеспечивают гарантии для миллионов пользователей

Предварительные знания

• Proof of Stake
• BFT Consensus: PBFT and variants

Casper FFG: Friendly Finality Gadget

В классических blockchain-системах транзакция никогда не становится по-настоящему необратимой - она лишь становится *всё менее вероятной* для отмены с каждым новым блоком. **Casper FFG** решает эту проблему: он добавляет механизм **finality** поверх любого fork choice rule.

Casper FFG - это **overlay protocol**. Он не производит блоки сам, а работает *поверх* механизма выбора цепочки, периодически ставя на ней "печати необратимости".

Как это работает? Валидаторы голосуют за **checkpoint-пары**: (source, target). Source - это последний finalized checkpoint, target - текущий checkpoint-кандидат. Каждый голос (attestation) содержит:

1. **Source checkpoint** - откуда "прыгаем" (уже justified или finalized)
2. **Target checkpoint** - куда "прыгаем" (кандидат на justified)
3. **BLS-подпись** валидатора, подтверждающая его голос

Когда за пару (source → target) проголосовали валидаторы, контролирующие **2/3 от общего stake** (supermajority link), target получает статус **justified**.

Порог именно **2/3**, а не 1/2. При 1/2 две конфликтующие группы могли бы одновременно justify разные ветки. С порогом 2/3 это невозможно: два множества по 2/3 неизбежно пересекаются минимум на 1/3, и эта треть была бы slashed за двойное голосование.

Casper FFG определяет два вида нарушений (**slashing conditions**):

1. **Double vote** - голос за два разных target в одном epoch
2. **Surround vote** - голос, который "окружает" другой голос того же валидатора (source₁ < source₂ < target₂ < target₁)

Благодаря accountable safety, если finalized блоки конфликтуют, можно математически доказать, что минимум 1/3 валидаторов нарушили правила и заслужили slashing. Это делает атаку крайне дорогой: атакующий потеряет как минимум 1/3 всего заложенного ETH.

LMD-GHOST: выбор правильной цепочки

Casper FFG обеспечивает finality, но между checkpoint-ами сеть должна решать, какую именно цепочку блоков считать каноничной. Для этого Ethereum использует **LMD-GHOST** - Latest Message Driven Greedy Heaviest Observed SubTree.

Название длинное, но каждое слово несёт смысл:

• **Latest Message Driven** - учитывается только последний голос (attestation) каждого валидатора, а не вся история
• **Greedy** - алгоритм жадно выбирает лучший вариант на каждом шаге, спускаясь от корня к листу
• **Heaviest Observed SubTree** - на каждом fork выбираем ветку с наибольшим суммарным весом (stake) аттестаций

Ключевое отличие от **longest chain rule** (Bitcoin):

Важное свойство LMD-GHOST: каждый валидатор учитывается ровно один раз ("latest message"). Если валидатор проголосовал за блок X, а потом за блок Y - учитывается только голос за Y. Это предотвращает "flip-flopping" атаки.

В Gasper **LMD-GHOST и Casper FFG работают вместе**: LMD-GHOST отвечает за fork choice в реальном времени ("какой блок строить следующим?"), а Casper FFG периодически "цементирует" цепочку, превращая justified блоки в finalized.

Epochs и Slots: тактовый механизм Ethereum

Gasper делит время на фиксированные интервалы. Это не просто организационная структура - это фундаментальный механизм, позволяющий координировать сотни тысяч валидаторов без единого центра.

В каждом slot происходит чётко определённая последовательность действий:

1. **Proposer** (один валидатор) предлагает блок. Он выбирается псевдослучайно через RANDAO с весами пропорционально stake
2. **Committee** (группа валидаторов) голосует за блок через attestations. Каждый epoch весь набор валидаторов делится на 32 committee - по одному на slot
3. **Агрегаторы** (подмножество committee) собирают attestations в агрегированные подписи (BLS aggregation)

Минимальный размер committee - **128 валидаторов**. Это обеспечивает статистическую безопасность: вероятность того, что 2/3 committee окажутся злонамеренными, экспоненциально мала при случайном распределении.

Каждый epoch, все ~900,000+ активных валидаторов распределяются по 32 committee. Каждый валидатор аттестует ровно один раз за epoch. Это создаёт предсказуемую нагрузку на сеть:

Помимо основных committee, существуют **Sync Committees** - специальные группы из 512 валидаторов, ротирующиеся каждые ~27 часов (256 epochs). Их задача - создавать лёгкие подписи для light clients, чтобы те могли верифицировать цепочку без скачивания всех attestations.

Proposer selection использует **RANDAO** - decentralized random beacon. Каждый proposer добавляет свой RANDAO reveal (BLS-подпись числа epoch), который XOR-ится с текущим RANDAO mix. Результат используется для выбора следующих proposer-ов и перемешивания committee.

Justification и Finalization

Attestations накапливаются slot за slot, но настоящая магия происходит на границах epoch. Здесь Casper FFG превращает голоса валидаторов в **необратимые решения**. Процесс идёт в два этапа: justification, затем finalization.

Этап 1: Justification

Checkpoint (граница epoch) становится **justified**, когда supermajority link (2/3+ голосов) указывает от уже justified/finalized checkpoint на этот checkpoint.

Этап 2: Finalization

Checkpoint **A** становится **finalized**, когда выполнено одно из двух условий:

1. **Стандартная finalization (k=1):** A justified, и есть supermajority link A → B, где B - следующий непосредственный epoch после A
2. **Расширенная finalization (k=2):** A justified, и есть supermajority link A → C через один epoch (два epoch подряд justified)

После finalization блок **невозможно отменить** без slashing минимум 1/3 всех валидаторов. При текущем количестве stake (~32M ETH) это потребовало бы уничтожения ~10M ETH - экономически самоубийственная атака.

Когда finalization ломается: Inactivity Leak

Если сеть не может достичь 2/3 голосов (массовый offline валидаторов), finalization останавливается. Gasper имеет встроенный механизм самовосстановления - **inactivity leak**:

• Offline-валидаторы начинают **терять stake** квадратично по времени (чем дольше offline, тем быстрее потери)
• Через некоторое время их доля падает ниже 1/3, и оставшиеся online-валидаторы снова составляют 2/3
• Finalization возобновляется на новом checkpoint

Реальный случай: Beacon Chain Finality Issues (май 2023)

В мае 2023 Ethereum Beacon Chain дважды испытал проблемы с finality. Цепочка продолжала производить блоки, но finalization остановилась на ~25 минут и ~1 час соответственно. Причина - баг в двух крупных клиентах (Prysm и Teku), из-за которого часть валидаторов временно перестала аттестовать. Этот инцидент наглядно показал:

• **Liveness vs Safety trade-off**: цепочка продолжила работать (liveness), но без finality (ослабленная safety)
• **Client diversity критична**: если один клиент контролирует >1/3 сети, его баг может остановить finality
• **Inactivity leak не активировался**: проблема решилась слишком быстро (нужно 4+ epoch без finality)

Finalized означает необратимый. Justified означает "предварительно одобренный". Не путайте: транзакция в justified блоке ещё *может* быть отменена (хотя это крайне маловероятно), а в finalized - не может без уничтожения 1/3 stake.

Ключевые идеи

• **Gasper = Casper FFG + LMD-GHOST** - два протокола, один для finality (необратимости), другой для fork choice (выбора цепочки) в реальном времени
• **Casper FFG** - overlay protocol, создающий supermajority links между checkpoint-ами; 2/3 stake для justified, два подряд justified → finalized
• **LMD-GHOST** - fork choice rule: на каждом fork выбирается ветка с наибольшим весом attestations, учитывая только последний голос каждого валидатора
• **Epoch = 32 slots x 12 сек = 6.4 мин** - каждый валидатор аттестует ровно 1 раз за epoch; committee из 128+ валидаторов обеспечивают статистическую безопасность
• **Finalization за 2 epoch (~12.8 мин)** - детерминистическая, в отличие от вероятностных "6 подтверждений" Bitcoin. Помните The Merge? Именно эта детерминистическая finality позволила перейти на PoS без потери ни одной транзакции
• **Inactivity leak** - механизм самовосстановления: offline-валидаторы квадратично теряют stake, пока online-участники не достигнут supermajority

Связанные темы

Gasper стоит на плечах гигантов - он синтезирует идеи из Proof of Stake, BFT-консенсуса и криптографии:

• Proof of Stake — Gasper - конкретная реализация PoS; staking, slashing и validator selection из PoS являются фундаментом Casper FFG
• BFT-консенсус — Casper FFG - это BFT finality gadget; порог 2/3 и accountable safety напрямую следуют из теории Byzantine Fault Tolerance
• The Merge и будущее Ethereum — Gasper - движок Beacon Chain, который после The Merge стал консенсусом всего Ethereum; Danksharding и PBS строятся поверх Gasper
• BLS-подписи — Без BLS aggregation Gasper не масштабировался бы: 900K attestations за epoch агрегируются в компактные подписи благодаря BLS

Вопросы для размышления

• Gasper жертвует скоростью finalization (12.8 мин) ради безопасности (детерминистическая finality). Существует ли фундаментальный trade-off между скоростью и безопасностью finality, или можно построить протокол с мгновенной детерминистической finality?
• При инциденте с finality в мае 2023 два клиента (Prysm и Teku) контролировали >2/3 сети. Как бы вы спроектировали стимулы, чтобы ни один клиент не занимал >1/3?
• Inactivity leak "наказывает" валидаторов, которые могли уйти offline не по своей вине (сбой интернета, DDoS). Справедлив ли этот механизм, и какие альтернативы могли бы существовать?

Связанные уроки

• dist-10-byzantine