Що таке нативна інтероперабельність?

TL;DR

• Нативна інтероперабельність означає, що один блокчейн напряму перевіряє та виконує зміни стану іншого, використовуючи докази легкого клієнта.
• Такий підхід усуває довірених посередників і зменшує площину атак порівняно з мостами.
• Реальні приклади у продакшені: Cosmos IBC і Polkadot XCM.
• Безпека ґрунтується на перевірюваних доказах консенсусу та економічній фінальності.
• Компроміси: вищі витрати на верифікацію та тісніша прив’язка правил консенсусу між мережами.

Нативна інтероперабельність у модульних блокчейнах

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

Такий підхід відповідає модульній архітектурі, де спеціалізовані шари відповідають за виконання транзакцій, доступність даних і фінальність.

Основний механізм: верифікація легким клієнтом

В основі — легкий клієнт, вбудований у контракт або протокольну логіку. Він зберігає компактне представлення віддаленого консенсусу: Merkle-корені заголовків блоків, підписані валідаторами.

При запиті взаємодії:

• передається останній фіналізований заголовок мережі B,
• Merkle-доказ зміни стану або транзакції, прив’язаної до цього заголовка,
• підписи валідаторів мережі B понад порогове значення (зазвичай >2/3 стейку).

Мережа A звіряє дані зі своїм станом легкого клієнта і локально виконує дію. Для двосторонніх процес дзеркальний.

Верифікація відбувається на-чейні в тій же VM/WASM-середі, що й смарт-контракти.
Без оракулів. Без мультисиг-комітетів.

Модель безпеки: від фінальності до виконання

Безпека зводиться до трьох питань.

1. Чи може мережа A довіряти фінальності мережі B?

Економічна фінальність важливіша за ймовірнісні гарантії.
Мережа на PoS зі слешингом повинна розкривати стейки валідаторів і періоди анбондингу для легкого клієнта.
Якщо мережа B відкатує фіналізований блок, легкий клієнт фіксує форк і блокує крос-чейн повідомлення.

2. Чи коректно сформовано доказ?

Merkle-докази детерміновані.
Верифікатор повторно обчислює корінь із листа та шляху і звіряє з заголовком.
Будь-яка невідповідність скасовує транзакцію.

3. Що відбувається при збої виконання?

Неуспішні крос-чейн виклики не повинні пошкоджувати локальний стан.
Протоколи використовують двофазний коміт:
мережа A блокує активи, мережа B виконує операцію, після чого мережа A розблоковує активи при успіху або відкочує їх після тайм-ауту.

Ці правила формують мінімізовану за довірою модель.
Атака потребує або компрометації >2/3 стейку валідаторів віддаленої мережі, або злому криптографічних примітивів.

Реалізація на практиці: Cosmos IBC

Cosmos IBC — найтриваліший у роботі протокол нативної інтероперабельності.
Запущений у 2021 році, об’єднує понад 100 зон; станом на III квартал 2025 через нього передано понад $15 млрд.

Приклад маршруту пакета:

• Користувач Osmosis обмінює ATOM на USDC в Ethereum через Gravity Bridge (тепер керується Axelar).
• Реальний шлях: IBC між Osmosis і Cosmos Hub, потім окремий канал легкого клієнта до Ethereum.

Процес:

1. Osmosis створює IBC-пакет з параметрами трансферу.
2. Релейєри (недовірені вузли) пересилають пакет у Cosmos Hub.
3. Cosmos Hub перевіряє пакет через легкий клієнт Osmosis і переадресовує його до модуля шлюзу Ethereum.
4. Шлюз подає доказ легкого клієнта Ethereum у попередньо розгорнутий верифікаційний контракт.
5. Після успішної перевірки контракт карбує представлення ATOM у Ethereum.

Жоден міст не утримує активи довше одного вікна підтвердження.
Система обробила понад 50 млн пакетів без інцидентів, пов’язаних з IBC.

Реалізація на практиці: Polkadot XCM

Polkadot використовує інший підхід — XCM (Cross-Consensus Messaging).
Парачейни спільно використовують релейний ланцюг, який зберігає стани легких клієнтів для кожної підключеної мережі.

Приклад виконання

Moonbeam (EVM-парачейн) надсилає GLMR в Astar (Substrate-нативна мережа).

• Moonbeam кодує XCM-повідомлення: WithdrawAsset, DepositAsset.
• Повідомлення проходить через релейний ланцюг, який перевіряє кореневий хеш стану Moonbeam.
• XCM-модуль Astar приймає та виконує депозит безпосередньо на цільовий акаунт.

XCM підтримує складні інструкції: трансфери активів, виклики контрактів, оплату комісій активами з іншої мережі. Версія 4 (з березня 2025 року) додає механізми-бар’єри для запобігання reentrancy-атакам між мережами.

Компроміси дизайну в модульних стеках

Нативна інтероперабельність має витрати.

Вартість верифікації (gas)
Синхронізація легкого клієнта Ethereum коштує близько 500k gas за оновлення в Optimism.
Пакетування доказів зменшує витрати, але мережі з високою частотою змін стану схиляються до верифікації на рівні L2.

Зв’язаність консенсусу

Легкий клієнт повинен розуміти правила фінальності віддаленої мережі.
Для PoW потрібна логіка накопиченої складності, для Tendermint — відстеження змін валідаторського сету.
Оновлення протоколу на одній стороні може порушити сумісність, доки обидві мережі не синхронізують оновлення.

Затримки (latency)

Затримки фінальності накопичуються.
Переказ із Ethereum-роллапа (12 секунд) у Cosmos-зону (5 секунд) чекає обох порогів фінальності плюс доставку релейєрів — зазвичай 30–90 секунд.

Інженери зменшують ці затримки асинхронними моделями та спеціалізованими релейєрами, що пакетують докази.

Порівняння з мостовими моделями

Мости все ще домінують за обсягом у екосистемі Ethereum, оскільки підтримують довільні токени без змін протоколу.
Нативні системи потребують інтеграції заздалегідь, але усувають постійні припущення довіри.

Чек-лист інженерії нативних каналів

1. Визначити механізм фінальності: експортувати набір валідаторів, ваги стейків і період анбондингу як on-chain стан.
2. Реалізувати модуль легкого клієнта: зберігати Merkle-корені заголовків, забезпечити поріг >2/3 підписів, обробляти ротації валідаторів.
3. Стандартизувати формат пакетів: ICS-20 для взаємозамінних токенів або власні схеми для викликів контрактів.
4. Додати тайм-аут: пакети спливають через N блоків; відправник має довести недоставку, щоб повернути активи.
5. Протестувати сценарії форку: slash 1/3 валідаторів, зупинку мережі, spam заголовками.

Cosmos SDK і Substrate мають референтні реалізації

Кастомні мережі можуть форкнути ці модулі з мінімальними змінами.

Поточні обмеження та відкриті проблеми

• Сумісність з EVM складна: у Solidity немає нативних бібліотек Merkle, тому верифікація переноситься у прекомпайли або L2.
• Масштабованість доказів погіршується зі зростанням кількості валідаторів: Tendermint обмежений ~200, Ethereum з >900k валідаторами потребує семплінгу або агрегації.
• Відсутність приватності: усі крос-чейн повідомлення публічні; zero-knowledge-релєєри досі експериментальні.

Дослідження в Altius Labs спрямовані на стислі докази для валідаторів Ethereum на базі KZG-комітментів.
Ранні бенчмарки показують ~80% зменшення gas-витрат на синхронізацію в мережах OP Stack.

Майбутні напрями

Модульна інтероперабельність, імовірно, зійдеться на двох моделях:

1. Хаб-та-спиці з високобезпечною мережею фіналізації (Cosmos Hub, Polkadot Relay).
2. Меш-топології, де кожна мережа запускає легкі клієнти для всіх інших - завдяки рекурсивним SNARK-доказам.

Обидва підходи потребують суворої верифікації. Переможуть ті, що мінімізують довіру та зберігають суверенні середовища виконання.

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