O panorama fragmentado da indústria blockchain é um facto amplamente reconhecido. Dezenas de blockchains públicas e soluções Layer 2 — incluindo Ethereum, Solana, Cosmos e Arbitrum — operam em paralelo, cada uma com o seu próprio sistema de contas, armazenamento de estado e regras de consenso. Nos últimos anos, assistiu-se ao surgimento acelerado de pontes de ativos cross-chain e protocolos de mensagens entre cadeias. Contudo, permanece por resolver uma questão estrutural fundamental: quem é responsável por autenticar os dados cross-chain?
A maioria das blockchains Layer 1 "externaliza" a verificação de oráculos ou pontes cross-chain para redes independentes fora da cadeia — ou uma rede de oráculos externa assina os dados, ou um comité multisig independente atesta os eventos de depósito. A cadeia em si mantém-se "limpa", mas é acrescentada uma nova assunção de confiança como canal lateral. Se este canal for comprometido, a cadeia continua a funcionar, mas os dados on-chain já foram corrompidos.
A Gravity apresenta uma resposta arquitetónica radicalmente diferente. Desenvolvida pela equipa da Galxe, a Gravity é uma blockchain Layer 1 de alto desempenho, totalmente compatível com EVM. O seu principal fator diferenciador reside no oráculo nativo — um mecanismo em que o mesmo conjunto de validadores, sob consenso AptosBFT, produz blocos enquanto observa dados externos, vota e escreve para a L1. Não existe rede de oráculos externa, nem comité multisig independente. A ponte cross-chain não é um serviço separado; é, sim, um contrato que recebe dados já submetidos pelo conjunto de validadores.
Isto é o verdadeiro significado de "nativo": o pipeline de atestação dos validadores faz parte da máquina de estados da cadeia, e não de um serviço paralelo. Qualquer dado processado através do oráculo nativo beneficia do mesmo nível de segurança da própria cadeia — o mesmo conjunto de validadores, o mesmo limiar BFT e a mesma janela de finalização.
Em junho de 2026, a mainnet Gravity L1 foi lançada oficialmente, marcando a transição desta arquitetura da teoria para a produção. Este artigo analisa de forma sistemática o protocolo de interoperabilidade da Gravity em quatro dimensões: mensagens cross-chain, roteamento de liquidez, modelos de validação e segurança, e o fluxo de ativos cross-chain de ponta a ponta.
Mensagens Cross-Chain: Da Lógica "Pull" ao Paradigma "Push"
A comunicação entre cadeias constitui a camada fundamental de todos os protocolos de interoperabilidade. No seu cerne, o desafio resume-se a: como pode a Cadeia A provar à Cadeia B que "algo aconteceu"?
Nos modelos tradicionais de pontes cross-chain, os utilizadores depositam ativos num contrato na cadeia de origem. Um conjunto de relayers externos deteta este evento e cunha ativos correspondentes na cadeia de destino. Este modelo depende da honestidade e disponibilidade dos relayers e, frequentemente, obriga os utilizadores a aguardar múltiplas confirmações de bloco para mitigar riscos de reorganização.
O mecanismo de mensagens da Gravity, assente no seu oráculo nativo, altera fundamentalmente este processo. O oráculo nativo é um contrato único, implementado num 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 privilegiada ao nível do consenso, não uma conta comum.
A função record aceita os seguintes parâmetros: tipo de origem (sourceType, por exemplo, blockchain), ID da origem (sourceId, por exemplo, chain ID), nonce, número do bloco da cadeia de origem, payload (um blob binário opaco) e um limite de gás para callback. Existe também uma variante recordBatch para entregar múltiplos eventos da mesma origem numa única transação.
Destacam-se três decisões de design fundamentais:
Em primeiro lugar, proteção centralizada contra replay. O oráculo nativo impõe nonce == currentNonce + 1 para cada par (sourceType, sourceId) — garantindo uma sequência estrita, sem falhas. Mensagens antigas nunca podem ser repetidas, pois o contrato já avançou no nonce. Os processadores ao nível da aplicação deixam de necessitar de manter os seus próprios mapeamentos de nonce processados. Isto significa que a lógica de deduplicação de mensagens cross-chain é elevada para o protocolo, em vez de ser deixada à implementação de cada contrato de aplicação — reduzindo significativamente o risco para os programadores.
Em segundo lugar, encaminhamento por callback em vez de polling. Cada par (sourceType, sourceId) pode registar um contrato de callback. Quando um dado é registado, o oráculo nativo invoca a função onOracleEvent do handler registado, utilizando o limite de gás especificado pelo chamador. Existem dois níveis de parsing: um handler por defeito para cada tipo de origem, que pode ser sobreposto por um handler especializado para um determinado sourceId. A governação gere o registo. Este modelo "push" permite que contratos de aplicação recebam notificações e executem lógica assim que os dados cross-chain chegam, eliminando a necessidade de polling constante ao estado.
Em terceiro lugar, tolerância a falhas no callback. O handler devolve shouldStore: bool — handlers que consomem totalmente o payload (aplicando-o ao seu próprio estado) podem devolver false para evitar armazenamento e poupar gás. Se o handler reverter ou esgotar o gás, o oráculo nativo captura a exceção, emite um evento CallbackFailed(reason) e armazena o payload. A operação de registo é sempre bem-sucedida, independentemente do resultado do handler.
Este design assegura uma clara separação de responsabilidades: o oráculo nativo é responsável pela verdade (atestado de consenso, proteção contra replay), enquanto os contratos de aplicação tratam do significado (decoding e execução). A autenticidade das mensagens cross-chain é garantida pelo conjunto de validadores Gravity com finalização BFT, não por uma rede de relayers externa.
Modelo de Validação e Segurança: Uma Fechadura, Uma Chave
O modelo de segurança é o principal fator diferenciador nos protocolos cross-chain. A arquitetura de segurança da Gravity pode resumir-se numa frase: a segurança do oráculo nativo é equivalente à segurança da própria cadeia.
Concretamente, a Gravity utiliza um mecanismo de validação Proof-of-Stake. Os validadores fazem staking de tokens G para participar no consenso e na atestação do oráculo nativo. O motor de consenso é o AptosBFT, que assegura finalização rápida. O conjunto de validadores protege a cadeia com um limiar de dois terços — o mesmo limiar que garante a autenticidade dos dados do oráculo nativo.
O que significa isto?
Na maioria das cadeias, falhas em oráculos ou pontes cross-chain são muitas vezes "invisíveis" — anomalias em redes de validação externas podem passar despercebidas durante longos períodos, por vezes até ocorrerem perdas catastróficas. Na Gravity, a segurança do oráculo é idêntica à da própria cadeia. Um atacante teria de controlar mais de um terço dos validadores para submeter dados cross-chain fraudulentos — o que significa igualmente que poderia atacar a própria cadeia. Não existe um "canal lateral mais fraco" para exploradores atacarem a um custo inferior.
Do ponto de vista dos ativos cross-chain, este modelo elimina o risco do "assinante externo" típico das pontes tradicionais. A ponte Gravity clássica Ethereum→Cosmos é composta por duas partes: um contrato inteligente Solidity em Ethereum e um módulo blockchain Cosmos SDK. Os utilizadores depositam ativos de um lado e cunham tokens correspondentes do outro. Na arquitetura de oráculo nativo da Gravity L1, a ponte de ativos Ethereum→Gravity L1 é a primeira aplicação em produção do oráculo nativo. Não há rede de oráculos externa, nem conjunto independente de signatários sobreposto ao consenso.
Importa ainda referir que a Gravity está a realizar uma atualização significativa de segurança. Em junho de 2026, a Gravity anunciou que, no âmbito do lançamento da mainnet L1, faria a transição de LayerZero para Chainlink CCIP como infraestrutura cross-chain padronizada. O token nativo da Gravity, G, tornar-se-á um ativo nativo cross-chain (CCT), permitindo aos programadores implementar pontes sob demanda, transferir ativos sem slippage e beneficiar de maior programabilidade. O CCIP, com a sua rede de oráculos descentralizada, irá reforçar significativamente a segurança e flexibilidade dos programadores que constroem aplicações cross-chain na Gravity. Esta atualização demonstra que, mantendo a vantagem do oráculo nativo, a Gravity integra ativamente os padrões cross-chain mais maduros do setor.
Fluxo de Ativos Cross-Chain de Ponta a Ponta: Oito Passos
Com base nos mecanismos acima, uma transferência completa de ativos cross-chain (utilizando 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 Ethereum da Gravity. Este contrato regista o evento de depósito, incluindo o endereço do utilizador, tipo de ativo, montante e informação 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 relayers externos para transmitir dados; observam de forma independente o estado da Ethereum.
Passo 3: Votação de consenso dos validadores. Em cada bloco da Gravity L1, os validadores assinam e difundem os dados externos que observam (incluindo eventos de depósito Ethereum) como parte do payload do oráculo nativo. As assinaturas para estes dados externos utilizam as mesmas chaves e limiares das transações da própria Gravity.
Passo 4: Submissão de dados ao oráculo nativo. Assim que o conjunto de validadores atinge consenso sobre um evento externo (atingindo o limiar de dois terços), os dados são escritos no contrato do oráculo nativo da Gravity L1 através da chamada record ou recordBatch.
Passo 5: Validação do 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 (devido a submissão duplicada ou omissão), o registo é rejeitado.
Passo 6: Acionamento do callback. O contrato da ponte de ativos, registado como handler de callback, recebe a chamada onOracleEvent. O contrato descodifica o payload, verifica o tipo e montante do ativo e confirma o endereço do destinatário.
Passo 7: Cunhagem ou libertação de ativos. O contrato da ponte de ativos cunha o montante correspondente de ativos G-tokenizados na Gravity L1 (ou liberta diretamente G em cenários de ponte nativa de ativos) e transfere-os para o endereço do utilizador na Gravity.
Passo 8: Confirmação de finalização. Todo o processo atinge finalização sub-segundo sob o consenso AptosBFT da Gravity. Os utilizadores podem receber ativos cross-chain em 200 milissegundos de tempo de bloco.
A principal característica deste processo: nenhum passo depende de relayers externos ou signatários independentes. Da observação dos dados à votação, escrita e execução, é sempre o mesmo conjunto de validadores a completar o processo sob uma única assunção de segurança.
Fundação de Desempenho: Mais de 12 000 TPS e Finalização Sub-Segundo
O valor deste design assenta numa base de desempenho robusta. Os parâmetros técnicos da Gravity tornam a interoperabilidade cross-chain viável na prática:
A mainnet da Gravity utiliza o motor de execução paralelo Grevm EVM (fork do revm). Sob cargas reais, a Gravity mantém mais 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 por nó), o throughput manteve-se entre 9 500 e 11 000 TPS.
Destaca-se ainda a estrutura de taxas. Com uma base de 50 Gwei, o espaço de bloco da Gravity torna-se, na prática, um bem público em vez de um ativo competitivo. Cada transferência ERC-20 custa cerca de 0,0026 $. Isto rompe com o modelo económico clássico das L1, que depende da pressão das taxas para valorização do token. A captação de valor desloca-se para os serviços prestados pelos validadores (atestado de oráculo, dados cross-chain, bridging) e transferências ao nível das aplicações.
Em cenários cross-chain, taxas reduzidas tornam viáveis transações cross-chain de alta frequência; a finalização sub-segundo aproxima a experiência do utilizador cross-chain da de transações intra-chain.
Desde o lançamento da mainnet Alpha da Gravity, baseada em Arbitrum Nitro L2, em agosto de 2024, foram processadas mais de 611 milhões de transações em 28,5 milhões de carteiras ao longo de 22 meses, com um tempo médio de bloco de 1,3 segundos. Este histórico serve de validação em produção para o lançamento da mainnet L1.
Dados de Mercado e Tokenomics
A 29 de junho de 2026, de acordo com dados de mercado da Gate, a Gravity (G) apresenta um preço de 0,003641 $, com uma valorização de +13,78 % em 24 horas, +36,62 % em 7 dias e +3,72 % em 30 dias. A capitalização de mercado situa-se em cerca de 26,33 milhões $, ocupando a posição 658. O volume de negociação em 24 horas é de 29,20 milhões $, com um fornecimento total de 12 mil milhões. O sentimento de mercado é neutro. No último ano, o preço variou -69,22 %, com um máximo histórico de 0,015440 $.
G é o token nativo da Gravity L1, com um fornecimento máximo de 12 mil milhões, migrado do token GAL original. No lançamento da mainnet, sete validadores génese receberam uma alocação inicial de staking de 7 milhões de G. Os respetivos 7 milhões de G estão permanentemente bloqueados no contrato GBridgeSender na mainnet Ethereum para suportar G nativo na L1.
O G serve como token de gás para transações, assegura a rede através de staking, impulsiona decisões de governação, incentiva o crescimento e facilita pagamentos. Os detentores de G participam na governação através do protocolo G DAO.
Conclusão: O Fim da Interoperabilidade é a Confiança Unificada
A evolução da interoperabilidade cross-chain pode dividir-se em três fases.
A primeira fase corresponde às pontes de ativos, onde os utilizadores transferem ativos da Cadeia A para a Cadeia B, confiando em validadores externos ou provas de light client.
A segunda fase são os protocolos de mensagens generalistas (como LayerZero e Axelar), que suportam chamadas de contratos inteligentes cross-chain, mas continuam a depender de uma combinação de oráculos externos e relayers para a lógica de verificação.
A terceira fase é a interoperabilidade ao nível do protocolo — onde o conjunto de validadores é responsável tanto pelas transições de estado como pela atestação de dados cross-chain, comprimindo as assunções de confiança externas até ao limite de segurança da própria cadeia.
A arquitetura do oráculo nativo da Gravity representa a concretização técnica desta terceira fase. Não se trata de uma otimização gradual dos modelos de ponte existentes, mas de uma reformulação fundamental da questão: quem certifica os dados cross-chain? Quando a segurança dos dados cross-chain e da própria L1 é garantida pelo mesmo conjunto de validadores e limiar BFT, o fosso de confiança entre "cross-chain" e "on-chain" é drasticamente reduzido.
Isto não significa que a Gravity elimina todos os riscos. A centralização do conjunto de validadores, a estabilidade a longo prazo do modelo económico de staking, vulnerabilidades em contratos inteligentes de aplicações cross-chain e os desafios de engenharia na migração de LayerZero para Chainlink CCIP exigem monitorização contínua. Adicionalmente, em maio de 2026, a Gravity Bridge foi alvo de um ataque que resultou numa perda de cerca de 5,4 milhões $ — um lembrete de que mesmo as arquiteturas cross-chain mais robustas requerem testes extensivos em ambiente real.
Mas a direção é clara: o futuro da interoperabilidade não passa por mais pontes, mas por menos assunções de confiança. Se a Gravity se tornará ou não a infraestrutura representativa deste futuro dependerá da descentralização dos validadores após o lançamento da mainnet, da velocidade de migração do ecossistema e da resiliência do oráculo nativo perante ataques reais. Para investigadores e programadores focados no setor cross-chain, as opções arquitetónicas da Gravity constituem um caso de estudo relevante a acompanhar.
FAQ
Q1: Qual é a principal diferença entre a Gravity e protocolos cross-chain como LayerZero e Axelar?
A LayerZero utiliza uma arquitetura Ultra Light Node (ULN), onde oráculos e relayers verificam em conjunto as mensagens cross-chain. A Axelar emprega uma rede de validação PoS independente e um mecanismo General Message Passing (GMP). A Gravity integra diretamente a validação de dados cross-chain na camada de consenso L1, com o mesmo conjunto de validadores e limiar BFT a proteger tanto o estado da cadeia como a autenticidade dos dados cross-chain.
Q2: Como é que o oráculo nativo da Gravity garante a segurança dos dados cross-chain?
O oráculo nativo não depende de redes externas nem de comités multisig. Os validadores, sob consenso AptosBFT, observam dados externos, votam e escrevem para a L1. A autenticidade dos dados é garantida pelo limiar de dois terços do conjunto de validadores — o mesmo que protege a cadeia. O custo de atacar dados cross-chain é idêntico ao de atacar a própria cadeia.
Q3: Quais são os atuais indicadores de desempenho da Gravity?
A Gravity L1 mantém mais de 12 000 TPS em transferências ERC-20 sob cargas reais, com tempos de bloco de 200 ms e finalização sub-segundo. Cada transferência ERC-20 custa cerca de 0,0026 $. A mainnet Alpha processou mais de 611 milhões de transações em 22 meses.
Q4: O que significa a atualização da Gravity de LayerZero para Chainlink CCIP?
Em junho de 2026, a Gravity anunciou o Chainlink CCIP como infraestrutura cross-chain padronizada. O G tornar-se-á um ativo nativo cross-chain (CCT), permitindo aos programadores implementar pontes sob demanda, transferir ativos sem slippage e beneficiar de maior programabilidade. Esta atualização eleva os padrões de segurança cross-chain e conveniência para programadores na Gravity.
Q5: Quais são as principais funções do token G?
O G é o token nativo de gás e staking da Gravity L1. Os validadores fazem staking de G para participar no consenso e na atestação do oráculo nativo. Os detentores de G tomam decisões de governação através do protocolo G DAO, e o G serve ainda como token de pagamento e incentivo dentro do ecossistema Galxe.
