Visión general de pagos confidenciales

Oracle Blockchain Platform Digital Assets Edition utiliza los compromisos de Pedersen para mantener los datos seguros.

Pruebas de conocimiento cero

Las pruebas de conocimiento cero (ZKP) son protocolos criptográficos que permiten a un prover honesto demostrar la verdad de una declaración a un verificador sin revelar ninguna información adicional. Un prover deshonesto no puede convencer a un verificador de que una declaración falsa es verdadera. ZKP se asegura de que no se revelen datos confidenciales más allá de la validez de la reclamación. Los ZKP permiten probar propiedades específicas de un valor secreto, como confirmar que se encuentra dentro de un rango o es el resultado de un cálculo específico, sin revelar el valor en sí.

Compromisos de Pedersen

Las pruebas de conocimiento cero dependen de esquemas de compromiso, donde alguien puede comprometerse con un cierto valor mientras lo mantiene oculto a los demás. La edición de activos digitales de Oracle Blockchain Platform utiliza compromisos de Pedersen. Los compromisos de Pedersen utilizan valores aleatorios conocidos como factores cegadores junto con la criptografía de la curva elíptica para garantizar tanto el secreto como la inmutabilidad. Los compromisos de Pedersen son homomórficos; en otras palabras, apoyan la realización de operaciones matemáticas, como la suma y la resta de compromisos, al tiempo que preservan las relaciones entre los valores subyacentes. Los compromisos de Pedersen se utilizan en protocolos de transacciones privadas, computación multiparte segura y sistemas de credenciales anónimas.

Trabajo con pagos confidenciales

Puede utilizar la cabecera Confidential-Transaction en una solicitud de transacción para activar la función de pagos confidenciales.

Cuando envía la cabecera Confidential-Transaction definida en true en una solicitud, el proxy REST de Oracle Blockchain Platform genera un número aleatorio único (el factor de enmascaramiento necesario para un compromiso de Pedersen) y lo transfiere en el mapa transitorio. El código de cadena lo utiliza para procesar la entrada y almacenar la información confidencial en una recopilación de datos privada en lugar de en la base de datos de estado.

Información de Transacción

Todas las operaciones de token (creación de cuentas, acuñación, transferencia, grabación, etc.) generan un registro de transacción para que se pueda realizar un seguimiento del historial de transacciones. Los datos de transacción se almacenan en dos lugares: el libro mayor público (base de datos de estado) y una recopilación de datos privada. Con los pagos confidenciales, los datos confidenciales se almacenan en texto claro solo en las recopilaciones de datos privados de las organizaciones involucradas en la transacción. La siguiente tabla muestra dónde se almacenan los valores de transacción para cualquier ID de transacción determinado.

Libro mayor (base de datos de estado)

Recopilación de datos privados

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

Información de cuenta de token

Del mismo modo, la información sobre las cuentas de token se almacena en el libro mayor público y en una recopilación de datos privada. La siguiente tabla muestra dónde se almacenan los valores de transacción para cualquier ID de cuenta de token determinado.

Libro mayor (base de datos de estado)	Recopilación de datos privados
assetType account_id org_id token_type token_id token_name balance (cifrado) onhold_balance (cifrado) onhold_burn_balance (cifrado) 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

Los siguientes datos se almacenan en el libro mayor público:

• La clave account_id, que es única para cada usuario del sistema. Typicall es el hash SHA-256 de orgId (ID de MSP) y userId (nombre de usuario o correo electrónico) combinados con otros prefijos o sufijos.
• Las contabilidades públicas almacenan todas las claves de cuenta de cualquier usuario. Los usuarios pueden tener varias cuentas de token fungibles, una para cada token.
• Los detalles del token se almacenan en los campos token_type, token_id y token_name.
• Los campos balance y onhold_balance contienen el hash de compromiso de Pedersen que representa el valor de texto real del balance almacenado en la recopilación de datos privada.

Los siguientes datos se almacenan en la recopilación de datos privados:

• La clave account_id, descrita anteriormente.
• Los campos balance y onhold_balance contienen el valor de texto real de esos balances.
• Los campos balance_blinding_factor y on_hold_balance_blinding_factor almacenan la clave aleatoria utilizada para crear los compromisos balance y onhold_balance almacenados en el libro mayor público.
• Los detalles de las transacciones diarias se almacenan en los campos max_daily_amount, daily_amount, max_daily_transactions, daily_transactions y current_date.

Operaciones típicas con pagos confidenciales

El flujo de trabajo al acuñar, transferir, retener o grabar tokens mientras se utilizan pagos confidenciales incluye pasos adicionales para garantizar la integridad de los datos.

Tokens de simulación

Para acuñar tokens, un usuario con el rol minter llama a la API issueTokens.

1. En el caso de los pagos confidenciales, el método issueTokens toma el valor token_id como entrada y también requiere un factor de cegamiento, que se envía desde el proxy REST junto con la cantidad de token transferida en la asignación transitoria.
2. Después de la verificación, el compromiso de Pedersen se genera a partir del factor de cegamiento y la cantidad de tokens a acuñar.
3. La cantidad total se actualiza tanto en el libro mayor público como en la recopilación de datos privados. En el libro mayor público, el compromiso de Pedersen que representa el saldo existente se incrementa con el compromiso de Pederson que representa la cantidad de tokens acuñados (emitidos). El valor real del saldo almacenado en la recopilación de datos privados se incrementa en consecuencia.
4. El factor de cegamiento también se actualiza, de modo que en cualquier momento se puede utilizar el factor de equilibrio y cegamiento en la recopilación de datos privados para verificar el compromiso correspondiente almacenado en el libro mayor público.

Transferencia de tokens dentro de una organización

Para transferir tokens dentro de una organización, el remitente llama a la API transferTokens.

1. En el caso de los pagos confidenciales, el método transferTokens toma los parámetros token_id y opcionales como entrada y también requiere un factor de cegamiento, que se envía desde el proxy REST junto con los valores userId y orgId para el receptor y la cantidad de token transferida en la asignación transitoria.
2. Después de la verificación, el compromiso de Pedersen se genera a partir del factor de cegamiento y la cantidad de tokens que se deben transferir.
3. La cantidad de tokens en la cuenta del remitente disminuye y la cantidad en la cuenta del receptor aumenta, tanto en el libro mayor público como en la recopilación de datos privados. En el libro mayor público, el compromiso de Pedersen que representa el saldo existente del remitente se reduce con el compromiso de Pedersen que representa la cantidad de tokens transferidos. Para el receptor, el saldo se incrementa de la misma manera. Los valores reales del saldo del remitente y el saldo del receptor se actualizan en la recopilación de datos privados.
4. El factor de cegamiento también se actualiza, de modo que en cualquier momento se puede utilizar el factor de equilibrio y cegamiento en la recopilación de datos privados para verificar el compromiso correspondiente almacenado en el libro mayor público.

Transferencia de tokens entre organizaciones

Para transferir tokens entre organizaciones, el remitente llama a la API holdTokens para extraer el importe de transferencia y retenerlo.

1. En el caso de los pagos confidenciales, el método holdTokens toma los valores token_id, operation_id y expiration_time como entrada, y también requiere un factor de cegamiento, que se envía desde el proxy REST junto con los valores notary_user_id, notary_org_id, to_user_id y to_org_id y la cantidad de token transferida en la asignación transitoria.
2. Después de la verificación, el compromiso de Pedersen se genera a partir del factor de cegamiento y la cantidad de tokens que se deben retener.
3. Se crean un objeto de retención y un objeto de remitente.
4. Los compromisos de saldo, los saldos reales y los objetos de transacción se guardan en el libro mayor público y en las recopilaciones de datos privados para ambas organizaciones, lo que actualiza todos los saldos según corresponda.

Tokens de tenencia

Como se mencionó anteriormente, las operaciones de retención se utilizan para transferir tokens entre organizaciones. Las operaciones de retención utilizan objetos de retención, de remitente y de receptor, similares a los objetos de transacción y cuenta de token que almacenan datos en el libro mayor público y en la recopilación de datos privada. Las operaciones de retención también se pueden utilizar para transferencias en la misma organización, en cuyo caso no se crean objetos de remitente y receptor y la transferencia se produce como una operación regular de Token Taxonomy Framework mediante compromisos de Pedersen. La siguiente tabla muestra dónde se almacenan los valores de transacción para cualquier ID de transacción de retención determinado.

En el modo confidencial, las transferencias entre organizaciones implican dos recopilaciones de datos privados. En lugar de modificar el par clave/valor de cuenta, para los débitos se crea un objeto de remitente durante la operación de retención y para los créditos se crea un objeto de receptor (cuando se ejecuta la API executeHoldReceiver). El saldo se coloca en el objeto del remitente. El importe acreditado se coloca en el objeto del receptor, que se asigna al destinatario. Una vez finalizada la operación de débito, el objeto de remitente ya no se utiliza y se puede suprimir. Del mismo modo, después de que el saldo se mueva del objeto de receptor a la cuenta del destinatario, el objeto de receptor se puede suprimir.

Libro mayor (base de datos de estado)	Recopilación de datos privados
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 (cifrado) time_to_expiration sender_id category description	quantity blinding_factor assetType holding_id

En la siguiente tabla se muestra la información del objeto de remitente que se crea para las transferencias y retenciones entre organizaciones.

Libro mayor (base de datos de estado)	Recopilación de datos privados
assetType sender_id operation_id account_id transaction_id quantity (cifrado) version	assetType sender_id blindingFactor

La siguiente tabla muestra la información del objeto de receptor que se crea para transferencias y retenciones entre organizaciones.

Libro mayor (base de datos de estado)	Recopilación de datos privados
assetType receiver_id operation_id account_id transaction_id quantity (cifrado) version	assetType receiver_id blindingFactor

1. En el caso de los pagos confidenciales, el método holdTokens toma los parámetros token_id y opcionales como entrada y también requiere un factor de cegamiento, que se envía desde el proxy REST junto con los valores userId y orgId para el receptor y la cantidad de token transferida en la asignación transitoria.
2. la operación de retención debe ser aprobada o rechazada por un usuario notario.
   • Si el usuario del notario aprueba la operación de retención, la cantidad se debita del remitente y los objetos de retención, y se crea un objeto de transacción. También se crea un objeto receptor y la cantidad se acredita en el objeto receptor.
   • Si el usuario del notario rechaza la retención, la cantidad retenida se acredita en la cuenta del remitente y se crea un objeto de transacción.
3. Los compromisos de saldo, los saldos reales y los objetos de transacción se guardan en el libro mayor público y en la recopilación de datos privados, lo que actualiza todos los saldos según corresponda.

Tokens ardientes

Para grabar tokens, un usuario con el rol de quemador llama a la API burnTokens.

1. En el caso de los pagos confidenciales, el método burnTokens toma el valor token_id como entrada y también requiere un factor de cegamiento, que se envía desde el proxy REST junto con la cantidad de token transferida en la asignación transitoria.
2. Después de la verificación, el compromiso de Pedersen se genera a partir del factor de cegamiento y la cantidad de tokens que se queman.
3. La cantidad total se actualiza tanto en el libro mayor público como en la recopilación de datos privados. En el libro mayor público, el compromiso de Pedersen que representa el saldo existente se reduce con el compromiso de Pederson que representa la cantidad de tokens quemados. El valor real del saldo almacenado en la recopilación de datos privados se reduce en consecuencia.
4. El factor de cegamiento también se actualiza, de modo que en cualquier momento se puede utilizar el factor de equilibrio y cegamiento en la recopilación de datos privados para verificar el compromiso correspondiente almacenado en el libro mayor público.