Descripción general de XCMP

XCMP es el protocolo de paso de mensajes entre cadenas (cross-chain message-passing) de Polkadot. Permite que una parachain envíe mensajes a otra parachain y proporciona garantías sobre la entrega de estos mensajes. Polkadot permite a los paracaidistas enviarse mensajes entre ellos siempre que hayan establecido canales de mensajería entre ellos. En este documento, revisamos primero el principio básico del diseño XCMP y luego revisamos la autenticación, la entrega de red, los canales y, finalmente, SPREE, que se puede utilizar para, por ejemplo, Transferencias de tokens confiables.

Principios básicos de diseño

Parachains alojará dapps en ellas, y la interoperabilidad entre dapps se ve muy facilitada por la entrega ordenada y oportuna de mensajes. Las garantías de entrega de Polkadot incluyen:

Entrega de mensajes garantizada: una cadena de recepción recibirá el mensaje siempre que siga produciendo bloques.
Entrega sin confianza (trustless): la seguridad compartida (shared security) de Polkadot garantiza la exactitud y autenticidad de la entrega de mensajes siempre que confiemos en el código que los produce y consume.
Entrega ordenada: los mensajes llegan en un orden bien definido.

La entrega ordenada y oportuna de mensajes no es un hecho en muchas aplicaciones, como algunas aplicaciones web. Esto se debe a que TCP ofrece garantías más débiles sobre la entrega y, por lo tanto, la aplicación web debe abordar estos problemas. Específicamente, las garantías de TCP no cubren problemas a nivel de aplicación como fallas. Crear transacciones atómicas en una capa de este tipo requiere mucho trabajo, que implica reconocimientos y tiempos de espera que persisten a lo largo de la vida útil del proceso. Sin embargo, la compensación para Polkadot es que la falta de disponibilidad de mensajes XCMP puede detener una parachain, por lo que Polkadot debe asegurarse de que esto nunca suceda.

(A modo de comparación, si bien Cosmos permite la opción de haber pedido la entrega, es posible que no haya garantías de que los mensajes lleguen alguna vez debido a la falta de un modelo general de incentivos para este propósito).

Queremos todas estas propiedades mientras mantenemos la escalabilidad, en el sentido de que la relay chain no debe sobrecargarse si 100 parachains envían mensajes a 10.000 destinos en un solo bloque de relay chain, lo que discutimos en las siguientes secciones. Esto incluye tratar de minimizar los datos almacenados en la relay chain y, en particular, debe ser constante o casi constante con respecto al tamaño del cuerpo del mensaje.

Modelo de comunicación

En este apartado se habla de la interfaz de comunicación XCMP desde el punto de vista de una parachain, sin entrar en detalles internos sobre cómo se implementa esta interfaz, o cómo se logran sus garantías, por Polkadot

Las parachains pueden enviarse mensajes entre ellas una vez que hayan establecido canales de mensajería entre ellas. Cada par de parachain (remitente, destinatario) puede tener hasta 1 canal abierto, lo que permite la comunicación bidireccional.

Mientras el canal está abierto, contiene una cola limitada de mensajes ordenados que han sido enviados pero aún no reconocidos por el destinatario. El remitente puede agregar un mensaje al final de la cola (es decir, enviar un mensaje), y el destinatario puede eliminar un mensaje del frente de la cola (es decir, aceptar un mensaje), indicándolo como tal en su respectivo próximo envío a la relay chain. También se espera que las parachains de remitente y destinatario monitoreen el estado de la relay chain para saber qué hay actualmente en la cola.

Nota: todos los mensajes para un determinado (remitente, bloque de relay chain) son procesados en un solo batch (lote) por el destinatario, por lo que para simplificar la discusión sin perder la generalidad, de aquí en adelante nos referiremos "al" mensaje (lógico) en un dado (remitente, bloque de relay chain) aunque en la práctica esto consiste en varios mensajes más pequeños a nivel de aplicación.

Los validadores de la relay chain y de parachain de Polkadot juntos verifican que el canal crece y se consume, de una manera consistente y confiable; para obtener detalles, consulte la autenticación para un historial consistente a continuación (Más abajo). También hacen cumplir otras garantías como la delimitación como se menciona, y también "fairness" que detallamos a continuación.

Fairness

Cualquier parachain de recepción dada puede tener múltiples canales entrantes de diferentes parachains de envío. En XCMP garantizamos que un destinatario debe procesar estos mensajes entrantes de manera justa (fairly) en todos los remitentes.

Específicamente, el orden en el que se deben reconocer los mensajes de diferentes remitentes / canales está predeterminado y fuera del control de la parachain receptora. En otras palabras, múltiples canales entrantes para un destinatario dado se multiplexan en una única cola de entrada, y el destinatario debe procesar esta cola en el orden predeterminado mencionado anteriormente. Además, una parachain receptora debe reconocer al menos un mensaje nuevo de un bloque, si tiene algún mensaje nuevo (de diferentes remitentes / canales) en ese bloque, para garantizar la vivacidad.

Proporcionamos esta garantía de "fairness", principalmente para asegurar que ningún mensaje quede sin procesar durante una demora infinita: el remitente sabe que el receptor debe, al menos, reconocer su contenido eventualmente, aunque puede eliminar el mensaje después de eso. Este es un juicio de valor realizado en el punto de diseño de XCMP; supervisaremos su desempeño en la práctica.

Aunque es diferente del procesamiento controlado por el destinatario de Internet, "fairness" no presenta muchos gastos generales, ya que para el orden global y la confiabilidad, el paso de mensajes se coordina a través de la relay chain de todos modos, y hacer cumplir "fairness" además de esto es sencillo.

Si las parachains que reciben sienten que están siendo spam por ciertas parachains de envío, pueden cerrar selectivamente estos canales.

Más sobre canales

Polkadot restringe a cuántas cadenas de recepción diferentes puede enviar mensajes una cadena de envío. Esto se debe a que enviar y recibir mensajes hacia o desde muchas cadenas requiere recursos. La autenticación requiere que la cadena de envío informe a la relay chain a qué cadenas está enviando mensajes. Un collator de la cadena de recepción necesita buscar datos en la relay chain para cada cadena que pueda enviar un mensaje. Es posible que tanto el lado emisor como el receptor necesiten implementar colas en su estado.

Esta restricción se aplica al permitir XCMP solo entre pares de parachains que han configurado canales entre sí. Una parathread está restringido a tener como máximo 100 canales. También restringimos el número total de canales en todas las cadenas en Polkadot al exigir un depósito para cada canal. Dado que un canal requiere un compromiso continuo de ambas partes, la creación de un canal requiere el permiso de ambas cadenas.

Autenticación para un historial coherente

Un fork de la relay chain de Polkadot define un posible historial de Polkadot. Para las parachains que se refieren a un historial de la relay chain en particular, queremos actuar sobre esos mensajes y solo aquellos que se enviaron en este historial. Esto significa que debemos usar la relay chain para autenticar mensajes. Para que esto sea eficiente y escalable, lo hacemos lo más liviano en computación y almacenamiento de datos como sea posible para la relay chain. Para autenticar mensajes, un collator puede incluir mensajes en un bloque de PoV (Proof-of-Validity) de la siguiente manera:

Un collator debe averiguar de la relay chain cuáles son los últimos mensajes para su parachain, y luego intentar obtener esos mensajes de la parachain de envío. Pueden obtenerlos de validadores que validaron el parablock de envío, nodos completos de la cadena de envío o nodos de la cadena de recepción que ya los tienen.
El collator necesita obtener suficientes datos de la relay chain y de la cadena de envío para producir una prueba de que recibió los mensajes correctos como en el paso anterior. Los mensajes se distribuyen junto con las pruebas de mensajes, que contienen los datos de la cadena de envío.

Una vez incluidos, la parachain actuará sobre los mensajes en orden.

Perfil de uso esperado

Cada parachain de envío puede enviar hasta ~ 1 MB por altura de cadena en total, a todos las parachains. En el caso más desequilibrado, esto será todo para una sola cadena receptora.

En todas las cadenas, entonces, el peor de los casos es que las parachains (C-1) enviarán cada una ~ 1 MB al mismo receptor parachain en un solo bloque; sin embargo, no es necesario que todo esto se distribuya durante el intervalo de tiempo de ese bloque; consulte "fairness" más arriba.

Networking

Consulte XCMP networking.

Recursos

https://app.subsocial.network/@PolkadotEspanol/cross-chain-message-passing-xcmp-18915

Gavin Wood presenta el esquema de cross-chain messaging (XCMP) de Polkadot. (Ingles) Pueden activar los subtítulos en español

Cómo funciona HRMP en Rococo. (Ingles) Pueden activar los subtítulos en español

Cross-chain Message Passing Protocol. (Ingles) Pueden activar los subtítulos en español