Como funciona a infraestrutura cross-chain? Análise aprofundada do Protocolo de Interoperabilidade Gravity e da arquitetura de oráculo nativo.

O cenário de fragmentação da indústria de blockchain já é um fato repetidamente afirmado. Dezenas de blockchains públicas como Ethereum, Solana, Cosmos, Arbitrum, entre outras, coexistem com L2s, cada uma com seu próprio sistema de contas, armazenamento de estado e regras de consenso. Pontes de ativos entre cadeias e protocolos de mensagens entre cadeias surgiram em profusão nos últimos anos, mas uma questão estrutural fundamental permanece sem solução: quem, afinal, autentica os dados entre cadeias?

A grande maioria das L1s "terceiriza" a responsabilidade de verificação de oráculos ou pontes para redes externas — uma rede de oráculo externa assina os dados, ou um comitê multisig independente prova eventos de depósito. A cadeia em si permanece "limpa", mas uma nova suposição de confiança é anexada na lateral. Uma vez que o canal lateral seja comprometido, a cadeia continua operando, mas os dados na cadeia já estão incorretos.

Gravity oferece uma resposta arquitetural radicalmente diferente. Desenvolvida pela equipe Galxe, Gravity é uma blockchain Layer 1 de alto desempenho e totalmente compatível com EVM, cujo diferencial central é o Oráculo Nativo (Native Oracle) — o mesmo conjunto de validadores que gera blocos sob o consenso AptosBFT também observa dados externos, vota e os escreve na L1. Não há rede de oráculo externa, nem comitê multisig independente. A ponte entre cadeias não é um serviço separado, mas um contrato que recebe dados já submetidos pelo conjunto de validadores.

Este é o significado de "nativo": o pipeline de prova do validador é parte da máquina de estado da cadeia, não um serviço executado ao lado. Qualquer dado que chegue através do Oráculo Nativo tem segurança equivalente à da própria cadeia — o mesmo conjunto de validadores, o mesmo limite BFT, a mesma janela de finalidade.

Em junho de 2026, a mainnet Gravity L1 foi oficialmente lançada, marcando a transição desta arquitetura da teoria para a produção. Este artigo irá desconstruir sistematicamente o mecanismo do protocolo de interoperabilidade do Gravity em quatro dimensões: transmissão de mensagens entre cadeias, roteamento de liquidez, modelo de verificação e segurança, e o fluxo completo de ativos entre cadeias.

Mecanismo de Transmissão de Mensagens entre Cadeias: Mudança de Paradigma de "Puxar" para "Empurrar"

A transmissão de mensagens entre cadeias é a camada base de todos os protocolos de interoperabilidade. Sua questão central pode ser simplificada: como a Cadeia A prova para a Cadeia B que "algo aconteceu"?

No design tradicional de pontes entre cadeias, o usuário deposita ativos em um contrato na cadeia de origem, e um grupo de relés externos monitora o evento e cunha ativos correspondentes na cadeia de destino. Este modelo depende da honestidade e disponibilidade dos relés, e frequentemente exige que o usuário aguarde múltiplas confirmações de bloco para reduzir o risco de reorganização.

O mecanismo de transmissão de mensagens do Gravity é construído sobre seu Oráculo Nativo, alterando fundamentalmente este fluxo. O Oráculo Nativo é um contrato único implantado em um endereço de sistema fixo na Gravity L1: NativeOracle → 0x0000000000000000000000000001625F4000. Este contrato expõe uma operação central, record, que só pode ser chamada por SYSTEM_CALLER — uma identidade de consenso privilegiada, não uma conta comum.

A função record recebe os seguintes parâmetros: tipo de origem (sourceType, ex.: blockchain), ID de origem (sourceId, ex.: chainID), nonce, número do bloco de origem, payload (bloco binário opaco) e limite de gas para callback. Há também uma variante recordBatch para entregar múltiplos eventos da mesma origem em uma única transação.

Três escolhas de design merecem destaque:

Primeiro, centralização da proteção contra replay. O Oráculo Nativo impõe strictamente para cada par (sourceType, sourceId) que nonce == currentNonce + 1 — sequencial estrito, sem saltos. Mensagens antigas nunca podem ser reproduzidas porque o contrato já avançou seu nonce. Os processadores da camada de aplicação não precisam manter seus próprios mapas de nonces processados. Isso significa que a lógica de desduplicação de mensagens entre cadeias é elevada ao nível do protocolo, em vez de ser deixada para cada contrato de aplicação implementar por conta própria — reduzindo significativamente a carga de segurança para desenvolvedores de aplicações.

Segundo, roteamento via callback em vez de polling. Cada par (sourceType, sourceId) pode registrar um contrato de callback. Quando os dados são registrados, o Oráculo Nativo chama a função onOracleEvent do processador registrado com o limite de gas especificado pelo chamador. A resolução é em duas camadas: um processador padrão para cada tipo de origem, que pode ser substituído por um processador especializado para um sourceId específico. A governança gerencia o registro. Este modelo de "push" permite que os contratos de aplicação sejam notificados e executem a lógica correspondente assim que os dados entre cadeias chegam, sem necessidade de polling contínuo do estado.

Terceiro, design tolerante a falhas no callback. O processador retorna shouldStore: bool — processadores que consomem completamente o payload (já aplicado ao seu próprio estado) podem retornar false para pular o armazenamento e economizar gas. Se o processador reverter ou ficar sem gas, o Oráculo Nativo captura a exceção, emite um evento CallbackFailed(reason) e ainda armazena o payload. A operação de registro sempre tem sucesso de qualquer forma.

Este design alcança uma clara separação de responsabilidades: o Oráculo Nativo cuida da verdade (prova de consenso, proteção contra replay), e os contratos de aplicação cuidam do significado (decodificação e execução). A autenticidade das mensagens entre cadeias é garantida pelo conjunto de validadores do Gravity com finalidade BFT, e não por uma rede de relés externa.

Modelo de Verificação e Segurança: A Mesma Fechadura, a Mesma Chave

As diferenças no modelo de segurança são a dimensão central que distingue a qualidade dos protocolos entre cadeias. A arquitetura de segurança do Gravity pode ser resumida em uma frase: a segurança do Oráculo Nativo é equivalente à segurança da própria cadeia.

Especificamente, o Gravity adota um mecanismo de validação Proof-of-Stake, onde os validadores fazem staking de tokens G para participar do consenso e da prova do Oráculo Nativo. O motor de consenso é o AptosBFT, fornecendo finalidade rápida. O conjunto de validadores garante a segurança da cadeia com um limite de dois terços — o mesmo limite também garante a autenticidade dos dados do Oráculo Nativo.

O que isso significa?

Na maioria das cadeias, falhas de oráculo ou ponte são frequentemente "invisíveis" — anomalias na rede de verificação externa podem passar despercebidas por muito tempo antes de causar grandes perdas. No Gravity, a segurança do oráculo é equivalente à segurança da própria cadeia. Um atacante que deseje submeter dados falsos entre cadeias precisaria controlar mais de um terço dos validadores — o que também significaria ser capaz de atacar a própria cadeia. Não existe um "canal lateral mais fraco" que um atacante possa explorar a um custo menor.

Do ponto de vista da transferência de ativos entre cadeias, este modelo elimina o risco de "assinantes externos" das pontes tradicionais. A ponte tradicional Ethereum→Cosmos Gravity consiste em duas partes: contratos inteligentes Solidity implantados na Ethereum e um módulo blockchain Cosmos SDK. O usuário deposita ativos de um lado e o token correspondente é cunhado do outro. Mas, sob a arquitetura de Oráculo Nativo do Gravity L1, a ponte de ativos Ethereum→Gravity L1 é o primeiro aplicativo de produção do Oráculo Nativo. Não há rede de oráculo externa, nem conjunto de assinantes independente sobreposto ao consenso.

Vale notar que o Gravity também está realizando atualizações importantes em sua arquitetura de segurança. Em junho de 2026, o Gravity anunciou que, durante o lançamento de sua L1, fará upgrade do LayerZero para o Chainlink CCIP como sua infraestrutura de ponte padronizada. O token nativo do Gravity, G, se tornará um ativo nativo entre cadeias (CCT), oferecendo aos desenvolvedores implantação autônoma, transferências sem slippage e maior programabilidade. O CCIP, apoiado por sua rede de oráculo descentralizada, aumentará significativamente a capacidade dos desenvolvedores da rede Gravity de construir aplicativos seguros entre cadeias. Esta atualização mostra que, enquanto mantém a vantagem central do Oráculo Nativo, o Gravity também está integrando ativamente os padrões de ponte entre cadeias mais maduros da indústria.

Fluxo Completo de Ativos entre Cadeias: Oito Passos do Depósito à Liquidação

Com base nos mecanismos acima, uma transferência completa de ativos entre cadeias (usando Ethereum→Gravity L1 como exemplo) pode ser decomposta no seguinte fluxo:

Primeiro passo: O usuário bloqueia ativos. O usuário deposita ETH ou tokens ERC-20 no contrato de ponte do Gravity na Ethereum. O contrato registra o evento de depósito, incluindo endereço do usuário, tipo de ativo, quantidade e informações da cadeia de destino.

Segundo passo: Finalização do bloco Ethereum. Os nós validadores do Gravity monitoram continuamente a cadeia Ethereum. Os validadores não dependem de relés externos para enviar dados; eles mesmos observam o estado da Ethereum.

Terceiro passo: Votação de consenso dos validadores. Em cada bloco do Gravity L1, os validadores assinam e transmitem os dados externos que observaram (incluindo eventos de depósito da Ethereum) como parte do payload do Oráculo Nativo. A assinatura dos validadores para esses dados externos usa exatamente as mesmas chaves e o mesmo limite que a assinatura para transações da própria cadeia Gravity.

Quarto passo: Submissão dos dados ao Oráculo Nativo. Uma vez que o conjunto de validadores atinge consenso sobre um evento externo (atingindo o limite de dois terços), os dados são escritos no contrato do Oráculo Nativo no Gravity L1 através da chamada record ou recordBatch.

Quinto passo: Verificação de nonce e proteção contra replay. O contrato do Oráculo Nativo verifica se o nonce do evento é estritamente incremental. Se o nonce não corresponder (submissão duplicada ou salto), o registro é rejeitado.

Sexto passo: Gatilho de callback. O contrato da ponte de ativos, como processador de callback registrado, recebe a chamada onOracleEvent. O contrato decodifica o payload, verifica o tipo e quantidade do ativo, e confirma o endereço de destino.

Sétimo passo: Cunhagem ou liberação de ativos. O contrato da ponte de ativos cunha a quantidade correspondente de ativos encapsulados do token G no Gravity L1 (ou no cenário de ponte de ativos nativa, libera G diretamente) e transfere para o endereço do usuário na cadeia Gravity.

Oitavo passo: Confirmação de finalidade. Todo o processo obtém finalidade subsegundo sob o consenso AptosBFT do Gravity. O usuário pode receber os ativos entre cadeias dentro do tempo de bloco de 200 milissegundos.

A característica chave deste fluxo completo é: nenhum passo depende de relés externos ou assinantes independentes. Da observação de dados à votação, escrita e execução, tudo é feito pelo mesmo conjunto de validadores sob as mesmas suposições de segurança.

Base de Desempenho: 12.000+ TPS e Finalidade Subsegundo

O valor do design de mecanismo precisa de uma base de desempenho para suportá-lo. Os parâmetros de desempenho do Gravity fornecem viabilidade prática para sua interoperabilidade entre cadeias:

A mainnet Gravity usa o motor de execução EVM paralelo Grevm (forkado do revm). Sob carga de trabalho em tempo real, o Gravity pode manter uma taxa de transferência de 12.000+ TPS para transferências ERC-20, com tempo de bloco de 200 ms. Em testes reais com um cluster de 3 nós validadores (8 vCPU / 16 GB cada), a taxa de transferência foi mantida em aproximadamente 9.500–11.000 TPS.

Mais digno de nota é sua estrutura de taxas. Com uma taxa base de 50 Gwei, o espaço de bloco no Gravity torna-se funcionalmente um bem público, em vez de um ativo competitivo. O custo de cada transferência ERC-20 é de aproximadamente $0,0026. Isso quebra o modelo econômico padrão de L1, que depende da pressão de taxas como principal mecanismo de acumulação de valor do token. A captura de valor se desloca para os serviços fornecidos pelos validadores (provas de oráculo, dados entre cadeias, pontes) e para a camada de aplicação.

Para cenários entre cadeias, taxas baixas significam que transações de alta frequência são economicamente viáveis; finalidade subsegundo significa que a experiência do usuário entre cadeias se aproxima da experiência intralivrete.

Olhando para dados históricos, desde que a Gravity Alpha Mainnet foi lançada em agosto de 2024 como uma L2 baseada no Arbitrum Nitro, em 22 meses processou mais de 611 milhões de transações, cobrindo 28,5 milhões de carteiras, com tempo médio de bloco de 1,3 segundos. Isso constitui uma validação em produção para o lançamento da L1.

Dados de Mercado e Economia de Token

Em 29 de junho de 2026, de acordo com dados de preços da Gate, Gravity (G) estava cotado a $0,003641, com alta de +13,78% nas últimas 24 horas, alta de +36,62% nos últimos 7 dias e alta de +3,72% nos últimos 30 dias. A capitalização de mercado era de aproximadamente $26,334 milhões, classificada em 658º lugar. O volume de negociação em 24 horas era de $29,1978 milhões, com uma oferta total de 12,0 bilhões. O sentimento do mercado era neutro. A variação de preço no último ano foi de -69,22%, com o preço histórico máximo de $0,015440.

G é o token nativo do Gravity L1, com suprimento máximo de 12 bilhões, migrado do token original GAL. No lançamento da mainnet, 7 validadores iniciais receberam uma alocação inicial de staking de 7 milhões de G. Os correspondentes 7 milhões de G foram bloqueados permanentemente no contrato GBridgeSender da ponte padrão na Ethereum mainnet para suportar o G nativo na L1.

G funciona como token de gas para transações, garante a segurança da rede através de staking, e impulsiona decisões de governança, incentiva o crescimento e facilita pagamentos. Os detentores de G governam as decisões do protocolo através do G DAO.

Conclusão: O Fim da Interoperabilidade é a Unificação da Confiança

A evolução da interoperabilidade entre cadeias pode ser dividida em três estágios.

O primeiro estágio são as pontes de ativos, onde o usuário transfere ativos da Cadeia A para a Cadeia B, dependendo de provas de validadores externos ou nós leves.

O segundo estágio são protocolos de mensagens universais (como LayerZero, Axelar), que suportam chamadas de contratos inteligentes entre cadeias, mas a lógica de verificação ainda depende de uma combinação de oráculos externos e relés.

O terceiro estágio é a interoperabilidade em nível de protocolo — o conjunto de validadores é responsável tanto pela transição de estado da cadeia quanto pela prova de dados entre cadeias, comprimindo as suposições de confiança externas para o mesmo perímetro de segurança que a própria cadeia.

A arquitetura de Oráculo Nativo do Gravity representa uma implementação de engenharia do terceiro estágio. Não é uma otimização incremental dos modelos de ponte existentes, mas sim uma reconstrução fundamental da resposta à pergunta "quem autentica os dados entre cadeias". Quando a segurança dos dados entre cadeias e a segurança da própria L1 são garantidas pelo mesmo conjunto de validadores e pelo mesmo limite BFT, a lacuna de confiança entre "entre cadeias" e "intralivrete" é drasticamente reduzida.

Isso não significa que o Gravity elimina todos os riscos. O grau de centralização do conjunto de validadores, a estabilidade de cauda longa do modelo econômico de staking, os riscos de código dos contratos entre cadeias e os desafios de engenharia durante a migração do LayerZero para o Chainlink CCIP são dimensões que precisam de observação contínua. Além disso, em maio de 2026, a Gravity Bridge sofreu um ataque com perdas de aproximadamente $5,4 milhões, o que lembra ao mercado: mesmo a arquitetura entre cadeias mais bem projetada ainda precisa passar por testes práticos suficientemente longos.

Mas a direção é clara: o fim da interoperabilidade não são mais pontes, mas menos suposições de confiança. Se o Gravity pode se tornar a infraestrutura representativa desse fim dependerá do processo de descentralização dos validadores após o lançamento de sua mainnet, da velocidade de migração dos aplicativos do ecossistema e da resiliência do Oráculo Nativo sob ataques reais. Para pesquisadores e desenvolvedores focados na área de pontes entre cadeias, a escolha arquitetural do Gravity oferece um modelo que vale a pena ser acompanhado continuamente.

FAQ

Q1: Qual é a principal diferença entre Gravity e protocolos de ponte como LayerZero e Axelar?

LayerZero baseia-se na arquitetura de nó ultraleve (ULN), onde Oracle e Relayer validam conjuntamente mensagens entre cadeias; Axelar adota uma rede de validação PoS independente com mecanismo de mensagens universais (GMP). Gravity incorpora a verificação de dados entre cadeias diretamente na camada de consenso da L1, onde o mesmo conjunto de validadores garante tanto o estado da cadeia quanto a autenticidade dos dados entre cadeias com o mesmo limite BFT.

Q2: Como o Oráculo Nativo do Gravity garante a segurança dos dados entre cadeias?

O Oráculo Nativo não possui rede externa ou comitê multisig. Os validadores observam dados externos, votam e escrevem na L1 sob o consenso AptosBFT. A autenticidade dos dados é garantida pelo limite de dois terços do conjunto de validadores — exatamente igual à segurança da própria cadeia. O custo de atacar dados falsos entre cadeias é equivalente ao custo de atacar a própria cadeia.

Q3: Quais são os parâmetros de desempenho atuais do Gravity?

O Gravity L1 mantém uma taxa de transferência de 12.000+ TPS para transferências ERC-20 sob carga de trabalho em tempo real, com tempo de bloco de 200 ms e finalidade subsegundo. O custo de cada transferência ERC-20 é de aproximadamente $0,0026. A Alpha Mainnet processou mais de 611 milhões de transações em 22 meses.

Q4: O que significa a atualização do Gravity do LayerZero para o Chainlink CCIP?

Em junho de 2026, o Gravity anunciou o Chainlink CCIP como sua infraestrutura de ponte padronizada. G se tornará um ativo nativo entre cadeias (CCT), permitindo que desenvolvedores obtenham implantação autônoma, transferências sem slippage e maior programabilidade. Isso eleva os padrões de segurança e facilidade de desenvolvimento para aplicações entre cadeias no Gravity.

Q5: Quais são as principais funções do token G?

G é o token nativo de gas e staking do Gravity L1. Validadores fazem staking de G para participar do consenso e da prova do Oráculo Nativo. Detentores de G governam as decisões do protocolo através do G DAO, e G também serve como token de pagamento e incentivo no ecossistema Galxe.