Insights técnicos Novo progresso da Polkadot: Asset Center suporta reserva de ativos multicadeia

Escrito por Joe Petrowski, Web3 Foundation System Parachain Team Leader

Compilado pela Comunidade OneBlock

A grande maioria das pessoas está acostumada a identificar ativos por nome ou símbolo, como "Tether" ou "USDT". Se você está familiarizado com Ethereum, você está acostumado a 0x endereços de contrato.

Na Polkadot, o Asset Hub hospeda a funcionalidade de ativos diretamente no protocolo, usando inteiros simples como IDs de ativos. O nome "1984" é um pouco atrevido, mas é certamente mais fácil para os humanos se lembrarem (e verificarem) do que 0xdAC17F958D2ee523a2206206994597C13D831ec7.

Polkadot agora tem outra instância paralela desse ativo funcional, exceto que essa instância usa uma primitiva XCM chamada multilocation para identificar o ativo. Através desta explicação, espero transmitir que este recurso cria um modelo expressivo e poderoso para a utilização de ativos dentro e dentro da rede Polkadot.

! [Técnico Detalhado Polkadot Novo Progresso: Asset Center Suporta Reserva de Ativos Multi-cadeia] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-310f5be259-dd1a6f-69ad2a.webp)

"Multi-localização" reconhecívelAtivos locais e externos

Quando o Asset Center foi lançado pela primeira vez, ele hospedava apenas uma instância do palete de Ativos, permitindo que qualquer pessoa reivindicasse um ID de ativo disponível e criasse seus ativos. Em vez de ter um contrato personalizado para cada ativo, o Asset Center incorpora a lógica de ativos como uma primitiva de primeiro nível. Cada ativo tem a mesma funcionalidade.

Esses ativos exigíveis, baseados em ID de ativos inteiros, são chamados de ativos locais. Os centros de ativos são usados principalmente por criadores desses ativos, geralmente stablecoins lastreados em reservas, como USDT. No entanto, o protocolo só impõe a exclusividade de IDs de ativos, neste caso inteiros. Os criadores podem definir metadados, como símbolos de ativos. Portanto, os usuários ainda precisam fazer alguma diligência sobre o ativo; Qualquer pessoa pode nomear seu ativo USDT, mas os usuários geralmente querem escolher USDT criado pela Tether.

O Asset Center atua como um "portal de gerenciamento" para criadores de ativos, permitindo que eles cunham e queimem tokens e conheçam a emissão total em toda a rede Polkadot, incluindo tokens que foram enviados para outros locais da rede.

Mas os IDs de ativos em si não são muito expressivos. Embora seja mais fácil de verificar do que o endereço do contrato, o ID não transmite nenhuma informação sobre o ativo ao usuário. É aqui que é a vez do XCM (Cross-Consensus Message Format).

Multi-location expressa caminhos relativos. A sua posição em relação à explicação: "Como chego ao supermercado" terá direções diferentes dependendo do local de partida. No nível mais básico, esses caminhos representam a direção para outras cadeias, e também podem expressar a direção de quase tudo: ativos, contratos, índices de painéis, órgãos de governança, contas e assim por diante.

Um multilocal tem uma série de interseções, geralmente divididas em duas partes: "pais" e caminhos estendidos, como "pais: 1, interior: Parachain(9.000)". Isso significa "ir para o meu pai, e de lá para parachain 9.000". Aqui, o "pai" é um sistema que contém consenso. Por exemplo, uma cadeia de relé é um sistema de consenso que contém parachains, enquanto uma parachain pode ser um sistema de consenso que contém contratos inteligentes. Neste exemplo, vários locais podem vir de outra parachain, como um centro de ativos. Parachain 9.000 será um par de irmãos porque compartilham o mesmo pai, a cadeia de revezamento.

Como identificadores de ativos, vários locais têm vantagens significativas sobre os identificadores absolutos (por exemplo, endereço, hash, inteiro). Em primeiro lugar, as múltiplas localizações de um ativo são, elas próprias, indicativas da entidade controladora. No exemplo acima está a governança de Parachain 9.000. Ao visualizar identificadores absolutos, os usuários devem confiar na entidade emissora e em suas declarações, como tokens on-chain e ativos off-chain um a um. Multi-posição inclui parachains, contratos inteligentes ou outros protocolos, o que realmente indica a lógica de controle de ativos. No entanto, isso não significa que os usuários podem desistir de todas as diligências necessárias, como parachain 9.000 pode ter um "superusuário" confiável. Mas a multilocalização é capaz de comunicar ao usuário por qual protocolo o ativo é controlado.

Além do ponto final de várias posições, ele realmente esclarece a "cadeia de comando". Para um exemplo mais longo, parachain 9.000 ativos com ID 42: "pais: 1, interior: Parachain(9.000), PalletIndex(99), GeneralIndex(42)". Este ativo é controlado por um palete que fica dentro do consenso da parachain, que por sua vez reside dentro do consenso do pai compartilhado (a cadeia de retransmissão). Multi-localização pode até representar um sistema de consenso completamente externo, como "pais: 2, interior: GlobalConsensus (Ethereum)". De uma perspetiva parachain, isso significa "subir dois níveis (ou seja, acima da cadeia de retransmissão) e, em seguida, entrar no consenso do Ethereum".

Esses locais são muito semelhantes aos caminhos de arquivos Unix, como ": /Parachain (9000)/PalletIndex (99)/GeneralIndex (42)" ou ".. /.. /GlobalConsensus (Ethereum)"。

Em última análise, o centro de ativos da Polkadot pode representar qualquer ativo acessível a partir da Polkadot. Seja invocado por meio de um painel ou contrato local, XCMP ou bridge, token nativo de protocolo ou outros ativos locais da cadeia, o Asset Center fornece uma interface comum para todos os ativos, e o identificador do ativo comunica sua localização soberana.

Dois tipos de relações de transferência de ativos: **Transferência e reserva

A linguagem XCM tem duas maneiras de expressar a relação de transferência de ativos de localização/par: teleportes e reservas. Estes definem a relação entre o centro de ativos e outras cadeias e como elas interagem.

**A transmissão é simples. Quando duas cadeias confiam uma na outra para um determinado ativo, o remetente pode simplesmente destruí-lo e emitir uma instrução do recetor para cunha-lo. Desde que o remetente confie que o recetor não irá cunhar mais do que o número enviado, o remetente pode aceitar a mesma instrução de transmissão.

**As reservas são mais complexas. Quando a cadeia da qual o ativo se origina não confia em outra cadeia, ela pode colocar o ativo na conta soberana da cadeia de destino e enviar uma mensagem para a cadeia de destino indicando que o ativo foi registrado em sua conta local. A cadeia alvo pode então cunhar ativos derivados para seus usuários. Quando a reserva estiver completa, a cadeia de destino pode enviar uma mensagem de resposta instruindo a cadeia de origem a mover o ativo para fora de sua conta (supondo que tenha destruído o ativo derivado correspondente).

No caso das reservas, a relação de confiança é unidirecional. A cadeia de ativos derivados cunhados confia na cadeia de emissão para manter o saldo da sua conta soberana e respeitar os reembolsos. No entanto, a cadeia emissora não confia na cadeia de destino para lidar com os ativos com verdade.

Uma coisa a notar aqui é que as relações de confiança existem em pares de localização/ativos: ou seja, uma cadeia pode confiar em outra cadeia para entregar certos ativos, mas não para transferir outras coisas.

Então, quem confia em quem? Em que confiar? As entidades confiam sempre no seu "pai" no paradigma multi-localização. Por exemplo, um contrato inteligente localizado em Parachain 8.000 confia na governança de Parachain 8.000, enquanto Parachain 8.000 confia na Polkadot Relay Chain. As cadeias de relé Polkadot são regidas pela "origem raiz" e podem executar qualquer instrução, incluindo chutar parachains para fora. O Root Origin da Polkadot também gerencia todas as suas parachains de sistema (na verdade, a cadeia de relé mais todas as parachains de sistema podem ser pensadas como um único "protocolo Polkadot").

Todas as cadeias e subprotocolos na rede Polkadot, como contratos inteligentes, confiam no Polkadot, por isso devem ser capazes de transferir ativos com o protocolo. Na verdade, seria tolice usar reservas: se Polkadot não gosta de seu saldo de reservas na cadeia de origem, ele pode reescrever diretamente seu saldo favorito através de um referendo de origem raiz.

Por outro lado, Polkadot não pode estender essa confiança universal aos seus membros. Mas ele pode confiar em um local para gerenciar ativos que se originam desse local. O protocolo pode confiar no Parachain 9.000 para gerenciar seu token nativo (PNT, "pint"?). ) e ativos criados nele, como tokens emitidos localmente. Portanto, ao interagir com Parachain 9.000, o Asset Center transmitirá um PNT para reconhecer que o PNT se originou dessa parachain. Para Parachain 9.000, o centro de ativos usará a transferência de reserva de PET (Parachain 8.000 tokens, menos ambíguo).

**Asset Center serve como posição de reserva, **Ativos ilimitados interativos

A criação do PET é controlada pela governança da Parachain 8.000, que aceita a governança do protocolo Polkadot. Portanto, Polkadot naturalmente confiou no PET da Parachain 8.000, que faz parte do protocolo Parachain 8.000. Mas nem Polkadot nem Parachain 8.000 confiam em outros parachains para atuar como posições de reserva para o PET.

(* Nota: A confiança, no entanto, também é uma opção: Parachain 8.000 pode ter outros irmãos que se identificam com suas origens de governança, assim como muitas cadeias de sistema reconhecem as origens do Polkadot OpenGov. A este respeito, é melhor considerar um sistema soberano que possa conter várias cadeias, em vez de cadeias separadas. ）

Este conceito estende-se ao longo da cadeia de comando a outros ativos criados dentro do Parachain 8.000. Na prática, isso não tem nada a ver com cadeias independentes ou assincronia; Dois contratos inteligentes na mesma cadeia podem não confiar um no outro para gerenciar os ativos um do outro, mas ambos confiam na cadeia em que existem.

Dada essa relação de confiança bidirecional, o Asset Center pode atuar como um destino para ativos de reserva. A Parachain 8.000 pode transferir seu PET para o centro de ativos, que pode atuar como um local de reserva para transferências entre outros locais. Isso significa que a Parachain 9.000 pode usar o centro de ativos como um local de reserva para seu PET enviar para outras parachains.

No entanto, esses outros locais agora podem considerar tanto o Parachain 8.000 quanto o Asset Center como locais de reserva para PET.

Na prática, os protocolos (parachains, contratos inteligentes, etc.) que desejam usar centros de ativos dessa forma exigirão a ideia de gerenciar vários locais de reserva para um determinado ativo. Na prática, isso pode significar escolher um local de reserva para cada ativo, e protocolos e padrões comuns entre paracadeias e outros protocolos também simplificarão sua interação.

Existem milhares de protocolos na rede Polkadot, e estabelecer canais de comunicação com todos os protocolos é complicado, indesejável ou impraticável. Só porque um protocolo não quer estabelecer um canal de comunicação com todos os protocolos, ele ainda pode querer acesso livre aos ativos. Como o Asset Center pode representar e atuar como um local de reserva para qualquer ativo acessível da rede Polkadot, não apenas ativos dentro da rede Polkadot, o centro de ativos pode atuar como um único local de reserva a partir do qual um protocolo pode gerenciar e interagir com um número quase ilimitado de ativos.

Prática de código: Transferir ativos parachain para o Asset Center**

Vejamos um exemplo de como escrever um programa XCM que entrega ativos parachain para o centro de ativos. Para os desenvolvedores que desejam adicionar essa lógica aos parachains, há duas coisas a serem observadas.

Primeiro, a execução de um programa XCM é em termos de execução da instância do programa, não a origem do programa. Isso significa que o aplicativo deve enviar programas que fazem referência a ativos e locais da perspetiva do hub de ativos.

Em segundo lugar, pagar a taxa pode não ser fácil. Ao transferir DOTS entre cadeias de sistema, ou usando instruções de reserva para cadeias que mantêm DOTs em contas soberanas, esses aplicativos podem pagar taxas usando os ativos que estão negociando. No entanto, o Asset Center pode não aceitar os ativos do seu aplicativo para pagar taxas, portanto, seu aplicativo precisa pagar por taxas com ativos aceitáveis. Adicionar a Conversão de Ativos tornará o processo mais simples e flexível, mas a cadeia ainda precisará lançar pares de transações que possam pagar taxas.

Comece nosso processo definindo alguns ativos: DOT e parachain 9.000 PINTs de ativos nativos e o beneficiário do ativo recetor:

! [Técnico Detalhado Polkadot Novo Progresso: Asset Center Suporta Reserva de Ativos Multi-cadeia] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-6f1578732f-dd1a6f-69ad2a.webp)

Antes de criar um programa que é enviado para o centro de ativos, o remetente precisa manter uma conta dos ativos que está transferindo. Uma corrente também pode ser configurada com seus atuadores XCM para um manuseio mais elegante.

! [Técnico Detalhado Polkadot Novo Progresso: Asset Center Suporta Reserva de Ativos Multi-cadeia] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-706b50806e-dd1a6f-69ad2a.webp)

Agora, comece a criar o programa XCM que você enviou para o Asset Center:

! [Técnico Detalhado Polkadot Novo Progresso: Asset Center Suporta Reserva de Ativos Multi-cadeia] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-4a86958556-dd1a6f-69ad2a.webp)

Este programa retirará o DOT da conta soberana parachain para comprar os pesos necessários para realizar o procedimento, receber os PINTs enviados, reembolsar quaisquer pesos não utilizados e, finalmente, depositar dois ativos (retirando o DOT mais todas as alterações nos PINTs) na conta do beneficiário.

Tenha em mente que o remetente pode precisar fazer algum trabalho de contabilidade antes de enviar esta mensagem. Este tipo de construção de programas não deve ser fornecido diretamente ao usuário, mas após a inspeção adequada de programas externos. É quase certo que o remetente não é um transmissor confiável do DOT, em vez disso, o remetente pode transmitir ambos os ativos e pode não ter DOT em sua conta soberana para retirada.

Isso significa que eles podem ter um DOT derivado lastreado em ações em sua cadeia local. Levante este DOT da sua conta soberana e transfira-o para o pagamento da taxa, e o beneficiário reduzirá as suas reservas. Portanto, o remetente deve destruir a descrição deste suporte de reserva antes de enviar esta mensagem, para que sua cadeia não tenha garantias completas na reserva. O remetente pode deduzir do usuário que iniciou a transferência, ou manter sua própria biblioteca DOT para extração (e ocasionalmente reabastecer a reserva). Para obter um exemplo mais completo, consulte Contabilidade feita em Trapista:

🔗

Conclusão

Adicionar ativos externos ao centro de ativos abre novos paradigmas, como vários locais como identificadores de ativos e vários locais de reserva, permitindo uma interação expressiva e conveniente dentro da rede.

A Parity lançará mais exemplos e tutoriais nos próximos meses para demonstrar alguns padrões comuns para trabalhar com ativos externos. Os desenvolvedores do Parachain devem ficar de olho no Trappist no Rococo, enquanto os desenvolvedores de carteira/integração devem ficar de olho nas APIs de transferência de ativos:

🔗