Що таке ISM і Warp Route? Як налаштувати модуль безпеки Hyperlane? Вихідний текст не містить сегментів, які потребують додаткового уточнення. Налаштовуючи модуль безпеки Hyperlane, важливо зрозуміти ключове питання: як налаштувати кожен ISM. ISM (Intercha

У багатоланцюжкових застосунках кросчейн-мости часто покладаються на фіксовані, незмінні моделі безпеки, що ускладнює для розробників застосування різних рівнів верифікації до високоцінних управлінських повідомлень порівняно з оновленнями даних низької цінності. Модульна архітектура Hyperlane (HYPER) дозволяє кожному повідомленню визначати власний ISM, а розгортувачі Warp Route можуть налаштовувати виділений стек безпеки для кожного маршруту активів, узгоджуючи модель безпеки з конкретним бізнес-сценарієм. Потік кросчейн-повідомлень Hyperlane описує повторюваний шлях від відправлення до доставки, слугуючи відправною точкою для розуміння того, на якому етапі процесу втручається ISM.

Hyperlane vs. LayerZero vs. Wormhole відрізняє модульний підхід Hyperlane від LayerZero та Wormhole за трьома архітектурними шляхами — Mailbox/ISM, Endpoint/DVN та Guardian/VAA. Це допомагає прояснити, де налаштовувана верифікація ISM вписується в спектр протоколів сумісності.

Що таке ISM?

Модуль міжланцюжкової безпеки (ISM) — це модуль смарт-контракту, розгорнутий на цільовому ланцюжку. Він верифікує, чи справді кросчейн-повідомлення, призначене для доставки, існує у вихідному ланцюжку. Перед тим як Mailbox викликає функцію handle контракту-одержувача, він передає повідомлення та метадані, надані ретранслятором, функції verify ISM. Якщо верифікація успішна, доставка триває; якщо верифікація не вдається або виклик відхиляється, повідомлення не обробляється.

Взаємозв'язок між ISM, Mailbox та ретранслятором можна узагальнити так: вихідний Mailbox записує повідомлення через dispatch і генерує подію. Ретранслятор відстежує цю подію, потім викликає функцію process Mailbox на цільовому ланцюжку, надсилаючи повідомлення та метадані. Потім Mailbox викликає ISM для завершення верифікації. Якщо контракт-одержувач реалізує інтерфейс ISpecifiesInterchainSecurityModule, він може вказати ISM рівня застосунку; якщо жоден не вказано або надано нульову адресу, Mailbox використовує ISM за замовчуванням.

Наведена вище таблиця ілюструє місце ISM у ланцюжку доставки кросчейн-повідомлень: ISM знаходиться між цільовим Mailbox та контрактом-одержувачем, виконуючи роль контрольної точки безпеки, яка визначає, чи може повідомлення бути остаточно виконане.

Типи ISM за замовчуванням та спеціальних ISM

Hyperlane підтримує три режими використання ISM: Configure (використання готових ISM), Compose (комбінування кількох ISM) та Customize (написання нового ISM). ISM за замовчуванням — це попередньо налаштований Multisig ISM на контракті Mailbox, який забезпечує економічну безпеку через набір валідаторів Hyperlane. Стейкінг HYPER та stHYPER пояснює механізми стейкінгу та слєшінгу, що лежать в основі набору валідаторів. Якщо застосунок не вказує спеціальний ISM, використовується цей модуль за замовчуванням.

Попередньо створені типи ISM включають Multisig ISM, Routing ISM, Aggregation ISM, Rate Limited ISM та Pausable ISM, серед інших. Multisig ISM використовує модель підпису M з N валідаторів і є вибором за замовчуванням для більшості розгортань. Routing ISM спрямовує повідомлення до різних ISM на основі домену вихідного ланцюжка, що ідеально підходить для сценаріїв, де вимоги безпеки відрізняються залежно від вихідного ланцюжка. Aggregation ISM вимагає, щоб m з n дочірніх ISM пройшли верифікацію, що дозволяє накопичувати кілька умов безпеки.

Rate Limited ISM призначений для сценаріїв Warp Route, обмежуючи загальну кількість токенів, які можна передати в цільовий ланцюжок протягом одиничного часового вікна. Контракт RateLimitedIsm приймає параметри, такі як maxCapacity, і під час фази verify перевіряє, чи не перевищує загальна передана сума ліміт вікна. Якщо перевищує, верифікація не вдається, і повідомлення не доставляється. Цей механізм можна поєднати з RateLimitedHook вихідного ланцюжка для досягнення двонаправленого контролю пропускної здатності.

Pausable ISM дозволяє власнику маршруту призупиняти верифікацію повідомлень при виявленні аномалій, повністю зупиняючи кросчейн-перекази. Aggregation ISM може вкладати Rate Limited ISM з Pausable ISM: Rate Limited ISM обмежує масштаб втрат у межах вікна атаки, тоді як Pausable ISM дозволяє власнику повністю закрити маршрут після підтвердження події, формуючи стратегію глибокого захисту.

Наведена вище таблиця порівнює логіку верифікації та типові випадки використання п'яти поширених типів ISM. Aggregation ISM може комбінувати будь-які ISM у стек безпеки — наприклад, вимагати проходження як Multisig ISM, так і Wormhole ISM, або накладати Rate Limited ISM з Pausable ISM на повідомлення високої цінності.

Рисунок 1. Типи модулів безпеки Hyperlane ISM: співвідношення між Multisig за замовчуванням, спеціальним Multisig, Aggregation, Rate Limited та Pausable.

Як працює Warp Route

Hyperlane Warp Route (HWR) — це модульний кросчейн-маршрут активів, побудований на основі Mailbox. Кожен Warp Route розгортає контракти входу/виходу на всіх ланцюжках-учасниках та координує блокування, мінтинг, спалювання та вивільнення токенів через кросчейн-повідомлення. На відміну від традиційних мостів із фіксованими моделями безпеки, розгортувачі HWR можуть вказувати ISM, який використовується для верифікації повідомлень кросчейн-переказу, що дозволяє налаштовувати безпеку кожного маршруту незалежно.

Поширені типи HWR включають: Native Token HWR (прямий кросчейн-переказ нативних газових токенів, таких як ETH), Collateral-Backed ERC20 (блокування застави ERC-20 на вихідному ланцюжку та мінтинг синтетичних токенів на цільовому ланцюжку), Synthetic ERC20 (мінтинг синтетичної версії, що представляє оригінальний токен на цільовому ланцюжку) та Warp Route 2.0 (підтримка мультиланцюжкової застави та ребалансування Rebalancer). Перед використанням Warp Route користувачі повинні розуміти його конфігурацію ISM та припущення щодо довіри.

Типовий прямий потік: користувач вносить токени у Warp Route вихідного ланцюжка. Контракт блокує заставу та викликає Mailbox.dispatch для надсилання кросчейн-повідомлення. Ретранслятор надсилає повідомлення на цільовий ланцюжок через Mailbox.process. Після верифікації ISM Warp Route цільового ланцюжка мінтить або вивільняє відповідні токени. Зворотний потік: користувач спалює синтетичні токени на цільовому ланцюжку. Після верифікації ISM вихідний ланцюжок вивільняє заблоковані токени застави.

HypERC20Collateral та HypERC20 — це поширені форми контракту Warp Route на EVM-ланцюжках. Перший блокує ERC-20 на ланцюжку застави та надсилає повідомлення, тоді як другий отримує верифіковане повідомлення на синтетичному ланцюжку та мінтить синтетичний токен із співвідношенням 1:1. Nexus Bridge — це орієнтований на користувача кросчейн-інтерфейс, але під капотом він все одно слідує шляху Warp Route та верифікації ISM.

Рисунок 2. Потік Hyperlane Warp Route: вихідний ланцюжок блокує заставу, Mailbox надсилає повідомлення, цільовий ланцюжок ISM верифікує, потім мінтить синтетичні токени; зворотний шлях включає спалювання та вивільнення.

Комбінування ISM та хунків

Хунки — це модулі логіки пост-обробки, які виконуються після виклику dispatch вихідного Mailbox. Вони доповнюють ISM на цільовому ланцюжку: хунки контролюють поведінку на стороні надсилання повідомлення, тоді як ISM контролює верифікацію на стороні отримання повідомлення. Функція dispatch Mailbox викликає функцію postDispatch хунка після запису повідомлення. Хунк може збирати кросчейн-газові збори, записувати в дерево Меркла, застосовувати обмеження швидкості, виконувати перевірку призупинення тощо.

Стандартні типи хунків включають MERKLE_TREE, INTERCHAIN_GAS_PAYMASTER, PAUSABLE та RATE_LIMITED. RateLimitedHook розгортається на вихідному ланцюжку та поєднується з RateLimitedIsm цільового ланцюжка. Під час фази dispatch він перевіряє, чи не перевищує вихідна сума на стороні відправника ліміт вікна, досягаючи двонаправленого контролю пропускної здатності. Pausable Hook дозволяє власнику призупиняти надсилання повідомлень на вихідному ланцюжку, що в поєднанні з Pausable ISM може одночасно закрити маршрути на обох кінцях.

Хунки та ISM слідують логіці "хунк вихідного ланцюжка + ISM цільового ланцюжка": хунк виконує вихідні обмеження в postDispatch, тоді як ISM виконує вхідну верифікацію в verify. Спеціальні комбінації можуть слідувати патернам OpStackHook та OpStackIsm.

При розгортанні Warp Route адреси interchainSecurityModule та хунка можна вказати в конфігурації. TypeScript SDK та CLI підтримують переліки, такі як IsmType.RATE_LIMITED, що дозволяє розгортувачам безпосередньо записувати параметри RateLimitedIsm (наприклад, maxCapacity, owner, recipient) у конфігурацію Warp Route. При вкладенні Rate Limited ISM всередину Aggregation ISM версія ретранслятора повинна бути agents-v2.2.0 або вище.

Ризики налаштування ISM та Warp Routes

При налаштуванні ISM контракт-одержувач повинен реалізувати інтерфейс InterchainSecurityModule, який включає функції verify та moduleType. verify — це основна логіка верифікації; повернення false або відхилення запобігає доставці повідомлення. moduleType інформує ретранслятор про те, який формат метаданих слід додати. Якщо ISM налаштований неправильно — наприклад, занадто мало валідаторів, низький поріг або не охоплює всі вихідні ланцюжки — безпека кросчейн-взаємодії може бути ослаблена.

При комбінуванні дочірніх модулів в Aggregation ISM необхідно чітко визначити поріг m-of-n та адреси розгортання кожного дочірнього ISM. maxCapacity Rate Limited ISM повинен бути ≥ 86 400 і кратним 86 400. Власник може регулювати швидкість поповнення за допомогою setRefillRate. Повноваження призупинення в Pausable ISM зосереджені у власника; неналежне управління ключем власника може призвести до шкідливого закриття маршруту або несвоєчасного реагування на події.

При налаштуванні Warp Routes слід зазначити, що конфігурація ISM кожного маршруту незалежна. Користувачі повинні перевіряти адреси контрактів та типи ISM в ончейні перед використанням. Відображення токенів на ланцюжках застави та синтетичних ланцюжках має залишатися 1:1. Якщо Rebalancer є керованим сервісом, існує операційна залежність. Фейкові контракти Warp Route можуть призвести до втрати активів; користувачі повинні верифікувати через Explorer та відомі адреси розгортання.

Безпека Multisig ISM за замовчуванням підкріплюється стейкерами HYPER та набором валідаторів. Для спеціальних ISM розробники повинні самостійно оцінювати якість валідаторів, пороги підписів та покриття слєшінгу.

Підсумок

ISM — це модуль безпеки Hyperlane, який верифікує кросчейн-повідомлення на цільовому ланцюжку. Warp Route — це модульний маршрут активів на основі Mailbox. Multisig ISM за замовчуванням забезпечує економічну безпеку через набір валідаторів Hyperlane. Розробники можуть використовувати Configure, Compose або Customize для розгортання ISM, таких як Multisig, Routing, Aggregation, Rate Limited та Pausable, і поєднувати їх із хунками вихідного ланцюжка для двонаправленого обмеження швидкості та контролю призупинення. Розгортувачі Warp Route вказують незалежний ISM для кожного маршруту; користувачі повинні розуміти конфігурацію безпеки маршруту та припущення щодо довіри перед його використанням.

Поширені запитання

Яка різниця між ISM та ISM за замовчуванням?

ISM — це загальний термін для модулів верифікації кросчейн-повідомлень. ISM за замовчуванням — це попередньо налаштований Multisig ISM на контракті Mailbox, який використовується автоматично, коли застосунок не вказує спеціальний ISM. Застосунок може замінити конфігурацію за замовчуванням, вказавши незалежний ISM через інтерфейс ISpecifiesInterchainSecurityModule.

Як Rate Limited ISM обмежує суми кросчейн-переказів?

Rate Limited ISM під час фази verify на цільовому ланцюжку перевіряє, чи не перевищує загальна кількість вхідних токенів протягом одиничного часового вікна ліміт maxCapacity. Якщо перевищує, верифікація не вдається, і повідомлення не доставляється. RateLimitedHook вихідного ланцюжка може застосовувати те саме обмеження до вихідних сум під час фази dispatch, що дозволяє двонаправлений контроль. maxCapacity повинен бути ≥ 86 400 і кратним 86 400.

Як Aggregation ISM поєднує кілька модулів безпеки?

Aggregation ISM вимагає, щоб m з його n налаштованих дочірніх ISM пройшли верифікацію для доставки повідомлення. Наприклад, він може вимагати проходження як Multisig ISM, так і Rate Limited ISM, або вкладати Pausable ISM з Rate Limited ISM для досягнення обмеження швидкості плюс аварійного призупинення. Дочірніми ISM можуть бути будь-які розгорнуті адреси контрактів ISM.

Який зв'язок між Warp Route та Nexus Bridge?

Warp Route (HWR) — це ончейн-контракт кросчейн-маршрутизації активів, відповідальний за блокування, мінтинг, спалювання та вивільнення токенів, і може вказувати незалежний ISM. Nexus Bridge — це інтерфейс користувача, побудований на основі Warp Route, який полегшує кінцевим користувачам виконання кросчейн-операцій із токенами. Під капотом він все одно слідує шляху передачі повідомлень Mailbox та верифікації ISM.

Поширені ризики при налаштуванні ISM Warp Route

Занадто малий набір валідаторів або низький поріг можуть послабити безпеку Multisig ISM. Неправильна конфігурація дочірніх модулів в Aggregation ISM може призвести до неефективності певних умов безпеки. Неправильні налаштування maxCapacity в Rate Limited ISM можуть надмірно обмежити звичайні перекази. Витік ключа власника Pausable ISM може призвести до шкідливого призупинення маршруту. Перед використанням користувачі повинні перевірити адреси та параметри контрактів ISM в ончейні, а також розрізняти економічну безпеку валідаторів за замовчуванням та припущення щодо довіри спеціальних ISM.

На яких ланцюжках виконуються хунки та ISM?

Хунки виконують postDispatch після виклику dispatch вихідного Mailbox, контролюючи вихідну логіку, таку як оплата газу, запис у дерево Меркла, обмеження швидкості та призупинення. ISM виконує verify під час фази process цільового Mailbox, контролюючи вхідну верифікацію. RateLimitedHook та RateLimitedIsm знаходяться відповідно на вихідному та цільовому ланцюжках і поєднуються для досягнення двонаправленого контролю пропускної здатності.