¿Cómo funciona la infraestructura entre cadenas? Análisis profundo del protocolo de interoperabilidad Gravity y la arquitectura de oráculo nativo.

El panorama fragmentado de la industria blockchain es un hecho que se ha repetido en numerosas ocasiones. Decenas de cadenas públicas y L2 como Ethereum, Solana, Cosmos y Arbitrum coexisten, cada una con su propio sistema de cuentas, almacenamiento de estado y reglas de consenso. Los puentes de activos entre cadenas y los protocolos de mensajería entre cadenas han surgido sin cesar en los últimos años, pero un problema estructural fundamental sigue sin resolverse: ¿quién certifica realmente los datos entre cadenas?

La gran mayoría de las cadenas L1 "externalizan" la responsabilidad de verificación de los oráculos o puentes entre cadenas a redes independientes fuera de la cadena: una red de oráculos externa firma los datos, o un comité multifirma independiente prueba los eventos de depósito. La cadena en sí misma se mantiene "limpia", pero se añade un nuevo supuesto de confianza en un flanco externo. Si ese canal lateral es comprometido, la cadena sigue funcionando, pero los datos en la cadena ya son incorrectos.

Gravity ofrece una respuesta arquitectónica radicalmente diferente. Desarrollada por el equipo de Galxe, Gravity es una blockchain de capa 1 de alto rendimiento y totalmente compatible con EVM, cuya diferencia central radica en el Oráculo Nativo (Native Oracle): el mismo conjunto de validadores que generan bloques bajo el consenso AptosBFT también observan datos externos, votan y escriben en la L1. No hay una red de oráculos externa, ni un comité multifirma independiente. El puente entre cadenas no es un servicio independiente, sino un contrato que recibe datos ya enviados por el conjunto de validadores.

Este es el significado de "nativo": el conducto de prueba del validador es parte de la máquina de estado de la cadena, no un servicio que se ejecuta a su lado. Cualquier dato que llegue a través del oráculo nativo tiene la misma 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 red principal de Gravity L1 se lanzó oficialmente, marcando la transición de esta arquitectura de la teoría a la producción. Este artículo analizará sistemáticamente el mecanismo del protocolo de interoperabilidad de Gravity desde cuatro dimensiones: transmisión de mensajes entre cadenas, enrutamiento de liquidez, modelo de verificación y seguridad, y el proceso completo de transferencia de activos entre cadenas.

Mecanismo de transmisión de mensajes entre cadenas: un cambio de paradigma de "extracción" a "empuje"

La transmisión de mensajes entre cadenas es la capa base de todos los protocolos de interoperabilidad. Su problema central se puede simplificar a: ¿cómo prueba la cadena A a la cadena B que "algo ha sucedido"?

En el diseño tradicional de puentes entre cadenas, los usuarios depositan activos en un contrato en la cadena de origen, y un grupo de relayer externos escuchan ese evento y luego acuñan los activos correspondientes en la cadena de destino. Este modelo depende de la honestidad y disponibilidad de los relayer, y a menudo requiere que los usuarios esperen múltiples confirmaciones de bloques para reducir el riesgo de reorganización.

El mecanismo de transmisión de mensajes de Gravity se basa en su oráculo nativo, cambiando fundamentalmente este proceso. El oráculo nativo es un contrato único implementado en una dirección fija del sistema en Gravity L1: NativeOracle → 0x0000000000000000000000000001625F4000. Este contrato expone una operación central, record, que solo puede ser llamada por SYSTEM_CALLER, una identidad privilegiada en tiempo de consenso, no una cuenta normal.

La función record recibe los siguientes parámetros: tipo de fuente (sourceType, por ejemplo, blockchain), ID de fuente (sourceId, por ejemplo, ID de cadena), nonce, número de bloque de la cadena de origen, payload (bloque binario opaco) y límite de Gas de callback. También existe una variante recordBatch para entregar múltiples eventos de la misma fuente en una sola transacción.

Tres decisiones de diseño clave merecen un análisis detallado:

Primero, centralización de la protección contra replay. El oráculo nativo exige para cada par (sourceType, sourceId) que nonce == currentNonce + 1, estrictamente secuencial, sin saltos. Los mensajes antiguos nunca pueden ser reutilizados porque el contrato ya ha superado su nonce. Los procesadores de la capa de aplicación no necesitan mantener su propio mapeo de nonces procesados. Esto significa que la lógica de deduplicación de mensajes entre cadenas se eleva a la capa de protocolo, en lugar de ser implementada por cada contrato de aplicación por separado, lo que reduce significativamente la carga de seguridad para los desarrolladores de aplicaciones.

Segundo, enrutamiento de callback en lugar de sondeo. Cada par (sourceType, sourceId) puede registrar un contrato de callback. Cuando se registran datos, el oráculo nativo llama a la función onOracleEvent del procesador registrado con el límite de Gas especificado por el llamante. El análisis se divide en dos capas: un procesador predeterminado para cada tipo de fuente, que puede ser sobrescrito por un procesador especializado para un sourceId específico. La gobernanza se encarga de gestionar el registro. Este modelo de "empuje" permite que los contratos de aplicación sean notificados y ejecuten la lógica correspondiente tan pronto como llegan los datos entre cadenas, sin necesidad de sondear continuamente el estado.

Tercero, diseño de tolerancia a fallos en el callback. El procesador devuelve shouldStore: bool. Un procesador que consume completamente el payload (ya aplicado a su propio estado) puede devolver false para omitir el almacenamiento y ahorrar Gas. Si el procesador revierte o se queda sin Gas, el oráculo nativo captura la excepción, emite un evento CallbackFailed(reason) y aún así almacena el payload. La operación de registro tiene éxito de todas formas.

Este diseño logra una clara separación de preocupaciones: el oráculo nativo se encarga de la verdad (prueba de consenso, protección contra replay), y los contratos de aplicación se encargan del significado (decodificación y ejecución). La autenticidad de los mensajes entre cadenas está garantizada por el conjunto de validadores de Gravity con finalidad BFT, no por una red de relayer externa.

Modelo de verificación y seguridad: la misma cerradura, la misma llave

La diferencia en el modelo de seguridad es la dimensión central que distingue la calidad de los protocolos entre cadenas. La arquitectura de seguridad de Gravity se puede resumir en una frase: la seguridad del oráculo nativo es equivalente a la seguridad de la propia cadena.

Específicamente, Gravity adopta un mecanismo de verificación Proof-of-Stake, donde los validadores apuestan tokens G para participar en el consenso y en la prueba del oráculo nativo. El motor de consenso es AptosBFT, que proporciona una finalidad rápida. El conjunto de validadores garantiza la seguridad de la cadena con un umbral de dos tercios, el mismo umbral que también garantiza la autenticidad de los datos del oráculo nativo.

¿Qué significa esto?

En la mayoría de las cadenas, las fallas del oráculo o del puente entre cadenas suelen ser "invisibles": antes de causar grandes pérdidas, las anomalías en la red de verificación externa pueden pasar desapercibidas durante mucho tiempo. En Gravity, la seguridad del oráculo es equivalente a la seguridad de la propia cadena. Un atacante que quiera enviar datos falsos entre cadenas necesita controlar más de un tercio de los validadores, lo que al mismo tiempo significa que podría atacar la propia cadena. No existe un "canal lateral más débil" que el atacante pueda explotar a un costo menor.

Desde la perspectiva de la transferencia de activos entre cadenas, este modelo elimina el riesgo de "firmantes externos" de los puentes tradicionales. El puente tradicional Ethereum→Cosmos Gravity consta de dos partes: un contrato inteligente Solidity implementado en Ethereum y un módulo blockchain de Cosmos SDK. El usuario deposita activos en un lado y se acuñan tokens correspondientes en el otro. Pero bajo la arquitectura de oráculo nativo de Gravity L1, el puente de activos Ethereum→Gravity L1 es la primera aplicación de producción del oráculo nativo. No hay una red de oráculos externa, ni un conjunto de firmantes independientes superpuesto al consenso.

Es importante destacar que Gravity también está realizando una actualización importante en su arquitectura de seguridad. En junio de 2026, Gravity anunció que, durante el lanzamiento de su red principal L1, pasará de LayerZero a Chainlink CCIP como su infraestructura entre cadenas normalizada. El token nativo G de Gravity se convertirá en un activo nativo entre cadenas (CCT), ofreciendo a los desarrolladores implementación autónoma, transferencias sin deslizamiento y una mayor programabilidad. CCIP, con su red de oráculos descentralizada, mejorará enormemente la capacidad de los desarrolladores de la red Gravity para construir aplicaciones seguras entre cadenas. Esta actualización muestra que Gravity, manteniendo las ventajas centrales de su oráculo nativo, también está integrando activamente los estándares entre cadenas más maduros de la industria.

Proceso completo de transferencia de activos entre cadenas: ocho pasos desde el depósito hasta la recepción

Basado en el mecanismo anterior, una transferencia completa de activos entre cadenas (tomando como ejemplo Ethereum→Gravity L1) se puede descomponer en el siguiente proceso:

Paso 1: El usuario bloquea los activos. El usuario deposita ETH o tokens ERC-20 en el contrato puente de Gravity en Ethereum. Ese contrato registra el evento de depósito, incluyendo la dirección del usuario, el tipo de activo, la cantidad y la información de la cadena de destino.

Paso 2: Finalización del bloque de Ethereum. Los nodos validadores de Gravity monitorean continuamente la cadena Ethereum. Los validadores no dependen de relayer externos para enviar datos, sino que observan el estado de Ethereum por sí mismos.

Paso 3: Votación de consenso del validador. En cada bloque de Gravity L1, los validadores firman y transmiten los datos externos que han observado (incluyendo los eventos de depósito de Ethereum) como parte del payload del oráculo nativo. Los validadores utilizan exactamente las mismas claves y el mismo umbral para firmar estos datos externos que para las transacciones de la propia cadena Gravity.

Paso 4: Envío de datos al oráculo nativo. Una vez que el conjunto de validadores alcanza un consenso sobre un evento externo (alcanzando el umbral de dos tercios), los datos se escriben en el contrato del oráculo nativo de Gravity L1 a través de una llamada record o recordBatch.

Paso 5: Verificación de nonce y prevención de replay. El contrato del oráculo nativo verifica que el nonce del evento sea estrictamente creciente. Si el nonce no coincide (reenvío o salto), el registro es rechazado.

Paso 6: Disparo del callback. El contrato del puente de activos, como procesador de callback registrado, recibe la llamada onOracleEvent. El contrato decodifica el payload, verifica el tipo y la cantidad del activo, y confirma la dirección de recepción de destino.

Paso 7: Acuñación o liberación de activos. El contrato del puente de activos acuña la cantidad correspondiente de activos envueltos de tokens G en Gravity L1 (o libera directamente G en el caso de un puente de activos nativo) y los transfiere a la dirección del usuario en la cadena Gravity.

Paso 8: Confirmación de finalidad. Todo el proceso obtiene una finalidad de submilisegundo bajo el consenso AptosBFT de Gravity. El usuario puede recibir los activos entre cadenas dentro de un tiempo de bloque de 200 milisegundos.

La característica clave de este proceso completo es que ningún paso depende de relayer externos o firmantes independientes. Desde la observación de datos hasta la votación, la escritura y la ejecución, todo es realizado por el mismo conjunto de validadores con el mismo supuesto de seguridad.

Base de rendimiento: más de 12,000 TPS y finalidad de submilisegundo

El valor del diseño del mecanismo necesita una base de rendimiento para ser soportado. Los parámetros de rendimiento de Gravity proporcionan viabilidad práctica para su interoperabilidad entre cadenas:

La red principal de Gravity utiliza el motor de ejecución paralela EVM Grevm (bifurcado de revm). Bajo cargas de trabajo en tiempo real, Gravity puede mantener un rendimiento de más de 12,000 TPS en transferencias ERC-20, con un tiempo de bloque de 200 milisegundos. En pruebas con un clúster de 3 nodos validadores (8 vCPU / 16 GB por nodo), el rendimiento se mantuvo en aproximadamente 9,500–11,000 TPS.

Más destacable es su estructura de tarifas. Una tarifa base de 50 Gwei hace que el espacio de bloques en Gravity sea funcionalmente un bien público, no un activo competitivo. El costo de cada transferencia ERC-20 es de aproximadamente 0.0026 dólares. Esto rompe el modelo económico estándar de L1, que depende de la presión de las tarifas como principal acumulación de valor del token. La captura de valor se desplaza hacia los servicios proporcionados por los validadores (pruebas de oráculo, datos entre cadenas, puentes) y la capa de aplicación.

Para escenarios entre cadenas, las tarifas bajas hacen que las transacciones entre cadenas de alta frecuencia sean económicamente viables; la finalidad de submilisegundo hace que la experiencia del usuario entre cadenas se acerque a la de las transacciones dentro de la cadena.

Según datos históricos, desde que la red principal Alpha de Gravity se lanzó como una L2 basada en Arbitrum Nitro en agosto de 2024, ha procesado más de 611 millones de transacciones en 22 meses, cubriendo 28.5 millones de carteras, con un tiempo de bloque promedio de 1.3 segundos. Esto constituye una validación de producción para el lanzamiento de la red principal L1.

Datos de mercado y economía del token

Al 29 de junio de 2026, según los datos de precios de Gate, Gravity (G) tiene un precio de $0.003641, con un aumento del +13.78% en 24 horas, un aumento del +36.62% en 7 días y un aumento del +3.72% en 30 días. La capitalización de mercado es de aproximadamente 26.3342 millones de dólares, ocupando el puesto 658. El volumen de negociación en 24 horas es de 29.1978 millones de dólares, con un suministro total de 12,000 millones. El sentimiento del mercado es neutral. El cambio de precio en el último año es del -69.22%, y el precio máximo histórico es 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. En el lanzamiento de la red principal, 7 validadores de inicio recibieron una asignación inicial de 7 millones de G en staking. Los correspondientes 7 millones de G han sido bloqueados permanentemente en el contrato GBridgeSender del puente canónico en la red principal de Ethereum para respaldar el G nativo en L1.

G actúa como token de gas para impulsar las transacciones, asegura la red a través del staking y impulsa las decisiones de gobernanza, incentiva el crecimiento y facilita los pagos. Los titulares de G toman decisiones de protocolo a través de la gobernanza de G DAO.

Conclusión: el final de la interoperabilidad es la unificación de la confianza

La evolución de la interoperabilidad entre cadenas se puede dividir 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 nodos ligeros.

La segunda etapa son los protocolos de mensajería universal (como LayerZero, Axelar), que soportan llamadas de contratos inteligentes entre cadenas, pero la lógica de verificación aún depende de una combinación de oráculos externos y relayer.

La tercera etapa es la interoperabilidad a nivel de protocolo: el conjunto de validadores es responsable tanto de la transición de estado de la cadena como de la prueba de datos entre cadenas, comprimiendo los supuestos de confianza externos dentro del mismo límite de seguridad que la propia cadena.

La arquitectura del oráculo nativo de Gravity representa una implementación de ingeniería de la tercera etapa. No es una optimización incremental de los modelos de puentes entre cadenas existentes, sino una reestructuración fundamental de la respuesta a la pregunta "¿quién certifica los datos entre cadenas?". Cuando la seguridad de los datos entre cadenas y la seguridad de la propia L1 están garantizadas por el mismo conjunto de validadores y el mismo umbral BFT, la brecha de confianza entre "entre cadenas" y "dentro de la cadena" se reduce drásticamente.

Esto no significa que Gravity elimine todos los riesgos. El grado de centralización del conjunto de validadores, la estabilidad a largo plazo del modelo económico de staking, los riesgos de código de los contratos entre cadenas y los desafíos de ingeniería durante la migración de LayerZero a Chainlink CCIP son dimensiones que requieren una observación continua. Además, en mayo de 2026, el Gravity Bridge sufrió un ataque con pérdidas de aproximadamente 5.4 millones de dólares, lo que también recuerda al mercado que incluso las arquitecturas entre cadenas mejor diseñadas necesitan suficiente tiempo de prueba en combate real.

Pero la dirección es clara: el final de la interoperabilidad no es más puentes, sino menos supuestos de confianza. Si Gravity puede convertirse en la infraestructura representativa de este final depende del proceso de descentralización de validadores después del lanzamiento de su red principal, la velocidad de migración de las aplicaciones del ecosistema y la resiliencia del oráculo nativo bajo ataques reales. Para los investigadores y desarrolladores interesados en el ámbito entre cadenas, la elección arquitectónica de Gravity proporciona una muestra que vale la pena seguir de cerca.

FAQ

P1: ¿Cuál es la diferencia principal entre Gravity y protocolos entre cadenas como LayerZero y Axelar?

LayerZero se basa en la arquitectura de nodo ultraligero (ULN), verificando mensajes entre cadenas a través de un Oracle y un Relayer. Axelar utiliza una red de verificación PoS independiente con un mecanismo de mensajería universal (GMP). Gravity integra la verificación de datos entre cadenas directamente en la capa de consenso de L1, donde el mismo conjunto de validadores garantiza tanto el estado de la cadena como la autenticidad de los datos entre cadenas con el mismo umbral BFT.

P2: ¿Cómo garantiza la seguridad de los datos entre cadenas el oráculo nativo de Gravity?

El oráculo nativo no tiene una red externa ni un comité multifirma. Los validadores observan datos externos, votan y escriben en L1 bajo el consenso AptosBFT. La autenticidad de los datos está garantizada por el umbral de dos tercios del conjunto de validadores, exactamente igual que la seguridad de la propia cadena. El costo de atacar datos entre cadenas falsos equivale a atacar la propia cadena.

P3: ¿Cuáles son los parámetros de rendimiento actuales de Gravity?

Gravity L1 puede mantener un rendimiento de más de 12,000 TPS en transferencias ERC-20 bajo cargas de trabajo en tiempo real, con un tiempo de bloque de 200 milisegundos y finalidad de submilisegundo. Cada transferencia ERC-20 cuesta aproximadamente 0.0026 dólares. La red principal Alpha procesó más de 611 millones de transacciones en 22 meses.

P4: ¿Qué significa la actualización de Gravity de LayerZero a Chainlink CCIP?

En junio de 2026, Gravity anunció que utilizará Chainlink CCIP como su infraestructura entre cadenas normalizada. G se convertirá en un activo nativo entre cadenas (CCT), permitiendo a los desarrolladores implementación autónoma, transferencias sin deslizamiento y una mayor programabilidad. Esto mejora los estándares de seguridad y la facilidad de desarrollo para aplicaciones entre cadenas 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 apuestan G para participar en el consenso y en las pruebas del oráculo nativo. Los titulares de G toman decisiones de protocolo a través de la gobernanza de G DAO, y G también actúa como token de pago e incentivo en el ecosistema de Galxe.