Aprende qué son los tokens (fichas) nativos
Tokens Nativos es una nueva función que permite realizar transacciones con múltiples activos en Cardano. Los usuarios pueden realizar transacciones con ada, y un número ilimitado de tokens definidos por el usuario (personalizados) de forma nativa.
El soporte nativo ofrece claras ventajas para los desarrolladores: no hay necesidad de crear contratos inteligentes para manejar tokens personalizados, por ejemplo, lo que elimina una capa de complejidad añadida y el potencial de errores manuales, ya que el libro mayor maneja toda la funcionalidad relacionada con los tokens.
La función de tokens nativos amplía la infraestructura contable existente definida en el modelo de libro mayor (originalmente diseñado para procesar transacciones sólo de ada) para dar cabida a las transacciones que utilizan una serie de activos. Estos activos incluyen ada y una variedad de tipos de tokens personalizados definidos por el usuario.
Lee más sobre los tokens nativos y cómo se comparan con ada y ERC20 y mira nuestro vídeo explicativo sobre los tokens nativos.
Libro de contabilidad de activo único
Los libros de contabilidad de criptomonedas que registran exactamente un tipo de activo se denominan libros de contabilidad de activo único.
Soporte MultiActivo (MA)
Se dice que una blockchain, ledger o criptodivisa tiene soporte multiactivo (MA) cuando la red o el ledger soporta el seguimiento de la transferencia y la propiedad de diferentes tipos de activos en su ledger. En el entorno de Cardano, esta funcionalidad la proporciona la función de tokens nativos.
Esta función amplía la infraestructura contable existente definida en el modelo de libro mayor, que está diseñada para procesar transacciones sólo de ada, para dar cabida a transacciones que utilizan simultáneamente una serie de activos. Estos activos incluyen ada y una variedad de tipos de tokens personalizados definidos por el usuario.
Apoyo al MA nativo versus no nativo
Algunos libros de contabilidad de criptomonedas tienen soporte incorporado para registrar la propiedad y la transferencia de más de un tipo de activo. Este tipo de soporte de MA se llama nativo. La funcionalidad MA de Cardano es nativa.
Si una plataforma de criptodivisas tiene una funcionalidad de contratos inteligentes lo suficientemente potente, es posible hacer un seguimiento de los activos para los que no hay soporte contable en el libro mayor. Esto se hace con una solución de capa 2 construida con contratos inteligentes. Este tipo de soporte de MA no es nativo.
Activos y tokens
Activos
Un activo es un objeto que representa un valor en la blockchain. Estos objetos pueden ser una variedad de cosas, como un activo digital como ada, un rol, una credencial o una cantidad de bienes.
El término activo puede referirse a:
- el identificador de una clase de objetos, como "ada" o "couttscoins"; o
- una cantidad determinada de un objeto específico, como "100 lovelace", "24 couttscoins", "esta casa" o "estas 10 toneladas de café"
Un activo se identifica de forma única mediante un ID de activo, que es un par de ID de póliza y nombre de activo. Es importante señalar que, aunque ada puede actuar como un activo, no se representa utilizando un ID de póliza explícito.
Los tokens que tienen el mismo ID de activo tienen la propiedad de ser fungibles entre sí, y no son fungibles con tokens que tienen un ID de activo diferente. Un ID de activo es un identificador único para una colección de tokens fungibles.
- PolicyID - el identificador único que se asocia a una póliza de acuñación. Veamos dos ejemplos de identificadores de pólizas: NFLPlayerCardsPolicyID y RushConcertPolicyID. El ID se calcula aplicando una función hash a la propia póliza, por lo que es una secuencia de letras y números. Por ejemplo:
NFLPlayerCardsPolicyID = e0d123e5f316bef7
- Asset name - una propiedad (inmutable) de un activo que se utiliza para distinguir diferentes activos dentro de la misma póliza. A diferencia del policyID, el nombre del activo no hace referencia a ningún código o conjunto de reglas, y pueden ser palabras comunes, como ‘tickets’ o ‘VIPTickets’, por ejemplo. Sin embargo, la póliza bajo la que se engloba un activo puede especificar algunas restricciones sobre los nombres de activos válidos.
Diferentes pólizas pueden utilizar los mismos nombres de activos para diferentes tokens. Por ejemplo, el paquete de tokens:
FAKERushConcertPolicyID { (Tickets, 500),
(VIPTickets, 50)}
contiene los Tickets y VIPTickets nombres de activos, pero éstos no son fungibles con los RushConcertPolicyID que han sido definidos en otro paquete de tokens, ya que tienen un ámbito de póliza diferente.
Tokens
Un token es la abreviatura de " asset token ", que es la representación en la cadena de un activo y su unidad contable básica. Un token puede representar un ada, una casa o el valor de diez toneladas de café, por ejemplo.
Currencies
Currency (moneda) es un medio de intercambio de bienes y servicios que comúnmente se refiere a una unidad de pago. Cardano admite monedas como ada y tokens nativos, que actúan de forma similar en la red.
Sin embargo, ada es la principal moneda que, en este momento, se acepta como pago de tasas, para hacer depósitos, y es también la única moneda en la que se distribuyen las recompensas. Esta propiedad de ada (y de ningún otro tipo de activo) se debe a la construcción del protocolo de consenso subyacente.
Los tokens nativos representan algún valor y actúan como una unidad contable, que puede utilizarse para pagos, transacciones y puede enviarse a una dirección de intercambio. Nativo significa que estos tokens son soportados por el libro de contabilidad de Cardano sin la necesidad de contratos inteligentes adicionales, ya que el libro de contabilidad cuenta con soporte incorporado para registrar la propiedad y la transferencia de más de un tipo de activo.
Aunque tanto los tokens ada como los nativos tienen valor y actúan como unidad de pago y transacción, sólo los ada se utilizan para las comisiones y recompensas, mientras que sólo los tokens nativos pueden crearse de forma personalizada.
Uso de ada para las operaciones administrativas
Ada es la moneda principal de Cardano. Es esencial tener ada (además de otras monedas) para transferir tokens multiactivos entre direcciones, ya que cada dirección debe tener un valor mínimo de ada (min-ada-value, actualmente fijado en 1 ada).
Como consecuencia de este diseño, se aplica lo siguiente:
- Es imposible crear salidas que contengan sólo tokens personalizados.
- El número de cada tipo de token en una salida no afecta al min-ada-value de la salida, pero el número de tipos de tokens que contiene una salida incrementa el min-ada-value. (El motivo es que los nombres y los ID de las pólizas de cada uno de los tipos de tokens ocupan un espacio adicional en la salida.)
- El envío de tokens personalizados a una dirección siempre implica el envío de min-ada-value 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.
Nota: 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 los ada almacenados junto a los tokens personalizados en una salida O, el usuario debe hacer una de estas opciones:
- Gastar la salida O, y quemar los tokens personalizados que se almacenan en ella
- 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)
Por ejemplo: (CryptoDoggiesPolicy, poodle, 1) contenidos en O pueden ser consolidados con (CryptoDoggiesPolicy, poodle, 3) en O', para un total de (CryptoDoggiesPolicy, poodle, 4) en una nueva salida que realiza la operación de consolidación.
- La división de los tokens personalizados en más salidas de las que contenían antes de procesar la transacción requiere más ada total para cubrir el min-ada-value, ya que se debe suministrar algo de ada en cada salida.
Paquetes de Tokens
Un paquete de tokens es una colección heterogénea ("mixta") de tokens. Cualquier tokens pueden ser agrupados. Los paquetes de tokens son la forma estándar -y única- de representar y almacenar activos en la blockchain de Cardano.
Los paquetes de tokens organizan los tokens en un tipo particular de estructura de datos (véase el ejemplo y la explicación más abajo), de modo que cuáles tokens son fungibles con cuáles otros tokens se adhieren explícitamente a esta organización.
En versiones anteriores del libro mayor de Cardano, las cantidades de ada se especificaban en las salidas de transacciones y UTxO. Con la introducción del soporte multiactivo, estas cantidades se han ampliado con paquetes de tokens, que pueden especificar una cantidad de ada junto con cantidades de otros activos en una sola salida.
Los paquetes de tokens están contenidos en las salidas y los campos de acuñación de las transacciones, y las salidas en el conjunto UTxO registrado por el libro mayor. Hay que tener en cuenta que algunos campos de una transacción deben seguir especificando explícitamente las cantidades de ada, como el campo de la tasa.
Ejemplo de paquete de tokens
Este es un ejemplo de un paquete de tokens, llamémoslo TB_Example:
{
NFLPlayerCardsPolicyID {(SomeNFLPlayerCard, 1),
(SomeOtherNFLPlayerCard, 1),
(YetAnotherNFLPlayerCard, 1)}
RushConcertPolicyID {(Tickets, 500),
(VIPTickets, 50)}
}
¿Cómo y dónde se almacenan los paquetes de tokens?
Los paquetes de tokens se pueden encontrar:
- Como campo de acuñación de una transacción, indicando que la transacción está creando los tokens del paquete.
- En una salida de una transacción o una salida en el UTXO actual seguido por el libro mayor, junto a la dirección de la salida, por ejemplo Multi { MyAddress, value: TB_Example }
División y combinación de paquetes de tokens
Las transacciones pueden dividir y combinar arbitrariamente los paquetes de tokens en diferentes paquetes. Por ejemplo, podemos dividir el paquete TB_Example en dos:
TB_Example_Part1:
NFLPlayerCardsPolicyID {(SomeNFLPlayerCard, 1)}
RushConcertPolicyID {(Tickets, 200),
(VIPTickets, 20)}
TB_ExamplePart2:
NFLPlayerCardsPolicyID {(SomeOtherNFLPlayerCard, 1),
(YetAnotherNFLPlayerCard, 1)}
RushConcertPolicyID {(Tickets, 300),
(VIPTickets, 30)}
Comparación con tokens ERC20
ERC20 es un estándar de tokens de Ethereum, comunmente utilizado para la emisión de tokens en varias plataformas hoy en día. La peculiaridad de este tipo de tokens radica en que pueden representar valor y servir para fines tales como pagos, transferencia de valor, intercambio, recompensas o incentivos, acceso a servicios y productos, representar derechos de voto, etc. Además, estos tokens pueden tener características tanto de utilidad como de seguridad, lo que abre un rango de posibles casos de uso para negocios, aplicaciones y empresas.
En Cardano, los usuarios pueden crear tokens nativos que sirvan para los fines mencionados y, además, es posible crear activos únicos (no fungibles) que representen valor como bienes inmuebles o derechos intelectuales, por ejemplo (en Ethereum, esta funcionalidad requiere un estándar separado, ERC721).
A diferencia de los tokens ERC20, el seguimiento y la contabilidad de los tokens nativos están soportados por el libro mayor de forma nativa (los tokens ERC20 requieren contratos inteligentes para lograr lo mismo). Una ventaja importante del uso de tokens nativos es que no requieren contratos inteligentes para transferir su valor y pueden ser transferidos junto con otros tipos de tokens. Además, a diferencia de ERC20, los tokens nativos no requieren tasas especiales de transferencia ni una lógica adicional de gestión de eventos para el seguimiento de las transacciones.
Otra ventaja de los tokens nativos sobre los ERC20 es la seguridad. Los tokens ERC20 han demostrado ser vulnerables a una amplia gama de problemas de seguridad. Esto está condicionado por el hecho de que la creación de tokens ERC20 requiere la modificación manual del estándar del contrato, lo que puede dar lugar a errores y posibles fallos. La creación y transacción de tokens de forma nativa elimina la posibilidad de errores humanos, ya que el propio libro mayor se encarga de la lógica de los tokens. Además, las vulnerabilidades por exceso y por defecto que están presentes en ERC20 se eliminan en los tokens nativos, ya que el lenguaje de scripting de Cardano no tiene enteros de tamaño fijo y el propio libro de contabilidad (en lugar del código de usuario de ERC20) sigue el movimiento de los tokens.
Política de acuñación
Resumen
Una política de acuñación es el conjunto de reglas que gobiernan la acuñación y la quema de activos bajo esa política. El objetivo de una política de acuñación es especificar las condiciones bajo las cuales se acuñan (o queman) los tokens. Por ejemplo, las reglas pueden especificar quién tiene el control sobre el suministro de activos a través de la acuñación y la quema.
Las políticas de acuñación son definidas por los usuarios que quieren crear un nuevo activo. Por ejemplo, un usuario puede desear que sólo se le permita acuñar más de un determinado tipo de tokens. Esto se especificaría en la política.
Las reglas de acuñación pueden expresarse:
Como un conjunto muy básico de reglas que se compone de (ANDs y ORs de):
- Una especificación de qué firmas son necesarias para permitir la acuñación (por ejemplo, una especificación multisig, donde no se necesita ningún otro código).
- Una especificación de durante qué slot se puede gastar el script (por ejemplo, después del slot 15 y antes del 20) Con un script Plutus Core.
El nodo comprueba el cumplimiento de las políticas de acuñación en el momento de procesar una transacción, ejecutando el código o comprobando las firmas pertinentes. Las transacciones deben adherirse a todas las políticas de acuñación de todos los activos que la transacción intenta acuñar.
Puntos importantes sobre las políticas de acuñación y los activos
- Todos los activos tienen necesariamente una política de acuñación. Por ejemplo, la política de acuñación de ada es "nunca se pueden acuñar nuevos ada".
- Un token está asociado con (por ejemplo, cubierto por) exactamente una política de acuñación.
- Una única política especifica tanto las condiciones de acuñación como las de quema de tokens bajo su ámbito. Su cumplimiento se comprueba tanto en el momento de la acuñación como en el de la quema.
- Un activo no puede cambiar nunca su política de acuñación asociada. Esta asociación es permanente. En otras palabras, los tokens existentes no pueden asociarse a una nueva política. Sin embargo, los usuarios pueden recomprar y quemar todos los tokens existentes y acuñar otros nuevos, con una nueva política de acuñación. Ten en cuenta que esto es una característica, no un error!
- Si un activo existente en el libro mayor está incluido en una política determinada, se garantiza que fue acuñado originalmente de acuerdo con esa política.
- A menos que se acuñen tokens de una determinada política en una transacción, la política real es irrelevante. Sólo se utiliza como identificador del activo.
- Los activos asociados a diferentes políticas de acuñación nunca son fungibles entre sí. Se pueden intercambiar de la misma manera que se puede utilizar el USD para comprar CAD: la cantidad de CAD que se puede comprar con una cantidad fija de USD depende del tipo de cambio del lugar donde se realiza la operación.
Asociación entre un activo y su política de acuñación
La asociación entre un activo y su política de acuñación es permanente por razones de seguridad: esta característica protege a los usuarios y al sistema de tokens acuñados ilegítimamente.
Si la política de acuñación de un token cambia, ya no es realmente el mismo token, y su valor no puede compararse con el del token original. Este esquema de asociación permanente entre activos y políticas es integral para definir políticas de alta seguridad. Aflojar esta identificación abre nuestro esquema de MA a varios ataques. Tener una asociación permanente entre ellos nos permite garantizar que cada token se acuñó de acuerdo con su política de acuñación, y no con cualquier otra política a la que pudiera haberse asociado previamente.
Ten en cuenta que esto no es tan restrictivo como parece. En un paralelismo con la política monetaria de los Estados Unidos, podemos decir que la política es "el gobierno y las leyes establecen la política", y ésta es una política que requiere buscar las leyes actuales (que a su vez podrían cambiar), y sólo acuñar dinero de acuerdo con ellas.
Ejemplos de política de acuñación
- Política de emisor único
- Política de acuñación con límite de tiempo
- Política de acuñación de una sola vez
Nota: Hay muchos otros tipos de políticas de acuñación.
Política de emisor único
La Política de emisor único especifica que sólo la entidad que posee un determinado conjunto de claves está autorizada a acuñar tokens de un grupo particular de activos. 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.
Un ejemplo de un grupo de activos que utilizaría una política de emisor único sería el de los tokens que representan tarjetas de béisbol. La empresa que fabrica tarjetas de coleccionista legítimas publicaría las claves requeridas por el script de acuñación para acuñar nuevas tarjetas de béisbol. Esto significaría que no se pueden acuñar nuevos tokens de tarjetas de béisbol sin las firmas de la empresa. Este tipo de política puede aplicarse sin contratos inteligentes de Plutus.
Política de acuñación con límite de tiempo (token-locking)
Este tipo de política puede utilizarse para especificar cuándo se pueden gastar tokens de una dirección. En particular,
- sólo en o después de un slot de tiempo especificado
- sólo antes de un slot de tiempo especificado
Este tipo de política no suele utilizarse por sí sola. Por lo general, se encuentra en conjunción con la política de multifirma o de emisor único, por ejemplo, Esta salida puede ser gastada después del slot s y sólo por una transacción firmada por la clave k.
Este tipo de política se puede implementar sin contratos inteligentes Plutus.
Política de acuñación de una sola vez
En la Política de acuñación de una sola vez, el conjunto completo de tokens de un determinado grupo de activos es acuñado por una transacción específica. Esto significa que no se acuñarán más tokens de ese grupo de activos en particular. Este tipo de política necesita contratos inteligentes de Plutus para ser implementada.
Las políticas de acuñación única serían útiles para generar tokens de entradas para un concierto específico, por ejemplo. El aforo del recinto se conoce de antemano, por lo que no habrá necesidad de permitir que se acuñen más entradas.
Transacciones de acuñación
Para introducir nuevas cantidades de tokens en el libro de contabilidad (acuñación) o eliminar tokens existentes (quema), cada transacción cuenta con un campo de acuñación.Las transacciones en las que el campo de acuñación no está vacío se conocen como transacciones de acuñación. El uso de este campo debe estar estrechamente controlado para garantizar que la acuñación y la quema de tokens se produzcan de acuerdo con la política de acuñación del token.
Además del campo de acuñación, las transacciones de acuñación también deben llevar las políticas de acuñación de los tokens que están acuñando, para que estos tokens puedan ser comprobados durante la validación.
El resultado de procesar una transacción de acuñación es que el libro mayor contendrá los activos incluidos en el campo de acuñación, que se incluye en el balance de la transacción: si el campo es positivo, las salidas de la transacción deben contener más activos que los que proporcionan las entradas; si es negativo, deben contener menos.
Es importante destacar que una misma transacción puede acuñar tokens asociados a múltiples y distintas políticas de acuñación. Por ejemplo, (Policy1, SomeTokens) o (Policy2, SomeOtherTokens). Además, una transacción puede acuñar simultáneamente algunos tokens y quemar otros.
El ciclo de vida de los tokens nativos
El ciclo de vida de los tokens nativos consta de cinco fases principales:
- acuñación
- emisión
- utilización
- redención
- quema
El siguiente diagrama muestra la interacción entre los componentes del sistema:
Cada una de estas fases lógicas conlleva transacciones en la blockchain de Cardano, que pueden conllevar comisiones en ada. Los principales grupos de actores son:
- Los controladores de activos, que definen la política para la clase de activos, y autorizan a los emisores de tokens a acuñar/quemar tokens. También pueden conservar los derechos de cofirmación de los tokens emitidos/quemados.
- Los emisores de tokens, que acuñan nuevos tokens, mantienen la reserva de tokens en circulación, los emiten a los poseedores de tokens y queman tokens cuando ya no son útiles.
- - Los poseedores de tokens, que conservan los tokens, los envían a otros usuarios, los utilizan para pagar y pueden redimirlos con los emisores cuando hayan terminado de utilizarlos. Los usuarios de tokens pueden ser usuarios normales, intercambios, etc.
El ciclo de vida de los tokens multi-activos comienza con su creación - acuñación, que se refiere al proceso por el cual uno o más emisores de tokens crean nuevos tokens de acuerdo con el guión de política monetaria que el controlador de activos ha definido. Los nuevos tokens suelen crearse para cumplir fines específicos. Por ejemplo, pueden crearse tokens fungibles o no fungibles (únicos) para ser utilizados para necesidades específicas de pago, compra o intercambio. Cuando se acuña un nuevo token, la oferta total de tokens para ese token aumenta, pero no hay impacto en la oferta de ada. La acuñación de monedas y su transferencia a nuevas direcciones puede requerir el pago de un depósito de ada, que puede ser proporcional al número de tokens diferentes que se posean, por ejemplo.
Los poseedores de tokens tendrán tokens en sus billeteras, podrán pasarlos a otros usuarios, intercambiarlos por artículos de valor (incluyendo tokens no nativos), etc., exactamente de la misma manera que pueden usar ada. Cuando un usuario ha terminado de utilizar los tokens, puede optar por redimirlos. Esto significa que los tokens se devuelven a un emisor (quizás a cambio de un producto, un servicio o alguna otra moneda, por ejemplo). Una vez redimidos, los tokens podrían volver a ser emitidos a otros usuarios según sea necesario. Los poseedores de tokens tendrán que mantener algo de ada en sus billeteras para pagar las tasas de transacción.
Cuando los tokens se vuelvan redundantes, podrán ser quemados, si se desea, de acuerdo con el guión de la política monetaria subyacente. El proceso de quema destruye estos tokens (los retira de la circulación), y el suministro total de tokens disminuye. En este momento se devuelven los depósitos. El proceso de quema es idéntico para los tokens fungibles y no fungibles.
Nota: El ciclo de vida de los tokens multi-activos permite potencialmente que los tokens sean obtenidos y reemitidos por otras partes - titulares de tokens que actúan como reemisores del token. Esto puede hacerse, por ejemplo, para permitir la negociación en múltiples clases de activos, mantener la liquidez en uno o más tokens (actuando como intermediario), o para eliminar el esfuerzo/coste de la acuñación de tokens, la emisión o el mantenimiento del servidor de metadatos. De este modo, tanto los reemisores como los emisores pueden beneficiarse de este tipo de acuerdos, eliminando costes y esfuerzos, manteniendo la separación y la integridad, e inyectando valor a la clase de activos.
Encuentra una copia oficial de este documento aquí:
https://docs.cardano.org/en/latest/native-tokens/learn-about-native-tokens.html
© Copyright 2020, IOHK Revision 7c515a7b.
Más traducciones sobre Cardano en: http://CardanoForTheWorld.com