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

O panorama fragmentado da indústria blockchain é um facto repetidamente afirmado. Dezenas de blockchains públicas e L2, como Ethereum, Solana, Cosmos e Arbitrum, coexistem, cada uma com o seu próprio sistema de contas, armazenamento de estado e regras de consenso. Pontes de ativos entre cadeias e protocolos de mensagens entre cadeias têm surgido em abundância nos últimos anos, mas uma questão estrutural fundamental continua por resolver: quem certifica, de facto, os dados entre cadeias?

A maioria das L1 delega a responsabilidade de verificação de oráculos ou pontes a redes externas fora da cadeia — uma rede de oráculos externa assina os dados, ou um comité multisig independente prova eventos de depósito. A cadeia em si mantém-se "limpa", mas uma nova hipótese de confiança é adicionada na periferia. Assim que o canal lateral é comprometido, a cadeia continua a funcionar, mas os dados na cadeia já estão corrompidos.

A Gravity oferece uma resposta arquitetónica radicalmente diferente. Desenvolvida pela equipa Galxe, a Gravity é uma blockchain Layer 1 de alto desempenho, totalmente compatível com EVM, cuja principal diferença reside no Oráculo Nativo — o mesmo conjunto de validadores que gera blocos sob o consenso AptosBFT também observa dados externos, vota e escreve na L1. Não há rede de oráculos externa, nem comité multisig independente. A ponte entre cadeias não é um serviço separado, mas sim um contrato que recebe dados já submetidos pelo conjunto de validadores.

É este o significado de "nativo": o pipeline de prova do validador faz parte da máquina de estados da cadeia, não um serviço executado em paralelo. Qualquer dado que chegue através do oráculo nativo tem a mesma segurança que a própria cadeia — o mesmo conjunto de validadores, o mesmo limite BFT, a mesma janela de finalidade.

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

Mecanismo de Passagem de Mensagens Entre Cadeias: Mudança de Paradigma de "Pull" para "Push"

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

No design tradicional de pontes entre cadeias, os utilizadores depositam ativos num contrato na cadeia de origem, e um conjunto de retransmissores externos, ao detetar esse evento, cunha os ativos correspondentes na cadeia de destino. Este modelo depende da honestidade e disponibilidade dos retransmissores, exigindo frequentemente que os utilizadores aguardem várias confirmações de blocos para reduzir o risco de reorganização.

O mecanismo de passagem de mensagens da Gravity baseia-se no seu oráculo nativo, alterando fundamentalmente este processo. O oráculo nativo é um contrato único implantado num endereço de sistema fixo na L1 da Gravity: NativeOracle → 0x0000000000000000000000000001625F4000. Este contrato expõe uma operação central, record, que só pode ser chamada por SYSTEM_CALLER — uma identidade privilegiada em tempo de consenso, não uma conta normal.

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

Três escolhas de design críticas merecem destaque:

Primeiro, centralização da proteção contra replay. O oráculo nativo exige, para cada par (sourceType, sourceId), que nonce == currentNonce + 1 — estritamente sequencial, sem saltos permitidos. Mensagens antigas nunca podem ser repetidas, pois o contrato já ultrapassou o seu nonce. Os processadores da camada de aplicação não precisam de manter os seus próprios mapas de nonces processados. Isto 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 si só — reduzindo significativamente a carga de segurança para os desenvolvedores de aplicações.

Segundo, encaminhamento por callback em vez de polling. Para cada par (sourceType, sourceId), pode ser registado um contrato de callback. Quando os dados são registados, o oráculo nativo chama a função onOracleEvent do processador registado, com o limite de gas especificado pelo chamador. A resolução é feita em duas camadas: um processador padrão para cada tipo de fonte, que pode ser substituído por um processador especializado para um sourceId específico. A governança é responsável pela gestão do registo. 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 de callback. O processador retorna shouldStore: bool — um processador que consome completamente o payload (aplicou-o ao seu próprio estado) pode retornar false para saltar o armazenamento e poupar gas. Se o processador reverter ou ficar sem gas, o oráculo nativo captura a exceção, emite um evento CallbackFailed(reason) e ainda assim armazena o payload. A operação record é sempre bem-sucedida.

Este design implementa uma clara separação de preocupações: o oráculo nativo é responsável pela verdade (prova de consenso, proteção contra replay), e os contratos de aplicação são responsáveis pelo significado (descodificação e execução). A autenticidade das mensagens entre cadeias é garantida pelo conjunto de validadores da Gravity com finalidade BFT, em vez de depender de uma rede de retransmissores externa.

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

A diferença no modelo de segurança é a dimensão central que distingue a qualidade dos protocolos entre cadeias. A arquitetura de segurança da Gravity pode ser resumida numa frase: a segurança do oráculo nativo é igual à segurança da própria cadeia.

Especificamente, a Gravity emprega um mecanismo de verificação Proof-of-Stake, onde os validadores fazem staking de tokens G para participar no consenso e na prova do oráculo nativo. O motor de consenso é o AptosBFT, que proporciona finalidade de alta velocidade. O conjunto de validadores garante a segurança da cadeia com um limite de dois terços — o mesmo limite que garante a autenticidade dos dados do oráculo nativo.

O que é que isto significa?

Na maioria das cadeias, as falhas de oráculos ou pontes são frequentemente "invisíveis" — anomalias na rede de verificação externa podem passar despercebidas durante muito tempo antes de causarem perdas significativas. Na Gravity, a segurança do oráculo é equivalente à segurança da própria cadeia. Um atacante que pretenda submeter dados falsos entre cadeias precisa de controlar mais de um terço dos validadores — o que significa que também poderia atacar a própria cadeia. Não existe um "canal lateral mais fraco" que o 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 é composta por duas partes: um contrato inteligente Solidity implantado no Ethereum e um módulo blockchain Cosmos SDK. Os utilizadores depositam ativos de um lado e o token correspondente é cunhado do outro. Mas na arquitetura do oráculo nativo da Gravity L1, a ponte de ativos Ethereum→Gravity L1 é a primeira aplicação de produção do oráculo nativo. Não há rede de oráculos externa, nem conjunto de signatários independente sobreposto ao consenso.

Vale a pena notar que a Gravity está também a realizar atualizações importantes na sua arquitetura de segurança. Em junho de 2026, a Gravity anunciou que, durante o lançamento da sua blockchain L1, iria atualizar do LayerZero para o Chainlink CCIP como sua infraestrutura de ponte entre cadeias normalizada. O token nativo da Gravity, G, tornar-se-á um ativo nativo entre cadeias (CCT), oferecendo aos desenvolvedores implantação autónoma, transferências sem slippage e maior programabilidade. O CCIP, apoiado pela sua rede de oráculos descentralizada, aumentará significativamente a capacidade dos desenvolvedores na rede Gravity de construir aplicações seguras entre cadeias. Esta atualização mostra que a Gravity, mantendo as vantagens principais do seu oráculo nativo, está também a integrar ativamente os padrões entre cadeias mais maduros da indústria.

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

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

Passo 1: O utilizador bloqueia os ativos. O utilizador deposita ETH ou tokens ERC-20 no contrato da ponte da Gravity no Ethereum. O contrato regista o evento de depósito, incluindo o endereço do utilizador, tipo de ativo, quantidade e informações da cadeia de destino.

Passo 2: Finalização do bloco Ethereum. Os nós validadores da Gravity monitorizam continuamente a cadeia Ethereum. Os validadores não dependem de retransmissores externos para enviar dados; observam eles próprios o estado do Ethereum.

Passo 3: Votação de consenso dos validadores. Em cada bloco da Gravity L1, os validadores assinam e transmitem os dados externos que observaram (incluindo eventos de depósito do Ethereum) como parte do payload do oráculo nativo. A assinatura destes dados externos pelos validadores utiliza exatamente as mesmas chaves e o mesmo limite que a assinatura das suas próprias transações na Gravity.

Passo 4: Submissão de dados ao oráculo nativo. Assim que o conjunto de validadores atinge consenso sobre um determinado evento externo (atingindo o limite de dois terços), os dados são escritos no contrato do oráculo nativo da Gravity L1 através de uma chamada record ou recordBatch.

Passo 5: Verificação de nonce e proteção contra replay. O contrato do oráculo nativo verifica se o nonce do evento é estritamente crescente. Se o nonce não corresponder (submissão duplicada ou salto), o registo é rejeitado.

Passo 6: Acionamento do callback. O contrato da ponte de ativos, como processador de callback registado, recebe a chamada onOracleEvent. O contrato descodifica o payload, verifica o tipo e quantidade de ativo e confirma o endereço de destino.

Passo 7: Cunhagem ou libertação de ativos. O contrato da ponte de ativos cunha na Gravity L1 a quantidade correspondente de ativos encapsulados do token G (ou, no cenário de ponte de ativos nativos, liberta diretamente G) e transfere para o endereço do utilizador na cadeia Gravity.

Passo 8: Confirmação de finalidade. Todo o processo obtém finalidade subsegundo sob o consenso AptosBFT da Gravity. O utilizador pode receber os ativos entre cadeias dentro do tempo de bloco de 200 milissegundos.

A característica fundamental deste fluxo completo é: nenhum passo depende de retransmissores externos ou signatários independentes. Desde a observação de dados, passando pela votação, escrita e execução, tudo é realizado pelo mesmo conjunto de validadores com o mesmo conjunto de pressupostos de segurança.

Base de Desempenho: 12 000+ TPS e Finalidade Subsegundo

O valor do design de mecanismos precisa de uma base de desempenho para se tornar viável. Os parâmetros de desempenho da Gravity fornecem viabilidade prática para a sua interoperabilidade entre cadeias:

A mainnet Gravity utiliza o motor de execução EVM paralelo Grevm (fork do revm). Sob carga de trabalho em tempo real, a Gravity pode sustentar uma produção de 12 000+ TPS em transferências ERC-20, com um tempo de bloco de 200 milissegundos. Em testes com um cluster de 3 nós validadores (8 vCPU / 16 GB cada), a produção manteve-se em cerca de 9 500–11 000 TPS.

Mais notável é a sua estrutura de taxas. Uma taxa base de 50 Gwei torna o espaço de blocos na Gravity funcionalmente um bem público, em vez de um ativo competitivo. O custo de cada transferência ERC-20 é de aproximadamente $0,0026. Isto quebra o modelo económico padrão das L1 — que depende da pressão das taxas como principal acumulação de valor do token. A captura de valor desloca-se para os serviços fornecidos pelos validadores (prova de oráculo, dados entre cadeias, ponte) e para a camada de aplicação.

Para cenários entre cadeias, taxas baixas tornam as transações frequentes entre cadeias economicamente viáveis; finalidade subsegundo significa que a experiência do utilizador entre cadeias se aproxima das transações dentro da cadeia.

Historicamente, desde o lançamento da Gravity Alpha Mainnet em agosto de 2024 como uma L2 baseada em Arbitrum Nitro, processou mais de 611 milhões de transações em 22 meses, abrangendo 28,5 milhões de carteiras, com um tempo médio de bloco de 1,3 segundos. Isto constitui uma validação a nível de produção para o lançamento da mainnet L1.

Dados de Mercado e Economia do Token

De acordo com dados do Gate em 29 de junho de 2026, o preço do Gravity (G) é de $0,003641, com uma subida de +13,78% nas últimas 24 horas, +36,62% nos últimos 7 dias e +3,72% nos últimos 30 dias. A capitalização de mercado é de aproximadamente $26,33 milhões, classificando-se na 658.ª posição. O volume de negociação nas 24 horas é de $29,20 milhões, com uma oferta total de 12,00 mil milhões. O sentimento do mercado é neutro. A variação de preço no último ano é de -69,22%, com um máximo histórico de $0,015440.

G é o token nativo da Gravity L1, com uma oferta máxima de 12 mil milhões, migrado do token GAL original. 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 canónica na mainnet Ethereum 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 decidem sobre o protocolo através da governança da 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 fases.

A primeira fase são as pontes de ativos, onde os utilizadores transferem ativos da Cadeia A para a Cadeia B, dependendo de validadores externos ou provas de nós ligeiros.

A segunda fase são os 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 retransmissores.

A terceira fase é a interoperabilidade a nível de protocolo — o conjunto de validadores é responsável tanto pela transição de estado da cadeia como pela prova de dados entre cadeias, comprimindo as hipóteses de confiança externas para os mesmos limites de segurança que a própria cadeia.

A arquitetura do oráculo nativo da Gravity representa uma implementação de engenharia da terceira fase. Não é uma otimização incremental dos modelos de pontes existentes, mas sim uma reconstrução fundamental da resposta à pergunta "quem certifica 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, o fosso de confiança entre "entre cadeias" e "dentro da cadeia" é drasticamente reduzido.

Isto não significa que a Gravity tenha eliminado todos os riscos. O grau de descentralização do conjunto de validadores, a estabilidade a longo prazo 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 ser continuamente observadas. Além disso, em maio de 2026, a Gravity Bridge sofreu um ataque, resultando numa perda de aproximadamente 5,4 milhões de dólares, o que também lembra ao mercado que mesmo as arquiteturas entre cadeias mais bem desenhadas precisam de passar por um teste de combate suficientemente longo.

Mas a direção é clara: o fim da interoperabilidade não são mais pontes, mas sim menos hipóteses de confiança. Se a Gravity se tornará a infraestrutura representativa deste fim dependerá do processo de descentralização dos validadores após o lançamento da mainnet, da velocidade de migração das aplicações do ecossistema e da resiliência do oráculo nativo sob ataques reais. Para investigadores e desenvolvedores focados no setor entre cadeias, a escolha arquitetónica da Gravity oferece um exemplo digno de acompanhamento contínuo.

FAQ

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

A LayerZero baseia-se na arquitetura de nós ultra-leves (ULN), verificando mensagens entre cadeias através de um Oráculo e um Retransmissor; a Axelar utiliza uma rede PoS independente e o mecanismo de Mensagens Universais (GMP). A Gravity incorpora a verificação de dados entre cadeias diretamente na camada de consenso da L1, com o mesmo conjunto de validadores a garantir, com o mesmo limite BFT, tanto o estado da cadeia como a autenticidade dos dados entre cadeias.

P2: Como é que o oráculo nativo da Gravity garante a segurança dos dados entre cadeias?

O oráculo nativo não tem rede externa nem comité multisig. Os validadores, sob o consenso AptosBFT, observam dados externos, votam e escrevem na L1. A autenticidade dos dados é garantida pelo limite de dois terços do conjunto de validadores — exatamente a mesma segurança que a própria cadeia. O custo de atacar dados falsos entre cadeias é igual ao custo de atacar a própria cadeia.

P3: Quais são os parâmetros de desempenho atuais da Gravity?

A Gravity L1 pode sustentar uma produção de 12 000+ TPS em transferências ERC-20 sob carga de trabalho em tempo real, com um tempo de bloco de 200 milissegundos 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.

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

Em junho de 2026, a Gravity anunciou o Chainlink CCIP como a sua infraestrutura de ponte entre cadeias normalizada. O G tornar-se-á um ativo nativo entre cadeias (CCT), permitindo aos desenvolvedores implantação autónoma, transferências sem slippage e maior programabilidade. Isto aumenta os padrões de segurança e a conveniência de desenvolvimento para aplicações entre cadeias na Gravity.

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

O G é o token nativo de gas e staking da Gravity L1. Os validadores fazem staking de G para participar no consenso e na prova do oráculo nativo. Os detentores de G decidem sobre o protocolo através da governança da G DAO, e o G também funciona como token de pagamento e incentivo no ecossistema Galxe.