Як працює міжланцюгова інфраструктура? Gravity протокол взаємодії та глибокий аналіз архітектури рідного оракула

Блокчейн-індустрія фрагментована — це вже неодноразово підтверджений факт. Ethereum, Solana, Cosmos, Arbitrum та десятки інших публічних блокчейнів і L2 співіснують, кожен зі своєю системою облікових записів, зберіганням стану та правилами консенсусу. Містки для активів та протоколи міжланцюгових повідомлень з'являлися один за одним протягом останніх років, але фундаментальне структурне питання залишається відкритим: хто насправді підтверджує міжланцюгові дані?

Більшість L1-блокчейнів «перекладають» відповідальність за верифікацію оракулів або мостів на зовнішні незалежні мережі — зовнішня мережа оракулів підписує дані, або незалежний мультипідписний комітет підтверджує події депозиту. Сам блокчейн залишається «чистим», але нове припущення довіри додається на периферію. Якщо бічний канал зламано, блокчейн продовжує працювати, але дані вже помилкові.

Gravity пропонує принципово іншу архітектурну відповідь. Розроблена командою Galxe, Gravity — це високопродуктивний, повністю сумісний з EVM блокчейн Layer 1, ключова відмінність якого — вбудований оракул (Native Oracle). Ті самі валідатори, які генерують блоки за консенсусом AptosBFT, одночасно спостерігають за зовнішніми даними, голосують і записують їх у L1. Немає зовнішньої мережі оракулів, немає незалежного мультипідписного комітету. Міст — це не окремий сервіс, а контракт, який приймає дані, вже надані набором валідаторів.

Саме це означає «вбудований»: канал підтвердження даних валідаторами є частиною машини стану блокчейну, а не окремим сервісом, що працює поруч. Будь-які дані, отримані через Native Oracle, мають таку саму безпеку, як і сам блокчейн — той самий набір валідаторів, той самий поріг BFT, те саме вікно фіналізації.

У червні 2026 року основна мережа Gravity L1 офіційно запустилася, перетворивши цю архітектуру з теорії в реальність. У цій статті ми систематично розберемо механізм протоколу інтероперабельності Gravity за чотирма вимірами: передача міжланцюгових повідомлень, маршрутизація ліквідності, модель верифікації та безпеки, а також повний процес міжланцюгового переміщення активів.

Механізм передачі міжланцюгових повідомлень: парадигмальний зсув від «опитування» до «виштовхування»

Передача міжланцюгових повідомлень — це базовий шар будь-якого протоколу інтероперабельності. Основну проблему можна звести до одного питання: як блокчейн A може довести блокчейну B, що «щось сталося»?

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

Механізм передачі повідомлень Gravity, побудований на його вбудованому оракулі, докорінно змінює цей процес. Native Oracle — це єдиний контракт, розгорнутий на фіксованій системній адресі в Gravity L1: NativeOracle → 0x0000000000000000000000000001625F4000. Цей контракт має ключову операцію record, яку можна викликати лише з SYSTEM_CALLER — привілейованої ідентичності часу консенсусу, а не звичайного облікового запису.

Функція record приймає такі параметри: тип джерела (sourceType, наприклад, блокчейн), ідентифікатор джерела (sourceId, наприклад, ID ланцюжка), nonce, номер блоку вихідного ланцюжка, корисне навантаження (payload, непрозорий бінарний блок) та ліміт газу для зворотного виклику. Також існує варіант recordBatch для доставки кількох подій з одного джерела в одній транзакції.

Варто детальніше розглянути три ключові проектні рішення:

По-перше, централізація захисту від повторного відтворення. Native Oracle вимагає для кожної пари (sourceType, sourceId), щоб nonce == currentNonce + 1 — строго послідовно, без пропусків. Старі повідомлення ніколи не можна відтворити, оскільки контракт вже перевищив їхній nonce. Обробники на рівні додатків не повинні вести власну карту використаних nonce. Це означає, що логіка дедуплікації міжланцюгових повідомлень виноситься на рівень протоколу, а не залишається на реалізацію кожного контракту додатка — що значно знижує навантаження на безпеку для розробників додатків.

По-друге, маршрутизація зворотного виклику, а не опитування. Для кожної пари (sourceType, sourceId) можна зареєструвати контракт зворотного виклику. Коли дані записуються, Native Oracle викликає функцію onOracleEvent зареєстрованого обробника із зазначеним лімітом газу. Аналіз поділяється на два рівні: обробник за замовчуванням для кожного типу джерела, який може бути перевизначений спеціалізованим обробником для конкретного sourceId. Управління реєстром здійснюється через голосування. Ця модель «виштовхування» дозволяє контрактам додатків миттєво отримувати сповіщення та виконувати відповідну логіку, як тільки міжланцюгові дані надходять, не потребуючи постійного опитування стану.

По-третє, толерантність до помилок зворотного виклику. Обробник повертає shouldStore: bool — обробник, який повністю спожив корисне навантаження (вже застосував його до свого стану), може повернути false, щоб пропустити зберігання та заощадити газ. Якщо обробник відкочується або вичерпує газ, Native Oracle перехоплює виняток, викликає подію CallbackFailed(reason) і все одно зберігає це корисне навантаження. Операція запису в будь-якому випадку завершується успіхом.

Цей дизайн реалізує чіткий розподіл обов'язків: Native Oracle відповідає за істинність (підтвердження консенсусом, захист від повторного відтворення), а контракти додатків — за значення (декодування та виконання). Автентичність міжланцюгових повідомлень гарантується набором валідаторів Gravity з фіналізацією BFT, а не залежить від зовнішньої мережі ретрансляторів.

Модель верифікації та безпеки: один замок, один ключ

Відмінності в моделях безпеки є ключовим виміром, що відрізняє якість міжланцюгових протоколів. Архітектуру безпеки Gravity можна узагальнити одним реченням: безпека Native Oracle дорівнює безпеці самого блокчейну.

Конкретно, Gravity використовує механізм верифікації Proof-of-Stake: валідатори ставлять токени G для участі в консенсусі та доказі Native Oracle. Механізм консенсусу — AptosBFT, який забезпечує високу швидкість фіналізації. Безпеку блокчейну гарантує набір валідаторів з порогом у дві третини — той самий поріг одночасно гарантує автентичність даних Native Oracle.

Що це означає?

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

З точки зору міжланцюгового переміщення активів, ця модель усуває ризик «зовнішніх підписантів», притаманний традиційним мостам. Традиційний міст Ethereum→Cosmos Gravity складається з двох частин: смарт-контракту Solidity, розгорнутого на Ethereum, та модуля блокчейну Cosmos SDK. Користувач блокує активи на одній стороні, а на іншій стороні карбуються відповідні токени. Але в архітектурі Native Oracle Gravity L1 міст Ethereum→Gravity L1 — це перше виробниче застосування Native Oracle. Немає зовнішньої мережі оракулів, немає незалежного набору підписантів, доданого поверх консенсусу.

Варто зазначити, що Gravity також проводить важливе оновлення своєї архітектури безпеки. У червні 2026 року Gravity оголосив, що під час запуску основної мережі L1 він оновить свою міжланцюгову інфраструктуру з LayerZero до Chainlink CCIP як стандартизовану. Рідний токен Gravity G стане крос-чейн нативним активом (CCT), надаючи розробникам можливість самостійного розгортання, переказів без прослизання та вищої програмованості. CCIP, завдяки своїй децентралізованій мережі оракулів, значно підвищить здатність розробників мережі Gravity створювати безпечні міжланцюгові додатки. Це оновлення показує, що Gravity, зберігаючи основні переваги Native Oracle, також активно інтегрує найзріліші міжланцюгові стандарти галузі.

Повний процес міжланцюгового переміщення активів: вісім кроків від депозиту до отримання

На основі описаних механізмів повний процес міжланцюгового переміщення активів (на прикладі Ethereum→Gravity L1) можна розкласти на наступні кроки:

Крок 1: Користувач блокує активи. Користувач вносить ETH або токени ERC-20 у контракт мосту Gravity на Ethereum. Цей контракт фіксує подію депозиту, включаючи адресу користувача, тип активу, кількість та інформацію про цільовий ланцюжок.

Крок 2: Фіналізація блоку Ethereum. Валідатори Gravity постійно слухають блокчейн Ethereum. Валідатори не покладаються на зовнішніх ретрансляторів, а самостійно спостерігають за станом Ethereum.

Крок 3: Голосування валідаторів на основі консенсусу. У кожному блоці Gravity L1 валідатори підписують і поширюють спостережувані зовнішні дані (включаючи події депозиту на Ethereum) як частину корисного навантаження Native Oracle. Для підпису таких зовнішніх даних валідатори використовують ті самі ключі та той самий поріг, що й для власних транзакцій Gravity.

Крок 4: Дані надходять до Native Oracle. Як тільки набір валідаторів досягає консенсусу щодо певної зовнішньої події (досягаючи порогу в дві третини), ці дані записуються в контракт Native Oracle на Gravity L1 через виклик record або recordBatch.

Крок 5: Перевірка nonce та захист від повторного відтворення. Контракт Native Oracle перевіряє, чи nonce цієї події строго зростає. Якщо nonce не збігається (повторна або пропущена подія), запис відхиляється.

Крок 6: Спрацьовує зворотний виклик. Контракт мосту активів, як зареєстрований обробник зворотного виклику, отримує виклик onOracleEvent. Контракт декодує корисне навантаження, перевіряє тип і кількість активів, підтверджує цільову адресу отримувача.

Крок 7: Карбування або вивільнення активів. Контракт мосту активів карбує на Gravity L1 відповідну кількість обгорнутих токенів G (або безпосередньо вивільняє G у випадку мосту для рідних активів) і переказує їх на адресу користувача в мережі Gravity.

Крок 8: Підтвердження фіналізації. Весь процес отримує субсекундну фіналізацію завдяки консенсусу AptosBFT Gravity. Користувач може отримати міжланцюгові активи протягом 200 мс часу блоку.

Ключова особливість цього повного процесу: жоден крок не залежить від зовнішніх ретрансляторів або незалежних підписантів. Від спостереження даних до голосування, запису та виконання — все виконується тим самим набором валідаторів з тими самими припущеннями безпеки.

Основа продуктивності: понад 12 000 TPS та субсекундна фіналізація

Цінність дизайну потребує продуктивності для своєї реалізації. Параметри продуктивності Gravity забезпечують практичну здійсненність його міжланцюгової інтероперабельності:

Основна мережа Gravity використовує паралельний EVM-двигун Grevm (форк від revm). Під реальним навантаженням Gravity може підтримувати пропускну здатність понад 12 000 TPS для переказів ERC-20, з часом блоку 200 мс. У тестах з кластером із 3 валідаторів (8 vCPU / 16 ГБ на вузол) пропускна здатність становила приблизно 9 500–11 000 TPS.

Ще більш вартою уваги є структура комісій. Базова комісія в 50 Gwei робить блоковий простір Gravity функціонально суспільним благом, а не конкурентним активом. Вартість одного переказу ERC-20 становить приблизно 0,0026 долара США. Це ламає стандартну економічну модель L1, яка покладається на тиск комісій як на основне джерело накопичення вартості токена. Захоплення вартості переміщується на послуги, що надаються валідаторами (докази оракула, міжланцюгові дані, мостинг) та рівень додатків.

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

З точки зору історичних даних, альфа-основна мережа Gravity, яка працювала як L2 на основі Arbitrum Nitro з серпня 2024 року, за 22 місяці обробила понад 611 мільйонів транзакцій, охопивши 28,5 мільйона гаманців, із середнім часом блоку 1,3 секунди. Це становить виробничу верифікацію перед запуском основної мережі L1.

Ринкові дані та токеноміка

Станом на 29 червня 2026 року, згідно з даними біржі Gate, ціна Gravity (G) становить $0,003641, зростання за 24 години: +13,78%, за 7 днів: +36,62%, за 30 днів: +3,72%. Ринкова капіталізація становить приблизно $26 334 200, що відповідає 658-му місцю. Обсяг торгів за 24 години — $29 197 800, загальна пропозиція — 12,000 млрд. Ринкові настрої — нейтральні. Зміна ціни за останній рік: -69,22%, історичний максимум: $0,015440.

G — це рідний токен Gravity L1, з максимальною пропозицією 12 мільярдів, мігрувавший з оригінального токена GAL. Під час запуску основної мережі 7 валідаторів-ініціаторів отримали початковий розподіл ставки в 7 мільйонів G. Відповідно, 7 мільйонів G були заблоковані на основній мережі Ethereum у контракті GBridgeSender канонічного мосту, назавжди заблоковані для підтримки рідного G на L1.

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

Висновок: Кінцева мета інтероперабельності — єдність довіри

Еволюцію міжланцюгової інтероперабельності можна поділити на три етапи.

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

Другий етап — це протоколи універсальної передачі повідомлень (такі як LayerZero, Axelar), які підтримують міжланцюгові виклики смарт-контрактів, але логіка верифікації все ще покладається на комбінацію зовнішніх оракулів і ретрансляторів.

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

Архітектура Native Oracle від Gravity є інженерною реалізацією третього етапу. Це не поступова оптимізація існуючих моделей мостів, а фундаментальна перебудова відповіді на питання «хто підтверджує міжланцюгові дані». Коли безпека міжланцюгових даних і безпека самого L1 гарантуються тим самим набором валідаторів і одним порогом BFT, розрив довіри між «міжланцюговим» і «внутрішньоланцюговим» значно скорочується.

Це не означає, що Gravity усуває всі ризики. Ступінь централізації набору валідаторів, довгострокова стабільність економічної моделі ставок, ризики коду міжланцюгових контрактів та інженерні виклики під час переходу від LayerZero до Chainlink CCIP — все це виміри, які потребують постійного спостереження. Крім того, у травні 2026 року Gravity Bridge зазнав атаки, втративши приблизно 5,4 мільйона доларів, що нагадує ринку: навіть найкраще спроектована міжланцюгова архітектура потребує достатньо тривалої перевірки в бойових умовах.

Але напрямок зрозумілий: кінцева мета інтероперабельності — не більше мостів, а менше припущень довіри. Чи стане Gravity репрезентативною інфраструктурою для цієї кінцевої мети, залежить від процесу децентралізації валідаторів після запуску основної мережі, швидкості міграції екосистемних додатків та стійкості Native Oracle до реальних атак. Для дослідників і розробників, які стежать за міжланцюговими треками, архітектурний вибір Gravity пропонує зразок, за яким варто постійно спостерігати.

FAQ

Q1: Яка ключова відмінність між Gravity та такими міжланцюговими протоколами, як LayerZero та Axelar?

LayerZero базується на архітектурі ультралегких вузлів (ULN), де Oracle та Relayer спільно підтверджують міжланцюгові повідомлення; Axelar використовує незалежну мережу валідаторів PoS та механізм універсальної передачі повідомлень (GMP). Gravity вбудовує верифікацію міжланцюгових даних безпосередньо в шар консенсусу L1, де той самий набір валідаторів з одним порогом BFT одночасно гарантує стан ланцюжка та автентичність міжланцюгових даних.

Q2: Як Native Oracle від Gravity забезпечує безпеку міжланцюгових даних?

Native Oracle не має зовнішньої мережі або мультипідписного комітету. Валідатори спостерігають зовнішні дані, голосують і записують їх у L1 під консенсусом AptosBFT. Автентичність даних гарантується порогом у дві третини набору валідаторів — що ідентично безпеці самого блокчейну. Вартість атаки на фальшиві міжланцюгові дані дорівнює вартості атаки на сам блокчейн.

Q3: Які поточні параметри продуктивності Gravity?

Gravity L1 під реальним навантаженням може підтримувати пропускну здатність понад 12 000 TPS для переказів ERC-20, з часом блоку 200 мс та субсекундною фіналізацією. Вартість одного переказу ERC-20 становить приблизно $0,0026. Альфа-основна мережа за 22 місяці обробила понад 611 мільйонів транзакцій.

Q4: Що означає оновлення Gravity з LayerZero до Chainlink CCIP?

У червні 2026 року Gravity оголосив про використання Chainlink CCIP як своєї стандартизованої міжланцюгової інфраструктури. G стане міжланцюговим рідним активом (CCT), що надає розробникам можливість самостійного розгортання, переказів без прослизання та вищої програмованості. Це підвищує стандарти безпеки та зручність розробки міжланцюгових додатків у мережі Gravity.

Q5: Яка основна функція токена G?

G — це рідний газовий та стейкінговий токен Gravity L1. Валідатори ставлять G для участі в консенсусі та доказі Native Oracle. Власники G приймають рішення протоколу через G DAO, а G також використовується як платіжний та стимулюючий токен в екосистемі Galxe.