La mayoría de los diseños entre cadenas fallan por tratar toda interacción como un único tipo de tráfico. XChain traza una línea dura entre READ (sin cambio de estado) y WRITE (con cambio de estado): una distinción primitiva de la que cuelga todo el modelo. La mayor parte de las necesidades entre cadenas se reducen a verificar que «X ocurrió en la cadena A» —un READ, por Interchain Queries (ICQ)—, algo barato y prácticamente ilimitado. Solo el cambio de estado atómico es un WRITE, por IBC v2/Eureka + Interchain Accounts (ICA), y se mantiene deliberadamente escaso.

Por qué un READ es casi gratis

La asimetría no viene de una tarifa; viene de lo que cada operación tiene que hacer. Un READ verifica una prueba de inclusión contra una raíz que la cadena consultante ya sigue, la misma que el Settlement Layer mantiene mediante PAI. No hay que acordar nada nuevo, no se abre ninguna ronda de consenso y no se toca el estado. El trabajo es una verificación de prueba, y ese coste no crece con el tamaño del estado leído: demostrar que un evento entre mil millones está en un registro cuesta lo mismo que demostrarlo entre mil.

Dos reglas duras hacen que esto sea seguro y no solo barato. Un READ NO DEBE cambiar el estado y DEBE ser idempotente, de modo que un reintento es inocuo, una consulta duplicada no cambia nada y un relayer que repita una consulta antigua no puede causar daño. Por eso mismo el presupuesto de READ puede dejarse prácticamente sin límite: una operación que no puede alterar nada tampoco puede ser forzada a alterar algo.

Tipo	Mecanismo	Coste	Presupuesto
READ	ICQ — verificar una prueba contra una raíz existente	Barato (una verificación)	Prácticamente ilimitado
WRITE dentro de una Cell	Secuenciador compartido (inclusión atómica)	Bajo	La mayor parte del tráfico con estado
WRITE entre Zone/Region	XMP + cliente ligero ZK + pessimistic proof	Alto, asíncrono	< 0,1%
WRITE atómico global	Solo en el Settlement Layer (Tier T0); intent/solver lo respaldan	Muy alto	< 0,01%

Lo que cuesta de verdad un WRITE

El WRITE es escaso porque es genuinamente caro, y ese precio compra un conjunto concreto de comprobaciones. Su ciclo de vida es fijo: SendPacket → el mensaje se escribe en el árbol de Merkle de mensajes salientes → un relayer lo transporta con su prueba → RecvPacket verifica la prueba y el nonce anti-repetición → el mensaje se ejecuta → Ack o Timeout. Aquí no se confía en el relayer en ningún punto: transporta bytes, y si miente, corrompe o descarta un mensaje, la comprobación de la prueba falla o se dispara la vía de timeout. Un relayer puede retrasar un WRITE; no puede falsificarlo.

Tres obligaciones están especificadas como MUST, y son lo que impide que el modelo se desdibuje según se añaden cadenas:

El nonce DEBE crecer de forma monótona por cada par (origen, destino): esto hace la repetición estructuralmente imposible, no simplemente improbable.
Todo WRITE que mueva un activo DEBE llamar a **UAC.checkPlacement**, de modo que la frontera de 2 Dominios se vuelve a comprobar en cada transferencia y no solo en la emisión.
Los WRITE entre regiones DEBEN llevar contabilidad de pessimistic proof: el mecanismo que convierte un fallo remoto en una pérdida acotada.

La ruta de datos de referencia: registrar un «me gusta» y demostrarlo entre cadenas sin volver a ejecutar nada:

Diagrama

Figura 4 — La ruta de datos de referencia: anexar, anclar y demostrar la inclusión entre cadenas.

Qué se rompe y qué sigue en pie

Los sistemas entre cadenas se juzgan por sus modos de fallo, no por su camino feliz, así que aquí están los que importan, incluida la garantía que XChain deliberadamente no ofrece:

Qué sale mal	Qué ocurre	Qué sigue en pie
El relayer se cae o censura	El WRITE se retrasa; finalmente salta el `Timeout`	No hay aplicación parcial: el mensaje se ejecuta con una prueba válida o expira. Cualquiera puede correr un relayer, así que la censura es un problema de vivacidad, no de seguridad
Se repite un mensaje	`RecvPacket` lo rechaza en el nonce	El nonce monótono por par hace la repetición imposible, no improbable
Una cadena se ve comprometida e intenta retirar más de lo que depositó	La pessimistic proof rechaza el exceso	El daño queda contenido en la propia parte de esa cadena: es exactamente lo que el criterio de aceptación MVC-3 ejercita contra una cadena defectuosa simulada (Cómo correr un nodo)
Alguien intenta mover un activo de alto valor al Dominio de datos	`UAC.checkPlacement` rechaza el WRITE	La frontera de Dominios se impone en cada transferencia, no solo en la emisión
Un WRITE entre regiones se completa a medias	No se evita. La atomicidad entre zonas de consenso independientes no tiene construcción sin confianza	La contención y el respaldo económico acotan la pérdida. Esto se declara como problema sin resolver, no se disimula: véase Problemas abiertos

La última fila es el borde honesto de este diseño. XChain no reclama atomicidad global, porque nadie tiene una construcción sin confianza para ella; lo que reclama es que un fallo se quede dentro de la región donde ocurrió y que el tamaño de la pérdida se conozca de antemano en vez de descubrirse después.

Conclusión: otra cadena demuestra que el «me gusta» ocurrió con una sola comprobación de prueba: sin mensaje con estado y sin reejecución. Los WRITE atómicos entre regiones no se prometen como todo-o-nada en la capa de protocolo; logran contención mediante pessimistic proofs y respaldo económico. Ahora bien, una ruta de lectura casi gratuita solo es segura si el valor nunca puede filtrarse a través de la frontera sobre la que lee, y eso es una cuestión de seguridad, respondida a continuación.