Слэшинг — это "наказание" для валидатора, которое заключается в конфискации части его токенов. То, какой процент токенов будет "слэширован", зависит от допущенного валидатором нарушения и угрозы безопасности других участников сети. Это не только финансовый стимул для валидатора добросовестно выполнять свои обязанности, но и мера, заставляющая валидаторов «рисковать собственной шкурой». Одновременно с этим, это то, что мотивирует делегаторов тщательнее выбирать валидаторов, т.к. для них тоже существует риск потери части своих токенов.
Существует два типа событий, которые приводят к слешингу:
Кроме того, валидатор выпадает из консенсуса и не получает награды за блок как минимум на 10 минут (термин jail). После устранения проблем валидатор может повторно присоединиться к набору валидаторов, отправив unjail-транзакцию.
IBC
Протокол взаимодействия между блокчейнами (Inter-Blockchain Communication Protocol) или же IBC – это фреймворк, который позволяет зонам осуществлять кросс-чейн взаимодействие без установления доверительных допущений от третьей стороны (т.е. без использования мостов, например), его можно сравнить с TCP/IP протоколом в традиционных сетевых технологиях. Взаимодействующие сети договариваются доверять модели безопасности друг друга и использовать расшаренный стандарт обмена сообщениями для взаимодействия и верификации изменений состояния сети. Таким образом IBC модель наследует самую низкую из безопасностей сетей, участвующих в обмене сообщениями (*имеется ввиду, что, если, допустим, безопасность одной сети на 10/10, а второй на 8/10, то безопасность IBC модели будет тоже на 8/10).
Установление такого взаимодействия является ресурсоемким для обеих сетей. Когда одна сеть инициирует отправку сообщения в другую сеть, открытый ретранслятор (permissionless relayer, далее возможен вариант перевода "релэер", что одно и тоже) передает доказательство запроса сообщения в другую сеть. Сеть, принимающая сообщение, валидирует данное доказательство, использую для этого легкий клиент (light client), который считывает состояние отправляющей сети и записывает копию этого состояния в свой собственный реестр. Данный прямой процесс верификации гарантирует принимающей сети, что запрос действительно был достоверным, и только потом изменяется состояние самой принимающей сети.
Из-за оптимизации в сторону безопасности, IBC модель имеет несколько важных особенностей (необходимых компромиссов):
Принимающая сеть вынуждена предполагать, что транзакционный запрос был финализирован (finalized) в сети, отправляющей сообщение (запрос). Форки и реорганизация блоков, которые являются привычным делом для пробабилистической финализации (probabilistic finality, например, сеть эфира), разрушили бы основы модели безопасности IBC. Поэтому IBC совместима только с механизмами консенсуса, обладающими гарантией финальности, такими, как Tendermint. В качестве решения для установления порога финальности при взаимодействии с пробабилистической сетью могут использоваться так называемые «зоны привязки (pegzones)». Но такое решение усложняет систему и таким образом создает дополнительные векторы для атаки на нее.
IBC модель слишком дорого обходится блокчейнам с низкой пропускной способностью и дорогими блоками. Но в экосистеме Cosmos такой проблемы нет, поскольку IBC изначально разрабатывали для работы с блокчейнами, построенными при помощи Cosmos SDK, где IBC модули работают на сетевом уровне, а не на уровне смарт контрактов. К тому же это позволяет сетям внутри экосистемы Cosmos перенаправлять издержки и ответственность за запись состояния других экосистемных сетей от приложений к валидаторам сети.
Транзакционные издержки за передачу сообщений между сетями несут ретрансляторы, а не пользователи. Ретрансляторы часто управляются валидаторами, которые мотивированы поддерживать работу обеих (отправляющей и принимающей) сетей. Экономическая модель IBC делает рациональным координацию между различными ретрансляторами для того, чтобы в одно и тоже время только один ретранслятор обслуживал один IBC канал. Если возникает ситуация, когда ни один из ретрансляторов не обслуживает канал, то сообщение «застрянет» до тех пор, пока не появится обслуживающий ретранслятор. Хотя данный факт никак не влияет на безопасность ни принимающей, ни отправляющей сети, жизнеспособность IBC может быть временно снижена по этой причине. Для того, чтобы IBC обмен сообщениями полностью встал, нужно чтобы треть всех валидаторов перестала работать.
Схема работы IBC приведена на рисунке ниже (источник тут)
По сути, транзакции IBC – это пакеты информации, которые передаются из одной зоны в другую путем публикации Merkle-proofs (подробнее тут) в качестве доказательства того, что информация была отправлена и получена.
Чтобы принимающая сеть могла проверить это доказательство, она должна быть в состоянии следить за заголовками блоков отправителя. Этот механизм аналогичен механизму, используемому сайдчейнами (подробнее тут), который требует, чтобы две взаимодействующие сети знали друг о друге через двунаправленный поток транзакций, подтверждающих существование.
Протокол IBC использует два типа транзакций: IBCBlockCommitTx , которые взаимодействуют с хешем самого последнего блока любой зоны, и IBCPacketTx, которые содержат данные о легитимности пакета информации и приложении отправителя.