Lo que comenzó como una aproximación a la comunicación entre cadenas, ha evolucionado hasta convertirse en un formato para la Comunicación de Consenso Cruzado que no sólo se lleva a cabo entre cadenas, sino también entre contratos inteligentes, paletas, puentes e incluso enclaves fragmentados como SPREE.

Visión General de XCM: Un Formato, No un Protocolo #

XCM está relacionado con las cadenas cruzadas de la misma manera que REST está relacionado con RESTful. XCM no puede enviar mensajes entre sistemas. Es un formato sobre cómo debe realizarse la transferencia de mensajes, de forma similar a como los servicios RESTful utilizan REST como estilo arquitectónico de despliegue.

XCM pretende ser un lenguaje de comunicación de ideas entre sistemas de consenso, por lo tanto, “Cross-Consensus” con las siguientes propiedades:

• Genérico y extensible para su uso con plataformas de contratos inteligentes libres de tarifas y de gas, parachains de la comunidad, interacciones de confianza entre parachains del sistema y su relay chain, y más.
• Interacción con un sistema cuyo formato de transacción es desconocido.
  • XCM está bien versionado, es abstracto y general y puede utilizarse como medio para proporcionar un formato de transacción duradero para que las wallets lo utilicen para crear muchas transacciones comunes. Es extensible y, a su vez, a prueba de futuro y compatible con el avance.
• Es altamente eficiente para operar en un entorno restringido y medido, como es el caso de muchas cadenas.

XCM no está diseñado de forma que se espere que todos los sistemas que soportan el formato sean capaces de interpretar cualquier mensaje XCM posible. En la práctica, cabe imaginar que algunos mensajes no tendrán interpretaciones razonables en algunos sistemas o no serán soportados intencionadamente.

Ejemplos de Casos de Uso #

• Solicitar que se realicen operaciones específicas en el sistema receptor.
• Incluir opcionalmente el pago de tarifas en una red de destino para la operación solicitada.
• Proporcionar métodos para varios modelos de transferencia de tokens:
  • Transferencias remotas: controlar una cuenta en una cadena remota, permitiendo a la cadena local tener una dirección en la cadena remota para recibir fondos y eventualmente transferir esos fondos que controla a otras cuentas en esa cadena remota.
  • Teletransporte: el movimiento de un activo se produce destruyéndolo en un lado y creando un clon en el otro.
  • Transferencia a la inversa: puede haber dos cadenas que quieran nominar a una tercera cadena, en la que una incluye un activo nativo que puede utilizarse como reserva de ese activo. Entonces, la forma derivada del activo en cada una de esas cadenas estaría totalmente respaldada, permitiendo que el activo derivado se intercambie por el activo subyacente en la cadena de reserva que lo respalda.

Pila tecnológica de XCM #

• XCM puede utilizarse para expresar el significado de los mensajes a través de cada uno de estos tres canales de comunicación.

Protocolos de Consenso Cruzado #

Una vez establecido el formato XCM, se necesitan patrones comunes para protocolizar estos mensajes. Polkadot implementa dos para actuar sobre los mensajes XCM entre sus parachains constituyentes.

VMP (Paso de Mensajes Vertical) #

Existen dos tipos de protocolos de transporte de paso de mensajes verticales:

• UMP (Upward Message Passing): permite a las parachains enviar mensajes a su relay chain.
• DMP (Downward Message Passing): permite a la relay chain pasar mensajes a una de sus parachains.

Los mensajes que se pasan a través de DMP pueden provenir de una parachain. En ese caso, primero se utiliza UMP para comunicar el mensaje a la Relay Chain y DMP para trasladarlo hacia abajo a otra parachain.

XCMP (Paso de Mensajes Entre Cadenas) #

XCMP permite a las parachains intercambiar mensajes con otras parachains de la misma Relay Chain.

Las transacciones entre cadenas se resuelven mediante un sencillo mecanismo de colas basado en un árbol de Merkle para garantizar la fidelidad. La tarea de los validadores de la Relay Chain es mover las transacciones de la cola de salida de una parachain a la cola de entrada de la parachain de destino. Sin embargo, sólo los metadatos asociados se almacenan como un hash en el almacenamiento de la Relay Chain.

La cola de entrada y la cola de salida se denominan a veces en el código base de Polkadot y en la documentación asociada como mensajes ingress y egress, respectivamente.

XCMP-Lite (HRMP)

Mientras se implementa XCMP, existe en su lugar un protocolo provisional (véase la definición más abajo) conocido como Horizontal Relay-routed Message Passing (HRMP). HRMP tiene la misma interfaz y funcionalidad que XCMP, pero es mucho más exigente en cuanto a recursos, ya que almacena todos los mensajes en el almacén de la Relay Chain. Cuando se haya implementado XCMP, está previsto que HRMP quede obsoleto y se elimine progresivamente en favor de éste.

• Nota: Un protocolo provisional es un sustituto temporal de la funcionalidad que no está totalmente completa. Mientras el XCMP propiamente dicho sigue en desarrollo, el HRMP es un sustituto que funciona.

Diseño de XCMP

• XCMP está actualmente en desarrollo y los detalles están sujetos a cambios.

Sin embargo, esta arquitectura general y las decisiones de diseño son más estables:

• Los mensajes entre cadenas no se entregarán a la Relay Chain.
• Los mensajes entre cadenas estarán limitados a un tamaño máximo en bytes.
• Se permite a las parachains bloquear mensajes de otras parachains, en cuyo caso la parachain despachadora sería consciente de este bloqueo.
• Los nodos collators son responsables de enrutar los mensajes entre cadenas.
• Los collators producen una lista de mensajes de egress y recibirán los mensajes de ingress de otras parachains.
• En cada bloque, se espera que las parachains enruten los mensajes de algún subconjunto de todas las demás parachains.
• Cuando un collator produce un nuevo bloque para entregarlo a un validador, recogerá la última información de la cola de ingress y la procesará.
• Los validadores comprobarán la prueba de que el nuevo candidato para el siguiente bloque de parachain incluye el procesamiento de los mensajes de ingress esperados para esa parachain.

Las colas XCMP deben iniciarse abriendo primero un canal entre dos parachains. El canal es identificado por las parachains emisora y receptora, lo que significa que es un canal unidireccional. Un par de parachains puede tener como máximo dos canales entre ellas, uno para enviar mensajes a la otra cadena y otro para recibirlos. El canal requerirá un depósito en DOT para ser abierto, que será devuelto cuando el canal se cierre.

Formato de mensajes XCMP

Para una descripción actualizada y completa del formato de los mensajes XCMP, consulta el repositorio xcm-format en GitHub.

La anatomía de una interacción XCMP

Un contrato inteligente que existe en la parachain A dirigirá un mensaje a la parachain B en el que se llama a otro contrato inteligente que realiza una transferencia de algunos activos dentro de esa cadena.

Charlie ejecuta el contrato inteligente en la parachain A, que inicia un nuevo mensaje de cross chain (cadena cruzada) para el destino de un contrato inteligente en la parachain B.

El nodo collator de la parachain A colocará este nuevo mensaje de cross chain (cadena cruzada) en su cola de mensajes de salida, junto con un destination y una timestamp.

El nodo collator de la parachain B hace un ping rutinario a todos los demás nodos collators solicitando nuevos mensajes (filtrando por el campo destination). Cuando el collator de la parachain B haga su próximo ping, verá este nuevo mensaje en la parachain A y lo añadirá a su propia cola de entrada para procesarlo en el siguiente bloque.

Los validadores de la parachain A también leerán la cola de salida y conocerán el mensaje. Los validadores de la parachain B harán lo mismo. Esto es para que puedan verificar que se ha producido la transmisión del mensaje.

Cuando el collator de la parachain B esté construyendo el siguiente bloque en su cadena, procesará el nuevo mensaje en su cola de entrada, así como cualquier otro mensaje que haya encontrado/recibido.

Durante el procesamiento, el mensaje ejecutará el contrato inteligente en la parachain B y completará la transferencia de activos según lo previsto.

El collator ahora entrega este bloque al validador, que a su vez verificará que este mensaje fue procesado. Si el mensaje fue procesado y todos los demás aspectos del bloque son válidos, el validador incluirá este bloque para la parachain B en la Relay Chain.

XCVM (Máquina Virtual de Consenso Cruzado) #

Una computadora de ultra alto nivel no Turing-completo cuyas instrucciones están diseñadas de forma que estén más o menos al mismo nivel que las transacciones.

Un mensaje en XCM es simplemente un programa que se ejecuta en la XCVM: en otras palabras, una o más instrucciones XCM. Para saber más sobre la XCVM y el formato XCM, consulta la última entrada del blog del Dr. Gavin Wood. La versión en español de blog del Dr. Gavin Wood pueden encontrarla en el blog de PolkadotEspanol.

Cómo hacer Transferencias Cruzadas #

Puedes encontrar un tutorial sobre transferencias descendentes, ascendentes y laterales aquí.

Recursos #

• XCM: The Cross-Consensus Message Format – Entrada de blog detallada del Dr. Gavin Wood sobre el formato XCM (en ingles) y en PolkadotEspanol (en español).
• Formato XCM – Descripción del formato XCM de alto nivel enviado a través de XCMP.
• Esquema XCMP – Descripción técnica completa de la comunicación entre cadenas en el wiki de investigación de la Fundación Web3.
• Visión general del mensaje – Una visión general de los esquemas de mensaje de la guía del implementador de Parachain.