Mensagens de consenso cruzado (XCM)

Introdução

A arquitetura de Polkadot permite que as parachains se comuniquem nativamente umas com as outras, permitindo a transferência de qualquer tipo de dados ou ativos entre blockchains .

Para fazer isso, oformato Cross-Consensus Message (XCM) define uma linguagem sobre como a transferência de mensagens entre duas blockchains deve ser realizada. O XCM não é específico para Polkadot, pois visa ser uma linguagem genérica e extensível entre diferentes sistemas de consenso.

Este artigo é uma breve introdução e visão geral do XCM e outros elementos relacionados. Mais informações podem ser encontradas no Wiki do Polkadot .

Definições Gerais do XCM

XCM — significa Cross-Consensus Messaging, ou mensagem de consenso cruzado, e é uma maneira geral para os sistemas de consenso se comunicarem entre si.

VMP — significa vertical message passing, ou passagem vertical de mensagens, e permite que as parachains troquem mensagens com a Relay Chain. O UMP (upward message passing, ou passagem de mensagem ascendente) permite que as parachains enviem mensagens para sua cadeia de retransmissão, enquanto o DMP (downward message passing ou passagem de mensagem descendente) permite que a cadeia de retransmissão(Relay Chain) passe mensagens para uma de suas parachains

XCMP — significa cross-consensus message passing ou passagem de mensagens de consenso cruzado, e permite que as parachains troquem mensagens com outras parachains na mesma cadeia de retransmissão.

HRMP — significa horizontal relay-routed message passing, ou passagem horizontal de mensagens roteadas por retransmissão, e é um protocolo “tapa buraco” enquanto uma implementação completa do XCMP não é lançada. Mesma interface do XCMP, mas as mensagens são armazenadas na cadeia de retransmissão (Relay Chain).

Multilocation — uma maneira de especificar um local em todo o ecossistema da RelayChain/Parachain a partir de uma determinada origem relativa ou absoluta. Por exemplo, ele pode ser usado para especificar uma parachain, ativo, conta ou até mesmo um pallet específico dentro de uma parachain. Em termos gerais, um Multilocation é definida com um parentse um interior. Parents indica quantos "saltos" na blockchain pai você precisa realizar de uma determinada origem. O interior, indica quantos campos você precisa para definir o ponto de destino. Por exemplo, para localizar a parachain com ID 1000de outra parachain, o Multilocation seria:

{ "parents": 1, "interior": { "X1": [{ "Parachain": 1000 }]}}

Protocolos de transporte XCM

Polkadot implementa dois protocolos de consenso cruzado para atuar na troca de mensagens XCM entre as parachains:

Vertical Message Passing (VMP) — dividido em dois tipos de protocolos de transporte de passagem de mensagens:

• Upward Message Passing (UMP) — permite que as parachains enviem mensagens para sua cadeia de retransmissão, por exemplo, da Moonbeam para Polkadot.
• Downward Message Passing (DMP) — permite que a cadeia de retransmissão passe mensagens para uma de suas parachains, por exemplo, da Polkadot para Moonbeam.

Cross-Chain Message Passing (XCMP) — permite que duas parachains troquem mensagens desde que estejam ligadas à mesma RelayChain/cadeia de retransmissão. As transações entre cadeias são resolvidas usando um mecanismo simples de enfileiramento baseado em uma árvore Merkle para garantir a fidelidade. Os Collators trocam mensagens entre parachains, enquanto os validadores da relay chain irão verificar se a transmissão da mensagem aconteceu.

Observação

Atualmente, enquanto o XCMP está sendo desenvolvido, há um protocolo paliativo em funcionamento chamado Horizontal Relay-routed Message Passing (HRMP), no qual as mensagens são armazenadas e lidas na cadeia de retransmissão. Esse protocolo será desprezado no futuro para a implementação completa do XCMP.

Os dois casos de uso mais comuns para mensagens XCM, pelo menos nos estágios iniciais são:

Teletransporte de Ativos — consiste em mover um ativo de uma blockchain para outra, destruindo a quantidade que está sendo transferida na cadeia de origem e criando um clone (mesma quantidade destruída) na cadeia de destino. Nesses casos, cada cadeia mantém o ativo nativo como reserva, semelhante a um mecanismo de bridge burn-mint(queima-minta). O modelo requer um certo grau de confiança, pois uma das cadeias pode criar ativos maliciosamente.

Transferências remotas — consistem em mover um ativo de uma blockchain para outra por meio de uma conta intermediária na cadeia de origem que pertence à cadeia de destino. Essa conta intermediária é conhecida como conta “Soberana”. Nesses casos, o ativo da cadeia de origem não é destruído, mas mantido na conta Soberana. A execução do XCM na cadeia de destino cria uma representação encapsulada (também chamada de ativo “virtual” ou cross chain) para um endereço de destino. A representação encapsulada é sempre intercambiável em uma base de 1:1 com o ativo nativo. Isso é semelhante a um mecanismo de bridge lock-mint/burn-unlock.

Um artigo muito mais detalhado sobre o XCM pode ser encontrado no Polkadot Wiki .

Inicialmente, a Moonbeam suportará apenas transferências remotas. Todos os ativos de cadeia cruzada na Moonbeam serão conhecidos como xc + TokenName . Por exemplo, a representação KSM de Kusama em Moonriver será conhecida como xcKSM . Você pode ler mais sobre o padrão XC-20 aqui .

Os desenvolvedores devem compreender que o envio de mensagens XCM incorretas pode resultar na perda de fundos. Consequentemente, é essencial testar os recursos do XCM em uma TestNet antes de passar para um ambiente de produção.

Registro de canal

Antes que duas cadeias possam iniciar a comunicação, um canal de mensagens deve ser aberto. Os canais são unidirecionais, ou seja, um canal da cadeia A para a cadeia B pode passar apenas mensagens de A para B. Consequentemente, as transferências de ativos serão possíveis apenas das cadeias A para B. Portanto, dois canais devem ser abertos para enviar mensagens (ou transferir ativos), um de ida e um de volta.

Um canal XCMs entre a cadeia de retransmissão e parachain é aberto automaticamente quando uma conexão é estabelecida. No entanto, quando a parachain A deseja abrir um canal de comunicação com a parachain B, a parachain A deve enviar um extrínseco de canal aberto em sua rede. Este extrínseco também é um XCM! O destinatário deste XCM é a cadeia de retransmissão, e o extrínseco deve inclui informações como:

• O destino onde a mensagem será executada (cadeia de retransmissão neste caso)

• A conta que pagará as taxas (pagas no token da cadeia de retransmissão)

• As taxas que a transação pode consumir quando executada

• Dados de chamada codificados tais como:

• Método/Função a ser chamado na cadeia de retransmissão (open channel).

• ID da parachain destino (parachain B neste exemplo).

• Número máximo de mensagens na fila de destino.

• Tamanho máximo das mensagens a serem enviadas.

As taxas de transação são pagas na representação cross-chain (xc) do ativo da cadeia de retransmissão ( xcRelayChainAsset ). Por exemplo, para Kusama/Moonriver, as taxas de transação seriam pagas em xcKSM . Portanto, a conta que paga as taxas deve ter o xcRelayChainAsset suficiente . Isso pode ser resolvido no Moonbeam/Moonriver com taxas de mensagens XCM , que são pagas no ativo da cadeia de origem, enviadas para o tesouro, e usando a conta do tesouro para pagar o registro extrínseco do canal.

Embora a parachain A tenha expressado suas intenções de abrir um canal XCM com a parachain B, esta última não sinalizou para a cadeia de retransmissão suas intenções de receber mensagens da parachain A. Portanto, para ter um canal estabelecido, a parachain B também deve enviar uma mensagem extrínseca (que também é um XCM) para a cadeia de retransmissão. O canal de aceitação do extrínseco é semelhante ao anterior. No entanto, os dados de chamada codificados incluem apenas o novo método (accept channel) e o ID da parachain remetente (parachain A neste exemplo). Uma vez que ambas as parachains concordam, o canal é aberto na próxima mudança de época.

Todas as ações mencionadas acima podem ser executadas via SUDO (se disponível), ou via Governança(comitê técnico ou referendos).

Uma vez que o canal é estabelecido, os ativos precisam ser registrados antes de serem transferidos através do XCMs, seja inserido no tempo de execução como uma constante ou por meio de um pallete. O processo de registro de ativos para Moonbeam é explicado na próxima seção.

Registro de Ativos XCM

Uma vez que um canal é estabelecido entre parachains (ou relay chain-parachain), o registro de ativos pode acontecer.

Em geral, o registro de ativos pode acontecer em tempo de execução, o que significa que é necessário um upgrade em tempo de execução, após o qual o ativo é registrado e suportado pelo XCM. No entanto, o Moonbeam incluiu um palete de substrate para lidar com o registro de ativos sem a necessidade de atualizações em tempo de execução, tornando o processo muito mais simples.

Ao registrar um ativo XCM, o extrínseco deve incluir (entre outras coisas):

• ID da Parachain onde o recurso de origem está localizado

• Tipo de ativo. No momento da escrita, você pode registrar o token parachain nativo ou um ativo criado por meio do Pallet Assets , fornecendo seu índice

• Um nome de recurso, símbolo e contagem decimal.

• Saldo mínimo

Após o registro do ativo XCM, as unidades por segundo de execução devem ser definidas. Esta é uma métrica usada para cobrar a execução da mensagem XCM recebida na parachain alvo, semelhante às taxas de gás no mundo Ethereum. No entanto, as taxas podem ser cobradas em outro token, por exemplo, DOT. Se a quantidade de tokens enviados pelo XCM não for suficiente para cobrir a execução do XCM, a transação do XCM falhará e a taxa gasta NÃO será reembolsada.

Uma vez que o canal tenha sido estabelecido com sucesso, o ativo XCM registrado na parachain de destino e as unidades por segundo de execução tenham sido definidas, os usuários podem iniciar a transferência de ativos.

Todas as ações mencionadas acima podem ser executadas via SUDO (se disponível), ou via Governança(comitê técnico ou referendos).

Moonbeam e XCM

Como a Moonbeam é um parachain dentro dos ecossistemas Polkadot, uma das implementações mais diretas do XCM é permitir a transferência de ativos de Polkadot e outras parachains de/para o Moonbeam. Isso permitirá que os usuários tragam seus tokens para o Moonbeam e todos os seus dApps.

Expandindo os recursos exclusivos da compatibilidade com Ethereum da Moonbeam, os ativos estrangeiros(da Ethereum) são representados por meio de uma interface padrão ERC-20 através de um contrato pré-compilado. Os ativos XCM na Moonbeam são chamados de XC-20s para diferenciar ativos XCM nativos dos ERC-20 gerados via EVM. O contrato pré-compilado acessa as funções do Substrate para realizar as ações necessárias. No entanto, do ponto de vista de um desenvolvedor, os XC-20s são tokens ERC-20 com o benefício adicional de serem um ativo de cadeia cruzada XCM, e os dApps podem suportá-los facilmente por meio de uma interface ERC-20 comum.

A pré-compilação em si não suporta transferências entre cadeias para ficar o mais próximo possível da interface ERC-20 original. Consequentemente, os desenvolvedores terão que confiar na API do Substrate e no XCMs para mover os ativos de volta para a cadeia original, ou em um contrato pré-compilado diferente para acessar recursos baseados em XCM da API Ethereum.

Dependendo do blockchain de destino, as transferências de ativos podem ser feitas por teletransporte ou transferências remotas, sendo este último o método mais comumente usado. Inicialmente, a Moonbeam suportará apenas transferências remotas.

As seções a seguir fornecem uma visão geral de alto nível dos dois casos de uso iniciais do XCM no Moonbeam: transferências de ativos de/para Polkadot (via VMP) e transferências de ativos de/para outras parachains (via XCMP).

Moonbeam e polkadot

Como Moonbeam é uma parachain dentro do ecossistema Polkadot, o conjunto XCM + VMP irá permitir transferências de DOTs nos dois sentidos entre Polkadot e Moonbeam. Esta seção apresenta uma visão geral de todas as ações envolvidas durante a execução de tais mensagens XCM.

Uma vez que um projeto é integrado como uma parachain, ele automaticamente possui um canal de comunicação bidirecional com a cadeia de retransmissão. Portanto, não há necessidade de registro da cadeia. No entanto, o token nativo da cadeia de retransmissão precisa ser registrado na parachain.

Alice (Polkadot) quer transferir uma certa quantidade de DOTs da Polkadot para sua conta na Moonbeam, chamada Alith. Portanto, ela inicia uma mensagem XCM que expressa suas intenções. Para tais transferências, Moonbeam possui uma conta soberana na Polkadot.

Consequentemente, a execução da mensagem XCM na Polkadot transferirá a quantidade definida de DOTs para a conta Soberana de Moonbeam na Polkadot. Uma vez que os ativos são depositados, a segunda parte da mensagem é enviada para Moonbeam.

Moonbeam executará localmente a ação para a qual a mensagem XCM está programada. Neste caso, é cunhar e transferir a mesma quantidade de xcDOTs (cross-chain DOTs) para a conta definida por Alice, que neste caso é Alith. A taxa para executar o XCM na parachain alvo é paga no ativo que está sendo transferido ( xcDOTs para este exemplo).

Observe o seguinte:

• As contas de Alice e Alith podem ser diferentes. Por exemplo, as contas da Polkadot são SR25519 (ou ED25519), enquanto as da Moonbeam são contas ECDSA (estilo Ethereum). Eles também podem ter proprietários diferentes

• Existe um certo grau de confiança, onde uma cadeia depende da outra para executar sua parte da mensagem XCM. Isso é programado em nivel execução, para que possa ser facilmente verificado

• Para este exemplo, os DOTs de cadeia cruzada ( xcDOTS ) são uma representação embrulhada dos DOTs originais mantidos na conta Soberana de Moonbeam na Polkadot. xcDOTs podem ser transferidos dentro da Moonbeam a qualquer momento, e também podem ser trocados por DOTs em uma base de 1:1.

Alith depositou seus xcDOTs em um pool de liquidez. Em seguida, Charleth adquire alguns desses xcDOTs trocando contra esse pool de liquidez e deseja transferir os xcDOTs para a conta Polkadot de Charley. Portanto, ele inicia um XCM que comunica suas intenções.

Consequentemente, a execução da mensagem XCM no Moonbeam queimará o número de xcDOTs . Uma vez que os ativos são queimados, a segunda parte da mensagem é enviada à Polkadot.

Polkadot executará localmente a ação que a mensagem XCM indicando. Neste caso, é transferir DOTs, na mesma quantidade de xcDOTs queimados, da conta Soberana Moonbeam para a conta definida por Charleth, que neste caso é Charley.

Moonbeam e outras Parachains

Como Moonbeam é uma parachain dentro do ecossistema Polkadot, XCM + XCMP irá permitir transferências de ativos nos dois sentidos entre Moonbeam e outras parachains. Esta seção apresenta uma visão geral das principais diferenças em comparação com XCMs entre Polkadot e Moonbeam.

O primeiro requisito é que exista um canal entre as parachains e que o ativo que está sendo transferido seja registrado na parachain de destino. Somente quando ambas as condições são atendidas, XCMs podem ser trocados entre as parachains.

Então, quando Alith (Moonbeam) transfere GLMRs da Moonbeam para uma conta (Alice) em outra parachain, os tokens são enviados para a Conta Soberana pertencente à parachain alvo na Moonbeam.

Como a mensagem XCM é executada na parachain de destino, espera-se que esta cunhe e transfira a mesma quantidade de xcGLMRs (cross-chain GLMRs) para a conta definida por Alith, que neste caso é Alice. A taxa para executar o XCM na parachain de destino é paga no ativo transferido ( xcGLMRs para este exemplo).

O processo é semelhante para xcGLMRs voltarem ao Moonbeam, conforme explicado na seção anterior. Primeiro, a execução da mensagem XCM queima o número de xcGLMRs retornados ao Moonbeam. Uma vez queimada, a parte remanescente da mensagem é enviada para Moonbeam através da cadeia de retransmissão. A Moonbeam executará localmente as mensagens XCM e transferirá GLMRs (na mesma quantidade de xcGLMRs queimados ) da conta Soberana da parachain de destino para o endereço especificado.

Artigo original em: Cross-Consensus Messaging (XCM)

---

Giorge Abdala

Twitter: https://twitter.com/AbdalaGiorge

Wallet DOT: 16XUE2ByWUV3xU3Lmpi2fiba122ZgnARFZcHyY7QxXB468uv

Formado em TI pela UFPR, com pós graduação em Gestão de Marketing e MBA em Mercado Financeiro. É um membro ativo da comunidade DotSama Brasileira, desenvolvedor de softwares, apaixonado pelo ecosssitema de Polkadot, Kusama e suas parachains. Produz conteúdo original no Medium Blog PolkaMix e traduz conteúdos ainda não traduzidos para o português sobre o mundo DotSama no geral.