Slashing – это протокольное наказание валидатора за действия, которые могут угрожать согласованности сети. В Ethereum оно связано прежде всего с конфликтующими подписями, а не с любым пропущенным блоком. Поэтому фраза «валидатор был офлайн и потерял весь залог» обычно смешивает разные механизмы: обычные штрафы за неучастие, особый режим длительной неактивности сети и собственно slashing.
За какие действия валидатора применяют slashing
Валидатор Ethereum подписывает предложения блоков и аттестации. Нарушение возникает, когда одним ключом подтверждают несовместимые сообщения: например, предлагают два разных блока для одного слота или создают конфликтующие аттестации. Такие подписи можно предъявить сети как доказательство. Валидатора принудительно выводят из активного набора, а часть его залога списывают.
Обычный простой устроен иначе. Если валидатор временно не отправляет аттестации, он не получает ожидаемое вознаграждение и несёт небольшие потери за пропуски, но это само по себе не является slashable-событием. Во время продолжительного нарушения финализации действует inactivity leak – баланс неактивных валидаторов уменьшается быстрее, чтобы сеть могла восстановить финализацию. Для владельца средств экономический результат неприятен в обоих случаях, но причина и масштаб риска различаются.
Самая распространённая операционная причина slashing – одновременный запуск одного валидаторского ключа на двух машинах. Оператор переносит узел, видит, что новый сервер синхронизировался, и запускает валидатор до того, как окончательно остановил старый. Два экземпляра могут подписать разные сообщения. Подробнее роль узла и валидатора разобрана в материале об инфраструктуре блокчейна.
Из чего складывается потеря
После обнаружения нарушения сеть применяет начальный штраф и начинает процедуру выхода. Окончательная потеря зависит не только от одного валидатора: корреляционная часть становится тяжелее, когда примерно в тот же период нарушает правила много валидаторов. Так протокол сильнее наказывает общий отказ одной инфраструктуры или массовое использование одинаково ошибочной конфигурации. Назвать универсальный процент заранее нельзя.
Валидатор после slashing не продолжает работать как обычно. Он выходит из активного набора, а вывод оставшегося баланса становится доступен после установленной протоколом задержки. Отдельно пользователь может потерять доход за время выхода. Если стейкинг организован через сервис, пул или ликвидный токен, к протокольному наказанию добавляются правила конкретного продукта: распределяет ли сервис убыток между всеми участниками, удерживает ли резерв и компенсирует ли ошибку оператора.
Что проверить делегатору до внесения средств
Сначала определите, кто фактически контролирует валидаторские ключи. При самостоятельном стейкинге это владелец инфраструктуры. При делегировании ответственность несёт оператор, а пользователь принимает его технический риск. Полезно узнать, использует ли оператор независимые площадки и клиенты, как переносит ключи, ведёт ли историю инцидентов и публикует ли правила компенсации. Высокая доходность не заменяет эти ответы.
Затем отделите нативный стейкинг от токена, который представляет долю в пуле. Цена ликвидного токена может отклоняться от стоимости базового актива, а обмен зависит от ликвидности рынка и смарт-контрактов. Эти риски подробно описаны в статье о ликвидном стейкинге. Также проверьте срок выхода, очередь вывода и то, кто оплачивает убыток при slashing.
- найдите в условиях сервиса отдельный раздел о slashing, а не только обещанную доходность;
- проверьте, относится ли заявленная защита к протокольному штрафу или лишь к простоям;
- уточните, есть ли предел компенсации и из какого резерва она выплачивается;
- оцените концентрацию операторов: одинаковая инфраструктура повышает корреляционный риск;
- сохраните адрес или идентификатор позиции, условия продукта и подтверждение внесения средств.
Как безопасно перенести собственный валидатор
Перед миграцией остановите валидаторский клиент на старой машине и убедитесь, что процесс действительно завершён. Перенесите базу защиты от slashing, если выбранный клиент предусматривает её экспорт и импорт. Только после этого запускайте ключ на новом сервере. Старый экземпляр нельзя оставлять как «резервный», способный автоматически включиться: горячий резерв с тем же ключом создаёт именно тот риск, от которого нужна защита.
Если непонятно, завершилась ли работа старого узла, безопаснее пропустить несколько аттестаций, чем одновременно подписывать с двух машин. Временный простой приводит к упущенному вознаграждению и небольшим штрафам за неучастие, тогда как конфликтующая подпись необратимо фиксируется в сети. Резервирование строят на безопасном переключении и защите ключей, а не на параллельном запуске.
Что делать после подозрения на slashing
Проверьте валидатор в обозревателе консенсусного слоя по его индексу или публичному ключу. Важно увидеть статус выхода и конкретное slashable-событие, а не ориентироваться на падение баланса кошелька. Соберите время, идентификатор валидатора, версии клиентов и журналы запуска обеих машин. Не публикуйте файл ключа, пароль к нему или seed-фразу.
При стейкинге через провайдера запросите идентификатор затронутого валидатора, транзакцию депозита и применяемую политику компенсации. Сравните ответ с ончейн-данными. Если сервис предлагает «восстановить штраф» после ввода seed-фразы, это мошенничество: протокольное наказание нельзя отменить секретом от кошелька. Базовые правила хранения секрета собраны в инструкции о действиях после компрометации кошелька.
Главный вывод прост: slashing – не синоним любой убыточности стейкинга. Для оценки риска нужно выяснить, кто подписывает сообщения, может ли один ключ запуститься дважды и как продукт распределяет протокольный штраф. Сравнить стейкинг с другими способами участия в сети помогает материал о различиях майнинга и стейкинга.
