Panoramica pagamenti riservati

Oracle Blockchain Platform Digital Assets Edition utilizza gli impegni di Pedersen per garantire la sicurezza dei dati.

Prove a conoscenza zero

Le prove a conoscenza zero (ZKP) sono protocolli crittografici che consentono a un prover onesto di dimostrare la verità di una dichiarazione a un verificatore senza rivelare alcuna informazione aggiuntiva. Un prover disonesto non può convincere un verificatore che una falsa affermazione è vera. Gli ZKP garantiscono che non vengano rivelati dati sensibili oltre la validità del reclamo. Gli ZKP consentono di dimostrare proprietà specifiche di un valore segreto, come la conferma che rientra in un intervallo o è il risultato di un calcolo specifico, senza rivelare il valore stesso.

Impegni Pedersen

Le prove a conoscenza zero dipendono da schemi di impegno, in cui qualcuno può impegnarsi a un certo valore pur tenendolo nascosto agli altri. Oracle Blockchain Platform Digital Assets Edition utilizza gli impegni di Pedersen. Gli impegni di Pedersen utilizzano valori casuali noti come fattori di accecamento insieme alla crittografia a curva ellittica per garantire sia la segretezza che l'immutabilità. Gli impegni di Pedersen sono omomorfici; in altre parole, supportano l'esecuzione di operazioni matematiche come l'aggiunta e la sottrazione degli impegni, preservando al contempo le relazioni tra i valori sottostanti. Gli impegni Pedersen vengono utilizzati nei protocolli di transazione privata, nel calcolo sicuro multiparte e nei sistemi di credenziali anonime.

Utilizzo dei pagamenti riservati

Utilizzare l'intestazione Confidential-Transaction in una richiesta di transazione per abilitare la funzione Pagamenti riservati.

Quando si invia l'intestazione Confidential-Transaction impostata su true in una richiesta, il proxy REST in Oracle Blockchain Platform genera un numero casuale univoco (il fattore di accecamento richiesto per un impegno Pedersen) e lo passa nella mappa transitoria. Viene utilizzato dal codice concatenato per elaborare l'input e per memorizzare le informazioni riservate in una raccolta dati privata anziché nel database di stato.

Informazioni transazione

Tutte le operazioni token (creazione conto, stampa, trasferimento, masterizzazione e così via) generano un record transazione in modo che la cronologia delle transazioni possa essere tracciata. I dati delle transazioni vengono memorizzati in due posizioni: il registro pubblico (database di stato) e una raccolta di dati privati. Con pagamenti riservati, i dati sensibili vengono memorizzati in chiaro solo nelle raccolte di dati privati delle organizzazioni coinvolte nella transazione. La tabella seguente mostra dove vengono memorizzati i valori delle transazioni per un determinato ID transazione.

Libro contabile pubblico (database di stato)

Raccolta dati privati

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 (cifrato) 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

Informazioni account token

Allo stesso modo, le informazioni sui conti token vengono memorizzate nel libro contabile pubblico e in una raccolta di dati privati. La tabella riportata di seguito mostra dove vengono memorizzati i valori delle transazioni per qualsiasi ID conto token specificato.

Libro contabile pubblico (database di stato)	Raccolta dati privati
assetType account_id org_id token_type token_id token_name balance (cifrato) onhold_balance (cifrato) onhold_burn_balance (cifrato) 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

I seguenti dati vengono memorizzati nel registro pubblico:

• La chiave account_id, univoca per ogni utente del sistema. Tipicamente è l'hash SHA-256 di orgId (MSP ID) e userId (nome utente o e-mail) combinati con altri prefissi o suffissi.
• I libri contabili pubblici memorizzano tutte le chiavi conto di qualsiasi utente. Gli utenti possono avere più account token fungibili, uno per ogni token.
• I dettagli del token vengono memorizzati nei campi token_type, token_id e token_name.
• I campi balance e onhold_balance contengono l'hash di impegno Pedersen che rappresenta il valore di testo effettivo del saldo memorizzato nella raccolta dati privata.

I seguenti dati vengono memorizzati nella raccolta dati privata:

• La chiave account_id, descritta in precedenza.
• I campi balance e onhold_balance contengono il valore di testo effettivo di tali saldi.
• I campi balance_blinding_factor e on_hold_balance_blinding_factor memorizzano la chiave casuale utilizzata per creare gli impegni balance e onhold_balance memorizzati nel libro contabile pubblico.
• I dettagli delle transazioni giornaliere vengono memorizzati nei campi max_daily_amount, daily_amount, max_daily_transactions, daily_transactions e current_date.

Operazioni tipiche con pagamenti riservati

Il flusso di lavoro durante la creazione, il trasferimento, il blocco o la masterizzazione di token durante l'utilizzo di pagamenti riservati include passaggi aggiuntivi per garantire l'integrità dei dati.

Token di stampa

Per eseguire il mint dei token, un utente con il ruolo minore chiama l'API issueTokens.

1. Nel caso dei pagamenti riservati, il metodo issueTokens utilizza il valore token_id come input e richiede anche un fattore di accecamento, che viene inviato dal proxy REST insieme alla quantità di token passata nella mappa transitoria.
2. Dopo la verifica, l'impegno Pedersen viene generato dal fattore di accecamento e dalla quantità di gettoni alla menta.
3. La quantità complessiva viene quindi aggiornata sia nel libro contabile pubblico che nella raccolta di dati privati. Nel registro pubblico, l'impegno di Pedersen che rappresenta il saldo esistente viene aumentato con l'impegno di Pederson che rappresenta la quantità di token coniati (emessi). Il valore effettivo del saldo memorizzato nella raccolta di dati privati viene aumentato di conseguenza.
4. Anche il fattore cieco viene aggiornato, in modo che in qualsiasi momento il saldo e il fattore cieco nella raccolta di dati privati possano essere utilizzati per verificare l'impegno corrispondente memorizzato nel registro pubblico.

Trasferimento di token in un'organizzazione

Per trasferire i token all'interno di un'organizzazione, il mittente chiama l'API transferTokens.

1. Nel caso dei pagamenti riservati, il metodo transferTokens utilizza i parametri token_id e facoltativi come input e richiede anche un fattore di accecamento, che viene inviato dal proxy REST insieme ai valori userId e orgId per il ricevente e alla quantità di token passata nella mappa transitoria.
2. Dopo la verifica, l'impegno di Pedersen viene generato dal fattore accecante e dalla quantità di token da trasferire.
3. La quantità di token nel conto del mittente viene ridotta e la quantità nel conto del ricevente viene aumentata, sia nel registro pubblico che nella raccolta di dati privati. Nel registro pubblico, l'impegno Pedersen che rappresenta il saldo esistente del mittente è diminuito dall'impegno Pedersen che rappresenta la quantità di token transferrerd. Per il ricevitore, il saldo viene aumentato allo stesso modo. I valori effettivi del saldo del mittente e del saldo del ricevente vengono aggiornati nella raccolta dati privata.
4. Anche il fattore cieco viene aggiornato, in modo che in qualsiasi momento il saldo e il fattore cieco nella raccolta di dati privati possano essere utilizzati per verificare l'impegno corrispondente memorizzato nel registro pubblico.

Trasferimento di token tra organizzazioni

Per trasferire i token tra organizzazioni, il mittente chiama l'API holdTokens per estrarre l'importo di trasferimento e bloccarlo.

1. Nel caso dei pagamenti riservati, il metodo holdTokens prende i valori token_id, operation_id e expiration_time come input e richiede anche un fattore di accecamento, che viene inviato dal proxy REST insieme ai valori notary_user_id, notary_org_id, to_user_id e to_org_id e alla quantità di token passata nella mappa transitoria.
2. Dopo la verifica, l'impegno di Pedersen viene generato dal fattore di accecamento e dalla quantità di token da contenere.
3. Vengono creati un oggetto di blocco e un oggetto mittente.
4. Gli impegni saldo, i saldi effettivi e gli oggetti transazione vengono salvati nel libro contabile pubblico e nelle raccolte dati private per entrambe le organizzazioni, che aggiornano di conseguenza tutti i saldi.

Token in sospeso

Come accennato in precedenza, le operazioni di blocco vengono utilizzate per trasferire i token tra le organizzazioni. Le operazioni di blocco utilizzano oggetti di blocco, mittente e destinatario, simili agli oggetti conto transazione e token che memorizzano i dati sia nel libro contabile pubblico che nella raccolta dati privata. Le operazioni di blocco possono essere utilizzate anche per i trasferimenti nella stessa organizzazione, nel qual caso gli oggetti mittente e destinatario non vengono creati e il trasferimento avviene come normale operazione Token Taxonomy Framework utilizzando gli impegni di Pedersen. La tabella riportata di seguito mostra dove vengono memorizzati i valori delle transazioni per qualsiasi ID transazione blocco specificato.

In modalità riservata, i trasferimenti tra organizzazioni coinvolgono due raccolte di dati private. Anziché modificare la coppia chiave/valore conto, per gli addebiti viene creato un oggetto mittente durante l'operazione di blocco e per gli accrediti viene creato un oggetto ricevente (quando viene eseguita l'API executeHoldReceiver). Il saldo viene inserito nell'oggetto mittente. L'importo accreditato viene inserito nell'oggetto ricevente, che viene assegnato al destinatario. Al termine dell'operazione di addebito, l'oggetto mittente non è più in uso e può essere eliminato. Allo stesso modo, dopo che il saldo passa dall'oggetto ricevente al conto del destinatario, l'oggetto ricevente può essere eliminato.

Libro contabile pubblico (database di stato)	Raccolta dati privati
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 (cifrato) time_to_expiration sender_id category description	quantity blinding_factor assetType holding_id

La tabella riportata di seguito mostra le informazioni per l'oggetto mittente creato per i trasferimenti e i blocchi tra organizzazioni.

Libro contabile pubblico (database di stato)	Raccolta dati privati
assetType sender_id operation_id account_id transaction_id quantity (cifrato) version	assetType sender_id blindingFactor

La tabella riportata di seguito mostra le informazioni per l'oggetto ricevente creato per i trasferimenti e i blocchi tra organizzazioni.

Libro contabile pubblico (database di stato)	Raccolta dati privati
assetType receiver_id operation_id account_id transaction_id quantity (cifrato) version	assetType receiver_id blindingFactor

1. Nel caso dei pagamenti riservati, il metodo holdTokens utilizza i parametri token_id e facoltativi come input e richiede anche un fattore di accecamento, che viene inviato dal proxy REST insieme ai valori userId e orgId per il ricevente e alla quantità di token passata nella mappa transitoria.
2. L'operazione di blocco deve essere approvata o rifiutata da un utente notaio.
   • Se l'utente notaio approva l'operazione di blocco, la quantità viene addebitata al mittente e gli oggetti di blocco e viene creato un oggetto transazione. Viene creato anche un oggetto ricevente e la quantità viene accreditata all'oggetto ricevente.
   • Se l'utente notaio rifiuta il blocco, la quantità bloccata viene riaccreditata sul conto del mittente e viene creato un oggetto transazione.
3. Gli impegni saldo, i saldi effettivi e gli oggetti transazione vengono salvati nel libro contabile pubblico e nella raccolta dati privata, che aggiorna di conseguenza tutti i saldi.

Token di combustione

Per masterizzare i token, un utente con il ruolo di burner chiama l'API burnTokens.

1. Nel caso dei pagamenti riservati, il metodo burnTokens utilizza il valore token_id come input e richiede anche un fattore di accecamento, che viene inviato dal proxy REST insieme alla quantità di token passata nella mappa transitoria.
2. Dopo la verifica, l'impegno Pedersen viene generato dal fattore accecante e dalla quantità di gettoni da bruciare.
3. La quantità complessiva viene quindi aggiornata sia nel libro contabile pubblico che nella raccolta di dati privati. Nel registro pubblico, l'impegno di Pedersen che rappresenta il saldo esistente viene ridotto con l'impegno di Pederson che rappresenta la quantità di token bruciati. Il valore effettivo del saldo memorizzato nella raccolta di dati privati viene diminuito di conseguenza.
4. Anche il fattore cieco viene aggiornato, in modo che in qualsiasi momento il saldo e il fattore cieco nella raccolta di dati privati possano essere utilizzati per verificare l'impegno corrispondente memorizzato nel registro pubblico.