Tokenização

Tokenização é um processo em que ativos físicos ou digitais são representados por tokens, que podem ser transferidos, rastreados e armazenados em um blockchain.

Ao representar ativos como tokens, você pode usar o razão blockchain para estabelecer o estado e a propriedade de um ativo e usar funções de plataforma blockchain padrão para transferir a propriedade de um ativo.

O Blockchain App Builder inclui suporte à tokenização: classes e métodos de token são gerados automaticamente, e métodos de token adicionais são fornecidos para que os desenvolvedores possam criar lógica de negócios complexa para tokens. O projeto gerado automaticamente contém classes e funções de ciclo de vida de token, métodos CRUD e métodos SDK de token adicionais e suporta validação automática de argumentos, marshalling/unmarshalling e capacidade de persistência transparente. Você pode usar esses métodos de controlador para inicializar tokens, controlar o acesso, configurar contas, gerenciar atribuições e gerenciar o ciclo de vida dos tokens.

O diagrama a seguir mostra a arquitetura de token implementada pelo Blockchain App Builder, incluindo a API de token e o SDK de token. Diagrama da arquitetura de token

API de Token Gerado Automaticamente: O Blockchain App Builder gera automaticamente métodos para suportar tokens e ciclos de vida de token. Você pode usar esses métodos para inicializar tokens, gerenciar atribuições e contas e concluir outras tarefas de ciclo de vida de token sem qualquer codificação adicional.
Token SDK: O Token SDK inclui métodos que ajudam a desenvolver uma lógica de negócios complexa para aplicativos de token.
Otimização de MVCC (Multiversion Concurrency Control): A otimização MVCC para token chaincode pode reduzir erros para operações de transferência, hortelã, gravação e retenção.

Tokens e o Modelo de Conta/Saldo

O Blockchain App Builder suporta tokens fungíveis e não fungíveis.

Os tokens fungíveis têm um valor intercambiável. Qualquer quantidade de tokens fungíveis tem o mesmo valor que qualquer outra quantidade igual da mesma classe de token. Tokens não fungíveis são exclusivos. Os tokens também podem ser inteiros ou fracionários. Os tokens fracionários podem ser subdivididos em partes menores, com base em um número especificado de casas decimais.

Os tokens também podem ser descritos por comportamentos. Os comportamentos suportados para tokens fungíveis incluem: mintable, transferable, divisible, holdable, burnable e roles (minter, burner e holder). Os comportamentos suportados para tokens não fungíveis incluem: mintable, transferable, singleton, indivisible, burnable e roles (minter e burner).

O recurso de tokenização usa um modelo de conta/saldo para representar ativos tokenizados como saldos em uma conta. Contas são semelhantes às contas bancárias típicas, onde depósitos e transferências e outras transições estaduais afetam o saldo de uma conta. O saldo de cada conta é rastreado globalmente para garantir que os valores da transação sejam válidos. O saldo em espera (para tokens fungíveis) e o histórico de transações também são rastreados.

Qualquer usuário que possua tokens ou conclua operações relacionadas a token em qualquer ponto deve ter uma conta na rede. Cada conta é identificada por um ID exclusivo (account_id). O ID da conta é criado combinando um nome de usuário ou um ID de e-mail (user_id) do proprietário da instância ou do usuário que está conectado à instância com o ID do provedor de serviços de associação (org_id) do usuário na organização de rede atual. Métodos prontos para uso são fornecidos para a criação da conta. Como o ID da conta inclui o ID da organização, os usuários podem ter suporte em várias organizações.

Padrões de token

O Blockchain App Builder estende os padrões e classificações do Token Taxonomy Framework, do padrão ERC-721 e do padrão ERC-1155 para definir a anatomia e o comportamento dos tokens.

ERC-1155 é um padrão que suporta tokens fungíveis e não fungíveis (NFTs). O ERC-721 é um padrão para NFTs. O Token Taxonomy Framework foi desenvolvido pela Token Taxonomy Initiative. Para obter mais informações, consulte Estrutura de Taxonomia de Token.

A tabela a seguir descreve os tipos de token suportados pelo Blockchain App Builder:

Padrão	Tipos de Token Suportados
Estrutura de taxonomia de token	fichas fungíveis fracionárias
ERC-721	tokens inteiros não fungíveis
ERC-1155	tokens fungíveis inteiros fichas fungíveis fracionárias tokens inteiros não fungíveis fichas fracionárias não fungíveis

Fluxo de Tokenização

Como o Blockchain App Builder suporta tokenização estendendo a sintaxe do arquivo de especificação de entrada, você cria projetos específicos do token da mesma forma que cria outros projetos, usando a CLI ou no Visual Studio Code.

Para obter mais informações sobre como criar projetos com o Blockchain App Builder, consulte Arquivo de Especificação de Entrada.

Um fluxo típico de tokenização segue estas etapas básicas:

Decida qual padrão de token usar.
Decida quais comportamentos de token especificar (mintable, transferable, divisible, indivisible, singleton, holdable, burnable e roles).
Defina o ativo de token e suas propriedades no arquivo de especificação de entrada.
Reporte o projeto chaincode a partir do arquivo de especificação de entrada. Isso cria um projeto scaffolded, incluindo um modelo que contém a definição de ativo de token e suas propriedades e um controlador que contém o comportamento e os métodos do token.
Implante e teste o projeto chaincode.

Depois de implantar um projeto baseado em token, o fluxo típico para criar tokens e concluir operações do ciclo de vida segue estas etapas:

Um chaincode de token é implantado; os usuários na lista informados para o método de inicialização se tornam usuários Token Admin do chaincode.
Um ativo tokenizado é inicializado, o que cria o token_id, um identificador exclusivo para essa instância específica do token.
Contas devem ser criadas para cada usuário que possuirá tokens ou concluir operações relacionadas a tokens.
Se o comportamento roles for especificado para o token, as atribuições deverão ser designadas aos usuários para que eles possam concluir operações relacionadas a token.
Os métodos de ciclo de vida do token podem ser usados, com base nos comportamentos que foram especificados para o ativo do token. Por exemplo, você pode chamar um método para cunhar tokens para uma conta.

Controle de Acesso

O suporte à tokenização inclui um recurso de controle de acesso que oferece suporte a mecanismos de controle baseados em função e em propriedade.

Com o controle baseado em atribuição, os usuários podem chamar métodos específicos com uma atribuição associada, como Token Admin ou Token Minter. Com controle baseado em propriedade, você pode restringir os usuários de acessar ativos que eles não possuem. Com o controle de acesso baseado em propriedade, os usuários que possuem os ativos podem chamar métodos específicos, como Token Owner ou Account Owner. Para obter informações específicas sobre o controle de acesso para métodos, consulte as entradas individuais para os métodos documentados nos seguintes tópicos:

O controle de acesso baseado em função suporta as seguintes personas:

Administrador de Token: Os usuários do Token Admin podem ser designados quando um chaincode de token é implantado. As informações do usuário Token Admin são salvas no banco de dados de estado. Um usuário Token Admin pode conceder e remover privilégios Token Admin para outros usuários. Um usuário do Token Admin não pode remover seus próprios privilégios Token Admin. Um usuário do Token Admin pode atribuir a função Org Admin, minter, burner ou notary a qualquer usuário.
Administrador da Organização: Os métodos estendidos da Estrutura de Taxonomia de Token suportam a função Org Admin. Um usuário do Token Admin pode designar a atribuição Org Admin a qualquer usuário. Os usuários Org Admin têm privilégios administrativos, mas somente dentro de sua organização. Eles podem criar contas ou ver saldos de contas, mas apenas para usuários em suas organizações. Os usuários do Org Admin que têm uma função de mineiro, queimador ou notário podem atribuir essa função a outros usuários em sua organização.
Token Minter: Um usuário que recebe a atribuição de minter é um Token Minter e pode cunhar tokens.
Queimador de tokens: Um usuário que recebe a atribuição de gravador é um Token Burner e pode gravar tokens.
Notário de Token: Um usuário com a atribuição de notário é um Token Notary. Um Token Notary atua como um terceiro nas transações entre pagadores e favorecidos. Um Token Notary pode acionar a conclusão de uma transferência de token de um pagador para um beneficiário ou, em vez disso, pode retornar os tokens à conta do pagador.
Gerenciador do Vault: Um usuário com a atribuição de vault designada é o Vault Manager. O Vault Manager pode desbloquear um NFT bloqueado. A atribuição de vault é aplicável apenas para os padrões ERC-721 e ERC-1155 estendidos. A atribuição da atribuição de vault a um usuário é um pré-requisito para bloquear NFTs. Somente um usuário por chaincode pode receber a atribuição vault.
Auditor de Tokens: Somente Edição de Ativos Digitais: os métodos estendidos da Estrutura de Taxonomia de Token suportam a função Token Auditor. Essa atribuição é semelhante à atribuição Token Admin, mas somente com acesso de leitura.
Auditor Org: Somente Edição de Ativos Digitais: os métodos estendidos da Estrutura de Taxonomia de Token suportam a função Org Auditor. Essa atribuição é semelhante à atribuição Org Admin, mas somente com acesso de leitura.

O controle de acesso baseado em propriedade suporta as seguintes personas:

Proprietário da conta: Qualquer usuário que tenha uma conta é um Account Owner.
Proprietário do Token: Qualquer usuário que atualmente possua um token não fungível é o Token Owner desse token.

Controle de acesso baseado em função e controle de acesso baseado em propriedade também são combinados em alguns métodos. Por exemplo, o controle de acesso baseado em função permite que um usuário com a função de minter crie tokens. Com o controle de acesso baseado em propriedade, um proprietário de token não fungível pode modificar as propriedades personalizadas de um token, mas não pode modificar os metadados do token. Quando um usuário com a função de mineiro cria um token não fungível (NFT), ele se torna o proprietário do NFT. Como proprietário desse NFT, ele pode modificar as propriedades personalizadas (para um token de coleção de arte, o preço do token é uma propriedade personalizada). Depois que o criador do token transfere o NFT para outro usuário, o segundo usuário se torna o proprietário e o usuário que criou o token não é mais o proprietário do token. Devido ao controle de acesso baseado em propriedade, o novo proprietário agora pode atualizar um valor de propriedade personalizado, mas o proprietário anterior não pode mais. Devido ao controle de acesso baseado em função, o proprietário anterior ainda pode cunhar um NFT, mas o novo usuário não pode.

Você também pode escrever suas próprias funções de controle de acesso ou desativar o controle de acesso. O código gerado automaticamente que controla o acesso é mostrado nos exemplos a seguir.

TypeScript:

await this.Ctx.<Token Standard>Auth.checkAuthorization(...)

Ir:

auth, err := t.Ctx.<Token Standard>Auth.CheckAuthorization(...)

Observação:

Para remover a função de controle de acesso gerada automaticamente, remova a linha de código anterior do seu projeto TypeScript ou Go.

Otimização MVCC

Os bancos de dados do Hyperledger Fabric usam MVCC (Multi-version Concurrency Control) para evitar gastos duplos e inconsistência de dados.

Quando o mesmo estado é atualizado, uma nova versão do registro substitui a versão antiga. Se houver solicitações simultâneas para atualizar a mesma chave em um bloco, um erro MVCC_READ_CONFLICT poderá ser gerado.

Para reduzir erros MVCC em operações de transferência, hortelã, gravação e retenção, você pode ativar a otimização MVCC para código de cadeia de token. Essa otimização funciona apenas no Oracle Blockchain Platform. Por padrão, a otimização é desativada. Para ativar a otimização, conclua a etapa a seguir aplicável.

CLI: Especifique o parâmetro Booliano -m ou --enable_mvcc_optimization com o comando ochain init. Por padrão, o parâmetro é definido como false. Para ativar a otimização, adicione -m true à linha de comando ochain init.
Visual Studio Code: Quando você cria um chaincode, selecione Ativar otimização MVCC na janela Criar Chaincode.

Para usar a otimização com chaincode criado em versões anteriores do Blockchain App Builder, execute as seguintes etapas:

Depois de instalar a versão mais recente do Blockchain App Builder, faça upgrade do chaincode conforme descrito em Fazendo Upgrade de Projetos de Chaincode na CLI e Fazendo Upgrade de Projetos de Chaincode no Visual Studio Code.
Edite o arquivo .ochain.json na pasta raiz do chaincode para definir enableMvccOptimization como true.
Sincronize o chaincode, que adiciona a otimização e cria duas novas pastas na pasta raiz do chaincode: statedb e tokens. Para obter mais informações sobre sincronização, consulte Sincronizar Alterações no Arquivo de Especificação com Código de Origem Gerado e Sincronizar Alterações no Arquivo de Especificação com Código de Origem Gerado.

Outros métodos para contornar erros MVCC_READ_CONFLICT incluem ter as solicitações de repetição do aplicativo cliente quando esse erro é gerado ou usar uma fila para capturar solicitações simultâneas antes de serem enviadas para a rede blockchain. Para obter mais informações, consulte Semântica do conjunto de Leitura e Gravação na documentação do Hyperledger Fabric.

Observação:

A otimização MVCC não funciona em redes híbridas que incluem os pares Oracle Blockchain Platform e Hyperledger Fabric ou ao testar em uma rede Hyperledger Fabric local. Não ative a otimização MVCC em redes híbridas, pois isso pode levar a inconsistências entre pares.