Perguntas frequentes sobre tokens nativos

Ativos em cadeia

Q. Qual é a definição de suporte a 'multi-ativos (MA)' e o Cardano possui isso?

A. Suporte a multi-ativos (MA) é o nome de um conjunto de funcionalidades que um ledger (blockchain/carteira/criptomoeda/plataforma bancária) pode fornecer, o que permite fazer contabilidade ou transacionar com mais de um tipo de ativo.

A funcionalidade de suporte a MA do Cardano é chamada Tokens Nativos. MA permite aos usuários transacionar com ada e um número ilimitado de tokens definidos pelo usuário. Este suporte é nativo, o que significa que os tokens podem ser transacionados (rastreados/enviados/recebidos) usando o sistema de contabilidade definido como parte da funcionalidade do ledger da criptomoeda, sem a necessidade de contratos inteligentes para habilitar essa funcionalidade.

Q. O que é tokenização de (ativo)?

A. Tokenizar um ativo significa criar uma representação desse ativo na cadeia.

Cunhagem

Q. O que significa 'cunhar' um token?

A.'Cunhar' refere-se ao processo pelo qual novos tokens são criados ou destruídos. Ou seja, a quantidade total em circulação (ou seja, somada em todos os endereços no ledger) do tipo de token sendo cunhado aumenta ou diminui. Cunhar uma quantidade positiva de tokens é criação de token, e cunhar uma quantidade negativa é destruição de token.

Q. O que significa 'queimar' um token?

A.'Queimar' refere-se ao processo pelo qual tokens são destruídos. É sinônimo de 'cunhagem negativa'.

Q. O que é resgatar um token?

A. Resgatar um token é a ação de enviar tokens de volta ao emissor para serem queimados. Isso geralmente é feito quando os tokens sendo resgatados não têm mais um propósito no ledger, e o usuário ou contrato em posse deles não é capaz (não autorizado pela política de cunhagem) de queimar os tokens.

Pode não haver compensação oferecida pelo resgate dos tokens (decidir isso cabe ao emissor do token/política de cunhagem), mas o usuário pode optar por fazer isso mesmo assim para evitar ter tokens inutilizáveis em sua carteira.

Q. O que é uma transação de cunhagem?

A. As transações têm diferentes estruturas nas eras Shelley, ShelleyMA e Goguen, mas essa estrutura é a mesma dentro de uma única era. As transações Shelley+MA e Goguen podem carregar dados que especificam quais tokens estão sendo cunhados. As transações em que essa peça de dados da transação (chamada campo de cunhagem) não está vazia são chamadas de transações de cunhagem. Essas transações também devem carregar as políticas de cunhagem para os tokens que estão sendo cunhados, para que possam ser verificadas durante a validação.

O resultado do processamento de uma transação de cunhagem é que o ledger agora conterá adicionalmente os ativos incluídos no campo de cunhagem (campo de mint) da transação. Se a quantidade de um ativo específico no campo de cunhagem for negativa, o resultado é que após o processamento da transação, a quantidade total desse ativo específico no ledger será reduzida pela quantidade refletida no campo de cunhagem.

Note que uma única transação pode cunhar tokens associados a várias políticas de cunhagem distintas, por exemplo, (Policy1, SomeTokens), (Policy2, SomeOtherTokens). Note também que uma transação pode simultaneamente cunhar alguns tokens e queimar alguns outros.

Q. O que é uma política de cunhagem?

A. Uma política de cunhagem é um conjunto de regras usadas para regular a cunhagem de ativos associados a ela (escopados sob ela). Por exemplo, quem tem controle (e sob quais condições) sobre o fornecimento da moeda, e sua cunhagem e queima. Essas regras são sobre o conteúdo dos dados da transação da transação que está tentando a cunhagem. Por exemplo, uma política de cunhagem pode exigir um conjunto específico de chaves para ter assinado a transação de cunhagem.

Este conjunto de regras é definido pelo usuário que deseja criar o novo ativo. Por exemplo, um usuário pode desejar permitir apenas a si mesmo a cunhagem desse tipo específico de token. Nesse caso, ele estipularia isso na política. O nó verifica a adesão às políticas de cunhagem quando uma transação é processada executando o código ou verificando as assinaturas relevantes. Os dados da transação devem satisfazer todas as políticas de cunhagem de todos os ativos que a transação está tentando cunhar.

Q. O que é um construtor de tokens e qual é sua funcionalidade?

A. Um construtor de tokens é um software que permite ao usuário definir os tokens a serem cunhados e incluí-los em uma transação de cunhagem. Ele também garante que os dados adicionais apropriados necessários para verificar que a transação está autorizada a realizar a cunhagem sejam incluídos na transação (veja a questão da política de cunhagem abaixo).

Exemplos de políticas e maneiras de definir políticas

Q. O que é 'multisig' e como isso se relaciona com políticas de cunhagem?

A. A linguagem de script multisig (que existia antes da introdução da funcionalidade MA no Cardano) especifica um conjunto mínimo de assinaturas necessárias para permitir que uma transação realize uma certa ação, geralmente para gastar uma entrada UTXO.

Scripts multisig também podem ser usados para especificar as políticas de cunhagem mais básicas, ou seja, as políticas que exigem um conjunto específico de chaves para assinar a transação de cunhagem. Por exemplo, uma política de cunhagem de único emissor pode ser expressa usando um script multisig. Note que políticas de cunhagem são os únicos tipos de política que podem ser expressas usando multisig.

Sem a capacidade de contrato inteligente Plutus, ou quaisquer outras extensões de linguagem de política de cunhagem, multisig é a única maneira de especificar uma política de cunhagem.

Q. O que os contratos inteligentes Plutus têm a ver com tokens nativos?

A. Políticas de cunhagem podem ser escritas na linguagem de contrato inteligente Plutus. Isso permite aos usuários expressar uma gama muito mais ampla de políticas do que apenas a política de único emissor expressável usando multisig. A política de cunhagem única, por exemplo, pode ser expressa em Plutus (mas não apenas como multisig).

Q. O que é uma política de cunhagem de único emissor?

A. Uma política de cunhagem de único emissor especifica que apenas a entidade que possui um conjunto particular de chaves está autorizada a cunhar tokens sob uma política específica. Por exemplo, o conjunto de chaves especificado na política de cunhagem deve ter assinado a transação de cunhagem. Esse tipo de política pode ser especificado usando multisig.

Um exemplo de uso de uma política de único emissor poderia ser tokens representando cartões de beisebol. Isso significaria que nenhum novo token de cartão de beisebol poderia ser cunhado sem as assinaturas da empresa. Por outro lado, a política prova que todos os cartões existentes escopados sob esta política foram legitimamente cunhados pela empresa de cartões de beisebol.

Q. O que é uma política de cunhagem única?

A. Em uma política de cunhagem única, o conjunto completo de tokens escopados sob ela é cunhado por uma transação específica. Isso significa que nunca mais tokens serão cunhados sob essa política. Esse tipo de política requer contratos inteligentes e não pode ser expresso usando multisig.

Um caso de uso de uma política de cunhagem única seria cunhar tokens de ingressos para um show específico. A capacidade do local é conhecida antecipadamente, então não haverá necessidade de permitir que mais ingressos sejam cunhados.

Estrutura, representação e propriedades de multi-ativos

Q. O que é fungibilidade e não fungibilidade?

A. Fungibilidade é uma relação entre dois ativos/tokens. Tokens são considerados fungíveis entre si quando são intercambiáveis. Por exemplo, dinheiro fiat é fungível pois uma nota de $10 é intercambiável com todas as outras (notas reais) de $10 (e todos os conjuntos de 10 notas de $1, e todos os pares de $5).

Ativos não fungíveis não são intercambiáveis entre si. Por exemplo, dois diamantes, ou dois tokens na cadeia representando os dois diamantes reais. Se não houver outros ativos com os quais um token é fungível -como um token representando uma casa- o token é considerado único (não fungível).

Q. O que é um pacote de tokens?

A. Uma coleção mista de tokens escopados sob uma ou mais políticas de cunhagem. Qualquer token pode ser agrupado.

Para mais detalhes, veja a seção de pacote de tokens.

Transacionando com tokens nativos

Q. Como os tokens nativos aparecem na carteira de um usuário?

A. Antes da introdução da funcionalidade MA no sistema Cardano, a carteira de um usuário contém tanto saídas com endereços que pertencem ao usuário, quanto as quantidades de ada que esses endereços possuem. Por exemplo, (endereço_do_usuário1, algumaQuantidadeDeAda)

Com suporte a MA, a carteira do usuário será capaz de conter vários tipos de ativos em uma única saída, ou seja, a carteira pode conter um pacote de tokens. Isso significa que carteiras podem conter:

• Ativos escopados sob diferentes políticas em uma única UTXO (incluindo ada)
• Ativos escopados sob uma política, espalhados por várias UTXOs

A carteira de um usuário pode conter algo como:

(endereço_do_usuário1, (políticaAda, algunsTokensDeAda))(endereço_do_usuário1, (cryptoDoggie, algunsDoggies), (políticaAda, maisTokensDeAda))(endereço_do_usuário2, (cryptoDoggie, outrosDoggies), (cryptoBirds, apenasCacatuas))

Neste exemplo, existem três políticas: políticaAda, cryptoDoggie, e cryptoBirds.

Q. Os tokens nativos têm identificadores legíveis por humanos e outros metadados?

A. Nomes legíveis por humanos para ativos (em vez das longas strings alfanuméricas de ID da Política e nomes de ativos) podem ser registrados em um servidor de metadados. Se um usuário estiver usando uma carteira integrada a um servidor de metadados, eles poderão ver os nomes legíveis por humanos ao olhar para seus ativos.

Os usuários poderão fazer o upload de nomes para seus tokens, juntamente com quaisquer outros metadados referentes aos tokens específicos, para um servidor de metadados. Pode haver mais de um servidor de metadados operacional ao mesmo tempo (incluindo um executado pelo Cardano), então os usuários terão que escolher em qual(is) servidor(es) fazer o upload de seus metadados, ou de onde baixar seus metadados.

Os usuários também podem optar por adicionar nomes e outros metadados diretamente no campo de metadados da transação. Isso aumentará as taxas de transação proporcionalmente ao tamanho dos metadados adicionais.

Q. Quais são os custos relacionados à cunhagem e negociação de tokens nativos?

A. Os custos relacionados a multi-ativos podem ser divididos em duas categorias:

• Taxas: Enviar e cunhar tokens afeta as taxas que o autor da transação deve pagar. Como com um ledger apenas de ada, as taxas são calculadas com base no tamanho total da transação. Também pode haver taxas para verificar políticas de cunhagem, mas inicialmente apenas políticas multisig são suportadas, que não incorrem em taxas adicionais além das baseadas no tamanho da transação.

• Valor-min-ada: Cada saída criada por uma transação deve incluir uma quantidade mínima de ada, que é calculada com base no tamanho da saída (ou seja, no número de diferentes tipos de token nela, e nos comprimentos de seus nomes).

Explicação do valor-min-ada:

Lembre-se de que as saídas podem conter uma coleção heterogênea de tokens, incluindo ada é um recurso limitado no sistema Cardano. Exigir alguma quantidade de ada ser incluída em cada saída no ledger (onde essa quantidade é baseada no tamanho da saída, em bytes) protege o tamanho do ledger Cardano de crescer incontrolavelmente.

Cálculo do valor-min-ada:

A quantidade mínima de ada necessária para ser contida em cada UTXO apenas de ada sem dados adicionais (ou seja, um UTXO contendo apenas o endereço e a quantidade de ada) é um parâmetro do sistema Cardano: minUTxOValue

O tamanho de tal UTXO tem um limite superior: adaOnlyUTxOSize

Podemos calcular o limite superior no tamanho de um UTXO u contendo tokens não-ada: sizeBound (u)

Queremos calcular o min-ada necessário para ser contido em u: minAda (u)

Uma quantidade minUTxOValue de ada paga por adaOnlyUTxOSize bytes de armazenamento UTXO no ledger. Para fazer o valor-min-ada proporcional para todos UTXOs, a seguinte proporção deve ser satisfeita:

minUTxOValue / adaOnlyUTxOSize = minAda (u) / sizeBound (u) Então, o cálculo do min-ada para qualquer UTxO é:

minAda (u) = sizeBound (u) * minUTxOValue / adaOnlyUTxOSize

Como consequência deste design:

• É impossível fazer saídas contendo apenas tokens personalizados
• O número de cada tipo de token em uma saída não afeta o valor-min-ada da saída, mas o número de tipos de tokens contidos em uma saída aumenta o valor mínimo.
• A razão para isso é que os nomes e IDs de política de cada um dos tipos de tokens ocupam espaço adicional na saída.
• Enviar tokens personalizados para um endereço sempre envolve enviar o valor-min-ada de ada para aquele endereço junto com os tokens personalizados (incluindo a ada na mesma saída). Se o endereço não for gasto pelo usuário que envia os tokens, a ada enviada junto com os tokens não pertence mais ao remetente.
• Antes de transferir tokens personalizados, os usuários podem optar por usar comunicação fora da cadeia para negociar quem fornece a ada para cobrir o valor-min-ada na saída feita pela transação de transferência
• Para recuperar a ada armazenada junto com tokens personalizados em uma saída O, o usuário deve:

a) Gastar a saída O e queimar os tokens personalizados armazenados nela b) Gastar uma saída O e uma saída O', e consolidar os tokens nelas com a mesma coleção de tipos de tokens personalizados armazenados em outra saída (gasta na 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.

• Dividir tokens personalizados em mais saídas do que estavam contidos antes da transação ser processada requer usar, no total, mais ada para cobrir o valor-min-ada, pois ada é necessária nas saídas adicionais.

Q. Quais tipos de ativos posso usar para cobrir custos associados a tokens nativos?

A. Atualmente, apenas ada pode ser usada para fazer pagamentos de taxas ou depósitos.

Q. Como funciona a seleção de moedas para tokens nativos personalizados?

A. Do ponto de vista dos usuários, é semelhante à seleção de moedas de ada, ou seja, o usuário seleciona os tokens e as quantidades que deseja gastar, e a carteira escolhe as entradas apropriadas e cobre as taxas.

Q. É possível enviar tokens para um endereço?

A. Sim, enviar tokens nativos para um endereço é feito da mesma maneira que enviar ada para um endereço, ou seja, enviando uma transação com saídas contendo os pacotes de tokens que o autor da transação deseja enviar, junto com os endereços para os quais eles são enviados.

Qual controle o usuário tem sobre ativos de token personalizados?

Os usuários podem gastar, enviar, negociar ou receber todos os tipos de tokens MA da mesma maneira que ada. Ao contrário de ada, os usuários também podem cunhar e queimar tokens nativos.

Gastar tokens: Os usuários podem gastar os tokens em sua carteira, ou tokens em saídas bloqueadas por scripts que permitem que este usuário gaste a saída.

Enviar tokens para outros usuários: Os usuários podem enviar os tokens em suas carteiras (ou quaisquer tokens que possam gastar) para qualquer endereço.

Cunhar tokens: Os usuários podem cunhar tokens personalizados de acordo com a política associada a esse ativo. A transação de cunhagem pode colocar esses tokens no endereço do usuário ou de qualquer outra pessoa. Se necessário, a política pode restringir o local exato de saída para os tokens.

Note que mesmo que o usuário tenha definido uma política, esse usuário pode não ser capaz de cunhar ou queimar ativos escopados sob esta política, dependendo das regras da política. Uma política de cunhagem controla a cunhagem de todos os ativos escopados sob ela, independentemente da identidade do usuário que definiu a política.

Queimar tokens: Queimar tokens também é controlado pela política associada ao ativo. Além de ser permitido queimar os tokens (sempre de acordo com a política de cunhagem), o usuário também deve ser capaz de gastar os tokens que está tentando queimar. Por exemplo, se os tokens estão em sua carteira).

Os usuários não podem queimar tokens sobre os quais não têm controle, como tokens na carteira de outra pessoa, mesmo que a política de cunhagem permita especificamente isso.

Q. Existe uma Exchange Descentralizada (DEX) para tokens nativos do Cardano?

A. Não. O ledger Cardano não suporta funcionalidade DEX por si só. No entanto, quando a funcionalidade de contrato inteligente estiver disponível, pode-se postar ativos não-ada para troca ou venda no ledger usando um contrato inteligente.

Q. Existe um registro de ativos para tokens nativos do Cardano?

A. Não. A implementação da funcionalidade Tokens Nativos no Cardano não requer um registro de ativos. No entanto, o servidor de metadados (veja "Os ativos têm identificadores legíveis por humanos e outros metadados?") pode ser usado para listar tokens que um usuário cunhou, se eles desejarem fazer isso.

Tokens Nativos do Cardano vs ERC

Q. Como os tokens nativos do Cardano se comparam aos tokens personalizados ERC-721 e ERC-20 do Ethereum?

A. A abordagem do Cardano para criar tokens personalizados difere de uma implementação não nativa de tokens personalizados, como ERC-721 ou ERC-20, onde tokens personalizados são implementados usando funcionalidade de contrato inteligente para simular transferência de ativos personalizados (ou seja, um sistema de contabilidade de ledger). Nossa abordagem para criar tokens personalizados não requer contratos inteligentes, pois a implementação do ledger em si suporta a contabilidade em ativos nativos não-ada.

Outra diferença chave é que o ledger multi-ativo do Cardano suporta tanto tokens fungíveis quanto não fungíveis sem contratos especializados (diferente de ERC-721 ou ERC-20), e é versátil o suficiente para incluir uma combinação de diferentes tipos de tokens fungíveis e não fungíveis em uma única saída.