El panorama fragmentado de la industria blockchain es un hecho ampliamente reconocido. Docenas de cadenas públicas y soluciones de capa 2, como Ethereum, Solana, Cosmos y Arbitrum, operan en paralelo, cada una con su propio sistema de cuentas, almacenamiento de estado y reglas de consenso. En los últimos años, han surgido de forma acelerada puentes de activos cross-chain y protocolos de mensajería entre cadenas. Sin embargo, sigue sin resolverse una cuestión estructural fundamental: ¿quién es responsable de autenticar los datos entre cadenas?
La mayoría de las cadenas de capa 1 "externalizan" la verificación de oráculos o puentes cross-chain a redes independientes fuera de la cadena: o bien una red de oráculos externa firma los datos, o bien un comité multisig independiente certifica los eventos de depósito. La cadena en sí permanece "limpia", pero se añade una nueva suposición de confianza como un canal lateral. Si este canal lateral se ve comprometido, la cadena sigue funcionando, pero los datos on-chain ya han sido alterados.
Gravity ofrece una respuesta arquitectónica radicalmente diferente. Desarrollada por el equipo de Galxe, Gravity es una blockchain de alto rendimiento, totalmente compatible con EVM y de capa 1. Su principal elemento diferenciador reside en su oráculo nativo: un mecanismo donde el mismo conjunto de validadores, bajo el consenso AptosBFT, produce bloques y, al mismo tiempo, observa datos externos, vota y los escribe en L1. No existe una red de oráculos externa ni un comité multisig independiente. El puente cross-chain no es un servicio separado, sino un contrato que recibe datos ya enviados por el conjunto de validadores.
Esto es lo que realmente significa "nativo": el flujo de certificación de validadores forma parte de la máquina de estados de la cadena, no es un servicio paralelo. Cualquier dato procesado a través del oráculo nativo goza del mismo nivel de seguridad que la propia cadena: el mismo conjunto de validadores, el mismo umbral BFT y la misma ventana de finalidad.
En junio de 2026, la mainnet de Gravity L1 se lanzó oficialmente, marcando el paso de esta arquitectura de la teoría a la producción. Este artículo desglosa de forma sistemática el protocolo de interoperabilidad de Gravity en cuatro dimensiones: mensajería cross-chain, enrutamiento de liquidez, modelos de validación y seguridad, y el flujo de activos cross-chain de extremo a extremo.
Mensajería Cross-Chain: Del paradigma "pull" al "push"
La mensajería entre cadenas constituye la capa fundamental de todos los protocolos de interoperabilidad. En esencia, el reto se resume en: ¿cómo demuestra la Cadena A a la Cadena B que "algo ha sucedido"?
En los diseños tradicionales de puentes cross-chain, los usuarios depositan activos en un contrato de la cadena de origen. Un conjunto de relayers externos detecta este evento y acuña los activos correspondientes en la cadena de destino. Este modelo depende de la honestidad y disponibilidad de los relayers y, a menudo, exige que los usuarios esperen varias confirmaciones de bloque para mitigar riesgos de reorganización.
El mecanismo de mensajería de Gravity, basado en su oráculo nativo, cambia este proceso de forma fundamental. El oráculo nativo es un único contrato desplegado en una dirección de sistema fija en Gravity L1: NativeOracle → 0x0000000000000000000000000001625F4000. Este contrato expone una operación principal, record, que solo puede ser llamada por SYSTEM_CALLER (una identidad privilegiada en tiempo de consenso, no una cuenta regular).
La función record acepta los siguientes parámetros: tipo de origen (sourceType, por ejemplo, blockchain), ID de origen (sourceId, por ejemplo, chain ID), nonce, número de bloque de la cadena de origen, payload (un blob binario opaco) y un límite de gas para la callback. Existe también una variante recordBatch para entregar múltiples eventos del mismo origen en una sola transacción.
Tres decisiones de diseño destacan especialmente:
Primero, protección centralizada contra repeticiones. El oráculo nativo exige que nonce == currentNonce + 1 para cada par (sourceType, sourceId), garantizando una secuenciación estricta sin huecos. Los mensajes antiguos nunca pueden reproducirse porque el contrato ya ha avanzado más allá de su nonce. Los procesadores a nivel de aplicación ya no necesitan mantener sus propios mapeos de nonces procesados. Esto significa que la lógica de desduplicación de mensajes cross-chain se eleva al nivel del protocolo, en vez de dejarse a cada contrato de aplicación, lo que reduce enormemente la carga de seguridad para los desarrolladores.
Segundo, enrutamiento por callback en lugar de polling. Cada par (sourceType, sourceId) puede registrar un contrato de callback. Cuando se registra un dato, el oráculo nativo invoca la función onOracleEvent del handler registrado, usando el límite de gas especificado por el llamador. Hay dos capas de análisis: un handler por defecto para cada tipo de origen, que puede ser sobrescrito por un handler especializado para un sourceId concreto. La gobernanza gestiona el registro. Este modelo "push" permite que los contratos de aplicación reciban notificaciones y ejecuten lógica tan pronto como llegan los datos cross-chain, eliminando la necesidad de hacer polling constante del estado.
Tercero, tolerancia a fallos en el callback. El handler devuelve shouldStore: bool—los handlers que consumen completamente el payload (aplicándolo a su propio estado) pueden devolver false para omitir el almacenamiento y ahorrar gas. Si el handler revierte o se queda sin gas, el oráculo nativo captura la excepción, emite un evento CallbackFailed(reason) y almacena igualmente el payload. La operación de registro siempre tiene éxito, sea cual sea el resultado.
Este diseño logra una clara separación de responsabilidades: el oráculo nativo se encarga de la veracidad (certificación por consenso, protección contra repeticiones), mientras que los contratos de aplicación gestionan el significado (decodificación y ejecución). La autenticidad de los mensajes cross-chain está garantizada por el conjunto de validadores de Gravity con finalidad BFT, no por una red externa de relayers.
Modelo de Validación y Seguridad: Una cerradura, una llave
El modelo de seguridad es el principal elemento diferenciador en los protocolos cross-chain. La arquitectura de seguridad de Gravity puede resumirse en una frase: la seguridad del oráculo nativo es equivalente a la seguridad de la propia cadena.
En concreto, Gravity utiliza un mecanismo de validación Proof-of-Stake. Los validadores hacen staking de tokens G para participar en el consenso y la certificación del oráculo nativo. El motor de consenso es AptosBFT, que proporciona finalidad de alta velocidad. El conjunto de validadores protege la cadena con un umbral de dos tercios, el mismo que garantiza la autenticidad de los datos del oráculo nativo.
¿Qué implica esto?
En la mayoría de las cadenas, los fallos de oráculos o puentes cross-chain suelen ser "invisibles": anomalías en redes de validación externas pueden pasar desapercibidas durante largos periodos, a veces hasta que ocurren pérdidas catastróficas. En Gravity, la seguridad del oráculo es idéntica a la de la propia cadena. Un atacante necesitaría controlar más de un tercio de los validadores para enviar datos cross-chain fraudulentos, lo que también significa que podría atacar la propia cadena. No existe un "canal lateral más débil" que los atacantes puedan explotar a menor coste.
Desde la perspectiva de los activos cross-chain, este modelo elimina el riesgo del "firmante externo" presente en los puentes tradicionales. El puente clásico Ethereum→Cosmos Gravity consta de dos partes: un smart contract en Solidity en Ethereum y un módulo blockchain basado en Cosmos SDK. Los usuarios depositan activos en un lado y acuñan los tokens correspondientes en el otro. En la arquitectura de oráculo nativo de Gravity L1, el puente de activos Ethereum→Gravity L1 es la primera aplicación en producción del oráculo nativo. No existe una red de oráculos externa ni un conjunto de firmantes independientes superpuestos al consenso.
También cabe destacar que Gravity está llevando a cabo una importante actualización de seguridad. En junio de 2026, Gravity anunció que, como parte del despliegue de su mainnet L1, migraría de LayerZero a Chainlink CCIP como infraestructura cross-chain estandarizada. El token nativo de Gravity, G, se convertirá en un activo nativo cross-chain (CCT), permitiendo a los desarrolladores desplegar puentes bajo demanda, transferir activos sin slippage y beneficiarse de mayor programabilidad. CCIP, con su red de oráculos descentralizada, mejorará notablemente la seguridad y flexibilidad para los desarrolladores que construyan aplicaciones cross-chain sobre Gravity. Esta actualización demuestra que, aunque Gravity mantiene la ventaja de su oráculo nativo, también integra activamente los estándares cross-chain más maduros del sector.
Flujo de activos cross-chain de extremo a extremo: Guía en ocho pasos
Basándonos en los mecanismos anteriores, una transferencia completa de activos cross-chain (usando Ethereum→Gravity L1 como ejemplo) puede desglosarse en los siguientes pasos:
Paso 1: El usuario bloquea los activos. El usuario deposita ETH o tokens ERC-20 en el contrato puente de Ethereum de Gravity. Este contrato registra el evento de depósito, incluyendo la dirección del usuario, tipo de activo, cantidad e información de la cadena de destino.
Paso 2: Finalización del bloque en Ethereum. Los nodos validadores de Gravity monitorizan continuamente la cadena de Ethereum. Los validadores no dependen de relayers externos para enviar datos; en su lugar, observan de forma independiente el estado de Ethereum.
Paso 3: Votación por consenso de los validadores. En cada bloque de Gravity L1, los validadores firman y difunden los datos externos que observan (incluidos los eventos de depósito en Ethereum) como parte del payload del oráculo nativo. Las firmas para estos datos externos utilizan exactamente las mismas claves y umbrales que las transacciones propias de Gravity.
Paso 4: Envío de datos al oráculo nativo. Una vez que el conjunto de validadores alcanza consenso sobre un evento externo (cumpliendo el umbral de dos tercios), los datos se escriben en el contrato del oráculo nativo de Gravity L1 mediante la llamada a record o recordBatch.
Paso 5: Validación del nonce y protección contra repeticiones. El contrato del oráculo nativo comprueba que el nonce del evento sea estrictamente incremental. Si el nonce no coincide (por envío duplicado o salto), el registro se rechaza.
Paso 6: Activación del callback. El contrato puente de activos, registrado como handler de callback, recibe la llamada a onOracleEvent. El contrato decodifica el payload, verifica el tipo y la cantidad de activos, y confirma la dirección de destino del destinatario.
Paso 7: Acuñación o liberación de activos. El contrato puente de activos acuña la cantidad correspondiente de activos tokenizados G en Gravity L1 (o libera directamente G en escenarios de puente nativo de activos) y los transfiere a la dirección del usuario en Gravity.
Paso 8: Confirmación de finalidad. Todo el proceso logra finalidad subsegundo bajo el consenso AptosBFT de Gravity. Los usuarios pueden recibir activos cross-chain en apenas 200 milisegundos de tiempo de bloque.
La característica clave de todo este proceso: ni un solo paso depende de relayers externos ni de firmantes independientes. Desde la observación de datos hasta la votación, el registro y la ejecución, el mismo conjunto de validadores completa el proceso bajo una única suposición de seguridad.
Base de rendimiento: más de 12 000 TPS y finalidad subsegundo
El valor de este diseño mecánico se sustenta en un rendimiento robusto. Los parámetros técnicos de Gravity hacen que su interoperabilidad cross-chain sea viable en la práctica:
La mainnet de Gravity utiliza el motor de ejecución paralelo Grevm EVM (bifurcado de revm). Bajo cargas reales, Gravity mantiene más de 12 000 TPS para transferencias ERC-20, con un tiempo de bloque de 200 milisegundos. En pruebas con un clúster de 3 nodos validador (8 vCPU / 16 GB por nodo), el rendimiento se mantuvo entre 9 500 y 11 000 TPS.
Aún más destacable es la estructura de comisiones. Con una comisión base de 50 Gwei, el espacio de bloque de Gravity se convierte, en la práctica, en un bien público en lugar de un recurso competitivo. Cada transferencia ERC-20 cuesta unos 0,0026 $. Esto rompe el modelo económico estándar de L1, que depende de la presión de comisiones para la acumulación de valor del token. La captura de valor se traslada a los servicios proporcionados por los validadores (certificación de oráculo, datos cross-chain, puentes) y a las transferencias a nivel de aplicación.
En escenarios cross-chain, las bajas comisiones hacen viables las transacciones cross-chain de alta frecuencia; la finalidad subsegundo acerca la experiencia de usuario cross-chain a la de las transacciones dentro de la misma cadena.
A nivel histórico, desde el lanzamiento de Gravity Alpha mainnet como L2 basada en Arbitrum Nitro en agosto de 2024, se han procesado más de 611 millones de transacciones en 28,5 millones de monederos durante 22 meses, con un tiempo medio de bloque de 1,3 segundos. Esto sirve como validación de grado de producción para el lanzamiento de la mainnet L1.
Datos de mercado y tokenomics
A 29 de junio de 2026, según datos de mercado de Gate, Gravity (G) cotiza a 0,003641 $, con un aumento de +13,78 % en 24 horas, un incremento de +36,62 % en 7 días y una subida de +3,72 % en 30 días. La capitalización de mercado ronda los 26,33 millones de dólares, ocupando el puesto 658. El volumen de negociación en 24 horas es de 29,20 millones de dólares, con una oferta total de 12 000 millones. El sentimiento de mercado es neutral. En el último año, el precio ha variado un -69,22 %, con un máximo histórico de 0,015440 $.
G es el token nativo de Gravity L1, con un suministro máximo de 12 000 millones, migrado desde el token GAL original. Al lanzar la mainnet, siete validadores génesis recibieron una asignación inicial de staking de 7 millones de G. Los correspondientes 7 millones de G están bloqueados permanentemente en el contrato GBridgeSender en la mainnet de Ethereum para respaldar G nativo en L1.
G actúa como token de gas para las transacciones, asegura la red mediante staking, impulsa decisiones de gobernanza, incentiva el crecimiento y facilita pagos. Los poseedores de G participan en la gobernanza a través del protocolo G DAO.
Conclusión: El destino final de la interoperabilidad es la confianza unificada
La evolución de la interoperabilidad cross-chain puede dividirse en tres etapas.
La primera etapa son los puentes de activos, donde los usuarios transfieren activos de la Cadena A a la Cadena B, confiando en validadores externos o pruebas de light client.
La segunda etapa son los protocolos de mensajería general (como LayerZero y Axelar), que permiten llamadas a smart contracts cross-chain pero siguen dependiendo de una combinación de oráculos externos y relayers para la lógica de verificación.
La tercera etapa es la interoperabilidad a nivel de protocolo: el conjunto de validadores es responsable tanto de las transiciones de estado como de la certificación de datos cross-chain, comprimiendo las suposiciones de confianza externas hasta igualar el perímetro de seguridad de la propia cadena.
La arquitectura de oráculo nativo de Gravity representa una realización ingenieril de esta tercera etapa. No es una optimización gradual de los modelos de puente existentes, sino una reconsideración fundamental de la pregunta: ¿quién certifica los datos cross-chain? Cuando la seguridad de los datos cross-chain y de la propia L1 está garantizada por el mismo conjunto de validadores y el mismo umbral BFT, la brecha de confianza entre "cross-chain" y "on-chain" se reduce drásticamente.
Esto no significa que Gravity elimine todos los riesgos. La centralización del conjunto de validadores, la estabilidad a largo plazo del modelo económico de staking, las vulnerabilidades de smart contracts en aplicaciones cross-chain y los retos de ingeniería de la migración de LayerZero a Chainlink CCIP requieren una vigilancia constante. Además, en mayo de 2026, Gravity Bridge sufrió un ataque que supuso una pérdida de aproximadamente 5,4 millones de dólares, lo que recuerda que incluso las arquitecturas cross-chain más robustas necesitan pruebas exhaustivas en el mundo real.
Pero la dirección está clara: el destino final de la interoperabilidad no son más puentes, sino menos suposiciones de confianza. Que Gravity se convierta o no en la infraestructura representativa de este destino dependerá de la descentralización del conjunto de validadores tras el lanzamiento de la mainnet, la velocidad de migración del ecosistema y la resiliencia del oráculo nativo ante ataques en condiciones reales. Para investigadores y desarrolladores centrados en el sector cross-chain, las decisiones arquitectónicas de Gravity ofrecen un caso de estudio especialmente relevante.
Preguntas frecuentes
P1: ¿Cuál es la diferencia principal entre Gravity y protocolos cross-chain como LayerZero y Axelar?
LayerZero utiliza una arquitectura Ultra Light Node (ULN), donde oráculos y relayers verifican conjuntamente los mensajes cross-chain. Axelar emplea una red de validación PoS independiente y un mecanismo de General Message Passing (GMP). Gravity integra directamente la validación de datos cross-chain en la capa de consenso L1, con el mismo conjunto de validadores y umbral BFT protegiendo tanto el estado de la cadena como la autenticidad de los datos cross-chain.
P2: ¿Cómo garantiza el oráculo nativo de Gravity la seguridad de los datos cross-chain?
El oráculo nativo no depende de ninguna red externa ni comité multisig. Los validadores, bajo consenso AptosBFT, observan datos externos, votan y los escriben en L1. La autenticidad de los datos está garantizada por el umbral de dos tercios del conjunto de validadores, igual que la seguridad de la propia cadena. El coste de atacar los datos cross-chain es idéntico al de atacar la cadena.
P3: ¿Cuáles son los parámetros de rendimiento actuales de Gravity?
Gravity L1 mantiene más de 12 000 TPS para transferencias ERC-20 bajo cargas reales, con bloques de 200 ms y finalidad subsegundo. Cada transferencia ERC-20 cuesta unos 0,0026 $. La mainnet Alpha procesó más de 611 millones de transacciones en 22 meses.
P4: ¿Qué implica la actualización de Gravity de LayerZero a Chainlink CCIP?
En junio de 2026, Gravity anunció Chainlink CCIP como su infraestructura cross-chain estandarizada. G se convertirá en un activo nativo cross-chain (CCT), permitiendo a los desarrolladores desplegar puentes bajo demanda, transferir activos sin slippage y disfrutar de mayor programabilidad. Esta actualización eleva los estándares de seguridad cross-chain y facilita el desarrollo en Gravity.
P5: ¿Cuáles son las funciones principales del token G?
G es el token nativo de gas y staking de Gravity L1. Los validadores hacen staking de G para participar en el consenso y la certificación del oráculo nativo. Los poseedores de G toman decisiones de gobernanza a través del protocolo G DAO, y G también sirve como token de pago e incentivos dentro del ecosistema Galxe.
