Mensajería de consenso cruzado (XCM)

Introducción

La arquitectura de Polkadot permite que las paracadenas interoperen de forma nativa entre sí, lo que permite transferencias entre cadenas de bloques de cualquier tipo de datos o activos.

Para hacerlo, un formato de mensaje de consenso cruzado (XCM) define un lenguaje sobre cómo se debe realizar la transferencia de mensajes entre dos cadenas de bloques interoperativas. XCM no es específico de Polkadot, ya que pretende ser un lenguaje genérico y extensible entre diferentes sistemas de consenso.

Esta página es una breve introducción y descripción general de XCM y otros elementos relacionados. Se puede encontrar más información en la Wiki de Polkadot .

Definiciones generales de XCM

• XCM : significa mensaje de consenso cruzado, es una forma general para que los sistemas de consenso se comuniquen entre sí.
• VMP : significa paso de mensajes verticales, permite que las paracadenas intercambien mensajes con la cadena de retransmisión. UMP (paso de mensajes hacia arriba) permite que las paracadenas envíen mensajes a su cadena de retransmisión, mientras que DMP (paso de mensajes hacia abajo) permite que la cadena de retransmisión pase mensajes a una de sus paracadenas.
• XCMP : significa paso de mensajes de consenso cruzado, permite que las paracadenas intercambien mensajes con otras paracadenas en la misma cadena de retransmisión.
• HRMP : significa paso de mensajes enrutados por retransmisión horizontal, un protocolo provisional mientras se lanza una implementación completa de XCMP. La misma interfaz que XCMP, pero los mensajes se almacenan en la cadena de retransmisión
• Multiubicación : una forma de especificar un punto en todo el ecosistema de la cadena de retransmisión/paracadena desde un origen determinado, ya sea relativo o absoluto. Por ejemplo, se puede usar para especificar una paracadena, un activo, una cuenta o incluso una plataforma específica dentro de una paracadena. En términos generales, una multiubicación se define con a parentsy an interior. Padres se refiere a cuántos "saltos" en una cadena de bloques principal necesita tomar desde un origen determinado. El interior, se refiere a cuántos campos necesita para definir el punto objetivo. Por ejemplo, para apuntar a una parachain con ID 1000de otra parachain, la multiubicación sería{ "parents": 1, "interior": { "X1": [{ "Parachain": 1000 }]}}

Protocolos de transporte XCM

Polkadot implementa dos protocolos de consenso cruzado o de transporte para actuar sobre mensajes XCM entre sus paracadenas constituyentes, Moonbeam es uno de ellos:

• Paso de mensajes vertical (VMP) : dividido en dos tipos de protocolos de transporte de paso de mensajes:
• Paso de mensajes hacia arriba (UMP) : permite que las paracadenas envíen mensajes a su cadena de retransmisión, por ejemplo, de Moonbeam a Polkadot
• Paso de mensajes hacia abajo (DMP) : permite que la cadena de retransmisión pase mensajes a una de sus paracadenas, por ejemplo, de Polkadot a Moonbeam
• Cross-Chain Message Passing (XCMP) : permite que dos parachains intercambien mensajes siempre que estén conectados a la misma cadena de retransmisión. Las transacciones entre cadenas se resuelven mediante un mecanismo de cola simple basado en un árbol de Merkle para garantizar la fidelidad. Los recopiladores intercambian mensajes entre paracadenas, mientras que los validadores de la cadena de retransmisión verificarán que se haya producido la transmisión del mensaje.

Nota

Actualmente, mientras se desarrolla XCMP, se implementa un protocolo provisional llamado Paso de mensajes enrutados por retransmisión horizontal (HRMP), en el que los mensajes se almacenan y se leen en la cadena de retransmisión. Esto quedará obsoleto en el futuro para la implementación completa de XCMP.

Además, los dos casos de uso más comunes para los mensajes XCM, al menos en las primeras etapas de su implementación, son:

• Teletransportación de activos : consiste en mover un activo de una cadena de bloques a otra destruyendo la cantidad que se transfiere en la cadena de origen y creando un clon (la misma cantidad que se destruyó) en la cadena de destino. En tales casos, cada cadena mantiene el activo nativo como reserva, similar a un mecanismo de puente de menta quemada. El modelo requiere un cierto grado de confianza, ya que cualquiera de las dos cadenas podría acuñar maliciosamente más activos.
• Transferencias remotas : consiste en mover un activo de una cadena de bloques a otra a través de una cuenta intermedia en la cadena de origen que pertenece sin confianza a la cadena de destino. Esta cuenta intermedia se conoce como la cuenta “Soberana”. En tales casos, el activo de la cadena de origen no se destruye sino que se mantiene en la cuenta soberana. La ejecución de XCM en la cadena de destino acuña una representación envuelta (también conocida como activo “virtual” o “cadena cruzada”) en una dirección de destino. La representación envuelta siempre es intercambiable en una proporción de 1:1 con el activo nativo. Esto es similar a un mecanismo puente de bloqueo-menta/quema-desbloqueo

Puede encontrar un artículo mucho más detallado sobre XCM en Polkadot Wiki .

Inicialmente, Moonbeam solo admitirá transferencias remotas. Todos los activos de cadena cruzada en Moonbeam se conocerán como xc + TokenName . Por ejemplo, la representación de KSM de Kusama en Moonriver se conocerá como xcKSM . Puede leer más sobre el estándar XC-20 aquí .

Los desarrolladores deben comprender que el envío de mensajes XCM incorrectos puede provocar la pérdida de fondos. En consecuencia, es fundamental probar las funciones de XCM en una TestNet antes de pasar a un entorno de producción.

Registro de canales

Antes de que dos cadenas puedan comenzar a comunicarse, se debe abrir un canal de mensajería. Los canales son unidireccionales, lo que significa que un canal de la cadena A a la cadena B solo pasará mensajes de A a B. En consecuencia, las transferencias de activos solo serán posibles de las cadenas A a B. Por lo tanto, se deben abrir dos canales para enviar mensajes (o transferir activos) de ida y vuelta.

Un canal para XCM entre la cadena de retransmisión y la paracadena se abre automáticamente cuando se establece una conexión. Sin embargo, cuando la paracadena A quiere abrir un canal de comunicación con la paracadena B, la paracadena A debe enviar un canal abierto extrínseco en su red. ¡Este extrínseco también es un XCM! El destinatario de este XCM es la cadena de retransmisión, y el extrínseco incluye información como:

• El destino donde se ejecutará el mensaje (cadena de relés en este caso)
• La cuenta que pagará las tarifas (pagadas en el token de la cadena de retransmisión)
• Comisiones que puede consumir la transacción al ejecutarse
• Datos de llamadas codificados, obtenidos imitando lo extrínseco en la cadena de retransmisión. Esto incluye la siguiente información codificada:
• Método a llamar en la cadena de retransmisión (canal abierto)
• Parachain ID de la cadena de destino (parachain B en este ejemplo)
• Número máximo de mensajes en la cola de destino
• Tamaño máximo de los mensajes a enviar

Las tarifas de transacción se pagan en la representación de cadena cruzada (xc) del activo de la cadena de retransmisión ( xcRelayChainAsset ). Por ejemplo, para Kusama/Moonriver, las tarifas de transacción se pagarían en xcKSM . Por lo tanto, la cuenta que paga las tarifas debe tener suficiente xcRelayChainAsset . Esto podría abordarse en Moonbeam/Moonriver cobrando tarifas por los mensajes XCM entrantes, que se pagan en el activo de la cadena de origen, se envían a la tesorería y se usa la cuenta de tesorería para pagar el registro del canal extrínseco.

Aunque la paracadena A ha expresado sus intenciones de abrir un canal XCM con la paracadena B, esta última no ha señalado a la cadena de retransmisión sus intenciones de recibir mensajes de la paracadena A. Por lo tanto, para tener un canal establecido, la paracadena B también debe enviar un mensaje extrínseco. (que también es un XCM) a la cadena de relés. El canal de aceptación extrínseco es similar al anterior. Sin embargo, los datos de llamada codificados solo incluyen el nuevo método (aceptar canal) y el ID de parachain del remitente (parachain A en este ejemplo). Una vez que ambas paracadenas se han puesto de acuerdo, el canal se abre dentro del próximo cambio de época.

Todas las acciones mencionadas anteriormente pueden ejecutarse a través de SUDO (si está disponible), oa través de Democracia (comité técnico o referéndum).

Una vez que se establece el canal, los activos deben registrarse antes de transferirse a través de XCM, ya sea incorporándolos al tiempo de ejecución como una constante o a través de una paleta. El proceso de registro de activos para Moonbeam se explica en la siguiente sección.

Registro de activos de XCM

Una vez que se establece un canal entre paracadenas (o cadena de retransmisión-paracadena), puede ocurrir el registro de activos.

En general, el registro de activos puede ocurrir a nivel de tiempo de ejecución, lo que significa que se requiere una actualización de tiempo de ejecución, después de lo cual XCM ahora registra y admite el activo. Sin embargo, Moonbeam incluyó una plataforma Substrate para manejar el registro de activos sin necesidad de actualizaciones de tiempo de ejecución, lo que simplifica mucho el proceso.

Al registrar un activo XCM, el extrínseco debe incluir (entre otras cosas):

• ID de Parachain de donde se encuentra el activo de origen
• Tipo de activo. Al momento de escribir, puede registrar el token nativo de parachain o un activo creado a través de Pallet Assets , proporcionando su índice
• Un nombre de activo, símbolo y número decimal
• Balance minimo

Después de registrar el activo XCM, se pueden configurar las unidades por segundo de ejecución. Esta es una métrica que se utiliza para cargar el mensaje XCM entrante para su ejecución en la parachain de destino, similar a las tarifas de gas en el mundo Ethereum. Sin embargo, las tarifas se pueden cobrar en otro token, por ejemplo, DOT. Si la cantidad de tokens que se envían a través de XCM no es suficiente para cubrir la ejecución de XCM, la transacción de XCM falla y la tarifa gastada no se reembolsa.

Una vez que el canal se haya establecido con éxito, el activo XCM registrado en la parachain de destino y las unidades por segundo de ejecución establecidas, los usuarios deberían poder comenzar a transferir activos.

Todas las acciones mencionadas anteriormente pueden ejecutarse a través de SUDO (si está disponible), oa través de Democracia (comité técnico o referéndum).

Rayo de luna y XCM

Como Moonbeam es una parachain dentro de los ecosistemas de Polkadot, una de las implementaciones más directas de XCM es permitir la transferencia de activos desde Polkadot y otras parachains desde/hacia Moonbeam. Esto permitirá a los usuarios llevar sus tokens a Moonbeam y todas sus dApps.

Ampliando las características únicas de compatibilidad con Ethereum de Moonbeam, los activos extranjeros se representarán a través de una interfaz ERC-20 estándar a través de un contrato precompilado. Los activos XCM en Moonbeam se denominan XC-20, para diferenciar los activos XCM nativos de los ERC-20 generados a través de EVM. El contrato de precompilación accederá a las funciones de Substrate necesarias para realizar las acciones requeridas. Sin embargo, desde la perspectiva de un desarrollador, los XC-20 son tokens ERC-20 con el beneficio adicional de ser un activo de cadena cruzada XCM, y las dApps pueden admitirlos fácilmente a través de una interfaz ERC-20 familiar.

La precompilación en sí no admite transferencias entre cadenas para mantenerse lo más cerca posible de la interfaz ERC-20 original. En consecuencia, los desarrolladores tendrán que confiar en Substrate API y XCM para devolver los activos a su cadena original, o en un contrato de precompilación diferente para acceder a las funciones basadas en XCM desde Ethereum API.

Dependiendo de la cadena de bloques de destino, las transferencias de activos se pueden realizar mediante teletransporte o transferencias remotas, siendo este último el método más común utilizado. Inicialmente, Moonbeam solo admitirá transferencias remotas.

Las siguientes secciones brindan una descripción general de alto nivel de los dos casos de uso iniciales de XCM en Moonbeam: transferencias de activos desde/hacia Polkadot (a través de VMP) y transferencias de activos desde/hacia otras paracadenas (a través de XCMP). Esta página se ampliará a medida que haya más funciones de interoperabilidad disponibles, como los movimientos de tokens ERC-20 de Moonbeam a otras paracadenas, o el movimiento de otros activos a Moonbeam como representaciones ERC-20.

Moonbeam y Polkadot

Como Moonbeam es una parachain dentro del ecosistema de Polkadot, XCM + VMP permite transferencias DOT desde/hacia Polkadot/Moonbeam. Esta sección repasa una descripción general de alto nivel de todas las acciones involucradas durante la ejecución de dichos mensajes XCM.

Una vez que un proyecto se incorpora como paracadena, automáticamente tiene un canal de comunicación bidireccional con la cadena de retransmisión. Por lo tanto, no hay necesidad de registrar la cadena. Sin embargo, el token nativo de la cadena de retransmisión debe registrarse en la parachain.

Alice (Polkadot) quiere transferir una cierta cantidad de DOT de Polkadot a su cuenta en Moonbeam, llamada Alith. Por lo tanto, inicia un XCM que expresa sus intenciones. Para tales transferencias, Moonbeam posee una cuenta Sovereign en Polkadot.

En consecuencia, la ejecución del mensaje XCM en Polkadot transferirá la cantidad de DOT a la cuenta soberana de Moonbeam en Polkadot. Una vez que se depositan los activos, la segunda parte del mensaje se envía a Moonbeam.

Moonbeam ejecutará localmente la acción para la que está programado el mensaje XCM. En este caso se trata de acuñar y transferir la misma cantidad de xcDOTs (cross-chain DOTs) a la cuenta definida por Alice, que en este caso es Alith. La tarifa para ejecutar el XCM en la parachain de destino se paga en el activo que se transfiere ( xcDOTs para este ejemplo).

Tenga en cuenta lo siguiente:

• Las cuentas de Alice y Alith pueden ser diferentes. Por ejemplo, las cuentas de Polkadot son SR25519 (o ED25519), mientras que las de Moonbeam son cuentas ECDSA (estilo Ethereum). También pueden tener diferentes dueños.
• Existe un cierto grado de confianza, donde una cadena confía en la otra para ejecutar su parte del mensaje XCM. Esto está programado a nivel de tiempo de ejecución, por lo que puede verificarse fácilmente
• Para este ejemplo, los DOT de cadena cruzada ( xcDOTS ) son una representación envuelta de los DOT originales que se encuentran en la cuenta soberana de Moonbeam en Polkadot. Los xcDOT se pueden transferir dentro de Moonbeam en cualquier momento, y también se pueden canjear por DOT en una base 1: 1

Alith depositó sus xcDOT en un grupo de liquidez. A continuación, Charleth adquiere algunos xcDOT intercambiando contra ese grupo de liquidez, y quiere transferir algunos xcDOT a la cuenta Polkadot de Charley. Por lo tanto, inicia un XCM que expresa sus intenciones.

En consecuencia, la ejecución del mensaje XCM en Moonbeam quemará la cantidad de xcDOT . Una vez que se queman los activos, la segunda parte del mensaje se envía a Polkadot.

Polkadot ejecutará la acción localmente para la que el mensaje XCM está programado. En este caso se trata de transferir la misma cantidad de xcDOTs quemados de la cuenta Moonbeam Sovereign a la cuenta definida por Charleth, que en este caso es Charley.

Moonbeam y otras parachain

Como Moonbeam es una parachain dentro del ecosistema de Polkadot, XCM + XCMP permite transferencias de activos desde/hacia Moonbeam y otras parachains. Esta sección repasa una descripción general de alto nivel de las principales diferencias en comparación con los XCM de/a Polkadot/Moonbeam.

El primer requisito es que debe existir un canal entre las paracadenas, y el activo que se transfiere debe estar registrado en la paracadena de destino. Solo cuando se cumplen ambas condiciones, los XCM se pueden enviar entre parachains.

Luego, cuando Alith (Moonbeam) transfiere una cierta cantidad de GLMR de Moonbeam a otra cuenta (Alice) en una parachain de destino, los tokens se envían a una cuenta soberana propiedad de esa parachain de destino en Moonbeam.

A medida que el mensaje XCM se ejecuta en la parachain de destino, se espera que acumule y transfiera la misma cantidad de xcGLMR (GLMR de cadena cruzada) a la cuenta definida por Alith, que en este caso es Alice. La tarifa para ejecutar el XCM en la parachain de destino se paga en el activo transferido ( xcGLMRs para este ejemplo).

El proceso es similar para que los xcGLMR regresen a Moonbeam, como se explica en la sección anterior. Primero, la ejecución del mensaje XCM quema la cantidad de xcGLMR devueltos a Moonbeam. Una vez quemado, la parte remanente del mensaje se envía a Moonbeam a través de la cadena de retransmisión. Moonbeam ejecutará localmente los mensajes XCM y transferirá los GLMR (la misma cantidad de xcGLMR quemados ) desde la cuenta soberana de parachain de destino a la dirección especificada.