Фрагментований ландшафт блокчейн-індустрії є усталеною реальністю. Десятки публічних блокчейнів і Layer 2, серед яких Ethereum, Solana, Cosmos та Arbitrum, функціонують паралельно, кожен із власною системою облікових записів, сховищем стану та правилами консенсусу. Протягом останніх років швидко з’являлися крос-чейн мости для активів і протоколи крос-чейн повідомлень. Однак залишається одна фундаментальна структурна проблема: хто відповідає за автентифікацію крос-чейн даних?
Більшість блокчейнів першого рівня «делегують» перевірку оракулів або крос-чейн мостів незалежним позаланчейновим мережам — або зовнішня мережа оракулів підписує дані, або незалежний мульти-підписний комітет підтверджує події депозиту. Сам блокчейн залишається «чистим», але додається нове припущення довіри у вигляді побічного каналу. Якщо цей побічний канал буде скомпрометовано, блокчейн продовжує працювати, але дані на ланцюгу вже пошкоджені.
Gravity пропонує радикально іншу архітектурну відповідь. Розроблений командою Galxe, Gravity — це високопродуктивний, повністю сумісний із EVM блокчейн першого рівня. Його ключова відмінність — власний оракул: механізм, у якому той самий набір валідаторів під консенсусом AptosBFT одночасно створює блоки, спостерігає зовнішні дані, голосує та записує дані у L1. Тут немає зовнішньої мережі оракулів чи незалежного мульти-підписного комітету. Крос-чейн міст не є окремим сервісом — це смарт-контракт, що отримує дані, які вже подані набором валідаторів.
Саме це означає «нативний»: процес підтвердження валідаторів є частиною стану блокчейну, а не паралельною службою. Дані, оброблені через нативний оракул, мають той самий рівень безпеки, що й сам блокчейн — той самий набір валідаторів, той самий поріг BFT і те саме вікно фіналізації.
У червні 2026 року Gravity L1 запустив основну мережу, перевівши цю архітектуру з теорії у реальне виробництво. У цій статті системно розглядається протокол взаємодії Gravity у чотирьох аспектах: крос-чейн повідомлення, маршрутизація ліквідності, моделі валідації та безпеки, а також повний цикл передачі активів між ланцюгами.
Крос-чейн повідомлення: Перехід від парадигми «Pull» до «Push»
Крос-чейн повідомлення — це основний шар усіх протоколів взаємодії. Головна задача полягає у тому, як Ланцюг А доводить Ланцюгу B, що «щось сталося».
У традиційних дизайнах крос-чейн мостів користувачі депонують активи у контракт на вихідному ланцюгу. Зовнішні ретранслятори фіксують цю подію та випускають відповідні активи на цільовому ланцюгу. Ця модель залежить від чесності та доступності ретрансляторів і часто вимагає від користувачів чекати кілька підтверджень блоків для зниження ризику реорганізації.
Механізм повідомлень Gravity, побудований на власному оракулі, докорінно змінює цей процес. Власний оракул — це єдиний контракт, розгорнутий за фіксованою системною адресою на Gravity L1: NativeOracle → 0x0000000000000000000000000001625F4000. Цей контракт надає основну операцію record, яку може викликати лише SYSTEM_CALLER — привілейована консенсусна ідентичність, а не звичайний обліковий запис.
Функція record приймає такі параметри: тип джерела (sourceType, наприклад, блокчейн), ID джерела (sourceId, наприклад, chain ID), nonce, номер блоку вихідного ланцюга, payload (непрозорий бінарний масив) і ліміт газу для callback. Є також варіант recordBatch для доставки кількох подій з одного джерела в рамках однієї транзакції.
Виділяються три ключові рішення дизайну:
По-перше, централізований захист від повтору. Власний оракул забезпечує умову nonce == currentNonce + 1 для кожної пари (sourceType, sourceId), гарантуючи сувору послідовність без пропусків. Старі повідомлення не можуть бути повторно використані, оскільки контракт вже перейшов до наступного nonce. Процесори на рівні додатків більше не повинні вести власні карти оброблених nonce. Це означає, що логіка дедуплікації крос-чейн повідомлень переноситься на рівень протоколу, а не реалізується окремо у кожному контрактному додатку, значно зменшуючи навантаження на розробників щодо безпеки.
По-друге, маршрутизація callback замість опитування (polling). Кожна пара (sourceType, sourceId) може зареєструвати контракт callback. Коли дані записуються, власний оракул викликає функцію onOracleEvent зареєстрованого обробника, використовуючи вказаний ліміт газу. Існує два рівні парсингу: дефолтний обробник для кожного типу джерела, який може бути перевизначений спеціалізованим обробником для конкретного sourceId. Реєстр управляється через governance. Така модель «push» дозволяє контрактам додатків отримувати сповіщення та виконувати логіку одразу після надходження крос-чейн даних, усуваючи потребу у постійному опитуванні стану.
По-третє, fault tolerance callback. Обробник повертає shouldStore: bool — обробники, які повністю споживають payload (застосовуючи його до власного стану), можуть повернути false, щоб пропустити зберігання та зекономити газ. Якщо обробник завершує виконання із помилкою або не вистачає газу, власний оракул ловить виняток, генерує подію CallbackFailed(reason) і все одно зберігає payload. Операція запису завжди успішна.
Такий дизайн забезпечує чіткий розподіл обов’язків: власний оракул відповідає за істину (атестацію консенсусу, захист від повтору), а контракти додатків — за смисл (декодування та виконання). Автентичність крос-чейн повідомлень гарантується набором валідаторів Gravity із фіналізацією BFT, а не зовнішньою мережею ретрансляторів.
Модель валідації та безпеки: Один замок, один ключ
Модель безпеки — головна відмінність крос-чейн протоколів. Архітектура безпеки Gravity формулюється так: безпека власного оракулу дорівнює безпеці самого блокчейну.
Gravity використовує механізм валідації Proof-of-Stake. Валідатори стейкають токени G для участі у консенсусі та атестації власного оракулу. Двигун консенсусу — AptosBFT, що забезпечує високу швидкість фіналізації. Набір валідаторів захищає блокчейн із порогом у дві третини — цей же поріг гарантує автентичність даних власного оракулу.
Що це означає?
На більшості блокчейнів помилки оракулів або крос-чейн мостів часто «невидимі» — аномалії у зовнішніх мережах валідації можуть залишатися непоміченими тривалий час, інколи до катастрофічних втрат. У Gravity безпека оракулу тотожна безпеці самого блокчейну. Атакуючий має контролювати понад третину валідаторів, щоб подати фальшиві крос-чейн дані — це також означає, що він може атакувати сам блокчейн. Тут немає «слабшого побічного каналу», який можна експлуатувати дешевше.
З точки зору крос-чейн активів ця модель усуває ризик «зовнішнього підписувача», притаманний традиційним мостам. Класичний міст Ethereum→Cosmos Gravity складається з двох частин: смарт-контракту Solidity на Ethereum і модулю Cosmos SDK на блокчейні. Користувачі депонують активи з одного боку та випускають відповідні токени з іншого. В архітектурі власного оракулу Gravity L1 міст активів Ethereum→Gravity L1 став першим виробничим застосуванням власного оракулу. Тут немає зовнішньої мережі оракулів чи незалежного набору підписувачів поверх консенсусу.
Варто також зазначити, що Gravity проходить суттєве оновлення безпеки. У червні 2026 року Gravity оголосив, що у рамках запуску основної мережі L1 він переходить від LayerZero до Chainlink CCIP як стандартизованої крос-чейн інфраструктури. Нативний токен Gravity, G, стане крос-чейн нативним активом (CCT), що дозволить розробникам запускати мости за запитом, передавати активи без сліпіджу та отримувати більшу програмованість. CCIP із децентралізованою мережею оракулів значно підвищить безпеку та гнучкість для розробників крос-чейн додатків на Gravity. Це оновлення демонструє, що Gravity, зберігаючи свою ключову перевагу власного оракулу, активно інтегрує найзріліші крос-чейн стандарти індустрії.
Повний цикл передачі активів між ланцюгами: Вісім кроків
Виходячи з описаних механізмів, повна передача активів між ланцюгами (на прикладі Ethereum→Gravity L1) складається з таких етапів:
Крок 1: Користувач блокує активи. Користувач депонує ETH або ERC-20 токени у контракт мосту Ethereum Gravity. Контракт фіксує подію депозиту, включаючи адресу користувача, тип активу, суму та інформацію про цільовий ланцюг.
Крок 2: Фіналізація блоку Ethereum. Валідаторні вузли Gravity постійно спостерігають за ланцюгом Ethereum. Валідатори не покладаються на зовнішніх ретрансляторів для передачі даних, а самостійно спостерігають стан Ethereum.
Крок 3: Голосування валідаторів. У кожному блоці Gravity L1 валідатори підписують і транслюють зовнішні дані, які вони спостерігають (зокрема події депозиту Ethereum), як частину payload власного оракулу. Підписи для таких зовнішніх даних використовують ті самі ключі та пороги, що й для власних транзакцій Gravity.
Крок 4: Подання даних у власний оракул. Після досягнення консенсусу валідаторів щодо зовнішньої події (дві третини порогу) дані записуються у контракт власного оракулу Gravity L1 через виклик record або recordBatch.
Крок 5: Перевірка nonce та захист від повтору. Контракт власного оракулу перевіряє, чи nonce події суворо збільшується. Якщо nonce не співпадає (через дублювання або пропуск), запис відхиляється.
Крок 6: Виклик callback. Контракт мосту активів, зареєстрований як обробник callback, отримує виклик onOracleEvent. Контракт декодує payload, перевіряє тип активу та суму, підтверджує адресу одержувача.
Крок 7: Мінтинг або випуск активів. Контракт мосту активів мінтить відповідну кількість токенізованих активів G на Gravity L1 (або безпосередньо випускає 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 GB на вузол) пропускна здатність залишалася на рівні 9 500–11 000 TPS.
Особливо примітна структура комісій. При базовій комісії 50 Gwei блокпростір Gravity фактично стає суспільним благом, а не конкурентним активом. Кожна передача ERC-20 коштує близько $0,0026. Це ламає стандартну економічну модель L1, яка базується на тиску комісій для накопичення вартості токена. Захоплення цінності зміщується до сервісів, що надаються валідаторами (атестація оракулу, крос-чейн дані, мостові операції) та передач на рівні додатків.
Для крос-чейн сценаріїв низькі комісії означають економічну доцільність високочастотних транзакцій; фіналізація менш ніж за секунду наближає досвід користувача до внутрішньоланцюгових операцій.
Історично, з моменту запуску Gravity Alpha mainnet як L2 на Arbitrum Nitro у серпні 2024 року, було оброблено понад 611 мільйонів транзакцій через 28,5 мільйонів гаманців за 22 місяці, із середнім часом блоку 1,3 секунди. Це служить виробничим підтвердженням для запуску основної мережі L1.
Ринкові дані та токеноміка
Станом на 29 червня 2026 року, згідно з ринковими даними Gate, Gravity (G) має ціну $0,003641, з 24-годинним зростанням +13,78%, 7-денним приростом +36,62% і 30-денним підйомом +3,72%. Ринкова капіталізація становить приблизно $26,33 мільйона, рейтинг — 658-й. 24-годинний обсяг торгів — $29,20 мільйона, загальна пропозиція — 12 мільярдів. Ринковий настрій — нейтральний. За рік ціна змінилася на -69,22%, історичний максимум — $0,015440.
G — нативний токен Gravity L1 із максимальною пропозицією 12 мільярдів, мігрував із оригінального токена GAL. На момент запуску основної мережі сім генезис-валідаторів отримали початкову алокацію стейкінгу у 7 мільйонів G. Відповідні 7 мільйонів G назавжди заблоковані у контракті GBridgeSender на основній мережі Ethereum для підтримки нативного G на L1.
G виступає газ-токеном для транзакцій, забезпечує мережу через стейкінг, стимулює прийняття рішень у governance, мотивує розвиток і підтримує платежі. Власники G беруть участь у governance через протокол G DAO.
Висновок: Кінцева мета взаємодії — єдина довіра
Еволюцію крос-чейн взаємодії можна розділити на три етапи.
Перший етап — мости активів, де користувачі передають активи з Ланцюга А у Ланцюг B, покладаючись на зовнішніх валідаторів або докази легких клієнтів.
Другий етап — загальні протоколи повідомлень (LayerZero, Axelar), які підтримують крос-чейн виклики смарт-контрактів, але все ще покладаються на комбінацію зовнішніх оракулів і ретрансляторів для логіки перевірки.
Третій етап — взаємодія на рівні протоколу, де набір валідаторів відповідає і за переходи стану, і за атестацію крос-чейн даних, стискаючи зовнішні припущення довіри до меж безпеки самого блокчейну.
Архітектура власного оракулу Gravity — це інженерна реалізація третього етапу. Це не поступова оптимізація існуючих моделей мостів, а фундаментальне переосмислення питання: хто сертифікує крос-чейн дані? Коли безпека крос-чейн даних і самого L1 забезпечується тим самим набором валідаторів і порогом BFT, розрив довіри між «крос-чейн» і «он-чейн» значно скорочується.
Це не означає, що Gravity усуває всі ризики. Централізація набору валідаторів, довгострокова стабільність економічної моделі стейкінгу, вразливості смарт-контрактів у крос-чейн додатках і інженерні виклики міграції від LayerZero до Chainlink CCIP потребують постійної уваги. Крім того, у травні 2026 року Gravity Bridge зазнав атаки із втратами близько $5,4 мільйона — це нагадування, що навіть найміцніші крос-чейн архітектури потребують масштабного тестування у реальних умовах.
Але напрямок очевидний: кінцева мета взаємодії — не більше мостів, а менше припущень довіри. Чи стане Gravity репрезентативною інфраструктурою для цієї мети, залежить від децентралізації валідаторів після запуску основної мережі, швидкості міграції екосистеми та стійкості власного оракулу під реальними атаками. Для дослідників і розробників, що працюють у крос-чейн секторі, архітектурні рішення Gravity — це яскравий кейс для спостереження.
FAQ
Q1: У чому принципова різниця між Gravity та крос-чейн протоколами LayerZero і Axelar?
LayerZero використовує архітектуру Ultra Light Node (ULN), де оракули та ретранслятори спільно перевіряють крос-чейн повідомлення. Axelar застосовує незалежну мережу валідації PoS і механізм General Message Passing (GMP). Gravity безпосередньо інтегрує перевірку крос-чейн даних у шар консенсусу L1, той самий набір валідаторів і поріг BFT забезпечують як стан ланцюга, так і автентичність крос-чейн даних.
Q2: Як власний оракул Gravity гарантує безпеку крос-чейн даних?
Власний оракул не має зовнішньої мережі чи мульти-підписного комітету. Валідатори під консенсусом AptosBFT спостерігають зовнішні дані, голосують і записують їх у L1. Автентичність даних гарантується порогом у дві третини валідаторів — так само, як і безпека самого ланцюга. Вартість атаки на крос-чейн дані дорівнює вартості атаки на блокчейн.
Q3: Які поточні показники продуктивності Gravity?
Gravity L1 витримує понад 12 000 TPS для передач ERC-20 під реальним навантаженням, із часом блоку 200 мс та фіналізацією менш ніж за секунду. Кожна передача ERC-20 коштує близько $0,0026. Alpha mainnet обробив понад 611 мільйонів транзакцій за 22 місяці.
Q4: Що означає оновлення Gravity з LayerZero на Chainlink CCIP?
У червні 2026 року Gravity оголосив Chainlink CCIP як стандартизовану крос-чейн інфраструктуру. G стане крос-чейн нативним активом (CCT), що дозволить розробникам запускати мости за запитом, передавати активи без сліпіджу та отримувати більшу програмованість. Це оновлення підвищує стандарти безпеки крос-чейн Gravity і зручність для розробників.
Q5: Які основні функції токена G?
G — нативний газ-токен і токен стейкінгу для Gravity L1. Валідатори стейкають G для участі у консенсусі та атестації власного оракулу. Власники G приймають рішення у governance через протокол G DAO, а G також використовується як платіжний і мотиваційний токен у екосистемі Galxe.
