Los activos en la red Polkadot pueden estar representados en varias cadenas. También pueden tomar muchas formas, desde un token nativo de una parachain hasta representaciones en la cadena de reservas fuera de la cadena. Esta página se centra en estas últimas, es decir, en los activos que serían emitidos por un creador (por ejemplo, los derechos de las reservas auditadas, fuera de la cadena, que posee el creador, o el arte emitido como NFT).
La parachain Statemint alberga estructuras de datos y lógica que se especializan en la creación, gestión y uso de activos en la red Polkadot. Aunque otras parachains pueden alojar aplicaciones que tratan con activos en Statemint, se puede considerar que Statemint es la “base de operaciones” de los activos en la red.
Statemint utiliza DOT como su token nativo. La cadena cede su gobierno a su cadena matriz Relay Chain, y no tiene inflación ni recompensas basadas en la era para los collators (aunque los collators reciben una parte de las tarifas por transacción). Como parachain de bien común, Statemint tiene una relación de confianza con la Relay Chain, y como tal, puede teletransportar DOT entre sí y la Relay Chain. Es decir, DOT en Statemint es tan bueno como DOT en la Relay Chain.
Statemint no soporta contratos inteligentes. Vea la sección Avanzada en la parte inferior para la discusión sobre el uso de cuentas proxy y multisig para replicar la lógica de los contratos más utilizados.
Activos Fungibles #
Los activos fungibles son aquellos que son intercambiables, es decir, una unidad es equivalente a cualquier otra a efectos de reclamar el artículo subyacente. Statemint representa los activos fungibles en la paleta de Activos. Para quienes estén familiarizados con el estándar ERC20, esta paleta presenta una interfaz similar. Sin embargo, la lógica se codifica directamente en el tiempo de ejecución de la cadena. Como tal, las operaciones no se miden con gas y, en cambio, se evalúan en cada lanzamiento, lo que conduce a una ejecución eficiente y a tarifas de transacción estables.
Creación y Gestión #
Cualquiera en la red puede crear activos en Statemint, siempre que pueda reservar el depósito requerido de 100 DOT. La red reserva el depósito en el momento de la creación. El creador también debe especificar un AssetId
único, un entero de tipo u32
, para identificar el activo. El AssetId
debe ser el identificador canónico de un activo, ya que la cadena no impone la unicidad de metadatos como “nombre” y “símbolo”. El creador también debe especificar un saldo mínimo, lo que evitará que las cuentas tengan saldos dust (ínfimos).
Una clase de activo tiene una serie de funciones privilegiadas. El creador del activo asume automáticamente todos los roles privilegiados, pero puede reasignarlos después de la creación. Estos roles son:
- Propietario
- Emisor
- Administrador
- Freezer
El propietario tiene la capacidad de establecer las cuentas responsables de los otros tres roles, así como establecer los metadatos de los activos (por ejemplo, nombre, símbolo, decimales). El emisor puede acuñar (mint) y quemar (burn) tokens a/desde las direcciones que elija. El freezer puede congelar los activos en las direcciones de destino o en toda la clase de activos. El administrador puede forzar transferencias así como descongelar cuentas de la clase de activos. Consulta siempre la documentación de referencia para tener certeza sobre los roles privilegiados.
Los detalles de un activo contienen un campo al que no puede acceder su propietario o el equipo de administración, el de la suficiencia del activo. Sólo el mecanismo de gobernanza de la red puede considerar que un activo es suficiente. El saldo de un activo no suficiente (el predeterminado) sólo puede existir en cuentas ya existentes. Es decir, un usuario no podría crear una nueva cuenta en la cadena transfiriéndole un activo insuficiente; la cuenta debe existir ya por tener más del depósito existencial en DOT (o un activo suficiente). Sin embargo, los activos considerados suficientes pueden instanciar cuentas. En el futuro, los activos suficientes podrán pagar las tarifas de transacción, de manera que los usuarios puedan realizar transacciones en Statemint sin necesidad de DOT .
Uso #
Los usuarios disponen de una interfaz sencilla, a saber, la posibilidad de transferir saldos de activos a otras cuentas de la cadena. Como ya se ha mencionado, si el activo no es suficiente, la cuenta de destino debe existir ya para que la transferencia tenga éxito.
La cadena también contiene una función transfer_keep_alive
, similar a la de la paleta Balances, que fallará si la ejecución mataría a la cuenta de envío.
Statemint también barre los saldos de dust en las transferencias. Por ejemplo, si un activo tiene un saldo mínimo de 10 y una cuenta tiene un saldo de 25, entonces un intento de transferir 20 unidades en realidad transferiría las 25.
Desarrollo de Aplicaciones #
Statemint proporciona una interfaz approve_transfer
, transfer_approved
y cancel_approval
. Los desarrolladores de aplicaciones pueden utilizar esta interfaz para que los usuarios puedan autorizar a la aplicación a efectuar transferencias hasta un importe determinado en nombre de una cuenta.
Contabilidad Cross – Chain #
Statemint utiliza un sistema de reservas para gestionar las transferencias de activos a otras parachains. Hace un seguimiento de cuánto de cada activo ha ido a cada parachain y no aceptará más de vuelta de un parachain en particular.
Como resultado de esto, los propietarios de activos pueden utilizar Statemint para rastrear información como la emisión total de su activo en toda la red, ya que los saldos de las parachains se incluirían en la tabla respaldada por la reserva. Asimismo, para la acuñación y quema de tokens, el equipo de un activo puede realizar todas las operaciones en Statemint y propagar cualquier token acuñado a otras parachains de la red.
Las parachains que quieran enviar activos a otras parachains deben hacerlo mediante instrucciones a Statemint para que la tabla de reservas se mantenga actualizada. Para más información, consulta la sección “Mover activos entre cadenas en XCM” del artículo sobre el formato XCM.
Activos No Fungibles #
A diferencia de los activos fungibles, la instancia particular de un activo no fungible (NFT) tiene un significado separado de otra instancia de la misma clase. Statemint representa los NFT en la paleta Uniques.
Al igual que la paleta de Activos, esta funcionalidad está codificada en la cadena. Las operaciones se evalúan antes de cada lanzamiento en lugar de cualquier medición en tiempo de ejecución, lo que garantiza una ejecución eficiente y tarifas de transacción estables.
Creación y Gestión #
Cualquiera en la red puede crear una clase de activos, siempre que reserve el depósito requerido de 100 DOT en Statemint. La creación de instancias de una clase también requiere un depósito por instancia, a menos que la gobernanza de la cadena designe la clase como “tenencia libre”, permitiendo que la clase acuñe más instancias sin depósito. El creador debe especificar un ClassId
, que, como su primo AssetId
, debe ser el identificador canónico de la clase.
El creador también puede especificar los mismos roles privilegiados de Propietario, Administrador, Emisor y Freezer.
Las clases e instancias de activos pueden tener metadatos asociados. Los metadatos son un array de datos que el Propietario de la clase puede añadir en la cadena, por ejemplo, un enlace a un hash IPFS u otro servicio de alojamiento fuera de la cadena. La paleta Uniques también permite establecer pares clave/valor como atributos de una clase o instancia.
Uso #
Los usuarios pueden transferir sus NFT a otras cuentas. La cadena también proporciona una interfaz approve_transfer
, transfer_approved
y cancel_approval
que los desarrolladores de aplicaciones pueden utilizar para permitir que los usuarios autoricen a una aplicación a transferir una instancia en su nombre.
Técnicas Avanzadas #
Muchos creadores de activos en otras redes utilizan contratos inteligentes para controlar funciones privilegiadas como la acuñación y la quema. Aunque Statemint no tiene una interfaz de contrato inteligente, contiene las paletas Multisig, Proxy y Utility, que satisfarán la mayoría de las necesidades de gestión de cuentas.
Por ejemplo, si un equipo quiere la aprobación de dos grupos para realizar una operación privilegiada, podría crear un multisig de 2 de 2 a partir de dos proxies anónimos, y luego establecer miembros de cada grupo como proxies de esas dos cuentas.