Валидаторы и Slashing

Зачем разбираться в валидаторах?

В предыдущем уроке мы увидели, что безопасность Ethereum PoS обеспечивается экономическим залогом валидаторов. Но как именно работает эта система? Что происходит от момента внесения 32 ETH до получения первой награды? Что случится, если валидатор нарушит правила?

Понимание механики валидаторов критично для:

• Разработчиков стейкинг-протоколов (Lido, Rocket Pool)
• Операторов нод (запуск собственного валидатора)
• Аудиторов (понимание условий slashing)
• Любого, кто стейкает ETH через пулы

Валидатор = нода + BLS-ключ + 32 ETH депозит
Его работа: аттестовать блоки, предлагать блоки (при выборе), участвовать в sync-комитетах
Его мотивация: награды за честную работу, slashing за нарушения

Интуитивное объяснение: валидатор как охранник

Представьте охранника в банке:

1. Устройство на работу (депозит): вносит залог 32 ETH
2. Испытательный срок (очередь активации): ожидание ~13 минут
3. Рабочая смена (активный): каждые 6.4 минуты подтверждает транзакции
4. Зарплата (награды): получает ETH за честную работу
5. Увольнение (выход): забирает залог + накопленные награды
6. Штраф (slashing): если пойман на мошенничестве — залог частично или полностью конфискуется

Жизненный цикл валидатора

Пройдите через все этапы жизни валидатора. Обратите внимание на изменения Pectra:

Этап 1: Депозит

Контракт депозита: 0x00000000219ab540356cBB839Cbe05303d7705Fa

deposit(
    pubkey,                  // BLS публичный ключ (48 байт)
    withdrawal_credentials,  // Куда вывести средства при выходе
    signature,               // Подпись BLS ключом
    deposit_data_root        // Корень Merkle дерева данных депозита
)

Минимум: 32 ETH
Максимум (Pectra): 2048 ETH (EIP-7251)

EIP-7251 (Pectra): Максимальный эффективный баланс увеличен с 32 до 2048 ETH. Крупные стейкеры (биржи, пулы) могут консолидировать десятки валидаторов в один, снижая нагрузку на сеть.

Этап 2: Очередь активации

До Pectra:
1. Депозит на Execution Layer
2. Beacon Chain обнаруживает через eth1_data_poll (~13 часов)
3. Валидатор попадает в очередь
4. Churn limit: max 13 валидаторов / эпоху (~800K валидаторов)

После Pectra (EIP-6110):
1. Депозит на Execution Layer
2. Deposit receipt включается в блок (~13 минут!)
3. Beacon Chain обрабатывает немедленно
4. Активация значительно быстрее

Этап 3: Обязанности активного валидатора

Каждый активный валидатор выполняет три типа обязанностей:

1. Аттестация (каждую эпоху, обязательно):
   - Head vote: какой блок считать head цепочки (LMD GHOST)
   - Source vote: последний justified checkpoint (Casper FFG)
   - Target vote: текущий checkpoint (Casper FFG)
   - Когда: один раз за эпоху (6.4 мин)

2. Предложение блока (при выборе, ~раз в 2 месяца):
   - Собрать транзакции из мемпула
   - Включить аттестации от других валидаторов
   - Сгенерировать RANDAO reveal (BLS подпись)
   - Когда: случайный выбор через RANDAO

3. Sync Committee (каждые ~27 часов):
   - 512 валидаторов подписывают head блока
   - Используется лёгкими клиентами для быстрой синхронизации
   - Когда: ротация каждые 256 эпох (~27 часов)

Этап 4: Система наград

# Упрощенная модель наград за эпоху:

base_reward = effective_balance * 64 / (sqrt(total_balance) * 4)

# Компоненты награды (веса):
SOURCE_WEIGHT  = 14 / 64  # Правильный source vote
TARGET_WEIGHT  = 26 / 64  # Правильный target vote
HEAD_WEIGHT    = 14 / 64  # Правильный head vote
SYNC_WEIGHT    = 2 / 64   # Участие в sync committee
PROPOSER_WEIGHT = 8 / 64  # Предложение блока

# Пример для 32 ETH при 33M стейке:
# base_reward ≈ 8904 gwei
# Годовой доход ≈ 2.9 ETH (если все обязанности выполняются идеально)

Пропущенная аттестация = не получаете награду + штраф (penalty, не slashing!) в размере base_reward. Это стимулирует 24/7 доступность ноды.

Четыре условия Slashing

Slashing — это серьезное наказание за нарушение правил протокола. В отличие от обычных штрафов (penalty) за пропущенные аттестации, slashing может уничтожить значительную часть залога.

Алгоритм наказания при slashing

Slashing состоит из 3 компонентов:

1. Начальный штраф (немедленно):
   penalty_1 = effective_balance / 4096  (Pectra)
   penalty_1 = effective_balance / 32    (до Pectra)

   При 32 ETH:
   Pectra:    32 / 4096 ≈ 0.0078 ETH
   До Pectra: 32 / 32   = 1.0 ETH

2. Корреляционный штраф (~18 дней):
   penalty_2 = effective_balance * slashed_in_period * 3 / total_balance

   Если 1 валидатор: penalty_2 ≈ 0 (ничтожная доля)
   Если 33% валидаторов: penalty_2 ≈ effective_balance (весь залог!)

   Это гениальный механизм: одиночная ошибка почти бесплатна,
   но координированная атака уничтожает залог всех атакующих.

3. Принудительный выход (~36 дней):
   Валидатор принудительно выводится из активного набора.
   В течение этого периода продолжает терять награды.

Почему Pectra снизил начальный штраф?

До Pectra: 1/32 от баланса (~1 ETH при 32 ETH)
Pectra:    1/4096 от баланса (~0.008 ETH при 32 ETH)

Причина: EIP-7251 позволяет валидаторы до 2048 ETH.
При старом штрафе: 2048 / 32 = 64 ETH -- слишком высокий риск
                   для случайного бага клиента.
При новом штрафе:  2048 / 4096 = 0.5 ETH -- приемлемый риск.

Безопасность сохраняется через корреляционный штраф:
если атака координированная, penalty_2 все равно уничтожит стейк.

BLS подписи: почему не ECDSA?

В CRYPTO-11 мы изучили ECDSA — подпись, которую используют Bitcoin и Ethereum для транзакций. Но валидаторы Beacon Chain используют BLS подписи (Boneh-Lynn-Shacham) на кривой BLS12-381:

ECDSA (secp256k1): одна подпись = 64 байта
BLS12-381:         одна подпись = 48 байт

Главное преимущество BLS -- АГРЕГАЦИЯ:

128 аттестаций ECDSA: 128 * 64 = 8192 байт + 128 верификаций
128 аттестаций BLS:   1 * 48 = 48 байт + 1 верификация (агрегированная)

Без BLS-агрегации Beacon Chain не смог бы обрабатывать
сотни тысяч аттестаций за эпоху.

# Концептуально (не реальная криптография):
# BLS позволяет "сложить" подписи:

sig_1 = BLS_sign(key_1, message)
sig_2 = BLS_sign(key_2, message)
sig_3 = BLS_sign(key_3, message)

# Агрегация -- простое сложение на кривой:
agg_sig = sig_1 + sig_2 + sig_3

# Верификация одной операцией:
BLS_verify(agg_sig, [key_1, key_2, key_3], message)  # True

EIP-7002: Выход через Execution Layer

До Pectra единственный способ инициировать выход — подписать VoluntaryExit BLS-ключом валидатора. Это создавало проблему для стейкинг-пулов:

Проблема:
Пул (smart contract) хочет вывести валидатора, но BLS-ключ у оператора.
Если оператор отказывается -- стейкеры заблокированы.

EIP-7002 решение:
Smart contract на Execution Layer может инициировать выход валидатора.

// Контракт стейкинг-пула:
function forceExit(bytes pubkey) external onlyGovernance {
    // Вызываем системный контракт для выхода валидатора
    VALIDATOR_EXIT_PRECOMPILE.requestExit(pubkey);
}

Математический уровень

Inactivity Leak

Если сеть не финализирует блоки более 4 эпох, включается inactivity leak — экспоненциально растущий штраф для оффлайн-валидаторов:

inactivity_penalty = effective_balance * inactivity_score
                     / (INACTIVITY_PENALTY_QUOTIENT * 2^24)

INACTIVITY_PENALTY_QUOTIENT = 2^26 (67108864)

Инактивные валидаторы теряют баланс экспоненциально,
пока оставшиеся онлайн-валидаторы не наберут 2/3 для финализации.

Этот механизм гарантирует, что сеть восстановит финальность,
даже если 50%+ валидаторов уйдут оффлайн.

Минимальный порог для slashing

Нарушение Casper FFG (surround/double vote) детектируется
через slasher-ноды, которые мониторят все аттестации.

Для обнаружения нужно:
1. Две аттестации от одного валидатора
2. С одним и тем же BLS-ключом
3. Подтвержденные валидной BLS-подписью

Формально: аттестации (s1, t1) и (s2, t2) нарушают правила если:
- Double vote: t1.epoch == t2.epoch и t1.root != t2.root
- Surround: s1 < s2 < t2 < t1 (одна окружает другую)

Связь с предыдущими темами

• ECDSA (CRYPTO-11): валидаторы используют BLS12-381 вместо secp256k1, потому что BLS поддерживает агрегацию подписей
• Merkle деревья (CRYPTO-13/14): Beacon State хранится как SSZ Merkle tree, что позволяет доказывать балансы валидаторов с помощью Merkle proof
• PoW (BTC-06/07): slashing — это PoS-аналог потерянного электричества в PoW, но наказание внутри протокола

Что дальше?

Мы разобрали всю механику PoS: от депозита до slashing. В следующем уроке изучим Account Abstraction — технологию, которая меняет модель взаимодействия пользователей с Ethereum, позволяя программировать логику аутентификации и спонсирование газа.