Внедрение слэшинга в Solana

Введение

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

Это отличительная особенность сетей Proof of Stake (PoS), таких как Solana. В Proof of Work (PoW) у нее нет аналога, поскольку она зависит от способности протокола напрямую применять финансовые санкции путем уничтожения застейканных активов. В PoW подобного механизма нет: блокчейн не может конфисковать или уничтожить физическое оборудование недобросовестных майнеров.

Слэшинг дает несколько важных преимуществ:

• Он напрямую снижает экономическую привлекательность злонамеренной деятельности
• Он стимулирует стейкеров распределять стейк между надежными валидаторами, улучшая децентрализацию
• Он стимулирует крупных операторов создавать разнородную инфраструктуру, которая снижает риск общих сбоев (например, распределять стейк между клиентами Firedancer и Agave).
• Он дает валидаторам еще один показатель, с помощью которого они могут выделиться и укрепить репутацию, избегая нарушений, ведущих к слэшингу, и выявляя злонамеренную активность других участников.

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

До сих пор ни один валидатор Solana не подвергался слэшингу. Ближе всего Solana подошла к подобному событию в мае 2020 года, через два месяца после запуска основной сети. Тогда Solana Foundation добровольно сожгла 11,36 млн SOL из собственного распределения в ответ на обеспокоенность сообщества нераскрытыми займами токенов для маркетмейкеров. Это сократило общее предложение токенов на 2,3% — с 500 млн до 488,64 млн SOL. Хотя формально это не было слэшингом, сжигание стало добровольным наказанием, направленным на восстановление доверия и решение проблем с прозрачностью, поднятых ранним сообществом.

Уже несколько лет звучат призывы внедрить в Solana более формальный механизм слэшинга, часто называемый программным слэшингом и применяемый непосредственно в блокчейне через встроенную программу. В этой системе, если валидатор нарушает конкретные правила протокола, можно сформировать криптографическое доказательство нарушения и отправить его в специальную программу, которая автоматически запускает слэшинг. Эта модель снижает зависимость от координации между людьми и позволяет применять санкции за незначительные нарушения без остановки сети. Так создается основа для масштабируемой и децентрализованной подотчетности.

Предстоящая активация функционального шлюза SIMD-0204: Проверка событий, влекущих слэшинг станет первым крупным и значимым шагом Solana к внедрению формального программного слэшинга в основной сети. Как мы рассмотрим далее в этом отчете, события программного слэшинга в блокчейн-сетях, к счастью, редки, а штрафы обычно невелики. Однако даже сама возможность автоматического уничтожения стейка валидатора протоколом создает новые риски, которые все заинтересованные стороны должны тщательно оценить. Остается много открытых вопросов об оптимальном подходе Solana к применению программного слэшинга. Как и любые экономические изменения, параметры и штрафы слэшинга потребуют широкого обсуждения в сообществе и в конечном итоге должны быть одобрены формальным голосованием по вопросам управления.

SIMD, связанные со слэшингом

Несколько SIMD относятся к развертыванию программного слэшинга в Solana. Первые два, SIMD-180 и SIMD-204, планируется запустить в основной сети в ближайшие месяцы.

Первое необходимое условие — SIMD-0180: Использование адреса аккаунта голосования в качестве ключа расписания лидеров. Этот SIMD заменяет ключ в расписании лидеров: вместо идентификационного адреса валидатора используется адрес его аккаунта голосования. Изменение необходимо для точного определения ответственного при слэшинге, поскольку создает прямую и однозначную связь между обязанностями валидатора по созданию блоков и делегированным ему стейком.

В SIMD-0204: Проверка событий, влекущих слэшинг описана новая Slashing Program. Она вводит ончейн-механизм, который позволяет любому участнику отправлять и регистрировать доказательства поведения, влекущего слэшинг. В результате создается проверяемая и неизменяемая запись о нарушениях валидаторов.

Наконец, SIMD-0212: Слэшинг описывает реализацию слэшинга в протоколе Solana. Он опирается на основу, заложенную SIMD-0204, и предусматривает применение штрафов за подтвержденные нарушения. Предложение остается открытым и активно обсуждается.

Выявление нарушений и определение ответственных

Slashing Program спроектирована как исключительно наблюдательный уровень. Она не изменяет стейки или вознаграждения; ее единственная функция — проверять и регистрировать нарушения. Ранний прототип уже работает в Testnet. Примеры отправленных данных, в том числе транзакции DuplicateBlockProof, показывают, как можно регистрировать нарушения.

Создание дублирующих блоков

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

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

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

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

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

struct DuplicateBlockProofData {
  shred1_length: u32      // Unaligned four-byte little-endian unsigned integer,
  shred1: &[u8]           // `shred1_length` bytes representing a shred,
  shred2_length: u32      // Unaligned four-byte little-endian unsigned integer,
  shred2: &[u8]           // `shred2_length` bytes representing a shred,
}

Отправитель формирует доказательство, сохраняет его в ончейн-аккаунте буфера, а затем отправляет транзакцию в Slashing Program по адресу `S1ashing11111111111111111111111111111111111` со ссылкой на свой аккаунт буфера. После успешной проверки доказательства результаты сохраняются по Program Derived Address (PDA) `report_account`, принадлежащему Slashing Program, для дальнейшего использования. Это упрощает создание панелей мониторинга с данными о слэшинге: достаточно выполнить вызов getProgramAccounts для Slashing Program. Валидаторы могут использовать их, чтобы проверить, поступали ли сообщения об их нарушениях, и при необходимости принять меры.

Ожидается, что Anza выпустит инструменты для наблюдения за этими событиями, создания доказательств и отправки доказательств в блокчейн. Вероятно, появится несколько реализаций, включая версию, встроенную в ПО валидатора. Достаточно, чтобы один добросовестный участник сообщил о нарушении в течение эпохи, поскольку каждую уникальную комбинацию нарушителя и слота можно зарегистрировать только один раз. Программа проверяет, существует ли уже сообщение о том же слоте и нарушителе. Если совпадение найдено, новая отправка отклоняется. Сообщения можно отправлять в течение одной эпохи после нарушения с учетом слота, в котором оно произошло, то есть не позднее чем через 432 000 слотов согласно sysvar `Clock`.

Вознаграждения информаторам

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

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

Ethereum предлагает небольшое вознаграждение информатору: 1/512 эффективного баланса валидатора, подвергнутого слэшингу. Для валидатора с полными 32 ETH оно составляет 0,0625 ETH. Вознаграждение выпускается в виде новых ETH, но компенсируется большей суммой, сожженной из стейка нарушившего правила валидатора. Низкий размер выбран намеренно: он должен поощрять добросовестность и честное участие, а не оппортунистическое поведение ради прибыли.

Нарушения при голосовании

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

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

Бот Votalizer, разработанный сооснователем Solana Michael Vines, сейчас работает в Solana Tech Discord и отслеживает нарушения блокировки по всей сети. На практике валидаторы редко совершают такие нарушения непреднамеренно, поскольку обычно для этого требуется сознательно изменить клиент валидатора. Встроенные защитные механизмы обеспечивают получение клиентом последнего ончейн-голоса и предотвращают действия, которые привели бы к нарушению блокировки.

Хотя нарушения блокировки прямо упоминаются в SIMD о слэшинге и ранней документации как пример нарушения при голосовании, которое может обрабатывать Slashing Program, запланированное обновление консенсуса Alpenglow удалит Tower BFT и саму концепцию блокировок. Поэтому ожидается, что нарушения при голосовании будут внедрены только после запуска Alpenglow.

Новые нарушения при голосовании в Alpenglow, для выявления которых может быть спроектирована Slashing Program, могут включать отправку конфликтующих голосов за один слот — например, одновременную отправку `NotarVote` и `SkipVote`.

Будущие типы нарушений

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

В сопоставимых блокчейн-сетях типы поведения, ведущие к слэшингу, зависят от протокола. Распространенные примеры:

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

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

Применение штрафов

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

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

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

Сейчас в качестве такого порога рассматривается линия коэффициента Накамото (NC), установленная на уровне стейка самого небольшого валидатора в сверхменьшинстве, то есть примерно 1% стейка. 

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

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

v = аккаунт голосования, подлежащий слэшингу

TSS = совокупный стейк, подлежащий слэшингу

TS = совокупный стейк

Линия NC = линия коэффициента Накамото

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

• 1,2%, если в нарушении участвует 4,66% стейка (то есть (3 * (0,0466 - 0,01) / 1)²)
• 7,3%, если в нарушении участвует 10% стейка (то есть (3 * (0,1 - 0,01) / 1)²)

На графике ниже показана предлагаемая кривая и два альтернативных варианта: агрессивный и линейный.

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

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

Альтернативы традиционному слэшингу

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

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

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

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

Важные аспекты

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

Периоды ожидания

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

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

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

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

Решением может стать дополнительный период ожидания, когда стейк все еще подлежит слэшингу, но больше не учитывается в весе стейка протокола. Стейкеры деактивируют стейк в эпохе N, но смогут вывести его только в начале эпохи N+3. Это повысит безопасность, однако такая задержка ухудшит пользовательский опыт, заставляя стейкеров ждать еще ~2–4 дня до полного вывода стейка. Один из вариантов решения — сократить эпохи, чтобы реальная продолжительность вывода из стейкинга оставалась близкой к текущему стандарту. Однако любое сокращение продолжительности эпох может иметь непредвиденные последствия для протокола и требует тщательной оценки.

Риски, страхование и операционная нагрузка

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

В число потенциально затронутых сторон входят:

• Протоколы ликвидного стейкинга
• Пулы стейкинга
• Кастодиальные поставщики стейкинга
• Протоколы рестейкинга
• Протоколы DeFi
• Стейкинговые ETF

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

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

Риск слэшинга также создает новые операционные обязанности по всей цепочке стейкинга. Он затрагивает:

• Операторов сервисов стейкинга, которым теперь необходимо отслеживать поведение валидаторов и заранее снижать риски
• Кастодиальные платформы и криптобиржи, которые зависят от сторонних операторов и могут быть вынуждены проверять и диверсифицировать наборы валидаторов
• Институциональных управляющих активами, которым может потребоваться страхование собственных убытков от слэшинга, вызванного действиями внешних операторов

Сравнение с сопоставимыми сетями

В этом разделе рассматривается реализация слэшинга в сопоставимых сетях Proof of Stake, таких как Ethereum и Cosmos. Эти сети уже много лет применяют программный слэшинг и предоставляют ценные практические данные о частоте таких событий и их влиянии на безопасность сети и поведение валидаторов.

Ethereum

Протокол Proof of Stake в Ethereum, представленный при запуске Beacon Chain в декабре 2020 года, с первого дня использует слэшинг как основной механизм принуждения. Ethereum определяет четыре конкретных нарушения, влекущих слэшинг, и все они связаны с противоречивыми действиями:

• Предложение нескольких блоков для одного слота
• Отправка конфликтующих аттестаций для одной целевой контрольной точки
• Аттестация разных головных блоков с одинаковыми исходной и целевой контрольными точками
• Создание двух аттестаций, одна из которых «окружает» другую с точки зрения исходного и целевого голосов

Для каждого из этих нарушений применяется одинаковая структура штрафов. При слэшинге валидатор сразу теряет 1/32 эффективного баланса. Штраф ограничен 1 ETH из-за максимального эффективного баланса в 32 ETH. Затем валидатор принудительно исключается из активного набора и примерно на 36 дней помещается в очередь выхода.

В этот период валидатор неактивен и не может вывести средства. Он продолжает терять вознаграждения, которые получил бы в активном состоянии, то есть несет постоянные альтернативные издержки. Через 18 дней применяется дополнительный корреляционный штраф, размер которого растет пропорционально числу валидаторов, подвергнутых слэшингу в течение 36-дневного окна. Если таких валидаторов мало, штраф незначителен. Однако при массовом слэшинге — из-за скоординированного неправомерного поведения или общих инфраструктурных сбоев — штрафы резко возрастают и в худшем случае могут привести к потере почти всего застейканного баланса валидатора.

Несмотря на центральную роль в протоколе Ethereum, на практике слэшинг происходит крайне редко. По состоянию на май 2025 года слэшингу подверглись лишь 484 валидатора — менее 0,05% от общего набора — в рамках 131 инцидента. Часто один сбой затрагивал несколько валидаторов, а причиной обычно становились ошибки операторов или баги ПО, а не злой умысел.

Крупнейшее событие произошло в ноябре 2023 года, когда Bitcoin Suisse столкнулась со слэшингом 100 валидаторов за нарушения, связанные с неактивностью. Каждый из них потерял 1 ETH.

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

Cosmos

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

Валидатор, подписавший два разных блока на одной высоте, немедленно наказывается. Любой участник может отправить ончейн-доказательство нарушения. После проверки валидатор автоматически теряет 5% застейканных токенов и переводится в состояние tombstoned: его навсегда удаляют из активного набора валидаторов без возможности вернуться. После этого и валидатор, и его делегаторы должны дождаться завершения периода отвязки, прежде чем смогут повторно делегировать стейк. Оператор такого валидатора может перезапуститься с новым ключом, но ему придется с нуля восстанавливать репутацию и делегации.

Cosmos также обеспечивает работоспособность через автоматический слэшинг за длительный простой. Если валидатор подписал менее 5% из последних 10 000 блоков, он считается неактивным и теряет 0,01% стейка. Хотя этот штраф невелик, правило применяется строго и без исключений, чтобы валидаторы поддерживали доступность и надежно участвовали в консенсусе.

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

Хотя сети Cosmos SDK используют стандартные параметры слэшинга по умолчанию, отдельные сети могут изменять или дополнять эти правила с учетом собственных допущений о безопасности и моделей риска. Такая гибкость позволяет каждой сети настраивать систему слэшинга в зависимости от размера набора валидаторов, целей децентрализации и ожидаемой отказоустойчивости. Активность слэшинга в 57 основных сетях на базе Cosmos SDK дает более широкое представление о применении штрафов во всей экосистеме:

• 12 143 случая слэшинга за простой
• 111 случаев слэшинга за двойную подпись
• 326 других нарушений
• Всего 12 580 случаев слэшинга

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

Заключение

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

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

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

Дополнительные материалы

• Слэшинг: панацея или ящик Пандоры? — Tim Roughgarden, Accelerate Conference
• Экономические пределы консенсуса без разрешений — Eric Budish, Andrew Lewis-Pye, Tim Roughgarden 
• Подотчетная работоспособность — Andrew Lewis-Pye, Joachim Neu, Tim Roughgarden, Luca Zanolini