Visão Geral de Pagamentos Confidenciais

O Oracle Blockchain Platform Digital Assets Edition usa os compromissos da Pedersen para manter os dados seguros.

Provas de Conhecimento Zero

As provas de conhecimento zero (ZKPs) são protocolos criptográficos que permitem a um provador honesto demonstrar a verdade de uma declaração a um verificador sem revelar qualquer informação adicional. Um provador desonesto não pode convencer um verificador de que uma afirmação falsa é verdadeira. As ZKPs garantem que não sejam revelados dados sensíveis para além da validade da alegação. As ZKPs permitem provar propriedades específicas de um valor secreto, como confirmar se ele está dentro de um intervalo ou é o resultado de um cálculo específico, sem revelar o próprio valor.

Compromissos Pedersen

As provas de conhecimento zero dependem de esquemas de compromisso, onde alguém pode se comprometer com um determinado valor, mantendo-o oculto dos outros. A Edição de Ativos Digitais do Oracle Blockchain Platform usa compromissos da Pedersen. Os compromissos de Pedersen usam valores aleatórios conhecidos como fatores ocultos, junto com a criptografia de curva elíptica, para garantir sigilo e imutabilidade. Os compromissos de Pedersen são homomomórficos; em outras palavras, eles suportam a execução de operações matemáticas, como adição e subtração de compromissos, preservando as relações entre os valores subjacentes. Os compromissos Pedersen são usados em protocolos de transação privada, computação multipartidária segura e sistemas de credenciais anônimas.

Trabalhando com Pagamentos Confidenciais

Você usa o cabeçalho Confidential-Transaction em uma solicitação de transação para ativar o recurso de pagamentos confidenciais.

Quando você envia o cabeçalho Confidential-Transaction definido como verdadeiro em uma solicitação, o proxy REST no Oracle Blockchain Platform gera um número aleatório exclusivo (o fator de ocultação necessário para um compromisso de Pedersen) e o transmite no mapa transitório. Isso é usado pelo chaincode para processar a entrada e armazenar as informações confidenciais em uma coleta de dados privada em vez do banco de dados de estado.

Informações sobre a transação

Todas as operações de token (criação, cunhagem, transferência, gravação etc.) geram um registro de transação para que o histórico de transações possa ser rastreado. Os dados da transação são armazenados em dois lugares: o razão público (banco de dados de estado) e uma coleta de dados privada. Com pagamentos confidenciais, os dados confidenciais são armazenados em texto claro apenas nas coleções de dados privados das organizações envolvidas na transação. A tabela a seguir mostra onde os valores de transação são armazenados para qualquer ID de transação fornecido.

Razão Público (Banco de Dados de Estado)

Coleta de Dados Privada

assetType transaction_id token_id from_account_id from_account_balance (encrypted) from_account_onhold_balance (encrypted) from_account_onhold_burn_balance (encrypted) to_account_id to_account_balance (encrypted) to_account_onhold_balance: (encrypted) to_account_onhold_burn_balance (encrypted) transaction_type amount (criptografado) timestamp number_of_sub_transactions holding_id sub_transaction sub_transaction_type category description global_transaction_id

assetType transaction_id from_account_balance from_account_onhold_balance from_account_onhold_burn_balance to_account_balance to_account_onhold_balance to_account_onhold_burn_balance amount blindingFactor version

Informações da Conta de Token

Da mesma forma, as informações sobre contas de token são armazenadas no razão público e em uma coleta de dados privada. A tabela a seguir mostra onde os valores de transação são armazenados para qualquer ID de conta de token fornecido.

Razão Público (Banco de Dados de Estado)	Coleta de Dados Privada
assetType account_id org_id token_type token_id token_name balance (criptografado) onhold_balance (criptografado) onhold_burn_balance (criptografado) application_groups bapAccountVersion	assetType account_id user_id balance onhold_balance onhold_burn_balance balanceBlindingFactor onHoldBalanceBlindingFactor onHoldBurnBalanceBlindingFactor max_daily_amount daily_amount max_daily_transactions daily_transactions current_date

Os seguintes dados são armazenados no razão público:

• A chave account_id, que é exclusiva para cada usuário no sistema. Normalmente, é o hash SHA-256 do orgId (ID MSP) e do userId (nome de usuário ou e-mail) combinados com outros prefixos ou sufixos.
• Os razões públicos armazenam todas as chaves de conta de qualquer usuário. Os usuários podem ter várias contas de token fungíveis, uma para cada token.
• Os detalhes do token são armazenados nos campos token_type, token_id e token_name.
• Os campos balance e onhold_balance contêm o hash de compromisso Pedersen que representa o valor de texto real do saldo armazenado na coleta de dados privada.

Os seguintes dados são armazenados na coleta de dados privada:

• A chave account_id, descrita anteriormente.
• Os campos balance e onhold_balance contêm o valor de texto real desses saldos.
• Os campos balance_blinding_factor e on_hold_balance_blinding_factor armazenam a chave aleatória usada para criar os compromissos balance e onhold_balance armazenados no razão público.
• Os detalhes diários da transação são armazenados nos campos max_daily_amount, daily_amount, max_daily_transactions, daily_transactions e current_date.

Operações Típicas com Pagamentos Confidenciais

O fluxo de trabalho ao cunhar, transferir, reter ou gravar tokens ao usar pagamentos confidenciais inclui etapas adicionais para garantir a integridade dos dados.

Tokens de Cunhagem

Para tokens de moeda, um usuário com a atribuição de minter chama a API issueTokens.

1. No caso de pagamentos confidenciais, o método issueTokens usa o valor token_id como entrada e também requer um fator de ocultação, que é enviado do proxy REST junto com a quantidade de token passada no mapa transitório.
2. Após verificação, o compromisso Pedersen é gerado a partir do fator cego e da quantidade de tokens para hortelã.
3. Em seguida, a quantidade geral é atualizada no razão público e na coleta de dados privada. Na contabilidade pública, o compromisso Pedersen que representa o saldo existente é aumentado com o compromisso Pederson que representa a quantidade de tokens cunhados (emitidos). O valor real do saldo armazenado na coleta de dados privados é aumentado de acordo.
4. O fator de ocultação também é atualizado, de modo que a qualquer momento o fator de equilíbrio e ocultação na coleta de dados privada possa ser usado para verificar o compromisso correspondente armazenado na contabilidade pública.

Transferindo Tokens em uma Organização

Para transferir tokens dentro de uma organização, o remetente chama a API transferTokens.

1. No caso de pagamentos confidenciais, o método transferTokens usa os parâmetros token_id e opcionais como entrada e também requer um fator de ocultação, que é enviado do proxy REST junto com os valores userId e orgId para o receptor e a quantidade de token passada no mapa transitório.
2. Após verificação, o compromisso Pedersen é gerado a partir do fator cego e da quantidade de tokens a serem transferidos.
3. A quantidade de tokens na conta do remetente é reduzida e a quantidade na conta do destinatário é aumentada, tanto no razão público quanto na coleta de dados privados. No livro-razão público, o compromisso Pedersen que representa o saldo existente do remetente é diminuído pelo compromisso Pedersen que representa a quantidade de tokens transferidos. Para o receptor, o saldo é aumentado da mesma forma. Os valores reais do saldo do remetente e do saldo do destinatário são atualizados na coleta de dados privada.
4. O fator de ocultação também é atualizado, de modo que a qualquer momento o fator de equilíbrio e ocultação na coleta de dados privada possa ser usado para verificar o compromisso correspondente armazenado na contabilidade pública.

Transferindo tokens entre organizações

Para transferir tokens entre organizações, o remetente chama a API holdTokens para extrair o valor da transferência e colocá-lo em retenção.

1. No caso de pagamentos confidenciais, o método holdTokens usa os valores token_id, operation_id e expiration_time como entrada e também requer um fator de ocultação, que é enviado do proxy REST junto com os valores notary_user_id, notary_org_id, to_user_id e to_org_id e a quantidade de token passada no mapa transitório.
2. Após verificação, o compromisso Pedersen é gerado a partir do fator cego e da quantidade de tokens a serem mantidos.
3. Um objeto de contenção e um objeto de remetente são criados.
4. Os compromissos de saldo, saldos reais e objetos de transação são salvos no razão público e nos conjuntos de dados privados para ambas as organizações, o que atualiza todos os saldos adequadamente.

Tokens de Retenção

Como mencionado anteriormente, as operações de retenção são usadas para transferir tokens entre organizações. As operações de retenção usam objetos de retenção, remetente e destinatário, semelhantes aos objetos de conta de token e transação que armazenam dados no razão público e na coleta de dados privada. As operações de retenção também podem ser usadas para transferências na mesma organização, caso em que os objetos do remetente e do destinatário não são criados e a transferência ocorre como uma operação regular do Token Taxonomy Framework usando compromissos Pedersen. A tabela a seguir mostra onde os valores de transação são armazenados para qualquer ID de transação de retenção fornecido.

No modo confidencial, as transferências entre organizações envolvem duas coletas de dados privadas. Em vez de modificar o par chave/valor da conta, para débitos, um objeto do remetente é criado durante a operação de retenção e, para créditos, um objeto do recebedor é criado (quando a API executeHoldReceiver é executada). O saldo é colocado no objeto do remetente. O valor creditado é colocado no objeto recebedor, que é atribuído ao destinatário. Quando a operação de débito é concluída, o objeto do remetente não está mais em uso e pode ser excluído. Da mesma forma, depois que o saldo passa do objeto do recebedor para a conta do destinatário, o objeto do recebedor pode ser excluído.

Razão Público (Banco de Dados de Estado)	Coleta de Dados Privada
operation_id token_name operation_type status assetType holding_id from_account_id from_org_id to_account_id notary_account_id token_id quantity (criptografado) time_to_expiration sender_id category description	quantity blinding_factor assetType holding_id

A tabela a seguir mostra as informações do objeto do remetente que é criado para transferências e retenções interorganizacionais.

Razão Público (Banco de Dados de Estado)	Coleta de Dados Privada
assetType sender_id operation_id account_id transaction_id quantity (criptografado) version	assetType sender_id blindingFactor

A tabela a seguir mostra as informações do objeto do recebedor que é criado para transferências e retenções interorganizacionais.

Razão Público (Banco de Dados de Estado)	Coleta de Dados Privada
assetType receiver_id operation_id account_id transaction_id quantity (criptografado) version	assetType receiver_id blindingFactor

1. No caso de pagamentos confidenciais, o método holdTokens usa os parâmetros token_id e opcionais como entrada e também requer um fator de ocultação, que é enviado do proxy REST junto com os valores userId e orgId para o receptor e a quantidade de token passada no mapa transitório.
2. A operação de retenção deve ser aprovada ou rejeitada por um usuário do notário.
   • Se o usuário do notário aprovar a operação de retenção, a quantidade será debitada do remetente e dos objetos de retenção e um objeto de transação será criado. Um objeto recebedor também é criado e a quantidade é creditada no objeto recebedor.
   • Se o usuário do notário rejeitar a retenção, a quantidade retida será creditada de volta na conta do remetente e um objeto de transação será criado.
3. Os compromissos de saldo, os saldos reais e os objetos de transação são salvos no razão público e na coleta de dados privada, que atualiza todos os saldos adequadamente.

Tokens de queima

Para gravar tokens, um usuário com a atribuição de gravador chama a API burnTokens.

1. No caso de pagamentos confidenciais, o método burnTokens usa o valor token_id como entrada e também requer um fator de ocultação, que é enviado do proxy REST junto com a quantidade de token passada no mapa transitório.
2. Após verificação, o compromisso Pedersen é gerado a partir do fator cego e da quantidade de tokens a serem queimados.
3. Em seguida, a quantidade geral é atualizada no razão público e na coleta de dados privada. No livro-razão público, o compromisso de Pedersen que representa o saldo existente é diminuído com o compromisso de Pederson que representa a quantidade de tokens queimados. O valor real do saldo armazenado na coleta de dados privados é diminuído de acordo.
4. O fator de ocultação também é atualizado, de modo que a qualquer momento o fator de equilíbrio e ocultação na coleta de dados privada possa ser usado para verificar o compromisso correspondente armazenado na contabilidade pública.