Interchain Security в Cosmos: сети-поставщики, потребители, награды и слешинг

Interchain Security (ICS) соединяет отдельные сети Cosmos через протокол Inter-Blockchain Communication (IBC). Сеть-поставщик управляет набором валидаторов, а сеть-потребитель использует допущенных валидаторов поставщика для создания и подтверждения собственных блоков. При этом у сетей остаются отдельные машины состояний, реестры, комиссии, токены, управление и правила приложений.

«Общая безопасность» не означает, что монеты делегатора переехали в сеть-потребитель. Делегированный ATOM остаётся в стейкинге у поставщика и подчиняется его правилам. Потребитель получает участие валидаторов, обеспеченное стейком поставщика, и может отправлять ему доказательства отдельных нарушений. Поэтому баланс кошелька, токен потребителя и заблокированный у поставщика стейк — разные вещи.

ICS — это не просто мост для токенов IBC. IBC обеспечивает аутентифицированную связь между сетями, а ICS использует отдельное приложение межсетевой валидации для передачи обновлений состава валидаторов и доказательств нарушений. Перевод токена может идти через ICS-20 и при этом не использовать общий набор валидаторов. И наоборот: общий набор валидаторов не делает безопасными все приложения и токены потребителя.

Обзор Interchain Security · Терминология Interchain Security

Потребитель не обязан копировать весь набор валидаторов поставщика. Partial Set Security (PSS) позволяет выбрать подмножество. Настройка Top N выбирает валидаторов по заданной доле голосующей силы поставщика. При opt-in допущенные валидаторы сами решают, подключаться ли к конкретному потребителю. Применяемый вариант нужно проверять по текущей конфигурации сети.

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

Для Top N обычно требуется одобрение управления поставщика: некоторых валидаторов могут обязать участвовать. Сети opt-in можно запускать без такого требования. Не стоит определять порядок запуска только по словам «сеть Cosmos». Проверьте chain ID и consumer ID, статус запуска, настройку Top N или opt-in, параметры power shaping и текущий процесс управления у поставщика: документация и функции меняются.

Partial Set Security · Power shaping · Permissionless ICS

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

Правило участия определяет, кому нужно запускать узел потребителя. В Top N обязанность может зависеть от голосующей силы поставщика и установленного порога; opt-in обычно оставляет решение за валидатором. Ограничения силы или списки могут изменить итоговый набор. Валидаторам следует проверять допуск, назначение ключа, хеш бинарного файла, время запуска и требования к мониторингу для каждого потребителя.

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

Руководство валидатора и запуск сети · Назначение ключей

Когда стейк или право участия у поставщика меняются, набор валидаторов потребителя может потребовать обновления. ICS передаёт такие изменения через канал Cross-Chain Validation (CCV). Релayer доставляет сообщения между сетями, а каждая сеть проверяет состояние по правилам протокола и применяет изменения самостоятельно. Релayer не становится валидатором потребителя и не определяет, какие подписи действительны.

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

Перед изменением делегации или выводом средств изучите актуальные документы поставщика и потребителя и проверьте незавершённые записи unbonding. Отделяйте обычный срок стейкинга от дополнительной координации ICS. Задержка relayer или устаревший client тоже могут замедлить обработку пакета, не меняя основное правило.

Обзор CCV в спецификации IBC · Руководство валидатора

Потребитель может отправить поставщику доказательство нарушения валидатора. В документации ICS различаются downtime и equivocation, например двойная подпись. Правила сети, версия протокола и параметры нарушения потребителя определяют, как обработают доказательство: возможны jail, сокращение стейка или обе меры.

Единой ставки наказания для всех сетей нет. Текущие официальные документы также расходятся в описании последствий downtime: руководство валидатора говорит о jail у поставщика без slash для Hub, а страница о slashing описывает jail и сокращение стейка согласно параметрам потребителя. Поэтому не выводите финансовые последствия только из метки «ICS»; проверьте реализацию, конфигурацию и процедуру работы с доказательствами именно этой сети. Достоверное доказательство двойной подписи может привести к slash, jail и tombstone у поставщика.

Если поставщик сокращает стейк, экономические последствия могут затронуть валидатора и делегаторов по правилам стейкинга поставщика. Jail может удалить валидатора из активного набора поставщика, а значит — и из наборов потребителей. Не следует считать, что нарушение в сети-потребителе уменьшит только награды в её собственном токене.

Слешинг по инициативе потребителя · Руководство валидатора Interchain Security

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

Простой гипотетический пример: за период потребитель учёл 12 000 единиц подходящих комиссий и инфляционных наград, а управление установило долю поставщика в 25%. Расчёт даёт 3 000 единиц, направляемых в сторону пула наград поставщика. Это не определяет долларовую стоимость, итоговую выплату валидатору, срок распределения или будущую доходность. При ограничении голосующей силы вес распределения может учитывать скорректированную силу в потребителе, а не исходную силу у поставщика.

Токен награды может быть волатильным, неликвидным или дорогим для получения. Отображаемый APY может объединять меняющиеся предположения об активности потребителя, доле наград, допущенных валидаторах, комиссии, распределении у поставщика, разрешённых denom и длительности opt-in. Рассматривайте награды потребителя как переменный поток протокола, а не гарантированный APY или компенсацию риска slash.

Правила распределения наград · Награды валидатора сети-потребителя

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

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

Фраза «защищена Cosmos Hub» — отправная точка для проверки, а не полная оценка риска. Выясните, кто поставщик, какие валидаторы участвуют, как сформирована их голосующая сила, какие доказательства приводят к slash, какие награды переводятся и как устроен выход или переход. Безопасность зависит от конкретной конфигурации и периода работы.

Терминология и варианты Interchain Security · Управление сетью-потребителем

Начните с точных chain ID, consumer ID и поставщика. Уточните, используется ли Top N или opt-in, меняют ли power cap или списки набор валидаторов и отражает ли опубликованный список последнее обновление. Само число валидаторов не показывает распределение голосующей силы.

Если вы валидатор или делегатор, выясните, должен ли валидатор включить opt-in, какой consensus key назначен потребителю, какая версия binary запущена и как обрабатываются downtime и двойная подпись. Проверьте действующие параметры jail и slash. При делегировании отличайте стейк, заблокированный у поставщика, от наград потребителя, показанных в кошельке.

Наконец, проверьте список принимаемых reward denom, число эпох для допуска, правила распределения и комиссии, полномочия управления потребителем, состояние relayer и client, а также текущую процедуру undelegation или changeover. Не смешивайте это со стейкингом только у поставщика или с переводом токенов: это разные операции.

[Делегирование и слешинг в Cosmos Hub](/learn/cosmos-staking-delegation-unbonding-slashing-validator-commission-explained) · [IBC-переводы и риски relayer](/learn/cosmos-ibc-transfer-clients-channels-packet-timeouts-relayer-risks-explained) · Криптостейкинг и кредитование DeFi

Первичные источники: Обзор Interchain Security; терминология; Partial Set Security; Power shaping; распределение наград; slashing по инициативе потребителя; руководство валидатора; спецификация CCV IBC.