Tokens Nativos Preguntas Frecuentes
Activos en cadena
P. ¿Cuál es la definición de soporte “multi-activo (MA)” y lo tiene Cardano?
R. El soporte multiactivo (MA) es el nombre de un conjunto de características (funcionalidad) que un libro de contabilidad (blockchain/wallet/criptomoneda/plataforma bancaria) puede proporcionar, lo que le permite hacer la contabilidad o realizar transacciones con más de un tipo de activo.
La función de soporte de MA de Cardano se llama Native Tokens. MA permite a los usuarios realizar transacciones con ada y un número ilimitado de tokens definidos por el usuario. Este soporte es nativo, lo que significa que los tokens pueden ser transaccionados (rastreados/enviados/recibidos) usando el sistema de contabilidad definido como parte de la funcionalidad del libro mayor de la criptomoneda, sin necesidad de contratos inteligentes para habilitar esta funcionalidad.
P. Qué es la tokenización (de activos)?
R. Tokenizar un activo significa crear una representación en la cadena de ese activo.
Acuñación
P. ¿Qué significa “acuñar” un token?
R. La “acuñación” se refiere al proceso por el que se crean o destruyen nuevos tokens. Es decir, la cantidad total en circulación (es decir, sumada en todas las direcciones del libro de contabilidad) del tipo de token que se acuña aumenta o disminuye. La acuñación de una cantidad positiva de tokens es la creación de tokens, y la acuñación de una cantidad negativa es la destrucción de tokens.
P. ¿Qué significa “quemar” un token?
R. La “quema” se refiere al proceso por el que se destruyen los tokens. Es sinónimo de “acuñación negativa”.
P. ¿Qué es la redención de tokens?
R. La redención de tokens es la acción de enviar tokens de vuelta al emisor para ser quemados. Esto se suele hacer cuando los tokens que se canjean ya no tienen un propósito en el libro mayor, y el usuario o el contrato en posesión de ellos no puede (no está autorizado por la política de acuñación) quemar los tokens.
Es posible que no se ofrezca ninguna compensación por redimir los tokens (la decisión depende del emisor de tokens/de la política de redención), pero el usuario puede optar por hacerlo de todos modos para evitar tener tokens inservibles en su wallet.
P. ¿Qué es una transacción de acuñación?
R. Las transacciones tienen una estructura diferente en las eras Shelley, ShelleyMA y Goguen, pero esta estructura es la misma dentro de una misma era. Las transacciones Shelley+MA y Goguen pueden llevar datos que especifican qué tokens están acuñando. Las transacciones en las que este dato de la transacción (llamado campo de acuñación) no está vacío se denominan transacciones de acuñación. Estas transacciones también deben llevar las políticas de acuñación de los tokens que están acuñando, para que puedan ser comprobadas durante la validación.
El resultado de procesar una transacción de acuñación es que el libro mayor contendrá ahora adicionalmente los activos incluidos en el campo de acuñación (minting field) de la transacción. Si la cantidad de un activo concreto en el campo de acuñación es negativa, el resultado es que después de procesar la transacción, la cantidad total de ese activo concreto en el libro mayor se reducirá en la cantidad reflejada en el campo de acuñación.
Obsérvese que una misma transacción puede acuñar tokens asociados a varias políticas de acuñación distintas, por ejemplo, (Policy1, SomeTokens), (Policy2, SomeOtherTokens). Obsérvese también que una transacción puede acuñar simultáneamente algunos tokens y quemar otros.
P. ¿Qué es una política de acuñación?
R. Una política de acuñación es un conjunto de normas que se utilizan para regular la acuñación de los activos asociados a ella (con ámbito de aplicación). Por ejemplo, quién tiene el control (y bajo qué condiciones) sobre el suministro de la moneda, y su acuñación y quema. Estas reglas se refieren al contenido de los datos de la transacción que se intenta acuñar. Por ejemplo, una política de acuñación puede exigir que un determinado conjunto de claves haya firmado la transacción de acuñación.
Este conjunto de reglas es definido por el usuario que desea crear el nuevo activo. Por ejemplo, un usuario puede querer que sólo él mismo pueda acuñar este tipo de token. En este caso, lo estipularía en la política. El nodo comprueba el cumplimiento de las políticas de acuñación cuando se procesa una transacción ejecutando el código o comprobando las firmas pertinentes. Los datos de la transacción deben satisfacer todas las políticas de acuñación de todos los activos que la transacción intenta acuñar.
P. ¿Qué es un token builder y cuál es su funcionalidad?
R. Un token builder es una pieza de software que permite al usuario definir los tokens a acuñar e incluirlos en una transacción de acuñación. También garantiza que se incluyan en la transacción los datos adicionales adecuados necesarios para verificar que la transacción está autorizada a realizar la acuñación (véase la pregunta sobre la política de acuñación más adelante).
Ejemplos de políticas y formas de definirlas
P. ¿Qué es el “multisig” y cómo se relaciona con las políticas de acuñación?
R. El lenguaje de scripting multisig (que existía antes de la introducción de la funcionalidad MA en Cardano) especifica un conjunto mínimo de firmas necesarias para permitir que una transacción realice una determinada acción, normalmente para gastar una entrada UTXO.
Los scripts multisig también pueden utilizarse para especificar las políticas de acuñación más básicas, es decir, las políticas que requieren un conjunto específico de claves para firmar la transacción de acuñación. Por ejemplo, una política de acuñación de un solo emisor puede expresarse utilizando un script multisig. Ten en cuenta que las políticas de acuñación son los únicos tipos de políticas que pueden expresarse utilizando multisig.
Sin la capacidad de contrato inteligente Plutus, o cualquier otra extensión del lenguaje de la política de acuñación, el multisig es la única manera de especificar una política de acuñación.
P. ¿Qué tienen que ver los contratos inteligentes de Plutus con los tokens nativos?
R. Las políticas de acuñación pueden escribirse en el lenguaje de contratos inteligentes de Plutus. Esto permite a los usuarios expresar una gama mucho más amplia de políticas que la política de un solo emisor expresable mediante multisig. La política de acuñación única, por ejemplo, puede expresarse en Plutus (pero no sólo como multisig).
P. ¿Qué es una política de acuñación de un solo emisor?
R. Una política de acuñación de un solo emisor especifica que sólo la entidad que posee un determinado conjunto de claves está autorizada a acuñar tokens bajo una política concreta. Por ejemplo, el conjunto de claves especificado en la política de acuñación debe haber firmado la transacción de acuñación. Este tipo de política se puede especificar utilizando multisig.
Un ejemplo de caso de uso de política de emisor único podría ser el de los tokens que representan tarjetas de béisbol. Esto significaría que no se podrían acuñar nuevos tokens de tarjetas de béisbol sin las firmas de la empresa. A la inversa, la política demuestra que todas los tokens existentes que están bajo esta política han sido acuñados legítimamente por la empresa de tokens de béisbol.
P. ¿Qué es una política de acuñación única?
R. En una política de acuñación única, el conjunto completo de tokens bajo ella se acuña mediante una transacción específica. Esto significa que no se acuñarán más tokens bajo esa política. Este tipo de política requiere contratos inteligentes y no puede ser expresada usando multisig.
Un caso de uso de una política de acuñación única sería acuñar tokens de entradas para un concierto específico. El aforo del local se conoce de antemano, por lo que no habrá necesidad de permitir que se acuñen más entradas.
Estructura, representación y propiedades de los activos múltiples
P. ¿Qué es la fungibilidad y la no fungibilidad?
R. La fungibilidad es una relación entre dos activos/tokens. Se dice que los tokens son fungibles entre sí cuando son intercambiables. Por ejemplo, el dinero fiduciario es fungible, ya que un billete de 10 dólares es intercambiable con todos los demás billetes (reales) de 10 dólares (y todos los conjuntos de 10 billetes de 1 dólar, y todos los pares de 5 dólares).
Los activos no fungibles no son intercambiables entre sí. Por ejemplo, dos diamantes, o dos tokens en la cadena que representan los dos diamantes del mundo real. Si no hay otros activos con los que un token sea fungible -como un token que represente una casa- se considera que el token es único (no fungible).
P. ¿Qué es un paquete de tokens?
R. Una colección mixta de tokens con una o más políticas de acuñación. Cualquier token puede ser agrupado.
Para más detalles, consulta la sección de paquetes de tokens.
Transacciones con tokens nativos
P. ¿Cómo aparecen los tokens nativos en el wallet de un usuario?
R. Antes de la introducción de la funcionalidad MA en el sistema Cardano, el wallet de un usuario contiene tanto las salidas con las direcciones que pertenecen al usuario, como las cantidades de ada que contienen estas direcciones. Por ejemplo, (users_address1, someAdaAmount)
Con el soporte de MA, el wallet del usuario podrá contener múltiples tipos de activos en una sola salida, es decir, el wallet puede contener un paquete de tokens. Esto significa que los wallets pueden contener:
- Activos con diferentes políticas en un solo UTXO (incluyendo ada)
- Activos incluidos en una política, repartidos en múltiples UTXOs
El wallet de un usuario puede contener algo así como:
(users_address1, (adaPolicy, someAdaTokens)) (users_address1, (cryptoDoggie, someDoggies), (adaPolicy, moreAdaTokens)) (users_address2, (cryptoDoggie, otherDoggies), (cryptoBirds, justCockatoos))
En este ejemplo, hay tres políticas: adaPolicy, cryptoDoggie, y cryptoBirds.
P. ¿Los tokens nativos tienen identificadores legibles para el ser humano y otros metadatos?
R. Los nombres legibles para los activos (en lugar de las largas cadenas alfanuméricas de ID de políticas y nombres de activos) pueden registrarse en un servidor de metadatos. Si un usuario utiliza un wallet integrado con un servidor de metadatos, podrá ver los nombres legibles por humanos cuando mire sus activos.
Los usuarios podrán subir los nombres de sus tokens, junto con cualquier otro metadato relativo a los tokens específicos, a un servidor de metadatos. Es posible que haya más de un servidor de metadatos operativo a la vez (incluido uno gestionado por Cardano), por lo que los usuarios tendrán que elegir a qué servidor(es) subir sus metadatos o descargarlos.
Los usuarios también pueden optar por añadir nombres y otros metadatos directamente en el campo de metadatos de la transacción. Esto aumentará las tarifas de las transacciones proporcionalmente al tamaño de los metadatos adicionales.
P. ¿Cuáles son los costos relacionados con la acuñación y el comercio de tokens nativos?
R. Los costos relacionados con los activos múltiples pueden dividirse en dos categorías:
- Tasas: El envío y la acuñación de tokens afecta a las tasas que debe pagar el autor de la transacción. Al igual que con un libro mayor sólo de ada, las tasas se calculan en función del tamaño total de la transacción. También puede haber tasas por comprobar las políticas de acuñación, pero inicialmente sólo se soportan las políticas multisig, que no incurren en tasas adicionales además de las basadas en el tamaño de la transacción.
- Min-ada-value : Cada salida creada por una transacción debe incluir una cantidad mínima de ada, que se calcula en función del tamaño de la salida (es decir, el número de tipos de token diferentes que contiene y la longitud de sus nombres).
Explicación de Min-ada-value :
Recuerda que las salidas pueden contener una colección heterogénea de tokens, incluyendo ada que es un recurso limitado en el sistema Cardano. Exigir que se incluya una cierta cantidad de ada en cada salida del libro de contabilidad (donde esa cantidad se basa en el tamaño de la salida, en bytes) protege el tamaño del libro de contabilidad de Cardano para que no crezca de forma intratable.
Cálculo de Min-ada-value:
La cantidad mínima de ada que debe contener cada UTXO de sólo ada sin datos adicionales (es decir, un UTXO que sólo contiene la dirección y la cantidad de ada) es un parámetro del sistema Cardano: minUTxOValue
El tamaño de tal UTXO tiene un límite superior: adaOnlyUTxOSize
Podemos calcular el límite superior del tamaño de un UTXO u que contenga tokens que no sean ada: sizeBound (u)
Queremos calcular los min-ada requeridos para estar contenidos en u : minAda (u)
Una cantidad minUTxOValue de ada paga por adaOnlyUTxOSize bytes de almacenamiento UTXO en el libro mayor. Para que el valor mínimo de ada sea proporcional para todos los UTXOs, debe cumplirse la siguiente proporción:
minUTxOValue / adaOnlyUTxOSize = minAda (u) / sizeBound (u) Por lo tanto, el cálculo de min-ada para cualquier UTxO es:
minAda (u) = sizeBound (u) * minUTxOValue / adaOnlyUTxOSize
Como consecuencia de este diseño,
- Es imposible hacer salidas que contengan sólo tokens personalizados
- El número de cada tipo de token en una salida no afecta al
min-ada-valuede la salida, pero el número de tipos de token contenidos en una salida aumenta el min-value. - El motivo es que los nombres y los ID de las políticas de cada uno de los tipos de token ocupan un espacio adicional en la salida.
- El envío de tokens personalizados a una dirección siempre implica el envío del valor mínimo de ada a esa dirección junto con los tokens personalizados (incluyendo el ada en la misma salida). Si - la dirección no es gastable por el usuario que envía los tokens, el ada enviado junto a los tokens ya no pertenece al remitente.
- Antes de transferir tokens personalizados, los usuarios pueden optar por utilizar la comunicación fuera de la cadena para negociar quién suministra los ada para cubrir el valor mínimo de los ada en la salida realizada por la transacción de transferencia
- Para recuperar la ada almacenada junto a los tokens personalizados en una salida O, el usuario debe: a) Gastar la salida O, y quemar los tokens personalizados almacenados en ella b) Gastar una salida O y una salida O’, y consolidar los tokens en ella con la misma colección de tipos de tokens personalizados almacenados en otra salida (gastados dentro de la misma transacción) P. ej,
(CryptoDoggiesPolicy, poodle, 1)contenida en O puede consolidarse con(CryptoDoggiesPolicy, poodle, 3)en O’, para un total de(CryptoDoggiesPolicy, poodle, 4)en una nueva salida realizada por la transacción de consolidación. - Dividir los tokens personalizados en más salidas de las que contenían antes de que se procesara la transacción requiere utilizar, en total, más ada para cubrir el valor mínimo de ada, ya que se necesita ada en las salidas adicionales.
P. ¿Qué tipos de activos puedo utilizar para cubrir los costes asociados a los tokens nativos?
R. Actualmente, sólo se puede utilizar ada para realizar pagos o depósitos de tasas.
P. ¿Cómo funciona la selección de monedas para los tokens nativos personalizados?
R. Desde el punto de vista de los usuarios, es similar a la selección de monedas ada, es decir, el usuario selecciona los tokens y las cantidades que desea gastar, y el wallet escoge las entradas adecuadas y cubre las tasas.
P. ¿Es posible enviar tokens a una dirección?
R. Sí, el envío de tokens nativos a una dirección se realiza de la misma manera que el envío de ada a una dirección, es decir, presentando una transacción con salidas que contengan los paquetes de tokens que el autor de la transacción desea enviar, junto con las direcciones a las que se envían.
¿Qué control tiene el usuario sobre los activos de token personalizados?
Los usuarios pueden gastar, enviar, intercambiar o recibir todo tipo de tokens de MA de la misma manera que ada. A diferencia de ada, los usuarios también pueden acuñar y quemar tokens nativos.
Gastar tokens : Los usuarios pueden gastar los tokens en su wallet, o tokens en salidas bloqueadas por scripts que permiten a este usuario gastar la salida.
Envío de tokens a otros usuarios : Los usuarios pueden enviar los tokens de sus wallets (o los tokens que puedan gastar) a cualquier dirección.
Acuñación de tokens : Los usuarios pueden acuñar tokens personalizados según la política asociada a este activo. La transacción de acuñación puede colocar estos tokens en la dirección del usuario, o en la de cualquier otra persona. Si es necesario, la política puede restringir la ubicación exacta de salida de los tokens.
Ten en cuenta que, aunque el usuario haya definido una política, es posible que no pueda acuñar o quemar activos incluidos en esta política, dependiendo de las reglas de la misma. Una política de acuñación controla la acuñación de todos los activos incluidos en ella, independientemente de la identidad del usuario que haya definido la política.
Quemar tokens : La quema de tokens también está controlada por la política asociada al activo. Además de poder quemar los tokens (siempre de acuerdo con la política de acuñación), el usuario debe poder gastar los tokens que intenta quemar. Por ejemplo, si los tokens están en su wallet).
Los usuarios no pueden quemar tokens sobre los que no tienen control, como los tokens del wallet de otra persona, aunque la política de acuñación lo permita específicamente.
P. ¿Existe una bolsa descentralizada (DEX) para los tokens nativos de Cardano?
R. No. El libro mayor de Cardano no soporta por sí mismo la funcionalidad DEX. Sin embargo, cuando la funcionalidad de los contratos inteligentes está disponible, se pueden publicar activos no-ada para su intercambio o venta en el libro mayor utilizando un contrato inteligente.
P. ¿Existe un registro de activos para los tokens nativos de Cardano?
R. No. La implementación de la función Native Tokens en Cardano no requiere un registro de activos. Sin embargo, el servidor de metadatos (véase “¿Tienen los activos identificadores legibles por humanos y otros metadatos?”) puede utilizarse para enumerar los tokens que un usuario ha acuñado, si así lo desea.
Tokens nativos de Cardano versus ERC
P. ¿Cómo se comparan los tokens nativos de Cardano con los tokens personalizados de Ethereum ERC-721 y ERC-20?
R. El enfoque de Cardano para crear tokens personalizados difiere de una implementación no nativa de tokens personalizados, como ERC-721 o ERC-20, donde los tokens personalizados se implementan utilizando la funcionalidad de contratos inteligentes para simular la transferencia de activos personalizados (es decir, un sistema de contabilidad del libro mayor). Nuestro enfoque para crear tokens personalizados no requiere de contratos inteligentes, ya que la propia implementación del ledger soporta la contabilidad sobre activos nativos no-ada.
Otra diferencia clave es que el ledger multiactivo de Cardano admite tokens fungibles y no fungibles sin contratos especializados (a diferencia de ERC-721 o ERC-20), y es lo suficientemente versátil como para incluir una combinación de diferentes tipos de tokens fungibles y no fungibles en una sola salida.
Encuentra una copia oficial de este documento aquí:
https://docs.cardano.org/native-tokens/faqs
Más traducciones de Cardano en: Cardano For The World