Aperçu des paiements confidentiels

Oracle Blockchain Platform Digital Assets Edition utilise les engagements de Pedersen pour assurer la sécurité des données.

Preuves de connaissance zéro

Les ZKP sont des protocoles cryptographiques qui permettent à un prover honnête de démontrer la vérité d'une déclaration à un vérificateur sans révéler d'informations supplémentaires. Un proverbe malhonnête ne peut pas convaincre un vérificateur qu'une fausse déclaration est vraie. Les ZKP s'assurent qu'aucune donnée sensible n'est révélée au-delà de la validité de la réclamation. Les ZKP permettent de prouver des propriétés spécifiques d'une valeur secrète, telles que la confirmation qu'elle se situe dans une plage ou est le résultat d'un calcul spécifique, sans révéler la valeur elle-même.

Engagements de Pedersen

Les preuves de connaissance zéro dépendent de schémas d'engagement, où quelqu'un peut s'engager à une certaine valeur tout en la gardant cachée aux autres. Oracle Blockchain Platform Digital Assets Edition utilise les engagements de Pedersen. Les engagements Pedersen utilisent des valeurs aléatoires connues sous le nom de facteurs aveuglants ainsi que la cryptographie à courbe elliptique pour assurer à la fois le secret et l'immutabilité. Les engagements Pedersen sont homomorphes, c'est-à-dire qu'ils prennent en charge des opérations mathématiques telles que l'addition et la soustraction des engagements tout en préservant les relations entre les valeurs sous-jacentes. Les engagements Pedersen sont utilisés dans les protocoles de transaction privés, le calcul multipartite sécurisé et les systèmes d'identification anonymes.

Utiliser des paiements confidentiels

Vous utilisez l'en-tête Confidential-Transaction dans une demande de transaction pour activer la fonction de paiements confidentiels.

Lorsque vous envoyez l'en-tête Confidential-Transaction défini sur true dans une demande, le proxy REST dans Oracle Blockchain Platform génère un nombre aléatoire unique (le facteur d'aveuglement requis pour un engagement Pedersen) et le transmet dans la correspondance transitoire. Ce code chaîne est utilisé pour traiter l'entrée et stocker les informations sensibles dans une collecte de données privée plutôt que dans la base de données d'état.

Informations sur la transaction

Toutes les opérations de jeton (création de compte, extraction, transfert, gravure, etc.) génèrent un enregistrement de transaction afin que l'historique des transactions puisse être suivi. Les données de transaction sont stockées à deux emplacements : le grand livre public (base de données d'état) et une collecte de données privée. Avec les paiements confidentiels, les données sensibles sont stockées en texte clair uniquement dans les collectes de données privées des organisations impliquées dans la transaction. Le tableau suivant indique où les valeurs de transaction sont stockées pour un ID de transaction donné.

Grand livre (base de données d'état)

Collecte de données privée

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 (crypté) 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

Informations sur le compte de jeton

De même, les informations sur les comptes de jetons sont stockées dans le grand livre public et dans une collecte de données privée. Le tableau suivant indique où les valeurs de transaction sont stockées pour un ID de compte de jetons donné.

Grand livre (base de données d'état)	Collecte de données privée
assetType account_id org_id token_type token_id token_name balance (crypté) onhold_balance (crypté) onhold_burn_balance (crypté) 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

Les données suivantes sont stockées dans le grand livre public :

• Clé account_id, unique pour chaque utilisateur du système. En règle générale, il s'agit du hachage SHA-256 de orgId (ID MSP) et userId (nom d'utilisateur ou adresse électronique) associé à d'autres préfixes ou suffixes.
• Les livres publics stockent toutes les clés de compte d'un utilisateur. Les utilisateurs peuvent avoir plusieurs comptes de jetons fongibles, un pour chaque jeton.
• Les détails de jeton sont stockés dans les champs token_type, token_id et token_name.
• Les champs balance et onhold_balance contiennent le hachage d'engagement Pedersen qui représente la valeur textuelle réelle du solde stocké dans la collecte de données privée.

Les données suivantes sont stockées dans la collecte de données privée :

• La clé account_id, décrite précédemment.
• Les champs balance et onhold_balance contiennent la valeur de texte réelle de ces soldes.
• Les champs balance_blinding_factor et on_hold_balance_blinding_factor stockent la clé aléatoire utilisée pour créer les engagements balance et onhold_balance stockés dans le grand livre public.
• Les détails quotidiens de la transaction sont stockés dans les champs max_daily_amount, daily_amount, max_daily_transactions, daily_transactions et current_date.

Opérations standard avec paiements confidentiels

Le workflow lorsque vous extrayez, transférez, bloquez ou gravez des jetons lors de l'utilisation de paiements confidentiels comprend des étapes supplémentaires pour garantir l'intégrité des données.

Jetons de menthe

Pour extraire des jetons, un utilisateur doté du rôle minter appelle l'API issueTokens.

1. Dans le cas des paiements confidentiels, la méthode issueTokens prend la valeur token_id en tant qu'entrée et requiert également un facteur d'aveuglement, qui est envoyé à partir du proxy REST avec la quantité de jeton transmise dans la correspondance non persistante.
2. Après vérification, l'engagement de Pedersen est généré à partir du facteur d'aveuglement et de la quantité de jetons à la menthe.
3. La quantité globale est ensuite mise à jour à la fois dans le livre public et dans la collecte de données privée. Dans le grand public, l'engagement de Pedersen qui représente le solde existant est augmenté avec l'engagement de Pederson qui représente la quantité de jetons frappés (émis). La valeur réelle du solde stocké dans la collecte de données privée est augmentée en conséquence.
4. Le facteur d'aveuglement est également mis à jour, de sorte qu'à tout moment, le solde et le facteur d'aveuglement dans la collecte de données privées peuvent être utilisés pour vérifier l'engagement correspondant stocké dans le grand livre public.

Transfert de jetons au sein d'une organisation

Pour transférer des jetons au sein d'une organisation, l'émetteur appelle l'API transferTokens.

1. Dans le cas des paiements confidentiels, la méthode transferTokens prend les paramètres token_id et facultatifs en entrée, et requiert également un facteur d'aveuglement, qui est envoyé à partir du proxy REST avec les valeurs userId et orgId pour le récepteur et la quantité de jeton transmise dans la correspondance transitoire.
2. Après vérification, l'engagement Pedersen est généré à partir du facteur d'aveuglement et de la quantité de jetons à transférer.
3. La quantité de jetons dans le compte de l'expéditeur est réduite et la quantité dans le compte du destinataire est augmentée, à la fois dans le grand livre public et dans la collecte de données privée. Dans le grand livre public, l'engagement de Pedersen qui représente le solde existant de l'expéditeur est diminué par l'engagement de Pedersen qui représente la quantité de jetons transférés. Pour le récepteur, le solde est augmenté de la même manière. Les valeurs réelles du solde de l'expéditeur et du solde du destinataire sont mises à jour dans la collecte de données privée.
4. Le facteur d'aveuglement est également mis à jour, de sorte qu'à tout moment, le solde et le facteur d'aveuglement dans la collecte de données privées peuvent être utilisés pour vérifier l'engagement correspondant stocké dans le grand livre public.

Transfert de jetons entre organisations

Pour transférer des jetons entre organisations, l'émetteur appelle l'API holdTokens afin d'extraire le montant du transfert et de le bloquer.

1. Dans le cas des paiements confidentiels, la méthode holdTokens prend les valeurs token_id, operation_id et expiration_time en entrée et requiert également un facteur d'aveuglement, qui est envoyé à partir du proxy REST avec les valeurs notary_user_id, notary_org_id, to_user_id et to_org_id et la quantité de jeton transmise dans la correspondance non persistante.
2. Après vérification, l'engagement de Pedersen est généré à partir du facteur d'aveuglement et de la quantité de jetons à conserver.
3. Un objet de blocage et un objet d'expéditeur sont créés.
4. Les engagements de solde, les soldes réels et les objets de transaction sont enregistrés dans le livre public et dans les collectes de données privées pour les deux organisations, ce qui met à jour tous les soldes en conséquence.

Stockage de jetons

Comme mentionné précédemment, les opérations de mise en attente sont utilisées pour transférer des jetons entre les organisations. Les opérations de blocage utilisent des objets de blocage, d'expéditeur et de destinataire, semblables aux objets de compte de transactions et de jetons qui stockent les données à la fois dans le livre public et dans la collecte de données privée. Les opérations de blocage peuvent également être utilisées pour les transferts dans la même organisation, auquel cas les objets expéditeur et destinataire ne sont pas créés et le transfert se produit en tant qu'opération standard de la structure de taxonomie de jeton à l'aide des engagements Pedersen. Le tableau suivant indique où les valeurs de transaction sont stockées pour un ID de transaction de blocage donné.

En mode confidentiel, les transferts entre organisations impliquent deux collectes de données privées. Au lieu de modifier la paire clé/valeur de compte, pour les débits, un objet émetteur est créé lors de l'opération de blocage et pour les crédits, un objet récepteur est créé (lors de l'exécution de l'API executeHoldReceiver). Le solde est placé dans l'objet expéditeur. Le montant crédité est placé dans l'objet bénéficiaire, qui est affecté au destinataire. Une fois l'opération de débit terminée, l'objet expéditeur n'est plus utilisé et peut être supprimé. De même, une fois que le solde passe de l'objet récepteur au compte du destinataire, l'objet récepteur peut être supprimé.

Grand livre (base de données d'état)	Collecte de données privée
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 (crypté) time_to_expiration sender_id category description	quantity blinding_factor assetType holding_id

Le tableau suivant présente les informations relatives à l'objet émetteur créé pour les transferts et blocages entre organisations.

Grand livre (base de données d'état)	Collecte de données privée
assetType sender_id operation_id account_id transaction_id quantity (crypté) version	assetType sender_id blindingFactor

Le tableau suivant présente les informations relatives à l'objet bénéficiaire créé pour les transferts et blocages interorganisationnels.

Grand livre (base de données d'état)	Collecte de données privée
assetType receiver_id operation_id account_id transaction_id quantity (crypté) version	assetType receiver_id blindingFactor

1. Dans le cas des paiements confidentiels, la méthode holdTokens prend les paramètres token_id et facultatifs en entrée, et requiert également un facteur d'aveuglement, qui est envoyé à partir du proxy REST avec les valeurs userId et orgId pour le récepteur et la quantité de jeton transmise dans la correspondance transitoire.
2. L'opération de blocage doit être approuvée ou rejetée par un utilisateur notaire.
   • Si l'utilisateur notaire approuve l'opération de blocage, la quantité est débitée de l'expéditeur et des objets de blocage et un objet de transaction est créé. Un objet bénéficiaire est également créé et la quantité est créditée à l'objet bénéficiaire.
   • Si l'utilisateur notaire rejette le blocage, la quantité bloquée est créditée sur le compte de l'expéditeur et un objet de transaction est créé.
3. Les engagements de solde, les soldes réels et les objets de transaction sont enregistrés dans le livre public et dans la collecte de données privée, ce qui met à jour tous les soldes en conséquence.

Jetons brûlants

Pour graver des jetons, un utilisateur doté du rôle de brûleur appelle l'API burnTokens.

1. Dans le cas des paiements confidentiels, la méthode burnTokens prend la valeur token_id en tant qu'entrée et requiert également un facteur d'aveuglement, qui est envoyé à partir du proxy REST avec la quantité de jeton transmise dans la correspondance non persistante.
2. Après vérification, l'engagement de Pedersen est généré à partir du facteur d'aveuglement et de la quantité de jetons à brûler.
3. La quantité globale est ensuite mise à jour à la fois dans le livre public et dans la collecte de données privée. Dans le grand livre public, l'engagement de Pedersen qui représente le solde existant est diminué avec l'engagement de Pederson qui représente la quantité de jetons brûlés. La valeur réelle du solde stocké dans la collecte de données privée est diminuée en conséquence.
4. Le facteur d'aveuglement est également mis à jour, de sorte qu'à tout moment, le solde et le facteur d'aveuglement dans la collecte de données privées peuvent être utilisés pour vérifier l'engagement correspondant stocké dans le grand livre public.