Workflow do Aplicativo CBDC de Atacado

Depois de instalar e configurar o aplicativo CBDC de atacado de amostra, você pode usá-lo em cenários em que um proprietário do sistema (um banco central) e organizações participantes (outras instituições financeiras) interagem em um mercado interbancário.

O aplicativo de amostra suporta onze funções ou personas. Cada função tem uma interface e um conjunto de operações diferentes que suportam todo o fluxo de trabalho de gerenciamento de token no cenário CBDC de atacado.

Funções do Sistema

  • Administrador do sistema: gerencia todo o sistema.
  • Criador do sistema: Cria tokens. Depois que uma solicitação de criação é enviada, ela é enviada ao gerente do sistema, que aprova ou rejeita a solicitação. Após a aprovação da solicitação de cunhagem, os tokens são creditados na conta do criador do sistema. O criador pode então transferir esses tokens para um emissor do sistema.
  • Gerente do sistema: Aprova ou rejeita solicitações de cunhagem, gravação e retenção de tokens. As aprovações de solicitação de retenção são usadas para transferências entre organizações.
  • Emissor do sistema: Transfere tokens para oficiais de instituições financeiras ou para o sistema de recuperação para queima. Os usuários nessa função recebem tokens do criador do sistema e dos diretores da instituição financeira. O gerente do sistema deve aprovar todas as transferências entre organizações.
  • Auditor do sistema: Tem acesso somente leitura a todos os dados organizacionais no sistema.
  • Recuperador do sistema: Grava tokens. Este papel recebe tokens do emissor do sistema. Depois que uma solicitação de gravação é enviada, ela é enviada ao gerenciador do sistema.

Atribuições da Organização

  • Administrador da organização: Gerencia sua organização específica.
  • Oficial da organização: Recebe tokens do emissor do sistema. Eles podem transferir esses tokens para usuários em qualquer organização ou devolver tokens ao emissor do sistema. Todas as transferências devem ser aprovadas pelo aprovador da organização.
  • Usuário da organização: Recebe tokens dos oficiais de suas respectivas organizações. Eles podem transferir esses tokens para usuários e oficiais em qualquer organização. Todas as transferências devem ser aprovadas pelo aprovador da organização.
  • Gerente da organização: Aprova ou rejeita solicitações de retenção para sua organização específica. Solicitações de retenção e aprovações são usadas para todas as transferências entre organizações ou dentro delas.
  • Auditor da organização: Tem acesso somente leitura aos dados específicos de sua organização.

Integração

Após instalar, configurar e preparar o aplicativo, siga as etapas abaixo para acessar o aplicativo.

  1. Depois que o aplicativo for preparado, navegue de volta para a home page.
  2. No painel de controle do aplicativo, localize o aplicativo preparado. O status é mostrado como Armaz. Área Temp. ao lado do nome do aplicativo.
  3. Clique no menu drop-down em Armaz. Área Temporária e selecione o nome do aplicativo.
  4. Copie o link ou abra o aplicativo preparado em uma nova guia ou janela do navegador para testar e revisar o aplicativo.

No modo genérico, todas as contas são exibidas e rastreadas por IDs usuário. No modo confidencial, as contas são exibidas e rastreadas por IDs de conta bancária. Os IDs de conta bancária são strings alfanuméricas aleatórias que são geradas quando a conta é criada. No modo confidencial, o ID da conta bancária substitui o ID do usuário na interface do aplicativo.

No modo confidencial, os saldos da conta são calculados sob demanda usando um método de consolidação (consolidateRunningBalanceInTransactions), que é definido no chaincode. Quando a consolidação é executada, todas as transações pendentes são processadas e o saldo da conta é atualizado. Os saldos de conta só estarão disponíveis após a execução da consolidação para uma organização. Se a consolidação não tiver sido executada para uma organização, os saldos da conta serão mostrados como Reconciliação Pendente.

O método consolidateRunningBalanceInTransactions consolida saldos de conta para a organização do chamador. Esse método pode ser chamado por um Token Admin ou Org Admin. Os proprietários do sistema devem se autenticar usando a conta de usuário SYSTEM_ADMINS associada à atribuição de token tokenAdmin. As organizações participantes devem se autenticar usando suas respectivas contas de usuário ORG_ADMINS, cada uma associada à atribuição de token orgAdmin.

Para manter os saldos das contas precisos na rede, o método de consolidação deve ser executado em intervalos regulares. Você pode usar o ponto final da API REST scheduleTransactions no Oracle Blockchain Platform para executar a consolidação automaticamente. Para obter melhores resultados, defina o scheduler para ser executado a cada dois minutos e defina a string de expiração como um valor alto, como 120M (dez anos). Para obter mais informações, consulte Programar Transação para Execução.

Quando um usuário tenta efetuar log-in no aplicativo, o sistema verifica se o usuário tem uma conta e a atribuição apropriada. Se a conta não existir ou se a função obrigatória estiver ausente, o erro a seguir será exibido.
Invalid Account. Please Contact Admin
A interface exibida após o log-in de um usuário depende de sua função.

A primeira vez que um usuário tenta fazer login no aplicativo, nenhuma conta de usuário foi criada ainda. Somente usuários do grupo System_Admins que também têm a atribuição tokenAdmin designada a eles podem fazer log-in. Todas as outras tentativas de log-in falharão. A seção a seguir inclui mais informações sobre a exceção para a persona SYSTEM_ADMINS.

System_Admins Exceção

O processo de log-in é diferente para usuários com a persona SYSTEM_ADMINS. Os usuários do grupo System_Admins podem fazer log-in mesmo que sua conta ainda não tenha sido criada, mas esses usuários devem ter a atribuição tokenAdmin.

Ao implantar o chaincode, certifique-se de que os usuários do grupo System_Admins tenham a atribuição tokenAdmin. Os parâmetros informados durante a inicialização do chaincode devem incluir os usuários administradores do sistema como tendo a atribuição tokenAdmin. Isso permite que o grupo System_Admins faça log-in no aplicativo pela primeira vez para criar as outras contas de usuário.

Se você efetuar log-in no aplicativo como um usuário no grupo System_Admins e esse usuário não tiver sido incluído como um parâmetro de inicialização quando o chaincode foi implantado, designe manualmente a atribuição tokenAdmin ao usuário. Você pode atribuir manualmente a função tokenAdmin usando uma coleção Postman.

Workflow da Candidatura

As etapas a seguir mostram as ações das várias funções em um fluxo de trabalho de aplicativo completo. As sete primeiras etapas devem ser concluídas para usar o aplicativo.

  1. O administrador do sistema efetua login.
  2. O administrador do sistema inicializa o token.
  3. O administrador do sistema cria sua própria conta bancária e, em seguida, recarrega a home page para ver os detalhes da rede atualizados.
  4. O administrador do sistema cria contas bancárias para todas as personas do CBDC, conforme mostrado na tabela a seguir.
    Grupo de Aplicativos Atribuição
    System_Admins Token Admin
    System_Auditors Token Auditor
    System_Creators Minter
    System_Managers Escrow
    System_Issuers nenhuma
    System_Retirers Burner
  5. O administrador do sistema cria contas bancárias do administrador da organização, que têm a atribuição Org Admin.
  6. Somente modo confidencial: o administrador do sistema e os administradores da organização configuram o scheduler para executar a consolidação automaticamente. Isso garante que os saldos de conta exibidos sejam precisos. Para obter mais informações, consulte Programar Transação para Execução.
  7. O administrador da organização faz logon e cria contas para os usuários da organização.
  8. O administrador do sistema atribui funções aos novos usuários da organização, conforme mostrado na tabela a seguir.
    Grupo de Aplicativos Atribuição
    Org_Admins Org Admin
    Org_Users nenhuma
    Org_Officers nenhuma
    Org_Managers Escrow
    Org_Auditors Org Auditor
  9. O criador do sistema faz login e solicita que os tokens sejam cunhados.
  10. O gerente do sistema faz logon e aprova ou rejeita a solicitação de cunhagem. Se a solicitação for aprovada, os tokens serão creditados ao criador do sistema.
  11. O criador do sistema transfere os tokens para o emissor do sistema.
  12. O emissor do sistema faz login e transfere os tokens para um oficial da organização. Se a transferência for aprovada pelo gerente do sistema, os tokens serão transferidos. Como alternativa, o emissor do sistema pode transferir os tokens para o recuperador do sistema para gravação.
  13. O auditor do sistema faz login, seleciona políticas de auditoria e analisa os dados de transação relevantes.
  14. O recuperador do sistema efetua log-in e solicita a desativação dos tokens. Se o gerente do sistema aprovar, os tokens serão gravados.
  15. O gerenciador do sistema faz login e aprova ou rejeita a solicitação de emissão de tokens. Se a transferência for aprovada, os tokens serão creditados ao oficial da organização, que poderá transferi-los para os usuários da organização.
  16. O responsável pela organização faz login e transfere tokens para usuários da organização, outros responsáveis pela organização ou de volta para o proprietário do sistema. Todas as transferências requerem a aprovação do gerente da organização.
  17. O gerente da organização faz login e aprova ou rejeita solicitações de transferência.
  18. os usuários da organização fazem login e transferem tokens para outros usuários da organização em qualquer organização.
  19. O auditor da organização faz login, seleciona políticas de auditoria e revisa os dados de transação relevantes.