Фрагментированная структура блокчейн-индустрии — давно признанный факт. Десятки публичных сетей и решений второго уровня, включая 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, например, блокчейн), идентификатор источника (sourceId, например, chain ID), nonce, номер блока в исходной сети, payload (непрозрачный бинарный блок данных) и лимит газа для обратного вызова. Также предусмотрен вариант recordBatch для передачи нескольких событий от одного источника в рамках одной транзакции.
Три ключевых архитектурных решения:
Во-первых, централизованная защита от повторов. Встроенный оракул требует, чтобы для каждой пары (sourceType, sourceId) выполнялось условие nonce == currentNonce + 1, обеспечивая строгую последовательность без пропусков. Старые сообщения не могут быть воспроизведены, так как контракт уже перешёл к следующему nonce. Контрактам приложений больше не нужно самостоятельно отслеживать обработанные nonce. Таким образом, логика дедупликации кроссчейн-сообщений поднимается на уровень протокола, что существенно снижает нагрузку на разработчиков с точки зрения безопасности.
Во-вторых, маршрутизация обратных вызовов вместо опроса. Для каждой пары (sourceType, sourceId) можно зарегистрировать контракт-обработчик. При поступлении данных встроенный оракул вызывает функцию onOracleEvent у зарегистрированного обработчика, используя указанный лимит газа. Предусмотрены два уровня парсинга: обработчик по умолчанию для типа источника и специализированный обработчик для конкретного sourceId. Реестр управляется через голосование. Такая push-модель позволяет контрактам приложений мгновенно получать уведомления и выполнять логику при поступлении кроссчейн-данных, устраняя необходимость постоянного опроса состояния.
В-третьих, устойчивость к ошибкам при обратных вызовах. Обработчик возвращает shouldStore: bool — если payload полностью обработан (и применён к состоянию), можно вернуть false, чтобы не сохранять данные и сэкономить газ. Если обработчик завершится с ошибкой или исчерпает лимит газа, встроенный оракул перехватит исключение, зафиксирует событие CallbackFailed(reason) и всё равно сохранит payload. Операция записи всегда завершается успешно.
Такая архитектура обеспечивает чёткое разделение ответственности: встроенный оракул отвечает за достоверность (консенсусное подтверждение, защиту от повторов), а контракты приложений — за интерпретацию и выполнение. Подлинность кроссчейн-сообщений гарантируется валидаторами Gravity с BFT-финализацией, а не внешней сетью ретрансляторов.
Модель валидации и безопасности: один замок — один ключ
Модель безопасности — главный отличительный признак кроссчейн-протоколов. В Gravity её можно описать одной фразой: безопасность встроенного оракула эквивалентна безопасности самой сети.
Gravity использует механизм валидации на основе Proof-of-Stake. Валидаторы стейкают токены G для участия в консенсусе и подтверждении данных встроенного оракула. За консенсус отвечает движок AptosBFT, обеспечивающий высокоскоростную финализацию. Безопасность сети поддерживается порогом в две трети валидаторов — тот же порог гарантирует подлинность данных встроенного оракула.
Что это означает?
На большинстве сетей сбои в работе оракулов или кроссчейн-мостов часто остаются «невидимыми» — аномалии во внешних сетях валидации могут не обнаруживаться длительное время, вплоть до катастрофических потерь. В Gravity безопасность оракула идентична безопасности самой сети. Для внесения ложных кроссчейн-данных злоумышленнику нужно контролировать более трети валидаторов — а значит, он сможет атаковать и сам блокчейн. Здесь нет «слабого бокового канала», который можно скомпрометировать с меньшими затратами.
С точки зрения кроссчейн-активов, такая модель устраняет риск «внешнего подписанта», характерный для традиционных мостов. Классический мост Ethereum→Cosmos Gravity состоит из двух компонентов: смарт-контракта на 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 в контракт моста Gravity на Ethereum. Контракт фиксирует событие депозита, включая адрес пользователя, тип актива, сумму и данные о целевой сети.
Шаг 2. Финализация блока в Ethereum. Узлы-валидаторы Gravity непрерывно отслеживают состояние сети Ethereum. Для этого не используются внешние ретрансляторы — валидаторы самостоятельно наблюдают за состоянием Ethereum.
Шаг 3. Голосование валидаторов по консенсусу. В каждом блоке Gravity L1 валидаторы подписывают и транслируют внешние данные (включая события депозита в Ethereum) как часть payload встроенного оракула. Для таких данных используются те же ключи и пороги, что и для собственных транзакций Gravity.
Шаг 4. Передача данных во встроенный оракул. После достижения консенсуса по внешнему событию (две трети валидаторов) данные записываются в контракт встроенного оракула Gravity L1 через вызов record или recordBatch.
Шаг 5. Проверка nonce и защита от повторов. Контракт встроенного оракула проверяет строго возрастающий nonce события. Если nonce не совпадает (из-за дублирования или пропуска), запись отклоняется.
Шаг 6. Запуск обратного вызова. Контракт моста активов, зарегистрированный как обработчик, получает вызов onOracleEvent. Контракт декодирует payload, проверяет тип и сумму актива, а также адрес получателя.
Шаг 7. Выпуск или разблокировка активов. Контракт моста выпускает соответствующее количество токенизированных активов G на Gravity L1 (или напрямую переводит G в случае нативного моста) и отправляет их на адрес пользователя в Gravity.
Шаг 8. Подтверждение финализации. Весь процесс завершается с финализацией менее чем за секунду благодаря консенсусу AptosBFT. Пользователь получает кроссчейн-активы в течение 200 миллисекунд после формирования блока.
Ключевая особенность: на протяжении всего процесса не используется ни один внешний ретранслятор или независимый подписант. От наблюдения до голосования, записи и исполнения — все этапы выполняет единый набор валидаторов под единой моделью безопасности.
Производительность: 12 000+ TPS и финализация менее секунды
Эффективность этой архитектуры обеспечивается высокой производительностью. Технические параметры Gravity делают кроссчейн-взаимодействие практически реализуемым:
Основная сеть Gravity использует параллельный движок исполнения Grevm (форк revm). В реальных условиях Gravity стабильно обрабатывает более 12 000 TPS для переводов ERC-20 при времени блока 200 миллисекунд. В тестах на кластере из трёх валидаторов (8 vCPU / 16 ГБ на узел) производительность сохранялась на уровне 9 500–11 000 TPS.
Особого внимания заслуживает структура комиссий. При базовой комиссии 50 Gwei пространство блоков Gravity становится по сути общественным благом, а не конкурентным ресурсом. Каждый перевод ERC-20 обходится примерно в $0,0026. Это ломает стандартную экономическую модель L1, основанную на росте стоимости токена за счёт комиссий. Захват ценности смещается в сторону сервисов валидаторов (оракульные подтверждения, кроссчейн-данные, мосты) и приложений.
В кроссчейн-сценариях низкие комиссии делают возможными частые межсетевые транзакции, а финализация менее секунды приближает пользовательский опыт кроссчейн-переводов к операциям внутри одной сети.
С момента запуска Gravity Alpha mainnet на базе Arbitrum Nitro в августе 2024 года сеть обработала более 611 миллионов транзакций для 28,5 миллионов кошельков за 22 месяца при среднем времени блока 1,3 секунды. Это служит промышленным подтверждением готовности L1 mainnet.
Рыночные данные и токеномика
По состоянию на 29 июня 2026 года, согласно данным Gate, токен Gravity (G) торгуется по цене $0,003641. За 24 часа рост составил +13,78 %, за 7 дней — +36,62 %, за 30 дней — +3,72 %. Рыночная капитализация — примерно $26,33 млн, 658 место в рейтинге. Объём торгов за сутки — $29,20 млн, общий объём предложения — 12 млрд токенов. Рыночное настроение — нейтральное. За год цена изменилась на -69,22 %, абсолютный максимум — $0,015440.
G — нативный токен Gravity L1 с максимальным объёмом предложения 12 млрд, мигрировавший с оригинального GAL. При запуске основной сети семь генезис-валидаторов получили по 7 млн G для стейкинга. Соответствующие 7 млн G навсегда заблокированы в контракте GBridgeSender в основной сети Ethereum для поддержки нативного G на L1.
G используется как газовый токен для транзакций, обеспечивает безопасность сети через стейкинг, участвует в управлении, стимулирует рост и служит средством платежа. Владельцы G принимают участие в управлении через протокол 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 принимают решения по управлению через протокол G DAO, а также используют G как платёжный и стимулирующий токен в экосистеме Galxe.
