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 sans connaissance

Les ZKPs sont des protocoles cryptographiques qui permettent à un proverbe 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 veillent à ce qu'aucune donnée sensible ne soit 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 qu'elle est le résultat d'un calcul spécifique, sans révéler la valeur elle-même.

Engagements Pedersen

Les preuves sans connaissance dépendent de systèmes d'engagement, où quelqu'un peut s'engager à une certaine valeur tout en la cachant aux autres. La solution Digital Assets Edition d'Oracle Blockchain Platform utilise les engagements de Pedersen. Les engagements de Pedersen utilisent des valeurs aléatoires appelées facteurs aveuglants ainsi que la cryptographie à courbe elliptique pour assurer à la fois le secret et l'immutabilité. Les engagements Pedersen sont homomorphes; en d'autres termes, ils soutiennent l'exécution d'opérations mathématiques telles que l'ajout et la soustraction d'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.

Utilisation 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 le jeu d'en-têtes Confidential-Transaction à Vrai dans une demande, le mandataire REST d'Oracle Blockchain Platform génère un nombre aléatoire unique (facteur d'aveuglement requis pour un engagement Pedersen) et le transmet dans la carte transitoire. Ce code de chaîne est utilisé pour traiter l'entrée et stocker les informations sensibles dans une collection de données privée plutôt que dans la base de données d'état.

Informations sur les transactions

Toutes les opérations de jeton (création de compte, frappe, 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 endroits : 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 collections 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 (chiffré) 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 jeton sont stockées dans le livre public et une collecte de données privée. Le tableau suivant montre où les valeurs de transaction sont stockées pour un ID compte de jeton 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 (chiffré) onhold_balance (chiffré) onhold_burn_balance (chiffré) 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. Typicall est le hachage SHA-256 des orgId (ID MSP) et userId (nom d'utilisateur ou courriel) combiné avec d'autres préfixes ou suffixes.
• Les grands livres publics stockent toutes les clés de compte de tout utilisateur. Les utilisateurs peuvent avoir plusieurs comptes de jeton fongibles, un pour chaque jeton.
• Les détails du 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 collection privée :

• Clé account_id, décrite précédemment.
• Les champs balance et onhold_balance contiennent la valeur textuelle 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 livre public.
• Les détails de transaction quotidienne sont stockés dans les champs max_daily_amount, daily_amount, max_daily_transactions, daily_transactions et current_date.

Opérations typiques avec paiements confidentiels

Le flux de travail lorsque vous mentez, transférez, bloquez ou brûlez des jetons lors de l'utilisation de paiements confidentiels comprend des étapes supplémentaires pour assurer l'intégrité des données.

Jetons d' menthe

Pour mint tokens, 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 nécessite également un facteur d'aveuglement, qui est envoyé par le mandataire REST avec la quantité de jeton transmise dans le mappage transitoire.
2. Après vérification, l'engagement 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 grand livre public et dans la collecte de données privée. Dans le grand livre public, l'engagement Pedersen qui représente le solde existant est augmenté avec l'engagement 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 facteur d'équilibre et d'aveuglement dans la collecte de données privées peut être utilisé pour vérifier l'engagement correspondant stocké dans le livre public.

Transfert de jetons au sein d'une organisation

Pour transférer des jetons au sein d'une organisation, l'expéditeur 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 nécessite également un facteur d'aveuglement, qui est envoyé à partir du mandataire REST avec les valeurs userId et orgId pour le destinataire et la quantité de jeton transmise dans le mappage 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 Pedersen qui représente le solde existant de l'expéditeur est diminué par l'engagement 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 facteur d'équilibre et d'aveuglement dans la collecte de données privées peut être utilisé pour vérifier l'engagement correspondant stocké dans le livre public.

Transfert de jetons entre organisations

Pour transférer des jetons entre organisations, l'expéditeur appelle l'API holdTokens pour extraire le montant du transfert et le mettre en attente.

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 mandataire REST avec les valeurs notary_user_id, notary_org_id, to_user_id et to_org_id, ainsi que la quantité de jeton transmise dans le mappage transitoire.
2. Après vérification, l'engagement Pedersen est généré à partir du facteur d'aveuglement et de la quantité de jetons à tenir.
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 grand livre public et dans les collections de données privées pour les deux organisations, ce qui met à jour tous les soldes en conséquence.

Jetons de détention

Comme mentionné précédemment, les opérations de blocage 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, similaires aux objets de compte de transaction et de jeton qui stockent des 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 cadre de taxonomie de jeton à l'aide d'engagements Pedersen. Le tableau suivant indique où les valeurs de transaction sont stockées pour un ID 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 d'expéditeur est créé lors de l'opération de blocage et pour les crédits, un objet destinataire 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 destinataire, 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 le solde déplacé de l'objet récepteur vers le 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 (chiffré) time_to_expiration sender_id category description	quantity blinding_factor assetType holding_id

Le tableau suivant présente les informations relatives à l'objet expéditeur créé pour les transferts et blocages interorganisations.

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

Le tableau suivant présente les informations relatives à l'objet destinataire créé pour les transferts et blocages interorganisations.

Grand livre (base de données d'État)	Collecte de données privée
assetType receiver_id operation_id account_id transaction_id quantity (chiffré) 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 nécessite également un facteur d'aveuglement, qui est envoyé à partir du mandataire REST avec les valeurs userId et orgId pour le destinataire et la quantité de jeton transmise dans le mappage 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 récepteur est également créé et la quantité est créditée à l'objet récepteur.
   • Si l'utilisateur du notaire refuse le blocage, la quantité bloquée est créditée dans 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 grand 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 nécessite également un facteur d'aveuglement, qui est envoyé par le mandataire REST avec la quantité de jeton transmise dans le mappage transitoire.
2. Après vérification, l'engagement 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 grand livre public et dans la collecte de données privée. Dans le grand livre public, l'engagement Pedersen qui représente le solde existant est diminué avec l'engagement 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 facteur d'équilibre et d'aveuglement dans la collecte de données privées peut être utilisé pour vérifier l'engagement correspondant stocké dans le livre public.