Як працює Hyperlane кросчейн-обмін повідомленнями? Повний процес — від моменту відправлення до доставки

Hyperlane Cross-Chain Message Passing (General Message Passing, GMP) — це стандартизований процес, який можна повторювати між будь-якими підтримуваними ланцюгами: застосунок викликає функцію dispatch на Mailbox вихідного ланцюга для надсилання повідомлення, офчейн-ретранслятор подає повідомлення разом із метаданими верифікації на цільовий ланцюг, а після верифікації модулем міжланцюгової безпеки (Interchain Security Module, ISM) Mailbox викликає функцію handle на контракті одержувача для завершення доставки. Hyperlane (HYPER) описує загальний фреймворк рівня сумісності Hyperlane через три компоненти: Mailbox, ISM і Warp Route.

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

Кожне кросчейн-повідомлення має глобально унікальний messageId, а Mailbox підтримує мапу доставлених повідомлень для запобігання атакам повторного відтворення. Hyperlane vs LayerZero vs Wormhole порівнює структурні відмінності між трьома протоколами з точки зору шляхів верифікації повідомлень і дозволів на розгортання. Відправник повідомлення попередньо сплачує комісію за доставку на цільовому ланцюзі на вихідному ланцюзі через Interchain Gas Payment (IGP); ретранслятор сплачує газ на цільовому ланцюзі для завершення виклику обробки. Explorer може відстежувати повний життєвий цикл повідомлення від відправлення до обробки.

Які етапи передачі кросчейн-повідомлень Hyperlane?

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

У таблиці вище показано повний розподіл етапів Hyperlane GMP від вихідного ланцюга до цільового. Dispatch і доставка відбуваються на контрактах Mailbox відповідних ланцюгів. Ретранслятори та валідатори виконують офчейн-передачу та функції атестації безпеки, тоді як ISM виступає шлюзом верифікації повідомлень на цільовому ланцюзі.

Рисунок 1. Огляд потоку кросчейн-повідомлень Hyperlane: повний шлях від dispatch на вихідному ланцюзі, через ретранслятор/валідатор, до верифікації ISM та доставки handle на цільовому ланцюзі.

Як надсилається повідомлення на етапі dispatch вихідного ланцюга?

Етап dispatch вихідного ланцюга ініціюється викликом Mailbox.dispatch() з контракту відправника. Mailbox отримує три основні параметри: ідентифікатор домену цільового ланцюга (destinationDomain), адресу одержувача (recipientAddress, закодовану як bytes32) та тіло повідомлення (messageBody). Mailbox додає стандартний заголовок повідомлення до тіла, який містить такі поля, як version, nonce, origin, sender, destination та recipient, забезпечуючи унікальну ідентифікацію повідомлення та стійкість до підробки.

Після виконання dispatch Mailbox вставляє повне повідомлення як листок в інкрементальне дерево Меркла (яке підтримується контрактом MerkleTreeHook) і випромінює події Dispatch та DispatchId. messageId — це хеш keccak256 повідомлення (включно із заголовком), який повертається викликом dispatch і доступний для відстеження в Explorer. nonce — це монотонно зростаючий лічильник на Mailbox вихідного ланцюга. Навіть якщо тіло повідомлення ідентичне, різні nonce дають різні messageId.

Відправник може запитати кросчейн-комісію через quoteDispatch(), яка покриває вартість dispatch на вихідному ланцюзі та попередньо сплачений міжланцюговий газ для доставки на цільовому ланцюзі. Post-Dispatch Hook може попередньо сплатити газ цільового ланцюга ретранслятору через InterchainGasPaymaster (IGP) після dispatch. Після завершення dispatch повідомлення переходить у стан очікування ретрансляції. messageId генерується з хешу повного повідомлення, а Mailbox цільового ланцюга запобігає повторній доставці через мапу delivered(messageId).

Як ретранслятор і валідатор співпрацюють для доставки повідомлень?

Ретранслятор і валідатор виконують різні, але взаємодоповнювальні функції в протоколі Hyperlane. Валідатор відповідає за атестацію безпеки: коли Mailbox вихідного ланцюга відправляє нове повідомлення, MerkleTreeHook випромінює подію InsertedIntoTree. Валідатор зчитує поточний корінь Меркла, підписує контрольну точку та публікує підпис у публічному сховищі (наприклад, AWS S3 або Google Cloud Storage). Ретранслятор відповідає за транспортний рівень: він слухає події від Mailbox вихідного ланцюга, збирає метадані, необхідні ISM (наприклад, підписи валідаторів, доказ Меркла), і викликає Mailbox.process() на цільовому ланцюзі для подання повідомлення.

Валідатор потрібен лише в сценаріях Multisig ISM або Economic Security Module. Якщо одержувач налаштовує Optimistic ISM, доказ з нульовим розголошенням або інший модуль, який не вимагає підписів валідаторів, ретранслятору потрібно лише зібрати метадані, необхідні цьому ISM. Hyperlane не вимагає закріпленого набору валідаторів; одержувач може самостійно налаштувати адреси валідаторів та поріг підписів у Multisig ISM.

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

Як завершується доставка на етапі доставки цільового ланцюга?

Етап доставки цільового ланцюга ініціюється викликом Mailbox.process(metadata, message) з боку ретранслятора. Mailbox спочатку перевіряє, чи вже було доставлено messageId; якщо він існує в мапі delivered, повторне відтворення відхиляється. Потім Mailbox запитує ISM, визначений контрактом одержувача (через recipientIsm() або спеціальну конфігурацію застосунку), і передає message та metadata функції ISM.verify().

Після проходження верифікації ISM Mailbox викликає функцію handle(origin, sender, body) контракту одержувача, передаючи тіло повідомлення та інформацію про джерело логіці застосунку. Контракт одержувача повинен реалізовувати функцію handle інтерфейсу IMessageRecipient, яка виконує бізнес-операції, такі як голосування кросчейн-управління, створення/вивільнення активів або оновлення стану. Після успішної доставки Mailbox позначає messageId як доставлений і випромінює події Process та ProcessId.

Для кросчейн-застосунків з активами, як-от Warp Route, функція handle запускає логіку блокування, створення, спалювання або вивільнення токенів. Для застосунків кросчейн-управління функція handle записує вагу голосів або виконує пропозиції. Газ для етапу доставки сплачується ретранслятором на цільовому ланцюзі, тоді як відправник уже попередньо сплатив відповідну комісію на вихідному ланцюзі через IGP.

Рисунок 2. Послідовність доставки цільового ланцюга: Mailbox process запускає ISM verify; після верифікації викликається handle одержувача, і повторне відтворення запобігається через мапу messageId.

Як ISM цільового ланцюга верифікує кросчейн-повідомлення?

ISM (Interchain Security Module) — це смарт-контракт на цільовому ланцюзі, відповідальний за верифікацію автентичності кросчейн-повідомлень. Перед доставкою Mailbox передає message та metadata, подані ретранслятором, до ISM.verify(). Логіка верифікації відрізняється залежно від типу ISM. Стандартним ISM є Multisig ISM, який вимагає, щоб налаштована кількість валідаторів підписала корінь Меркла вихідного ланцюга, досягнувши порогу. Застосунки також можуть розгортати власні ISM або використовувати Aggregation ISM для комбінування кількох шляхів верифікації.

Щоб перевірити конфігурацію ISM, Ви можете запитати адресу ISM контракту одержувача, перевірити поріг валідаторів та параметри типу ISM, а також підтвердити статус верифікації та метадані для конкретного повідомлення в Explorer.

У Multisig ISM ретранслятор отримує підписи контрольних точок із публічного сховища валідаторів і подає їх разом із доказом Меркла. Economic Security Module забезпечує економічну безпеку через EigenLayer AVS; шахрайство валідатора може призвести до слашингу. Якщо верифікація успішна, ISM повертає true, і Mailbox виконує handle; якщо верифікація не вдається, транзакція process відкочується, і ретранслятор повторює спробу відповідно до стратегії відступу.

Які ризики та обмеження передачі кросчейн-повідомлень?

Передача кросчейн-повідомлень Hyperlane містить структурні ризики на рівні механізму, які потрібно розуміти з точки зору рівня повідомлень, транспортного рівня та економічного рівня. Ризики рівня повідомлень: неправильна конфігурація користувацьких ISM може послабити силу верифікації; вразливості в логіці функції handle одержувача можуть призвести до неправильних оновлень стану. Ризики транспортного рівня: затримки або зупинки ретранслятора можуть залишити повідомлення недоставленими на тривалий час (IGP попередньо сплачено, але ретранслятор ще не подав); коливання цін на газ на цільовому ланцюзі можуть вплинути на бажання ретранслятора подавати; простої валідаторів у Multisig ISM з високим порогом можуть перешкоджати працездатності.

Ризики економічного рівня: шахрайство валідатора може спровокувати слашинг HYPER; неправильна конфігурація комісії IGP може призвести до недостатньої комісії за доставку. Доставка повідомлень не є миттєвою; потрібно чекати фінальності вихідного ланцюга та подання ретранслятора. Надійність залежить від попередньої оплати IGP та якості роботи ретранслятора.

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

Підсумок

Кросчейн-повідомлення Hyperlane слідують повторюваному потоку: dispatch → attestation → relay → verify → deliver. Mailbox.dispatch() вихідного ланцюга кодує повідомлення та записує його в дерево Меркла; валідатори підписують контрольну точку (у сценаріях Multisig ISM); ретранслятор збирає метадані та викликає process на цільовому ланцюзі; після верифікації ISM Mailbox викликає handle для завершення доставки. messageId є глобально унікальним, і доставлені повідомлення не можна повторно відтворювати. IGP попередньо сплачує газ цільового ланцюга, а Explorer забезпечує відстеження повного життєвого циклу.

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

Який базовий потік кросчейн-повідомлень Hyperlane?

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

На яких ланцюгах відбуваються dispatch і доставка?

Dispatch відбувається на контракті Mailbox вихідного ланцюга за ініціативою контракту відправника. Доставка відбувається на контракті Mailbox цільового ланцюга за ініціативою ретранслятора, який викликає process, і після верифікації ISM викликається handle одержувача.

Яка різниця між ретранслятором і валідатором?

Валідатор підписує контрольну точку кореня Меркла вихідного ланцюга, надаючи атестацію для модулів безпеки, таких як Multisig ISM. Ретранслятор відповідає за офчейн-транспортний рівень: індексує події вихідного ланцюга, збирає метадані та подає виклик process на цільовому ланцюзі. Їхні функції взаємодоповнювальні: ретранслятор необхідний для всіх доставок повідомлень, тоді як валідатор потрібен лише для певних типів ISM.

Як відстежити статус кросчейн-повідомлення?

Кожне повідомлення має унікальний messageId (хеш keccak256, повернутий під час dispatch). Hyperlane Explorer дозволяє запитувати статус повного життєвого циклу повідомлення від dispatch до process, включаючи час надсилання на вихідному ланцюзі, записи подання ретранслятора, результати верифікації ISM та підтвердження доставки на цільовому ланцюзі.

Що може спричинити недоставку повідомлення?

Поширені причини: недостатня попередньо сплачена комісія IGP, ретранслятор ще не подав або повторює спробу, підписи валідаторів не досягли порогу Multisig, комісія за газ на цільовому ланцюзі надто висока, що спричиняє затримку ретранслятора, або невдача верифікації ISM. Ви можете використовувати Explorer для перегляду конкретної причини очікування та записів повторних спроб для певного повідомлення.

Чи може кросчейн-повідомлення бути доставлено двічі?

Ні. Mailbox підтримує мапу delivered(messageId). Після того як messageId було доставлено, його буде відхилено під час process на цільовому ланцюзі, що запобігає атакам повторного відтворення. Поле nonce також гарантує, що навіть якщо тіло повідомлення однакове, різні відправлення дають різні messageId.