Aprenda sobre os Tokens Nativos do Cardano

Native tokens é um novo recurso que permite a transação de multiativos na Cardano. Os usuários podem transacionar com ada e um número ilimitado de tokens definidos pelo usuário (personalizados) nativamente.

O suporte nativo oferece vantagens distintas para os desenvolvedores: não há necessidade de criar contratos inteligentes para lidar com tokens personalizados, por exemplo, o que remove uma camada de complexidade adicional e potencial para erros manuais, já que o ledger lida com todas as funcionalidades relacionadas a tokens.

A funcionalidade de tokens nativos estende a infraestrutura contábil existente definida no modelo de ledger (originalmente projetado para processar transações somente com ada) para acomodar transações usando uma variedade de ativos. Esses ativos incluem ada e uma variedade de tipos de tokens personalizados definidos pelo usuário.

Leia mais sobre tokens nativos e como eles se comparam com ada e ERC20 e assista ao nosso vídeo explicativo sobre tokens nativos.

Navegue pelos tokens nativos criados na blockchain Cardano e veja suas transações e proprietários em um painel interativo que permite filtragem e busca: Cexplorer.io.

Ledgers de único ativo

Ledgers de criptomoeda que rastreiam exatamente um tipo de ativo são chamados de ledgers de único ativo.

Suporte a Multi-Ativos (MA)

Uma blockchain, ledger ou criptomoeda é dita ter suporte a multi-ativos (MA) quando a rede ou o ledger suporta o rastreamento e a propriedade de diferentes tipos de ativos em seu ledger. No ambiente Cardano, essa funcionalidade é fornecida pelo recurso de tokens nativos.

Esse recurso estende a infraestrutura contábil existente definida no modelo de ledger, que é projetado para processar transações somente com ada, para acomodar transações que usam simultaneamente uma variedade de ativos. Esses ativos incluem ada e uma variedade de tipos de tokens personalizados definidos pelo usuário.

Suporte nativo versus não nativo a MA

Algumas blockchains têm suporte integrado para rastrear a propriedade e a transferência de mais de um tipo de ativo. Esse tipo de suporte a MA é chamado de nativo. A funcionalidade MA da Cardano é nativa.

Se uma plataforma de criptomoeda tiver funcionalidade de contrato inteligente suficientemente poderosa, é possível rastrear ativos para os quais não há suporte de contabilidade no ledger. Isso é feito com uma solução de camada 2 construída usando contratos inteligentes. Esse tipo de suporte a MA é não nativo.

Ativos e tokens

Ativos

Um ativo é um objeto que representa valor na blockchain. Esses objetos podem ser uma variedade de coisas, como um ativo digital como ada, uma função, uma credencial ou uma quantidade de bens.

O termo ativo pode se referir a:

• o identificador de uma classe de objetos, como "ada" ou "couttscoins"; ou
• uma quantidade específica de um objeto específico, como "100 lovelace", "24 couttscoins", "esta casa" ou "esses 10 toneladas de café".

Um ativo é identificado exclusivamente por um ID de ativo, que é um par do ID de política e nome do ativo. É importante observar que embora ada possa atuar como um ativo, ele não é representado usando um ID de política explícito.

Tokens que têm o mesmo ID de ativo têm a propriedade de ser fungíveis entre si e não são fungíveis com tokens que têm um ID de ativo diferente. Um ID de ativo é um identificador único para uma coleção de tokens fungíveis.

• PolicyID - o identificador exclusivo associado a uma política de emissão. Vamos dar uma olhada em dois exemplos de ID de política: NFLPlayerCardsPolicyID e RushConcertPolicyID. O ID é calculado aplicando uma função hash à própria política e, portanto, é uma sequência de letras e números. Por exemplo:

NFLPlayerCardsPolicyID = e0d123e5f316bef7

• Nome do Ativo - uma propriedade (imutável) de um ativo que é usada para distinguir diferentes ativos dentro da mesma política. Ao contrário do ID de política, o nome do ativo não se refere a nenhum código ou conjunto de regras e pode ser palavras comuns, como 'ingressos' ou 'IngressosVIP', por exemplo. No entanto, a política sob a qual um ativo está agrupado pode especificar algumas restrições sobre nomes de ativos válidos.

Diferentes políticas podem usar os mesmos nomes de ativos para tokens diferentes. Por exemplo, o pacote de tokens:

FAKERushConcertPolicyID {  (Tickets, 500),
                           (VIPTickets, 50)}

contém os nomes de ativo 'Ingressos' e 'IngressosVIP', mas estes não são fungíveis com os ingressos 'RushConcertPolicyID' que foram definidos em outro pacote de tokens, pois estão agrupados sob políticas diferentes.

Tokens

Um token é uma abreviação para "token de ativo", que é a representação on-chain de um ativo e sua unidade contábil básica. Um token pode representar um ada, uma casa ou o valor de dez toneladas de café, por exemplo.

Moedas

Moeda é um meio de troca de bens e serviços que geralmente se refere a uma unidade de pagamento. A Cardano suporta moedas como ada e tokens nativos, que agem de forma semelhante na rede.

No entanto, ada é a moeda principal da Cardano que, neste momento, é aceita como pagamento de taxa, para fazer depósitos e é também a única moeda na qual as recompensas são distribuídas. Essa propriedade do ada (e nenhum outro tipo de ativo) se deve à construção do protocolo de consenso subjacente.

Os tokens nativos representam algum valor e atuam como uma unidade de contabilidade, que pode ser usada para pagamentos, transações e pode ser enviada para um endereço de troca. Nativo significa que esses tokens são suportados pelo livro-razão contábil do Cardano sem a necessidade de contratos inteligentes adicionais, pois o livro-razão apresenta suporte embutido para rastrear a propriedade e a transferência de mais de um tipo de ativo.

Embora tanto o ada quanto os tokens nativos tenham valor e atuem como uma unidade de pagamento e transação, apenas o ada é usado para taxas e recompensas, enquanto apenas os tokens nativos podem ser criados sob medida.

Usando ada para operações administrativas

Ada é a moeda principal do Cardano. É essencial manter ada (além de outras moedas) para transferir tokens multi-ativos entre endereços, pois cada endereço deve conter um valor mínimo de ada (min-ada-value, atualmente definido como 1 ada).

Como consequência desse design, o seguinte se aplica:

1. É impossível criar saídas que contenham apenas tokens personalizados.
2. O número de cada tipo de token em uma saída não afeta o min-ada-value da saída, mas o número de tipos de tokens contidos em uma saída aumenta o min-ada-value. (O motivo para isso é que os nomes e IDs de política de cada um dos tipos de tokens ocupam espaço adicional na saída.)
3. Enviar tokens personalizados para um endereço sempre envolve o envio do min-ada-value de ada para esse endereço ao lado dos tokens personalizados (incluindo o ada na mesma saída). Se o endereço não for gastável pelo usuário que está enviando os tokens, o ada enviado junto com os tokens não pertence mais ao remetente.

Nota: Antes de transferir tokens personalizados, os usuários podem optar por usar comunicação off-chain para negociar quem fornece o ada para cobrir o min-ada-value na saída feita pela transação de transferência.

4. Para recuperar o ada armazenado junto com tokens personalizados em uma saída O, o usuário deve fazer o seguinte:
   • Gastar a saída O e queimar os tokens personalizados armazenados nela.
   • Gastar uma saída O e uma saída O’, e consolidar os tokens nela com a mesma coleção de tipos de tokens personalizados armazenados em outra saída (gastos dentro da mesma transação).

Por exemplo: (CryptoDoggiesPolicy, poodle, 1) contido em O pode ser consolidado com (CryptoDoggiesPolicy, poodle, 3) em O’, totalizando (CryptoDoggiesPolicy, poodle, 4) em uma nova saída feita pela transação de consolidação.

5. Dividir tokens personalizados em mais saídas do que estavam contidos antes da transação ser processada requer mais ada total para cobrir o min-ada-value, já que algum ada deve ser fornecido em cada saída.

Pacotes de tokens

Um pacote de token é uma coleção heterogênea ('misturada') de tokens. Qualquer token pode ser agrupado junto. Pacotes de tokens são a maneira padrão - e única - de representar e armazenar ativos no blockchain do Cardano.

Pacotes de tokens organizam tokens em um tipo específico de estrutura de dados (veja o exemplo e a explicação abaixo), para que quais tokens são fungíveis com quais outros tokens adira explicitamente a essa organização.

Nas versões anteriores do livro-razão do Cardano, os montantes de ada eram especificados em transações e saídas UTxO. Com a introdução do suporte multi-ativos, esses montantes foram estendidos com pacotes de tokens, que podem especificar um valor ada juntamente com quantidades de outros ativos em uma única saída.

Os pacotes de tokens são contidos em saídas e campos de cunhagem de transações, e as saídas no conjunto UTxO rastreadas pelo livro-razão. Note que certos campos de uma transação ainda devem especificar explicitamente montantes de ada, como o campo de taxa.

Exemplo de pacote de token

Aqui está um exemplo de um pacote de token, vamos chamá-lo de TB_Example:

{
NFLPlayerCardsPolicyID {(SomeNFLPlayerCard, 1), 
                        (SomeOtherNFLPlayerCard, 1),
                        (YetAnotherNFLPlayerCard, 1)}


RushConcertPolicyID {(Tickets, 500),
                     (VIPTickets, 50)}
}

Como e onde os pacotes de tokens são armazenados?

Pacotes de tokens podem ser encontrados:

1. Como o campo de cunhagem de uma transação, indicando que a transação está criando os tokens no pacote.
2. Em uma saída de uma transação ou uma saída no conjunto UTxO atual rastreado pelo livro-razão, ao lado do endereço da saída, por exemplo. Multi { MeuEndereço, valor: TB_Example }

Dividindo e combinando pacotes de tokens

Transações podem arbitrariamente dividir e combinar pacotes de tokens em diferentes pacotes. Por exemplo, podemos dividir o pacote TB_Example em dois:

TB_Example_Part1:

NFLPlayerCardsPolicyID {(SomeNFLPlayerCard, 1)}


RushConcertPolicyID {(Tickets, 200),
                     (VIPTickets, 20)}

TB_ExamplePart2:

NFLPlayerCardsPolicyID {(SomeOtherNFLPlayerCard, 1),
                        (YetAnotherNFLPlayerCard, 1)}
 
RushConcertPolicyID {(Tickets, 300),
                     (VIPTickets, 30)}

Comparação com tokens ERC20

ERC20 é um padrão de token Ethereum, amplamente utilizado para emissão de tokens em várias plataformas hoje. A peculiaridade desse tipo de token reside no fato de que ele pode representar valor e servir para fins como pagamentos, transferência de valor, troca, recompensas ou incentivos, acesso a serviços e produtos, representação de direitos de voto, etc. Além disso, esses tokens podem possuir tanto características de utilidade quanto de segurança, o que abre uma variedade de possíveis casos de uso para empresas, aplicativos e empresas.

No Cardano, os usuários podem criar tokens nativos que servirão aos fins mencionados acima e, além disso, é possível criar ativos únicos (não fungíveis) representando valor como imóveis ou direitos intelectuais, por exemplo (no Ethereum, essa funcionalidade requer um padrão separado, ERC721).

Ao contrário dos tokens ERC20, o rastreamento e a contabilidade de tokens nativos são suportados nativamente pelo livro-razão (os tokens ERC20 requerem contratos inteligentes para alcançar a mesma coisa). Um benefício importante de usar tokens nativos é que eles não exigem contratos inteligentes para transferir seu valor e podem ser transferidos junto com outros tipos de tokens. Além disso, ao contrário do ERC20, os tokens nativos não exigem taxas de transferência especiais ou lógica adicional de tratamento de eventos para rastrear transações.

Outra vantagem dos tokens nativos sobre os ERC20 é a segurança. Os tokens ERC20 mostraram ser vulneráveis a uma ampla gama de questões de segurança. Isso é condicionado pelo fato de que a criação de tokens ERC20 requer modificação manual do padrão de contrato, o que pode resultar em erros e possíveis bugs. A criação e a transação de tokens de forma nativa eliminam a possibilidade de erro humano, já que o próprio livro-razão trata a lógica dos tokens. Além disso, vulnerabilidades de sobrefluxo e subfluxo presentes para ERC20 são eliminadas para tokens nativos, já que a linguagem de script do Cardano não possui inteiros de tamanho fixo e o próprio livro-razão (em vez do código de usuário ERC20) rastreia o movimento de tokens.

Política de cunhagem

Visão geral

Uma política de cunhagem é o conjunto de regras que governam a cunhagem e a queima de ativos abrangidos por essa política. O objetivo de uma política de cunhagem é especificar as condições sob as quais os tokens são cunhados (ou queimados). Por exemplo, as regras podem especificar quem tem controle sobre o fornecimento de ativos por meio de cunhagem e queima.

As políticas de cunhagem são definidas pelos usuários que desejam criar um novo ativo. Por exemplo, um usuário pode desejar permitir apenas a si mesmo a cunhagem de mais de um determinado tipo de token. Isso seria especificado na política.

As regras de cunhagem podem ser expressas:

Como um conjunto muito básico de regras que é composto por (ANDs e ORs de):

1. Uma especificação de quais assinaturas são necessárias para permitir a cunhagem (por exemplo, uma especificação de multisig, onde nenhum código é necessário).
2. Uma especificação de durante qual slot o script pode ser gasto (por exemplo, após o slot 15 e antes do slot 20) com um script Plutus Core.

A aderência às políticas de cunhagem é verificada pelo nó no momento em que uma transação é processada, executando o código ou verificando as assinaturas relevantes. As transações devem aderir a todas as políticas de cunhagem de todos os ativos que a transação está tentando cunhar.

Pontos importantes sobre políticas de cunhagem e ativos

• Todos os ativos necessariamente têm uma política de cunhagem. Por exemplo, a política de cunhagem do ada é "novo ada nunca pode ser cunhado".
• Um token está associado a (por exemplo, abrangido por) exatamente uma política de cunhagem.
• Uma única política especifica tanto as condições de cunhagem quanto de queima de tokens abrangidos por ela. A aderência a ela é verificada tanto no momento da cunhagem quanto da queima.
• Um ativo nunca pode mudar sua política de cunhagem associada. Essa associação é permanente. Em outras palavras, tokens existentes não podem ser associados a uma nova política. No entanto, os usuários podem comprar de volta e queimar todos os tokens existentes e cunhar novos, com uma nova política de cunhagem. Note que isso é uma característica, não um bug!
• Se um ativo existente no livro-razão está abrangido por uma determinada política, é garantido que ele foi originalmente cunhado de acordo com essa política.
• A menos que tokens de uma determinada política estejam sendo cunhados em uma transação, a política real é irrelevante. Ela é apenas usada como um identificador do ativo.
• Ativos associados a diferentes políticas de cunhagem nunca são fungíveis entre si. Eles podem ser negociados da mesma forma que se pode usar USD para comprar CAD: a quantidade de CAD que você pode comprar com uma quantidade fixa de USD depende da taxa de câmbio do local onde você faz a negociação.

Associação entre um ativo e sua política de cunhagem

A associação entre um ativo e sua política de cunhagem é permanente por motivos de segurança: esse recurso protege os usuários e o sistema de tokens cunhados ilegitimamente.

Se a política de cunhagem de um token mudar, ele não será mais o mesmo token, e seu valor não poderá ser comparado ao do token original. Esse esquema de associação permanente de ativo-política é fundamental para definir políticas de alta garantia. Afrouxar essa identificação abre nosso esquema de MA para vários ataques. Ter uma associação permanente entre eles nos permite garantir que cada token foi cunhado de acordo com sua política de cunhagem, e não qualquer outra política com a qual ele possa ter sido associado anteriormente.

Note que isso não é tão restritivo quanto parece. Em um paralelo solto com a política monetária dos EUA, podemos dizer que a política é "o governo e as leis estabelecem a política", e esta é uma política que requer consultar as leis atuais (que elas mesmas poderiam mudar) e apenas cunhar dinheiro em conformidade com elas.

Exemplos de políticas de cunhagem

• Política de único emissor
• Política de cunhagem com bloqueio de tempo
• Política de cunhagem única

Nota: Existem muitos outros tipos de políticas de cunhagem.

Política de único emissor

Uma política de cunhagem de único emissor especifica que apenas a entidade detentora de um determinado conjunto de chaves tem permissão para cunhar tokens do grupo de ativos específico. Por exemplo, o conjunto de chaves especificado na política de cunhagem deve ter assinado a transação de cunhagem.

Um exemplo de um grupo de ativos que usaria uma política de único emissor seria tokens que representam cartas de beisebol. A empresa que fabrica cartas colecionáveis legítimas publicaria as chaves necessárias para o script de cunhagem cunhar novas cartas de beisebol. Isso significaria que nenhum novo token de carta de beisebol pode ser cunhado sem as assinaturas da empresa. Esse tipo de política pode ser implementado sem contratos inteligentes de Plutus.

Política de cunhagem com bloqueio de tempo (bloqueio de token)

Esse tipo de política pode ser usado para especificar quando os tokens podem ser gastos de um endereço. Em particular,

• apenas em ou após um determinado slot de tempo
• apenas antes de um determinado slot de tempo

Esse tipo de política geralmente não é usado por si só. Normalmente, está em conjunto com a política de multisig ou único emissor, por exemplo. Esta saída pode ser gasta após o slot s e apenas por uma transação assinada pela chave k.

Esse tipo de política pode ser implementado sem contratos inteligentes de Plutus.

Política de cunhagem única

Em uma política de cunhagem única, o conjunto completo de tokens de um determinado grupo de ativos é cunhado por uma transação específica. Isso significa que nenhum token adicional nesse grupo de ativos será cunhado. Esse tipo de política precisa de contratos inteligentes de Plutus para ser implementado.

Políticas de cunhagem única seriam úteis para gerar tokens de ingressos de concerto para um concerto específico, por exemplo. A capacidade do local é conhecida antecipadamente, então não haverá necessidade de permitir mais ingressos a serem cunhados.

Transações de cunhagem

Para introduzir novas quantidades de novos tokens no livro-razão (cunhagem) ou remover tokens existentes (queima), cada transação apresenta um campo de cunhagem. As transações em que o campo de cunhagem não está vazio são conhecidas como transações de cunhagem. O uso desse campo precisa ser controlado rigorosamente para garantir que a cunhagem e a queima de tokens ocorram de acordo com a política de cunhagem do token.

Além do campo de cunhagem, as transações de cunhagem também devem carregar as políticas de cunhagem dos tokens que estão cunhando, para que esses tokens possam ser verificados durante a validação.

O resultado do processamento de uma transação de cunhagem é que o livro-razão conterá os ativos incluídos no campo de cunhagem, que são incluídos no equilíbrio da transação: se o campo for positivo, então as saídas da transação devem conter mais ativos do que as entradas fornecem; se for negativo, então devem conter menos.

É importante destacar que uma única transação pode cunhar tokens associados a várias e distintas políticas de cunhagem. Por exemplo, (Policy1, AlgunsTokens) ou (Policy2, AlgunsOutrosTokens). Além disso, uma transação pode simultaneamente cunhar alguns tokens e queimar outros.

O ciclo de vida do token nativo

O ciclo de vida do token nativo consiste em cinco fases principais:

1. cunhagem
2. emissão
3. uso
4. resgate
5. queima

O diagrama a seguir esboça a interação entre os componentes do sistema:

Cada uma dessas fases lógicas envolve transações no blockchain do Cardano, que podem incorrer em taxas em ada. Os principais grupos de atores são:

• Controladores de ativos, que definem a política para a classe de ativos e autorizam emissores de tokens a cunhar/queimar tokens. Eles também podem reter direitos de coassinatura para quaisquer tokens emitidos/queimados.
• Emissores de tokens, que cunham novos tokens, mantêm a reserva de tokens em circulação, os emitem para detentores de tokens e queimam tokens quando não são mais úteis.
• Detentores de tokens, que mantêm tokens em suas carteiras, podem passá-los para outros usuários, trocá-los por itens de valor (incluindo tokens não nativos), etc., da mesma forma que podem usar ada. Quando um usuário termina de usar o token, ele pode escolher resgatá-lo. Isso significa que os tokens são devolvidos a um emissor (talvez em troca de um produto, serviço ou alguma outra moeda, por exemplo). Depois de resgatados, os tokens podem ser reemitidos para outros usuários conforme necessário. Os detentores de tokens precisarão manter algum ada em suas carteiras para pagar as taxas de transação.
• Quando os tokens se tornam redundantes, eles podem ser queimados, se desejado, de acordo com o script de política monetária subjacente. O processo de queima destrói esses tokens (remove-os de circulação), e o fornecimento total de tokens diminui. Quaisquer depósitos serão devolvidos neste ponto. O processo de queima é idêntico para tokens fungíveis e não fungíveis.

Nota: O ciclo de vida de tokens multi-ativos potencialmente permite que os tokens sejam obtidos e reemitidos por outras partes - detentores de tokens que atuam como reemissores para o token. Isso pode ser feito, por exemplo, para permitir a negociação em várias classes de ativos, manter liquidez em um ou mais tokens (atuando como corretor) ou para eliminar o esforço/custo de emissão, emissão ou manutenção do servidor de metadados do token. Assim, tanto os reemissores quanto os emissores podem se beneficiar desse acordo - eliminando custo e esforço, mantendo separação e integridade, e injetando valor na classe de ativos.