El nuevo progreso de Polkadot: Asset Center admite activos multicadena de reserva

Escrito por Joe Petrowski, líder del equipo de Parachain del sistema Web3 Foundation

Compilado por OneBlock Community

La gran mayoría de las personas están acostumbradas a identificar activos por nombre o símbolo, como "Tether" o "USDT". Si estás familiarizado con Ethereum, estás acostumbrado a direcciones de contrato 0x.

En Polkadot, Asset Hub aloja la funcionalidad de activos directamente en el protocolo, utilizando enteros simples como ID de activos. El nombre "1984" es un poco descarado, pero ciertamente es más fácil de recordar (y verificar) para los humanos que 0xdAC17F958D2ee523a2206206994597C13D831ec7.

Polkadot ahora tiene otra instancia paralela de este activo funcional, excepto que esta instancia utiliza una primitiva XCM llamada multilocation para identificar el activo. A través de esta explicación, espero transmitir que esta característica crea un modelo expresivo y poderoso para la utilización de activos dentro y dentro de la red Polkadot.

! [Detalles técnicos de Polkadot New Progress: Asset Center admite activos multicadena de reserva] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-310f5be259-dd1a6f-69ad2a.webp)

"Multi-ubicación" reconocibleActivos locales y externos

Cuando el Centro de activos se lanzó por primera vez, solo alojaba una instancia de la paleta de activos, lo que permitía a cualquier persona reclamar un identificador de activo disponible y crear sus activos. En lugar de tener un contrato personalizado para cada activo, el Centro de activos incorpora la lógica de activos como una primitiva de primer nivel. Cada activo tiene la misma funcionalidad.

Estos activos reclamables, basados en enteros y basados en ID de activos se denominan activos locales. Los centros de activos son utilizados principalmente por los creadores de estos activos, generalmente stablecoins respaldadas por reservas como USDT. Sin embargo, el protocolo solo aplica la unicidad de los identificadores de activos, en este caso enteros. Los creadores pueden establecer metadatos, como símbolos de recursos. Por lo tanto, los usuarios aún deben hacer la debida diligencia sobre el activo; Cualquiera puede nombrar su activo USDT, pero los usuarios generalmente quieren elegir USDT creado por Tether.

El Centro de Activos actúa como un "portal de gestión" para los creadores de activos, permitiéndoles acuñar y quemar tokens y conocer la emisión total en toda la red Polkadot, incluidos los tokens que se han enviado a otras ubicaciones de la red.

Pero los ID de activos en sí mismos no son muy expresivos. Si bien es más fácil de verificar que la dirección del contrato, el ID no transmite ninguna información sobre el activo al usuario. Aquí es donde es el turno de XCM (Cross-Consensus Message Format).

La ubicación múltiple expresa rutas relativas. Su posición en relación con la explicación: "¿Cómo llego al supermercado?" tendrá diferentes direcciones dependiendo de la ubicación de inicio. En el nivel más básico, estas rutas representan la dirección hacia otras cadenas, y también pueden expresar la dirección de casi cualquier cosa: activos, contratos, índices de paneles, órganos de gobernanza, cuentas, etc.

Una multiubicación tiene una serie de intersecciones, generalmente divididas en dos partes: "padres" y rutas extendidas, como "padres: 1, interior: Parachain(9,000)". Esto significa "ir a mi padre, y de ahí parachain 9.000". Aquí el "padre" es un sistema que contiene consenso. Por ejemplo, una cadena de retransmisión es un sistema de consenso que contiene parachains, mientras que una parachain puede ser un sistema de consenso que contiene contratos inteligentes. En este ejemplo, varias ubicaciones pueden provenir de otra parachain, como un centro de activos. Parachain 9,000 será un par de hermanos porque comparten el mismo padre, la cadena de relevos.

Como identificadores de activos, las ubicaciones múltiples tienen ventajas significativas sobre los identificadores absolutos (por ejemplo, dirección, hash, entero). En primer lugar, las múltiples ubicaciones de un activo son en sí mismas indicativas de la entidad controladora. En el ejemplo anterior está la gobernanza de Parachain 9,000. Al ver identificadores absolutos, los usuarios deben confiar en la entidad emisora y sus reclamaciones, como los tokens on-chain y los activos off-chain uno a uno. La multiposición incluye parachains, contratos inteligentes u otros protocolos, lo que en realidad indica la lógica de control de los activos. Sin embargo, esto no significa que los usuarios puedan renunciar a toda la diligencia debida necesaria, como que parachain 9,000 pueda tener un "superusuario" de confianza. Pero la multiubicación es capaz de comunicar al usuario por qué protocolo está controlado el activo.

Más allá del punto final de múltiples posiciones, en realidad aclara la "cadena de mando". Para un ejemplo más largo, parachain 9,000 activos con ID 42: "parents: 1, interior: Parachain(9,000), PalletIndex(99), GeneralIndex(42)". Este activo está controlado por una paleta que se encuentra dentro del consenso de la parachain, que a su vez reside dentro del consenso del padre compartido (la cadena de retransmisión). La ubicación múltiple puede incluso representar un sistema de consenso completamente externo, como "padres: 2, interior: GlobalConsensus (Ethereum)". Desde el punto de vista de la parachain, esto significa "subir dos niveles (es decir, por encima de la cadena de retransmisión) y luego entrar en el consenso de Ethereum".

Estas ubicaciones son muy similares a las rutas de archivo de Unix, como ": /Parachain (9000)/PalletIndex (99)/GeneralIndex (42)" o ".. /.. /GlobalConsensus (Ethereum)"。

En última instancia, el centro de activos de Polkadot puede representar cualquier activo accesible desde Polkadot. Ya sea que se invoque a través de un panel o contrato local, XCMP o puente, token nativo de protocolo u otros activos locales de la cadena, Asset Center proporciona una interfaz común para todos los activos, y el identificador del activo comunica su ubicación soberana.

Dos tipos de relaciones de transferencia de activos: **Transferencia y reserva

El lenguaje XCM tiene dos formas de expresar la relación de transferencia de activos de ubicación/par: teletransportes y reservas. Estos definen la relación entre el centro de activos y otras cadenas y cómo interactúan.

**La transmisión es sencilla. Cuando dos cadenas confían entre sí para un activo determinado, el remitente puede simplemente destruirlo y emitir una instrucción del receptor para acuñarlo. Siempre que el emisor confíe en que el receptor no acuñará más que el número enviado, el remitente puede aceptar la misma instrucción de transmisión.

**Las reservas son más complejas. Cuando la cadena de la que procede el activo no confía en otra cadena, puede depositar el activo en la cuenta soberana de la cadena de destino y enviar un mensaje a la cadena de destino indicando que el activo se ha registrado en su cuenta local. La cadena objetivo puede entonces acuñar activos derivados para sus usuarios. Una vez que se completa la reserva, la cadena objetivo puede enviar un mensaje de respuesta indicando a la cadena de origen que saque el activo de su cuenta (suponiendo que haya destruido el activo derivado correspondiente).

En el caso de las reservas, la relación de confianza es unidireccional. La cadena de activos derivados acuñados confía en la cadena emisora para mantener el saldo de su cuenta soberana y respetar los reembolsos. Sin embargo, la cadena emisora no confía en que la cadena de destino maneje los activos con veracidad.

Una cosa a tener en cuenta aquí es que las relaciones de confianza existen en pares de ubicación/activo: es decir, una cadena puede confiar en otra cadena para entregar ciertos activos, pero no para transferir otras cosas.

Entonces, ¿quién confía en quién? ¿En qué confiar? Las entidades siempre confían en su "padre" en el paradigma de múltiples ubicaciones. Por ejemplo, un contrato inteligente ubicado en Parachain 8,000 confía en la gobernanza de Parachain 8,000, mientras que Parachain 8,000 confía en Polkadot Relay Chain. Las cadenas de retransmisión de Polkadot se rigen por el "origen raíz" y pueden ejecutar cualquier instrucción, incluida la expulsión de parachains. Root Origin de Polkadot también gestiona todas las parachains de su sistema (de hecho, la cadena de retransmisión más todas las parachains del sistema pueden considerarse como un único "protocolo Polkadot").

Todas las cadenas y subprotocolos de la red Polkadot, como los contratos inteligentes, confían en Polkadot, por lo que deberían poder transferir activos con el protocolo. De hecho, sería una tontería usar reservas: si a Polkadot no le gusta su saldo de reservas en la cadena de origen, puede reescribir directamente su saldo favorito a través de un referéndum de origen raíz.

Por otro lado, Polkadot no puede extender esta confianza universal a los miembros que la componen. Pero puede confiar en una ubicación para administrar los activos que se originan en esa ubicación. El protocolo puede confiar en Parachain 9,000 para administrar su token nativo (PNT, ¿"pinta"?). ) y los activos creados en él, como los tokens emitidos localmente. Por lo tanto, al interactuar con Parachain 9,000, el Centro de Activos transmitirá un PNT para reconocer que el PNT se originó a partir de esa parachain. Para Parachain 9,000, el centro de activos utilizará la transferencia de reserva de PET (tokens Parachain 8,000, menos ambiguos).

**El Centro de Activos sirve como posición de reserva, **Activos ilimitados interactivos

La creación de PET está controlada por la gobernanza de Parachain 8,000, que acepta la gobernanza del protocolo Polkadot. Por lo tanto, Polkadot confió naturalmente en el PET de Parachain 8,000, que forma parte del protocolo Parachain 8,000. Pero ni Polkadot ni Parachain 8,000 confían en que otras parachains actúen como posiciones de reserva para PET.

(* Nota: La confianza, sin embargo, también es una opción: Parachain 8,000 puede tener otros hermanos que se identifican con sus orígenes de gobernanza, al igual que muchas cadenas de sistemas reconocen los orígenes de Polkadot OpenGov. En este sentido, es mejor considerar un sistema soberano que pueda contener múltiples cadenas, en lugar de cadenas separadas. ）

Este concepto se extiende a lo largo de la cadena de mando a otros activos creados dentro de Parachain 8,000. En la práctica, esto no tiene nada que ver con cadenas independientes o asincronía; Es posible que dos contratos inteligentes en la misma cadena no confíen el uno en el otro para administrar los activos del otro, pero ambos confían en la cadena en la que existen.

Dada esta relación de confianza bidireccional, el Centro de Activos puede actuar como destino para los activos de reserva. Parachain 8,000 puede transferir su PET al centro de activos, que luego puede actuar como una ubicación de reserva para transferencias entre otras ubicaciones. Esto significa que Parachain 9,000 puede utilizar el centro de activos como ubicación de reserva para que su PET lo envíe a otras parachains.

Sin embargo, estas otras ubicaciones ahora pueden considerar tanto Parachain 8,000 como Asset Center como ubicaciones de reserva para PET.

En la práctica, los protocolos (parachains, contratos inteligentes, etc.) que deseen utilizar los centros de activos de esta manera requerirán la idea de gestionar múltiples ubicaciones de reserva para un activo determinado. En la práctica, esto podría significar elegir una ubicación de reserva para cada activo, y los protocolos y estándares comunes entre las parachains y otros protocolos también simplificarán su interacción.

Hay miles de protocolos en la red Polkadot, y establecer canales de comunicación con todos los protocolos es engorroso, indeseable o poco práctico. El hecho de que un protocolo no quiera establecer un canal de comunicación con todos los protocolos, es posible que desee acceso gratuito a los activos. Dado que el Centro de Activos puede representar y actuar como una ubicación de reserva para cualquier activo accesible de la red Polkadot, no solo los activos dentro de la red Polkadot, el centro de activos puede actuar como una única ubicación de reserva desde la cual un protocolo puede administrar e interactuar con un número casi ilimitado de activos.

Práctica de código: Transferir activos de parachain al Centro de activos**

Veamos un ejemplo de cómo escribir un programa XCM que entregue activos de parachain al centro de activos. Para los desarrolladores que quieran añadir esta lógica a las parachains, hay dos cosas a tener en cuenta.

En primer lugar, la ejecución de un programa XCM se realiza en términos de ejecución de la instancia del programa, no del origen del programa. Esto significa que la aplicación debe enviar programas que hagan referencia a activos y ubicaciones desde la perspectiva del centro de activos.

En segundo lugar, pagar la tarifa puede no ser fácil. Al transferir DOTS entre cadenas del sistema, o al utilizar instrucciones de reserva para las cadenas que tienen DOT en cuentas soberanas, estas aplicaciones pueden pagar tarifas utilizando los activos que están negociando. Sin embargo, es posible que el Centro de recursos no acepte los recursos de la aplicación para pagar las tarifas, por lo que la aplicación debe pagar las tarifas con recursos aceptables. Agregar la conversión de activos hará que el proceso sea más simple y flexible, pero la cadena aún tendrá que lanzar pares de transacciones que puedan pagar tarifas.

Comience nuestro proceso definiendo algunos activos: DOT y parachain 9,000 PIN de activos nativos, y el beneficiario del activo receptor:

! [Detalles técnicos de Polkadot New Progress: Asset Center admite activos multicadena de reserva] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-6f1578732f-dd1a6f-69ad2a.webp)

Antes de crear un programa que se envía al centro de activos, el remitente debe mantener una cuenta de los activos que está transfiriendo. También se puede configurar una cadena con sus actuadores XCM para un manejo más elegante.

! [Detalles técnicos de Polkadot New Progress: Asset Center admite activos multicadena de reserva] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-706b50806e-dd1a6f-69ad2a.webp)

Ahora, comience a crear el programa XCM que envió al Centro de activos:

! [Detalles técnicos de Polkadot New Progress: Asset Center admite activos multicadena de reserva] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-4a86958556-dd1a6f-69ad2a.webp)

Este programa sacará el DOT de la cuenta soberana de parachain para comprar los pesos necesarios para realizar el procedimiento, recibir los PINT enviados, reembolsar los pesos no utilizados y, finalmente, depositar dos activos (sacando el DOT más todos los cambios en los PINT) en la cuenta beneficiaria.

Tenga en cuenta que es posible que el remitente tenga que hacer algún trabajo de contabilidad antes de enviar este mensaje. Este tipo de creación de programas no debe proporcionarse directamente al usuario, sino después de una inspección adecuada de los programas externos. Es casi seguro que el remitente no es un transmisor confiable del DOT, en cambio, el remitente puede transmitir ambos activos y puede no tener DOT en su cuenta soberana para retirarlo.

Esto significa que pueden tener un DOT derivado respaldado por acciones en su cadena local. Retirar este DOT de su cuenta soberana y transferirlo al pago de la cuota, y el beneficiario reducirá sus reservas. Por lo tanto, el remitente debe destruir la descripción de este soporte de reserva antes de enviar este mensaje, para que su cadena no tenga una garantía completa en la reserva. El remitente puede deducir del usuario que inició la transferencia o mantener su propia biblioteca DOT para la extracción (y ocasionalmente reponer la reserva). Para ver un ejemplo más completo, consulte Contabilidad realizada en Trappist:

🔗

Conclusión

La adición de activos externos al centro de activos abre nuevos paradigmas, como múltiples ubicaciones como identificadores de activos y múltiples ubicaciones de reserva, lo que permite una interacción expresiva y conveniente dentro de la red.

Parity publicará más ejemplos y tutoriales en los próximos meses para demostrar algunos patrones comunes para trabajar con activos externos. Los desarrolladores de Parachain deben estar atentos a Trappist en Rococo, mientras que los desarrolladores de billeteras/integraciones deben estar atentos a las API de transferencia de activos:

🔗