﻿---
title: "Слэшинг"
description: "Слэшинг — это определённое протоколом сокращение ставок, подлежащих штрафу, после проступка валидатора или оператора, за который он несёт ответственность. Анализируйте точное правонарушение, доказательства, базу ставок, формулу штрафа, сроки, делегирование и риск при выводе, вместо того чтобы предполагать, что каждое пропущенное обязательство или указанная процентная ставка имеют одинаковый эффект."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Слэшинг

> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

<a id="answer"></a>

## Прямой ответ

Слэшинг — это определенное протоколом уменьшение стейка после нарушения, которое можно отнести к валидатору, оператору или другому связанному участнику. Полное правило задает слэшингуемое нарушение, доказательство или счетчик, который его подтверждает, подверженный риску стейк, расчет штрафа и срок применения. Слэшинг может сопровождаться блокировкой, отключением, принудительным выходом, потерей вознаграждений или наградой за сообщение, но это отдельные переходы состояния, если протокол явно не объединяет их.

Не существует универсального правила штрафов. Ethereum накладывает штрафы на конфликтующие предложения и подтверждения, но рассматривает обычные пропущенные обязанности и утечки бездействия отдельно. Цепочка Cosmos SDK может настраивать штрафы как за двойную подпись, так и за простои. Polkadot различает правонарушения, наложение штрафов, отключение и изменения репутации. Сервис повторного стекинга может добавить еще одно обязательство, подлежащее штрафам, контракты которого, набор операторов и окно вывода отличаются от базовой цепочки. Ознакомьтесь с действующими правилами для точной сети, форка, среды выполнения или развертывания контракта.

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

Держите эти концепции отдельно:

- **Пропущенное вознаграждение или обычное наказание:** долг отсутствовал, был выполнен с опозданием или неверно, но ни одно наказуемое правонарушение не было доказано.
- **Механизм бездействия:** При продолжительном отсутствии финальности штрафы растут или меняется вес голосов; утечка бездействия Ethereum сама по себе не является слэшингом.
- **Слэшинг:** переход состояния, признанный в цепочке или протоколом, уменьшает ставку, связанную с доказанным нарушением.
- **Заключение в тюрьму, отключение, изгнание или пометка как устаревшего:** Участие приостановлено или завершено; действие может произойти с дополнительным уменьшением ставки или без него.
- **Социальное или договорное наказание:** Управление , соглашение об оказании услуг, страховой полис или скоординированный форк накладывают последствия за пределами автоматической функции slash в базовом протоколе.

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

<a id="mechanism"></a>

## Как анализировать слэшинг

### 1. Зафиксируйте набор правил и точку наблюдения

Запишите `network`, `chain ID`, активный `fork version` или время выполнения, блок или эпоху, релиз клиента/спецификации и соответствующие адреса контрактов. Разделите правила консенсуса и условия поставщика стейкинга и пользовательский интерфейс. Текущий запрос параметров и окончательное состояние являются более весомыми доказательствами, чем несвязанная по дате справочная страница.

### 2. Напишите точное описание правонарушения

Назовите правило в выполнимых терминах: два различных предложения от одного валидатора для одного и того же слота, `double vote`, `surround vote`, недопустимое голосование, признанное протоколом, или `missed > max_missed` в пределах окна живости. Не заменяйте предикат такими обозначениями, как «плохое поведение», «офлайн» или «атака».

### 3. Проверьте атрибуцию и доказательства

Проверяйте личность валидатора или оператора, подписи, `signing root`, разделение доменов, контекст форка, высоты или эпохи и возраст доказательств. Для нарушений, связанных с противоречивыми сообщениями, сохраняйте оба подписанных объекта. Для правил живости воспроизводите счетчик и окно протокола. Включение доказательств может происходить после нарушения, поэтому различайте `infraction time`, `detection time` и `application time`.

### 4. Определите каждый открытый баланс

Определите, является ли база `effective balance`, заблокированной ставкой на высоте нарушения, текущей ставкой, собственной ставкой, делегированной ставкой, выделением слота валидатора или ставкой, назначенной `operator set`. Проверьте лимиты, минимумы, шаги округления, единицу измерения, предыдущие штрафы, перераспределения и остаются ли ожидающие снятия ставки подлежащими штрафу.

### 5. Воспроизведите каждый компонент штрафа

Разбейте результат на `initial penalty`, `correlation penalty`, продолжающиеся штрафы за обязанности, упущенные награды, эффекты принудительного выхода и вознаграждения за отчётность или уведомление о нарушениях. Простое фиксированное правило может использовать `slash_amount = slashable_stake * slash_fraction`; многие действующие протоколы вместо этого используют функции, зависящие от состояния. Никогда не применяйте проценты к балансу кошелька без подтверждения базы.

### 6. Сопоставьте полную временную шкалу и носителя убытков

Прослеживание нарушения, распространение доказательств, включение, учёт штрафов, период заключения или отключения, окно подачи апелляции или отмены, выход, разъединение и завершение вывода. Затем распределите убытки между оператором, делегаторами, номинаторами, держателями токенов пула и повторно ставящими в рамках протокола и сервисного контракта. Включите влияние цены токена и ликвидности отдельно от сожжённых единиц.

### 7. Проверьте элементы управления и согласуйте состояние

Проверьте ключевые вопросы хранения, эксклюзивность подписантов, прочность `slashing protection database`, защиту при сбоях, восстановление резервных копий, мониторинг часов и сети, разнообразие клиентов и процедуры при инцидентах. Пересчитайте событие по окончательному состоянию, параметрам, доказательствам и дельтам баланса; сопоставьте его с метками обозревателя, заявлениями поставщиков, бухгалтерскими проводками и любыми страховыми выплатами, не рассматривая ни один источник как окончательный.

<a id="example"></a>

## Рабочие примеры

### Конфликтующие подписи в стиле Ethereum

Предположим, что валидатор `V` подписывает заголовок блока `A` и другой заголовок `B` для `slot = 8`, с действительными подписями в рамках одного и того же применимого контекста форка. Эта пара удовлетворяет схеме proposer-equivocation Ethereum; пропущенное предложение на слоте 9 не удовлетворяет. Для аттестаций пусть будут `A = (source = 120, target = 125)` и `B = (source = 118, target = 127)`. Поскольку `B` охватывает `A`, пара имеет схему surround-vote. Одних только меток недостаточно: фактически подписанные данные, домены, индекс валидатора и проверки периода, подлежащего штрафу, должны соответствовать актуальной спецификации.

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

### Расчет потерь доли пропорционально

Рассмотрим иллюстративный протокол с токенами `slashable_stake = 12,500` и фиксированным `slash_fraction = 0.015`. Потери протокола составляют:

`12,500 * 0.015 = 187.5 tokens`.

Если правило взимает плату со всей резервной ставки пропорционально, токены `2,500` собственной ставки оператора теряют `37.5`, тогда как делегированные токены `10,000` теряют `150`. Если сервисный контракт возмещает делегаторам, но не оператору, этот платеж является отдельной дебиторской задолженностью и кредитным риском. Это не изменяет списание на блокчейне, и это распределение не должно передаваться в протокол, который защищает делегаторов или использует другую базу ставки.

### Окно контроля доступности в стиле Cosmos

Предположим, что цепочка на основе Cosmos SDK запросила параметры `window = 1,000` и `min_signed = 0.95`. Ее максимально допустимое количество пропусков:

`max_missed = 1,000 - (0.95 * 1,000) = 50`.

Если действующее правило срабатывает при `missed > max_missed`, ровно `50` пропусков не превышают порог, а `51` пропуск превышает. Доля слэшинга, срок блокировки, сброс счетчика и возможность разблокировки определяются действующими параметрами цепочки и версией модуля. Это пример настроенной цепочки, а не универсальное правило Proof of Stake и не описание обработки простоя в Ethereum.

### Формула коррелированного правонарушения

Проверенная документация Polkadot задает долю слэшинга за эквивокацию как `min((3 * x / n)^2, 1)`, где `x` — число нарушителей, а `n` — число активных валидаторов. При `x = 5` и `n = 100`:

`min((3 * 5 / 100)^2, 1) = 0.0225 = 2.25%`.

Применительно к `40,000` единицам ставки в слоте валидатора, это составляет `900` единиц. С `x = 20` та же формула дает `36%`, а не в четыре раза `2.25%`. Это демонстрирует риск корреляции; это не разрешает использовать эту формулу для Ethereum, цепочки Cosmos, парачейна или другой среды выполнения Polkadot без проверки текущих правил.

<a id="risks"></a>

## Риски и ошибки при проверке

- **Неправильный набор правил:** другая цепочка, форк, среда выполнения, тестовая сеть или развертывание контракта могут иметь разные нарушения и наказания.
- **Смешение нарушения и наказания:** Пропущенные вознаграждения, штрафы за бездействие, блокировка, отключение, исключение и слэшинг не являются взаимозаменяемыми терминами.
- **Устаревшие параметры:** Управление и обновления могут изменять окна, дроби, лимиты, задержки и защищённые балансы.
- **Путаница в домене:** Подписи из разных веток или доменных контекстов могут не образовывать доказательства для наказания.
- **Недействительные доказательства:** Неправильные, дублированные, просроченные, неправильно индексированные или неаутентифицированные доказательства могут быть отклонены.
- **Отсроченное обнаружение:** Доказательства могут поступать после переназначения или инициирования выхода, поэтому состояния нарушения и применения различаются.
- **Неправильный снимок ставки:** Текущий баланс может не соответствовать балансу, голосующей силе или эффективной ставке, используемой правилом.
- **Усиление корреляции:** общий клиент, облако, подписант или процедура могут превратить одну ошибку в зависящее от состояния массовое наказание.
- **Дублированные ключи:** Скопированные хранилища ключей и одновременно запущенные резервные узлы могут создавать конфликтующие подписи.
- **Сбой удалённого подписанта:** Повторные попытки , устаревшие блокировки, неконсистентные базы данных или двусмысленные подтверждения могут вызывать двойную подпись.
- **Резервное переключение при разделении сети:** два сайта могут оба считать себя основными, если переключение на резервный не защищено криптографически.
- **Потеря базы данных защиты:** Восстановление ключей без полной истории подписей может сделать, казалось бы, надежного валидатора небезопасным.
- **Концентрация оператора:** многие валидаторы под одной управляющей плоскостью имеют общие операционные и корреляционные риски.
- **Преемственность делегации:** Делегаторы или номинаторы могут нести убытки, вызванные оператором, которым они не могут напрямую управлять.
- **Перекрытие рестейкинга:** Один актив может обеспечивать несколько обязательств с разными полномочиями на слэшинг и правилами распределения.
- **Воздействие при отмене:** процесс разъединения или очередное снятие может оставаться подверженным штрафам за более ранние или вновь приписываемые преступления.
- **Неопределённость управления:** Апелляции , сроки отмены, улучшения или социальное восстановление могут изменить сроки, но не являются гарантированными средствами защиты.
- **Бухгалтерский учёт и округление:** Эффективные приросты баланса , конверсии акций, ограничения и десятичные дроби токенов могут нейтрализовать умножение баланса кошелька.
- **Пробелы в наблюдаемости:** Метки исследователя могут не включать пару доказательств, снимок параметров, затронутые делегации или последующие штрафы.
- **Риск контракта и контрагента:** Обещания о пуле, хранении, страховании и возмещении могут не сбыться независимо от правильности консенсуса.

<a id="misconceptions"></a>

## Распространённые заблуждения

### Каждый ли офлайн-валидатор подвергается слэшингу?

Нет. Ethereum применяет штрафы за пропущенные обязанности и бездействие, но не классифицирует обычные периоды простоя как наказуемое нарушение. Цепочки Cosmos SDK могут настраивать штрафы за простои. Другие протоколы могут отключать, помещать в режим блокировки, уменьшать вознаграждения или ничего не делать. Уточняйте конкретное правило, а не обобщайте по одной сети.

### Требует ли слэшинг доказательства злого умысла?

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

### Равен ли максимальный убыток заявленному проценту слэшинга?

Не обязательно. Процент может относиться к эффективной, закрепленной, выделенной, делегированной или исторической ставке; корреляция и продолжающиеся штрафы могут увеличить убытки; принудительный выход лишает будущих вознаграждений; а цена токена или скидки на ликвидный стекинг могут изменить экономическую стоимость. Напротив, лимит или защищенный баланс могут снизить базу начисления.

### Прекращает ли начало выхода подверженность слэшингу немедленно?

Нет универсального правила, говорящего об этом. Доказательства могут задерживаться, процесс разъединения частично существует для сохранения подотчетности, а некоторые выводы повторного стейкинга остаются подверженными штрафам во время очереди. Проверяйте последнее время, когда возможен штраф для каждого обязательства, а не только транзакцию, которая запросила выход.

### Удаляют ли делегирование, страхование или социальное восстановление риск штрафов?

Нет. Они перераспределяют или обещают возместить убыток в соответствии с дополнительными правилами. Покрытие может исключать коррелированные ошибки, истекать, ограничивать претензии, зависеть от управления или создавать риск контрагента. Срез протокола остается отдельным событием, которое должно быть урегулировано независимо.

<a id="related"></a>

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

- [Доказательство доли](/ru/crypto/proof-of-stake/)
- [Валидатор](/ru/crypto/validator/)
- [Стейкинг](/ru/crypto/staking/)
- [Повторная ставка](/ru/crypto/restaking/)
- [Очередь выхода и вывода валидатора](/ru/crypto/validator-exit-withdrawal-queue/)

<a id="sources"></a>

## Источники

- [Вознаграждения и штрафы за Proof-of-Stake](https://ethereum.org/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/) - Ethereum.org (доступ: 2026-08-19)
- [Спецификации консенсуса Ethereum: Честный валидатор](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/validator.md) - Ethereum Foundation (доступ: 2026-08-19)
- [Спецификации консенсуса Ethereum: Цепочка маяков](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (доступ: 2026-08-19)
- [Cosmos SDK модуль x/slashing](https://docs.cosmos.network/sdk/v0.53/build/modules/slashing/README) - Cosmos SDK (доступ: 2026-08-19)
- [Cosmos SDK модуль x/evidence](https://docs.cosmos.network/sdk/latest/modules/evidence/README) - Cosmos SDK (доступ: 2026-08-19)
- [Правонарушения и слэши](https://docs.polkadot.com/infrastructure/staking-mechanics/offenses-and-slashes/) - Polkadot Developer Docs (доступ: 2026-08-19)
- [Casper Дружелюбный гаджет завершения](https://arxiv.org/abs/1710.09437) - Бутерин и Гриффит (доступ: 2026-08-19)
- [EigenLayer DelegationManager](https://github.com/Layr-Labs/eigenlayer-contracts/blob/main/docs/core/DelegationManager.md) - Eigen Labs (доступ: 2026-08-19)

Source: https://wiki.fcontext.com/ru/crypto/slashing/index.mdx
