Suporte a Tokenização Usando o Blockchain App Builder

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 livro-razão blockchain para estabelecer o estado e a propriedade de um ativo e usar funções padrão da plataforma blockchain para transferir a propriedade de um ativo.

O Blockchain App Builder inclui suporte a 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 controle para inicializar tokens, controlar o acesso, configurar contas, gerenciar funçõ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 de arquitetura de token

API de Token Gerada 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.
SDK do Token: O Token SDK inclui métodos que ajudam a desenvolver lógica de negócios complexa para aplicativos de token.
Otimização do MVCC (Multiversion Concurrency Control): A otimização de MVCC para chaincode de token 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. Os 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.

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. As contas são semelhantes às contas bancárias típicas, em que 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 retido (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 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 ser suportados em várias organizações.

Padrões de Token

O Blockchain App Builder estende os padrões e classificações do Token Taxonomy Framework, o padrão ERC-721 e o padrão ERC-1155 para definir a anatomia e o comportamento dos tokens. O ERC-1155 é um padrão que suporta tokens fungíveis e não fungíveis (NFTs). ERC-721 é um padrão para NFTs. O Token Taxonomy Framework foi desenvolvido pela Token Taxonomy Initiative. Para obter mais informações, consulte Token Taxonomy Framework.

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 não fungíveis inteiros
ERC-1155	tokens fungíveis inteiros fichas fungíveis fracionárias tokens não fungíveis inteiros fichas não fungíveis fracionárias

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 de token da mesma forma que cria outros projetos, usando a CLI ou no Visual Studio Code. Para obter mais informações, 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.
Organize o projeto do chaincode a partir do arquivo de especificação de entrada. Isso cria um projeto com andaimes, incluindo um modelo que contém a definição do 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 de chaincode.

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

Um chaincode de token é implantado, e os usuários da lista transmitidos ao 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.
As contas devem ser criadas para cada usuário que possuirá tokens ou concluirá operações relacionadas a token.
Se o comportamento roles for especificado para o token, as atribuições deverão ser adicionadas aos usuários para que eles possam concluir operações relacionadas ao 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 mint tokens para uma conta.

Controle de Acesso

O suporte à tokenização inclui um recurso de controle de acesso que suporta 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 o 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, métodos específicos podem ser chamados pelos usuários que possuem os ativos, como Token Owner ou Account Owner. Para obter informações específicas sobre o controle de acesso para métodos, consulte as entradas individuais dos 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 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 Token Admin não pode remover seus próprios privilégios Token Admin. Um usuário Token Admin pode designar a atribuição Org Admin, minter, burner ou notary a qualquer usuário.
Administração da Organização: Os métodos estendidos da Estrutura de Taxonomia de Token suportam a atribuição Org Admin. Um usuário 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 sua organização. Org Admin os usuários que têm uma função de minerador, queimador ou notário podem atribuir essa função a outros usuários em sua organização.
Minerador de token: Um usuário que recebe a atribuição de minerador é um Token Minter e pode cunhar tokens.
Queimador de token: Um usuário que recebe a função de gravador é um Token Burner e pode gravar tokens.
Notário de Token: Um usuário que recebeu a atribuição de notário é um Token Notary. Um Token Notary atua como um terceiro em 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, retornar os tokens para a conta do pagador.
Gerenciador de Vault: Um usuário que recebeu a atribuição de vault é o Vault Manager. O Vault Manager pode desbloquear um NFT bloqueado. A função de cofre é aplicável apenas para as normas ERC-721 e ERC-1155 alargadas. 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 de vault.

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 possua atualmente um token não fungível é o Token Owner desse token.

O controle de acesso baseado em atribuição e o 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 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 minerador cria um token não fungível (NFT), ele se torna o proprietário do NFT. Como proprietário desse NFT, eles podem 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. Por causa do 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. Por causa do 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 gravar 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 projeto TypeScript ou Go.

Otimização de MVCC

Os bancos de dados do Hyperledger Fabric usam o controle de simultaneidade de várias versões (MVCC) 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 de MVCC para operações de transferência, hortelã, gravação e retenção, você pode ativar a otimização de MVCC para chaincode de token. Essa otimização funciona apenas no Oracle Blockchain Platform. Por default, 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: Ao criar um chaincode, selecione Ativar otimização MVCC na janela Criar Chaincode.

Para usar a otimização com chaincode criada 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 do Arquivo de Especificação com o Código de Origem Gerado e Sincronizar Alterações do Arquivo de Especificação com o Código de Origem Gerado.

Outros métodos para contornar erros MVCC_READ_CONFLICT, incluindo fazer com que o aplicativo cliente repita as solicitações quando esse erro é gerado ou usar uma fila para capturar solicitações simultâneas antes que elas sejam enviadas à 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 do MVCC não funciona em redes híbridas que incluem pares Oracle Blockchain Platform e Hyperledger Fabric ou para testes em uma rede local Hyperledger Fabric. Não ative a otimização MVCC em redes híbridas, pois isso pode levar a inconsistências entre pares.