Cosmos IBC timeout: почему возврат пока не виден

Надпись timeout у IBC-перевода не доказывает, что возврат уже обработан исходной цепочкой. Для стандартного процесса ICS20 найдите пакет и выясните, исполнен ли таймаут либо подтверждение ошибки на стороне отправки. Истёкший таймер приложения, получение в целевой сети и возвращённый баланс — разные наблюдения. Разберите первоначальный пакет до новой отправки.

Найдите пакет за записью кошелька

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

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

В спецификации ICS20 разделены отправка, получение, acknowledgement и timeout. Обработка возврата относится к приложению, а не просто к окончанию обратного отсчёта. Читайте подпись интерфейса рядом с действительными записями протокола. Если они не совпали, сохраните обе версии и время наблюдения вместо выбора удобного объяснения.

Определите последний подтверждённый этап

Отсутствующий acknowledgement не обязательно означает отсутствие платежа на цели. Пакет мог быть принят, а обратная передача оставаться неразобранной. Исходный успех, наоборот, не подтверждает целевое получение. В описании жизненного цикла пакета рассматриваются relayer и доказательства состояния между цепочками. Каждая сторона узнаёт нужный результат через проверяемое сообщение.

Таймаут должен стать обработанным действием

Источник не узнаёт о пропущенном сроке лишь потому, что изменились часы ноутбука. Требуются соответствующее доказательство и исходная транзакция обработки. Поэтому задержка relayer или состояние цепочки и клиента имеют значение и после надписи timeout. Уточните отсутствующую запись вместо предположения, что кошелёк уже обратил токеновое движение. Пользовательский таймер не заменяет подтверждение протокола.

В реализации ibc-go есть возврат при таймауте и при acknowledgement с ошибкой. Успешное подтверждение — другой случай. Это эталонная реализация, а не обещание полного совпадения каждого ответвления, middleware и развёрнутой сети. При несоответствии простой модели изучайте состояние конкретного приложения. Не переносите детали новой версии IBC на классический маршрут автоматически.

Фактическое получение пакета и произвольное заявление о его неполучении нельзя считать одним и тем же доказательством. Важны идентичность пакета и проверка протокола. Пользователю полезнее сохранить ссылки и попросить настоящую поддержку различить reception, acknowledgement и timeout. Одного слова «ошибка» на экране недостаточно для требования возврата за недоставку. Внутренняя подпись может описывать иной этап.

После обработки найдите исходный актив

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

Отделяйте количество токена от сетевых расходов. В учебном случае с одним активом было 20 единиц, отправили 5 и отдельно потратили 0,02 комиссии. Осталось 14,98. Возврат именно пяти единиц дал бы 19,98 без учёта других действий. Это не реальная комиссия сети и не обещание компенсации всех расходов. Сравнение лишь объясняет разницу между полным начальным остатком и возвращённой суммой.

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

Обратитесь к участнику нужного этапа

В справке Keplr об IBC рассматриваются задержки сети и relayer, обращение к команде цепочки. Короткая обычная оценка там не универсальный срок каждого маршрута. Используйте фактический статус и пакет. Не передавайте seed человеку, который обещает перезапустить relayer. Работа сетевого оператора не требует секретных слов пользователя.

Представим пакет «Ясень»: отправка успешна, кошелёк пишет timeout, но обработанного исходного таймаута ещё не видно. Нужно выяснять ожидающее действие источника. У пакета «Берёза» целевое получение успешно, а подтверждение остаётся открытым. Это другое состояние, не основание объявлять тот же возврат за недоставку. Оба примера вымышленные и нужны для выбора проверки.

1. Сохраните хеш, цепочки, адреса, сумму и точный исходный актив.
2. Найдите пакет, а для классического маршрута — канал и sequence.
3. Разделите получение, acknowledgement и timeout.
4. Найдите реальную обработку таймаута либо ошибки на источнике.
5. После возврата сопоставьте аккаунт, обозначение токена, расходы и последующие движения.
6. Передайте поддержке последний установленный этап и ссылки до новой отправки.

Читать записи поможет руководство Mintscan, учитывать расходы — разбор комиссий Cosmos. У обмена без регистрации собственные реквизиты сети и актива: его маршрут не следует автоматически из IBC-функции кошелька. Разберите существующий пакет и учёт возврата до нового заказа или перевода.