Vertrauliche Zahlungen - Überblick

Die Oracle Blockchain Platform Digital Assets Edition verwendet Pedersen-Verpflichtungen, um die Datensicherheit zu gewährleisten.

Zero-Knowledge-Beweise

Zero-Knowledge-Protokolle (ZKPs) sind kryptografische Protokolle, mit denen ein ehrlicher Prover die Wahrheit einer Aussage einem Verifizierer demonstrieren kann, ohne zusätzliche Informationen preiszugeben. Ein unehrlicher Prover kann einen Verifizierer nicht davon überzeugen, dass eine falsche Aussage wahr ist. ZKPs stellen sicher, dass keine sensiblen Daten über die Gültigkeit der Forderung hinaus offengelegt werden. ZKPs ermöglichen es, bestimmte Eigenschaften eines geheimen Wertes nachzuweisen, z. B. zu bestätigen, dass er in einen Bereich fällt oder das Ergebnis einer bestimmten Berechnung ist, ohne den Wert selbst aufzudecken.

Pedersen Verpflichtungen

Zero-Knowledge-Beweise hängen von Verpflichtungssystemen ab, bei denen sich jemand zu einem bestimmten Wert verpflichten kann, während er vor anderen verborgen bleibt. Die Oracle Blockchain Platform Digital Assets Edition verwendet Pedersen-Verpflichtungen. Pedersen-Verpflichtungen verwenden zufällige Werte, die als Blindfaktoren bezeichnet werden, zusammen mit elliptischer Kurvenkryptografie, um sowohl Geheimhaltung als auch Unveränderlichkeit sicherzustellen. Pedersen-Verpflichtungen sind homomorph; mit anderen Worten, sie unterstützen die Durchführung mathematischer Operationen wie Addition und Subtraktion von Verpflichtungen unter Beibehaltung der Beziehungen zwischen den zugrunde liegenden Werten. Pedersen-Verpflichtungen werden in privaten Transaktionsprotokollen, sicheren Multiparty-Berechnungen und anonymen Zugangsdatensystemen verwendet.

Mit vertraulichen Zahlungen arbeiten

Sie verwenden den Header Confidential-Transaction in einer Transaktionsanforderung, um das Feature "Vertrauliche Zahlungen" zu aktivieren.

Wenn Sie den Confidential-Transaction-Header senden, der in einer Anforderung auf true gesetzt ist, generiert der REST-Proxy in Oracle Blockchain Platform eine eindeutige Zufallszahl (den für eine Pedersen-Verpflichtung erforderlichen Blinding-Faktor) und übergibt sie in der transienten Karte. Dies wird vom Chaincode verwendet, um die Eingabe zu verarbeiten und die sensiblen Informationen in einer privaten Datenerfassung statt in der Statusdatenbank zu speichern.

Transaktionsinformationen

Alle Tokenvorgänge (Kontoerstellung, Minting, Transfer, Burning usw.) generieren einen Transaktionsdatensatz, damit die Transaktionshistorie verfolgt werden kann. Transaktionsdaten werden an zwei Stellen gespeichert: das öffentliche Hauptbuch (Staatsdatenbank) und eine private Datenerfassung. Bei vertraulichen Zahlungen werden die sensiblen Daten in Klartext nur in den privaten Datensammlungen der an der Transaktion beteiligten Organisationen gespeichert. Die folgende Tabelle zeigt, wo Transaktionswerte für eine bestimmte Transaktions-ID gespeichert werden.

Öffentliches Buch (Statusdatenbank) Private Datenerfassung
  • 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 (verschlüsselt)
  • 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

Tokenkontoinformationen

Ebenso werden Informationen zu Tokenkonten im öffentlichen Ledger und einer privaten Datenerfassung gespeichert. Die folgende Tabelle zeigt, wo Transaktionswerte für eine bestimmte Token-Konto-ID gespeichert werden.

Öffentliches Buch (Statusdatenbank) Private Datenerfassung
  • assetType
  • account_id
  • org_id
  • token_type
  • token_id
  • token_name
  • balance (verschlüsselt)
  • onhold_balance (verschlüsselt)
  • onhold_burn_balance (verschlüsselt)
  • 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
Folgende Daten werden im öffentlichen Ledger gespeichert:
  • Der account_id-Schlüssel, der für jeden Benutzer im System eindeutig ist. Typisch ist der SHA-256-Hash der orgId (MSP-ID) und userId (Benutzername oder E-Mail) in Kombination mit anderen Präfixen oder Suffixen.
  • In den öffentlichen Büchern werden alle Kontenschlüssel eines Benutzers gespeichert. Benutzer können mehrere fungible Tokenaccounts haben, eines für jedes Token.
  • Tokendetails werden in den Feldern token_type, token_id und token_name gespeichert.
  • Die Felder balance und onhold_balance enthalten den Pedersen-Verpflichtungshash, der den tatsächlichen Textwert des Saldos darstellt, der in der privaten Datenerfassung gespeichert ist.
Folgende Daten werden in der privaten Datenerhebung gespeichert:
  • Der account_id-Schlüssel, der zuvor beschrieben wurde.
  • Die Felder balance und onhold_balance enthalten den tatsächlichen Textwert dieser Salden.
  • In den Feldern balance_blinding_factor und on_hold_balance_blinding_factor wird der Zufallsschlüssel gespeichert, der zum Erstellen der Verpflichtungen balance und onhold_balance verwendet wird, die im öffentlichen Buch gespeichert sind.
  • Tägliche Transaktionsdetails werden in den Feldern max_daily_amount, daily_amount, max_daily_transactions, daily_transactions und current_date gespeichert.

Typische Vorgänge mit vertraulichen Zahlungen

Der Workflow, wenn Sie Token mintieren, übertragen, halten oder brennen, während Sie vertrauliche Zahlungen verwenden, umfasst zusätzliche Schritte, um die Datenintegrität sicherzustellen.

Prägetoken

Um Token zu mintieren, ruft ein Benutzer mit der Minter-Rolle die issueTokens-API auf.
  1. Im Fall vertraulicher Zahlungen verwendet die Methode issueTokens den Wert token_id als Eingabe. Außerdem ist ein Blinding-Faktor erforderlich, der vom REST-Proxy zusammen mit der in der transienten Zuordnung übergebenen Tokenmenge gesendet wird.
  2. Nach der Überprüfung wird die Pedersen-Verpflichtung aus dem Blinding-Faktor und der Menge der zu prägenden Token generiert.
  3. Die Gesamtmenge wird dann sowohl im öffentlichen Buch als auch in der privaten Datenerfassung aktualisiert. Im öffentlichen Hauptbuch wird die Pedersen-Verpflichtung, die den bestehenden Saldo darstellt, mit der Pederson-Verpflichtung erhöht, die die Anzahl der abgebauten (ausgestellten) Token darstellt. Der tatsächliche Wert des in der privaten Datenerhebung gespeicherten Guthabens wird entsprechend erhöht.
  4. Der Blinding-Faktor wird ebenfalls aktualisiert, so dass jederzeit der Balance- und Blinding-Faktor in der privaten Datenerfassung verwendet werden kann, um die entsprechende Verpflichtung zu überprüfen, die im öffentlichen Ledger gespeichert ist.

Token innerhalb einer Organisation übertragen

Um Token innerhalb einer Organisation zu übertragen, ruft der Absender die transferTokens-API auf.
  1. Im Fall der vertraulichen Zahlungen verwendet die Methode transferTokens die Parameter token_id und optional als Eingabe. Außerdem ist ein Blinding-Faktor erforderlich, der vom REST-Proxy zusammen mit den Werten userId und orgId für den Empfänger und der in der transienten Zuordnung übergebenen Tokenmenge gesendet wird.
  2. Nach der Überprüfung wird die Pedersen-Verpflichtung aus dem Blinding-Faktor und der Menge der zu übertragenden Token generiert.
  3. Die Anzahl der Token im Konto des Absenders wird verringert, und die Menge im Konto des Empfängers wird erhöht, sowohl im öffentlichen Buch als auch in der privaten Datenerfassung. Im öffentlichen Hauptbuch wird die Pedersen-Verpflichtung, die den vorhandenen Saldo des Absenders darstellt, durch die Pedersen-Verpflichtung verringert, die die Menge der übertragenen Token darstellt. Für den Empfänger wird das Gleichgewicht auf die gleiche Weise erhöht. Die Istwerte des Absendersaldos und des Empfängersaldos werden in der privaten Datenerfassung aktualisiert.
  4. Der Blinding-Faktor wird ebenfalls aktualisiert, so dass jederzeit der Balance- und Blinding-Faktor in der privaten Datenerfassung verwendet werden kann, um die entsprechende Verpflichtung zu überprüfen, die im öffentlichen Ledger gespeichert ist.

Token zwischen Organisationen übertragen

Um Token zwischen Organisationen zu übertragen, ruft der Absender die API holdTokens auf, um den Übertragungsbetrag zu extrahieren und zu sperren.
  1. Im Fall der vertraulichen Zahlungen verwendet die Methode holdTokens die Werte token_id, operation_id und expiration_time als Eingabe und erfordert außerdem einen Blinding-Faktor, der vom REST-Proxy zusammen mit den Werten notary_user_id, notary_org_id, to_user_id und to_org_id und der in der transienten Zuordnung übergebenen Tokenmenge gesendet wird.
  2. Nach der Überprüfung wird die Pedersen-Verpflichtung aus dem Blinding-Faktor und der Menge der zu haltenden Token generiert.
  3. Ein Sperrobjekt und ein Absenderobjekt werden erstellt.
  4. Die Saldenverpflichtungen, Istsalden und Transaktionsobjekte werden im öffentlichen Buch und in den privaten Datenerfassungen für beide Organisationen gespeichert. Dadurch werden alle Salden entsprechend aktualisiert.

Token halten

Wie bereits erwähnt, werden Sperrvorgänge verwendet, um Token zwischen Organisationen zu übertragen. Sperrenvorgänge verwenden Halte-, Absender- und Empfängerobjekte, ähnlich wie Transaktions- und Tokenkontenobjekte, die Daten sowohl im öffentlichen Buch als auch in der privaten Datenerfassung speichern. Hold-Operationen können auch für Transfers in derselben Organisation verwendet werden. In diesem Fall werden Absender- und Empfängerobjekte nicht erstellt, und die Übertragung erfolgt als regulärer Token Taxonomy Framework-Vorgang mit Pedersen-Verpflichtungen. Die folgende Tabelle zeigt, wo Transaktionswerte für eine bestimmte Sperrtransaktions-ID gespeichert werden.

Im vertraulichen Modus umfassen Übertragungen zwischen Organisationen zwei private Datensammlungen. Anstatt das Schlüssel/Wert-Paar des Kontos zu ändern, wird für Lastschriften während des Sperrvorgangs ein Absenderobjekt erstellt. Für Gutschriften wird ein Empfängerobjekt erstellt (wenn die API executeHoldReceiver ausgeführt wird). Der Saldo wird im Absenderobjekt platziert. Der gutgeschriebene Betrag wird im Empfängerobjekt platziert, das dem Empfänger zugewiesen ist. Wenn der Lastschriftvorgang abgeschlossen ist, wird das Absenderobjekt nicht mehr verwendet und kann gelöscht werden. Ebenso kann das Empfängerobjekt gelöscht werden, nachdem der Saldo vom Empfängerobjekt auf das Konto des Empfängers verschoben wurde.

Öffentliches Buch (Statusdatenbank) Private Datenerfassung
  • 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 (verschlüsselt)
  • time_to_expiration
  • sender_id
  • category
  • description
  • quantity
  • blinding_factor
  • assetType
  • holding_id

Die folgende Tabelle zeigt die Informationen für das Absenderobjekt, das für zwischenbetriebliche Transfers und Sperren erstellt wird.

Öffentliches Buch (Statusdatenbank) Private Datenerfassung
  • assetType
  • sender_id
  • operation_id
  • account_id
  • transaction_id
  • quantity (verschlüsselt)
  • version
  • assetType
  • sender_id
  • blindingFactor

Die folgende Tabelle zeigt die Informationen für das Empfängerobjekt, das für zwischenbetriebliche Transfers und Sperren erstellt wird.

Öffentliches Buch (Statusdatenbank) Private Datenerfassung
  • assetType
  • receiver_id
  • operation_id
  • account_id
  • transaction_id
  • quantity (verschlüsselt)
  • version
  • assetType
  • receiver_id
  • blindingFactor
  1. Im Fall der vertraulichen Zahlungen verwendet die Methode holdTokens die Parameter token_id und optional als Eingabe. Außerdem ist ein Blinding-Faktor erforderlich, der vom REST-Proxy zusammen mit den Werten userId und orgId für den Empfänger und der in der transienten Zuordnung übergebenen Tokenmenge gesendet wird.
  2. Der Sperrvorgang muss von einem Notar genehmigt oder abgelehnt werden.
    • Wenn der Notar den Sperrvorgang genehmigt, wird die Menge vom Absender belastet und Objekte gesperrt, und ein Transaktionsobjekt wird erstellt. Ein Empfängerobjekt wird ebenfalls erstellt, und die Menge wird dem Empfängerobjekt gutgeschrieben.
    • Wenn der Notar die Sperre zurückweist, wird die gesperrte Menge dem Konto des Absenders gutgeschrieben, und ein Transaktionsobjekt wird erstellt.
  3. Die Saldenverpflichtungen, Istsalden und Transaktionsobjekte werden im öffentlichen Buch und in der privaten Datenerfassung gespeichert. Dadurch werden alle Salden entsprechend aktualisiert.

Token brennen

Um Token zu brennen, ruft ein Benutzer mit der Burner-Rolle die burnTokens-API auf.
  1. Im Fall vertraulicher Zahlungen verwendet die Methode burnTokens den Wert token_id als Eingabe. Außerdem ist ein Blinding-Faktor erforderlich, der vom REST-Proxy zusammen mit der in der transienten Zuordnung übergebenen Tokenmenge gesendet wird.
  2. Nach der Überprüfung wird die Pedersen-Verpflichtung aus dem Blinding-Faktor und der Menge der zu brennenden Token generiert.
  3. Die Gesamtmenge wird dann sowohl im öffentlichen Buch als auch in der privaten Datenerfassung aktualisiert. Im öffentlichen Ledger wird die Pedersen-Verpflichtung, die den vorhandenen Saldo repräsentiert, mit der Pederson-Verpflichtung verringert, die die Anzahl der verbrannten Token darstellt. Der tatsächliche Wert des in der privaten Datenerfassung gespeicherten Saldos wird entsprechend verringert.
  4. Der Blinding-Faktor wird ebenfalls aktualisiert, so dass jederzeit der Balance- und Blinding-Faktor in der privaten Datenerfassung verwendet werden kann, um die entsprechende Verpflichtung zu überprüfen, die im öffentlichen Ledger gespeichert ist.