ES2880458T3 - Protección de datos de cadena de bloques basada en un modelo de cuenta genérico y un cifrado homomórfico - Google Patents

Abstract

Un procedimiento implementado por ordenador realizado por un nodo de consenso para validar una transacción (400) entre un primer nodo y un segundo nodo dentro de una red de cadena de bloques (102), estando caracterizando el procedimiento por: recibir datos de transacción (408) asociados a la transacción (400), donde los datos de transacción comprenden: datos representativos de una pluralidad de activos, un primer compromiso que oculta un primer número aleatorio y un importe de transacción de la transacción, un segundo compromiso que oculta un segundo número aleatorio y un cambio calculado en base a deducir el importe de transacción de un valor total de la pluralidad de activos, el importe de transacción y un tercer número aleatorio ambos cifrados por una clave pública del segundo nodo en base a un esquema de cifrado homomórfico - HE - determinista lineal, el cambio y un cuarto número aleatorio ambos cifrados por una clave pública del primer nodo en base al esquema de HE determinista lineal, una o más pruebas de intervalo, una prueba de conocimiento nulo - ZKP - y una firma digital generada en base a una clave privada correspondiente a la clave pública del primer nodo; verificar (322) la firma digital en base a la clave pública del primer nodo; determinar (328) que la una o más pruebas de intervalo demuestran que el importe de transacción y el cambio son cada uno mayores que, o iguales a, cero; determinar (326) que el valor total de la pluralidad de activos es igual a una suma del importe de transacción y del cambio; y determinar (330), en base a la ZKP, que la transacción (400) es válida al determinar que el primer número aleatorio es igual al tercer número aleatorio, que el segundo número aleatorio es igual al cuarto número aleatorio y que el importe de transacción oculto en el primer compromiso es igual al importe de transacción cifrado por la clave pública del segundo nodo.

Description

DESCRIPCIÓN

Protección de datos de cadena de bloques basada en un modelo de cuenta genérico y un cifrado homomórfico

ANTECEDENTES

Las redes de cadena de bloques, que también pueden denominarse sistemas de cadena de bloques, redes de consenso, redes de sistema de libro mayor distribuido o cadena de bloques, permiten a las entidades participantes almacenar datos de forma segura e inmutable. Una cadena de bloques puede describirse como un libro mayor de transacciones, y múltiples copias de la cadena de bloques se almacenan en la red de cadena de bloques. Tipos de ejemplo de cadenas de bloques pueden incluir cadenas de bloques públicas, cadenas de bloques de consorcio y cadenas de bloques privadas. Una cadena de bloques pública está abierta para que todas las entidades utilicen la cadena de bloques y participen en el proceso de consenso. Una cadena de bloques de consorcio es una cadena de bloques en la que el proceso de consenso está controlado por un conjunto de nodos preseleccionados, tal como ciertas organizaciones o instituciones. Una cadena de bloques privada se proporciona a una entidad en particular, que controla de manera centralizada los permisos de lectura y escritura.

Las cadenas de bloques pueden utilizar diferentes modelos de mantenimiento de registros para registrar transacciones entre usuarios. Ejemplos de modelos de mantenimiento de registros incluyen el modelo de salida de transacción no gastada (UTXO) y el modelo de saldo de cuenta. En el modelo UTXO, cada una de las transacciones gasta la salida de transacciones anteriores y genera nuevas salidas que se pueden gastar en transacciones posteriores. Se registran las transacciones no gastadas de un usuario, y el saldo disponible para gastarse se calcula como la suma de todas las transacciones no gastadas. En el modelo de saldo de cuenta, el saldo de cuenta de cada uno de los usuarios se registra como un estado global. Para cada transacción, se comprueba el saldo de una cuenta de gastos para garantizar que sea mayor que, o igual a, el importe de la transacción. Esto es comparable a la banca tradicional.

Una cadena de bloques incluye una serie de bloques, cada uno de los cuales contiene una o más transacciones ejecutadas en la red. Cada uno de los bloques puede ser análogo a una página del libro mayor, mientras que la cadena de bloques en sí es una copia completa del libro mayor. Las transacciones individuales se confirman y se añaden a un bloque, que se añade a la cadena de bloques. Las copias de la cadena de bloques se repiten en los nodos de la red. De esta manera, existe un consenso global sobre el estado de la cadena de bloques. Además, la cadena de bloques está abierta para que todos los nodos la vean, al menos en el caso de las redes públicas. Para proteger la privacidad de los usuarios de cadenas de bloques, se implementan tecnologías de cifrado.

Según el modelo de saldo de cuenta, pueden utilizarse esquemas de compromiso para ocultar valores con los que ambas partes de una transacción se comprometen. Los esquemas de compromiso pueden surgir de la necesidad de que las partes se comprometan con una elección o valor y, a continuación, comuniquen ese valor a las otras partes involucradas. Por ejemplo, en un esquema de compromiso de Pedersen (PC) interactivo, un primer usuario puede comprometerse con un importe de transacción t enviando un valor de compromiso PC(t, r) que se genera en base a un valor aleatorio r. Se genera el valor de compromiso, y un segundo usuario solo puede revelar el importe de transacción t mediante la obtención del número aleatorio r. Para garantizar que el importe de transacción sea válido, se puede crear una prueba de intervalo para probar que el importe de transacción es mayor que o igual a cero y menor que o igual al importe de cuenta.

En algunos casos, se pueden realizar múltiples transacciones desde un usuario. Debido a que la prueba de intervalo está asociada al saldo restante de la cuenta, las múltiples transacciones deben verificarse secuencialmente en la cadena de bloques. De este modo, las pruebas de intervalo correspondientes se pueden asociar correctamente a los saldos restantes de la cuenta después de cada una de las transacciones. Sin embargo, verificar múltiples transacciones secuencialmente puede llevar mucho tiempo. Un modelo de mantenimiento de registros que permita verificaciones paralelas de transacciones sería ventajoso, especialmente para tareas que requieren mucho tiempo. El documento CN 108764874 describe procedimientos de reembolso anónimos basados en cadena de bloques.

RESUMEN

La invención se define en las reivindicaciones adjuntas. Las implementaciones de la memoria descriptiva incluyen procedimientos implementados por ordenador para verificaciones de preservación de privacidad no interactivas de transacciones de cadena de bloques. Más en particular, las implementaciones de la memoria descriptiva se refieren a un procedimiento implementado por ordenador capaz de validar múltiples transacciones asociadas a una cuenta de un nodo de cadena de bloques en paralelo, en base a esquemas de compromiso y cifrado homomórfico sin revelar información de privacidad, tal como importes de transacciones, saldos de cuentas o números aleatorios para generar compromisos con otros nodos de cadena de bloques.

En algunas implementaciones, las acciones incluyen recibir datos de transacción asociados a la transacción, donde los datos de transacción comprenden: datos representativos de una pluralidad de activos, un primer compromiso que oculta un primer número aleatorio y un importe de transacción de la transacción, un segundo compromiso que oculta un segundo número aleatorio y un cambio calculado en base a deducir el importe de transacción de un valor total de la pluralidad de activos, el importe de transacción y un tercer número aleatorio, ambos cifrados por una clave pública del segundo nodo en base a un esquema de cifrado (HE) determinista lineal, el cambio y un cuarto número aleatorio, ambos cifrados por una clave pública del primer nodo en base al esquema de HE determinista lineal, una o más pruebas de intervalo, una prueba de conocimiento nulo (ZKP), y una firma digital generada en base a una clave privada correspondiente a la clave pública del primer nodo; verificar la firma digital en base a la clave pública del primer nodo; determinar que la una o más pruebas de intervalo demuestran que el importe de transacción y el cambio son cada uno mayores que, o iguales a, cero; determinar que el valor total de la pluralidad de activos es igual a una suma del importe de transacción y del cambio; y determinar, en base a la ZKP, que la transacción es válida al determinar que el primer número aleatorio es igual al tercer número aleatorio, el segundo número aleatorio es igual al cuarto número aleatorio y el importe de transacción oculto en el primer compromiso es igual al importe de transacción cifrado por la clave pública del segundo nodo. Otras implementaciones incluyen sistemas, aparatos y programas informáticos correspondientes, configurados para realizar las acciones de los procedimientos, codificados en dispositivos de almacenamiento informático.

Estas y otras implementaciones pueden incluir, opcionalmente, una o más de las siguientes características: la transacción se realiza entre una cuenta asociada al primer nodo y una cuenta asociada al segundo nodo, y el procedimiento comprende además actualizar, después de determinar que la transacción es válida, la cuenta del primer nodo y la cuenta del segundo nodo en base al importe de transacción y el cambio; cada uno de la pluralidad de activos está asociado a uno o más de un tipo de activo, un valor de activo oculto en un compromiso y un número aleatorio utilizado para generar el compromiso; determinar que cada uno de la pluralidad de activos está asociado a un mismo tipo de activo; el primer compromiso, el segundo compromiso y el compromiso que oculta el valor de activo se generan en base a un esquema de compromiso que es homomórfico, y donde la determinación de que el valor total de la pluralidad de activos es igual a la suma del importe de transacción y del cambio se realiza en base al homomorfismo del esquema de compromiso; el esquema de HE determinista lineal deriva de un esquema de HE probabilístico basado en cambiar un número aleatorio asociado al esquema de HE probabilístico en un número fijo; la ZKP comprende un compromiso que oculta un quinto número aleatorio y un sexto número aleatorio, un texto cifrado del quinto número aleatorio y el sexto número aleatorio cifrados por la clave pública de la segunda cuenta en base al esquema de HE determinista lineal, y un texto cifrado del quinto número aleatorio y el sexto número aleatorio cifrados por la clave pública de la primera cuenta en base al esquema de HE determinista lineal; la ZKP se genera y utiliza para determinar que la transacción es válida en base a propiedades del HE determinista lineal; la determinación de que la transacción es válida se realiza en base a la ZKP sin interacciones entre el primer nodo y el segundo nodo a través del exterior de la red de cadena de bloques.

La memoria descriptiva también proporciona uno o más medios de almacenamiento legibles por ordenador no transitorios acoplados a uno o más procesadores y que tienen instrucciones almacenadas en los mismos que, cuando se ejecutan por el uno o más procesadores, hacen que el uno o más procesadores realicen operaciones de acuerdo con implementaciones de los procedimientos proporcionados en el presente documento.

La memoria descriptiva proporciona además un sistema para implementar los procedimientos proporcionados en el presente documento. El sistema incluye uno o más procesadores y un medio de almacenamiento legible por ordenador acoplado al uno o más procesadores que tienen instrucciones almacenadas en los mismos que, cuando se ejecutan por el uno o más procesadores, hacen que el uno o más procesadores realicen operaciones de acuerdo con implementaciones de los procedimientos proporcionados en el presente documento.

Las implementaciones de la materia objeto descrita en esta memoria descriptiva pueden implementarse para lograr ventajas o efectos técnicos particulares. Por ejemplo, las implementaciones de la memoria descriptiva permiten que el saldo de cuenta y el importe de transacción de nodos de cadena de bloques sean privados durante las transacciones. El destinatario de una transferencia de fondos no necesita confirmar la transacción o utilizar un número aleatorio para verificar un compromiso; la validación de transacción puede ser no interactiva. Un nodo de cadena de bloques puede validar la transacción en base a HE y esquemas de compromiso para permitir una prueba de conocimiento nulo.

La metodología descrita permite mejorar la seguridad de cuenta/datos de diversos dispositivos informáticos móviles. El saldo de las cuentas y los importes de transacción pueden cifrarse en base a HE y ocultarse mediante esquemas de compromiso. Por lo tanto, un nodo de consenso puede actualizar los saldos de cuenta en el libro mayor después de la transacción en base a las propiedades de HE sin revelar el saldo de cuenta real de la cuenta. Debido a que no es necesario enviar el número aleatorio a un destinatario para confirmar la transacción, se puede reducir el riesgo de fuga de datos y se necesitan menos recursos de cálculo y de memoria para gestionar el número aleatorio.

Se aprecia que los procedimientos de acuerdo con la memoria descriptiva pueden incluir cualquier combinación de los aspectos y características descritos en el presente documento. Es decir, los procedimientos de acuerdo con la memoria descriptiva no se limitan a las combinaciones de aspectos y características específicamente descritos en el presente documento, sino que también incluyen cualquier combinación de los aspectos y características proporcionados.

Los detalles de una o más implementaciones de la memoria descriptiva se establecen en los dibujos adjuntos y en la siguiente descripción. Otras características y ventajas de la memoria descriptiva serán evidentes a partir de la descripción y los dibujos, y de las reivindicaciones.

DESCRIPCIÓN DE LOS DIBUJOS

La FIG. 1 representa un ejemplo de un entorno que puede ser utilizado para ejecutar implementaciones de la memoria descriptiva.

La FIG. 2 representa un ejemplo de una arquitectura conceptual de acuerdo con implementaciones de la memoria descriptiva.

La FIG. 3 representa un ejemplo de un proceso de validación con privacidad protegida de una transacción de cadena de bloques en base a cifrado homomórfico.

La FIG. 4 representa un ejemplo de una transacción de cadena de bloques de acuerdo con las implementaciones de la memoria descriptiva.

La FIG. 5 representa otro ejemplo de un proceso de validación con privacidad protegida de una transacción de cadena de bloques en base a cifrado homomórfico.

La FIG. 6 representa un ejemplo de un procedimiento que puede ser ejecutado de acuerdo con implementaciones de la memoria descriptiva.

La FIG. 7 representa otro ejemplo de un procedimiento que puede ser ejecutado de acuerdo con implementaciones de la memoria descriptiva.

La FIG. 8 representa un ejemplo de un nodo de cadena de bloques que puede llevar a cabo un proceso de acuerdo con implementaciones de la memoria descriptiva.

Los símbolos de referencia similares en los distintos dibujos indican elementos similares.

DESCRIPCIÓN DETALLADA

Las implementaciones de la memoria descriptiva incluyen procedimientos implementados por ordenador para verificaciones de preservación de privacidad no interactivas de transacciones de cadena de bloques. Más en particular, las implementaciones de la memoria descriptiva se refieren a un procedimiento implementado por ordenador capaz de validar múltiples transacciones asociadas a una cuenta de un nodo de cadena de bloques en paralelo, en base a esquemas de compromiso y cifrado homomórfico sin revelar información de privacidad, tal como importes de transacciones, saldos de cuentas o números aleatorios para generar compromisos con otros nodos de cadena de bloques. En algunas implementaciones, las acciones incluyen recibir datos de transacción asociados a la transacción, donde los datos de transacción comprenden: datos representativos de una pluralidad de activos, un primer compromiso que oculta un primer número aleatorio y un importe de transacción de la transacción, un segundo compromiso que oculta un segundo número aleatorio y un cambio calculado en base a deducir el importe de transacción de un valor total de la pluralidad de activos, el importe de transacción y un tercer número aleatorio, ambos cifrados por una clave pública del segundo nodo en base a un esquema de cifrado homomórfico (HE) determinista lineal, el cambio y un cuarto número aleatorio, ambos cifrados por una clave pública del primer nodo en base al esquema de HE determinista lineal, una o más pruebas de intervalo, una prueba de conocimiento nulo (ZKP), y una firma digital generada en base a una clave privada correspondiente a la clave pública del primer nodo; verificar la firma digital en base a la clave pública del primer nodo; determinar que la una o más pruebas de intervalo demuestran que el importe de transacción y el cambio son cada uno mayores que, o iguales a, cero; determinar que el valor total de la pluralidad de activos es igual a una suma del importe de transacción y del cambio; y determinar, en base a la ZKP, que la transacción es válida al determinar que el primer número aleatorio es igual al tercer número aleatorio, el segundo número aleatorio es igual al cuarto número aleatorio y el importe de transacción oculto en el primer compromiso es igual al importe de transacción cifrado por la clave pública del segundo nodo. Otras implementaciones incluyen sistemas, aparatos y programas informáticos correspondientes, configurados para realizar las acciones de los procedimientos, codificados en dispositivos de almacenamiento informático.

Para proporcionar un contexto adicional para las implementaciones de la memoria descriptiva, y como se ha introducido anteriormente, los sistemas de libro mayor distribuido (DLS), que también pueden denominarse redes de consenso (por ejemplo, formadas por nodos de igual a igual), y redes de cadena de bloques, permiten a las entidades participantes realizar transacciones de forma segura e inmutable y almacenar datos. La cadena de bloques se utiliza en el presente documento para hacer referencia, en general, a un DLS sin hacer referencia a ningún caso de uso particular.

Una cadena de bloques es una estructura de datos que almacena transacciones de manera que las transacciones son inmutables y pueden verificarse posteriormente. Una cadena de bloques incluye uno o más bloques. Cada uno de los bloques de la cadena está vinculado a un bloque anterior inmediatamente antes de él en la cadena al incluir un valor hash criptográfico del bloque anterior. Cada uno de los bloques también incluye una marca de tiempo, su propio valor hash criptográfico y una o más transacciones. Las transacciones, que ya han sido verificadas por los nodos de la red de cadena de bloques, se someten a una función hash y se codifican en un árbol Merkle. Un árbol Merkle es una estructura de datos en la que los datos en los nodos hoja del árbol se han sometido a una función hash, y todos los valores hash en cada una de las ramas del árbol se concatenan en la raíz de la rama. Este proceso continúa subiendo por el árbol hasta la raíz de todo el árbol, que almacena un valor hash que es representativo de todos los datos del árbol. Un valor hash que pretende ser de una transacción almacenada en el árbol se puede verificar rápidamente determinando si es coherente con la estructura del árbol.

Mientras que una cadena de bloques es una estructura de datos para almacenar transacciones, una red de cadena de bloques es una red de nodos de cálculo que gestionan, actualizan y mantienen una o más cadenas de bloques. Como se presentó anteriormente, una red de cadena de bloques se puede proporcionar como una red de cadena de bloques pública, una red de cadena de bloques privada o una red de cadena de bloques de consorcio.

En una cadena de bloques pública, el proceso de consenso está controlado por nodos de la red de consenso. Por ejemplo, cientos, miles, incluso millones de entidades pueden participar en una cadena de bloques pública, cada una de las cuales opera al menos un nodo en la cadena de bloques pública. En consecuencia, la cadena de bloques pública puede considerarse una red pública con respecto a las entidades participantes. En algunos ejemplos, la mayoría de las entidades (nodos) deben firmar cada uno de los bloques para que el bloque sea válido y se añada a la cadena de bloques. Las redes de cadena de bloques públicas de ejemplo incluyen redes de pago de igual a igual particulares que utilizan un libro mayor distribuido, denominado cadena de bloques. Como se señaló anteriormente, el término cadena de bloques, sin embargo, se utiliza para hacer referencia, en general, a libros mayores distribuidos sin una referencia particular a una red de cadena de bloques particular.

En general, una cadena de bloques pública admite transacciones públicas. Una transacción pública se comparte con todos los nodos de la cadena de bloques y la cadena de bloques se repite en todos los nodos. Es decir, todos los nodos están en perfecto estado de consenso con respecto a la cadena de bloques. Para lograr un consenso (p. ej., un acuerdo para la adición de un bloque a una cadena de bloques), se implementa un protocolo de consenso en la red de cadena de bloques. Ejemplos de protocolos de consenso incluyen, sin limitación, prueba de trabajo (POW), prueba de participación (POS) y prueba de autoridad (POA). En el presente documento se hace referencia a POW como un ejemplo no limitativo.

Las implementaciones de la memoria descriptiva incluyen procedimientos implementados por ordenador para verificaciones de preservación de privacidad no interactivas de transacciones de cadena de bloques. Más en particular, las implementaciones de la memoria descriptiva se refieren a un procedimiento implementado por ordenador capaz de validar múltiples transacciones asociadas a una cuenta de un nodo de cadena de bloques en paralelo, en base a esquemas de compromiso y cifrado homomórfico sin revelar información de privacidad, tal como importes de transacciones, saldos de cuentas o números aleatorios para generar compromisos con otros nodos de cadena de bloques.

De acuerdo con las implementaciones de la memoria descriptiva, los nodos de cadena de bloques pueden utilizar un modelo de cuenta genérico que puede admitir verificaciones de transacciones en paralelo como un procedimiento de mantenimiento de registros. En comparación con el modelo de saldo de cuenta, los nodos de cadena de bloques que adoptan el modelo de cuenta genérico pueden mantener registros de una pluralidad de activos en lugar de saldos de cuenta. Cada uno de la pluralidad de activos puede asociarse a al menos uno de entre un tipo de activo, un ID de activo o un valor de activo. El activo bajo el modelo de cuenta genérico puede estar en cualquier forma o tipo, tal como monetario o fijo. Los activos monetarios pueden incluir moneda real o criptomoneda. En algunas implementaciones, los activos fijos pueden convertirse en activos monetarios asociados a una cantidad monetaria. La cantidad monetaria puede utilizarse entonces para realizar transacciones entre cuentas de una red de cadena de bloques. A efectos ilustrativos, se supone que los activos descritos en las implementaciones de la memoria descriptiva se convierten en el mismo tipo de moneda y se guardan en las cuentas de cadena de bloques bajo el modelo de cuenta genérico.

Para proteger la privacidad de datos, las transacciones se pueden registrar en una cadena de bloques (libro mayor) en base al compromiso sin revelar el importe de transacción o la información de cantidad monetaria asociada a las cuentas de usuario de cadena de bloques. Un esquema de compromiso puede utilizarse para generar un compromiso de un importe de transacción utilizando un número aleatorio. Un esquema de compromiso de ejemplo incluye, sin limitación, el esquema de PC. Debido a que el importe de transacción está oculto en el compromiso, se pueden utilizar una o más pruebas de intervalo para demostrar que el importe de transacción no excede el valor de la cuenta de usuario de cadena de bloques.

Bajo el modelo de saldo de cuenta, las pruebas de intervalo están asociadas al saldo de cuenta. Si se realiza más de una transacción, pero no todas las transacciones se validan y registran en la cadena de bloques, las pruebas de intervalo pueden estar asociadas a saldos de cuenta incorrectos y, por lo tanto, pueden no ser válidas. En comparación, bajo el modelo de cuenta genérico, el valor de cuenta puede calcularse como la suma de una pluralidad de activos. Cuando un importe de transacción se va a transferir entre cuentas de usuario de cadena de bloques, al menos una parte de la pluralidad de activos con valor combinado mayor que, o igual a, el importe de transacción puede utilizarse para cubrir el importe de transacción. Se pueden realizar transferencias adicionales con la condición de que los activos restantes tengan un valor combinado mayor que el importe a transferir. Incluso si las transacciones no se validan ni registran en la cadena de bloques, las pruebas de intervalo que muestran que el valor combinado de los activos restantes es mayor que, o igual a, el importe de transacción puede seguir siendo válidas. Por lo tanto, se puede realizar más de una verificación de transacción en paralelo bajo el modelo de cuenta genérico.

De acuerdo con las implementaciones de la memoria descriptiva, las transacciones de cadena de bloques pueden validarse y registrarse en una cadena de bloques (libro mayor) en base al compromiso sin revelar el saldo de cuenta de transacción, el importe de transacción o el número aleatorio utilizado para generar el compromiso. Un esquema de compromiso, tal como el esquema de PC, puede utilizarse para generar un compromiso de un importe de transacción en base a un número aleatorio. El importe de transacción y el número aleatorio pueden cifrarse utilizando HE probabilístico o determinista lineal. El importe de transacción y el número aleatorio también pueden utilizarse para generar un conjunto de valores como ZKP para validar la transacción en base a las propiedades del esquema de HE utilizado. El compromiso del importe de transacción, el importe de transacción cifrado, el número aleatorio y la ZKP pueden ser utilizados por un nodo de cadena de bloques para verificar si la transacción es válida sin que se revelen los saldos de cuenta, el importe de transacción o el número aleatorio.

La FIG. 1 representa un ejemplo de un entorno 100 que puede ser utilizado para ejecutar implementaciones de la memoria descriptiva. En algunos ejemplos, el entorno 100 de ejemplo permite a las entidades participar en una cadena de bloques pública 102. El entorno 100 de ejemplo incluye sistemas informáticos 106, 108 y una red 110. En algunos ejemplos, la red 110 incluye una red de área local (LAN), una red de área amplia (WAN), e Internet, o una combinación de las mismas, y conecta sitios web, dispositivos de usuario (p. ej., dispositivos informáticos) y sistemas de procesamiento. En algunos ejemplos, se puede acceder a la red 110 a través de un enlace de comunicaciones cableado y/o inalámbrico.

En el ejemplo representado, los sistemas informáticos 106, 108 pueden incluir cada uno cualquier sistema informático apropiado que permita la participación como nodo en la cadena de bloques pública 102. Dispositivos informáticos de ejemplo incluyen, sin limitación, un servidor, un ordenador de sobremesa, un ordenador portátil, una tableta electrónica y un teléfono inteligente. En algunos ejemplos, los sistemas informáticos 106, 108 alojan uno o más servicios implementados por ordenador para interactuar con la cadena de bloques pública 102. Por ejemplo, el sistema informático 106 puede alojar servicios implementados por ordenador de una primera entidad (p. ej., el usuario A), tal como un sistema de gestión de transacciones que la primera entidad utiliza para gestionar sus transacciones con otra u otras entidades (p. ej., otros usuarios). El sistema informático 108 puede alojar servicios implementados por ordenador de una segunda entidad (p. ej., el usuario B), tal como un sistema de gestión de transacciones que la segunda entidad utiliza para gestionar sus transacciones con otra u otras entidades (p. ej., otros usuarios). En el ejemplo de la FIG. 1, la cadena de bloques pública 102 se representa como una red de nodos de igual a igual, y los sistemas informáticos 106, 108 proporcionan nodos de la primera entidad, y de la segunda entidad respectivamente, que participan en la cadena de bloques pública 102.

La FIG. 2 representa un ejemplo de una arquitectura conceptual 200 de acuerdo con implementaciones de la memoria descriptiva. La arquitectura conceptual 200 de ejemplo incluye una capa de entidad 202, una capa de servicios alojados 204 y una capa de cadena de bloques pública 206. En el ejemplo representado, la capa de entidad 202 incluye tres entidades, Entidad_1 (E1), Entidad_2 (E2) y Entidad_3 (E3), teniendo cada una de las entidades un respectivo sistema de gestión de transacciones 208.

En el ejemplo representado, la capa de servicios alojados 204 incluye interfaces de cadena de bloques 210 para cada uno de los sistemas de gestión de transacciones 208. En algunos ejemplos, un sistema de gestión de transacciones respectivo 208 se comunica con una interfaz de cadena de bloques respectiva 210 a través de una red (por ejemplo, la red 110 de la FIG. 1) utilizando un protocolo de comunicación (por ejemplo, protocolo de transferencia de hipertexto seguro (HTTPS)). En algunos ejemplos, cada interfaz de cadena de bloques 210 proporciona una conexión de comunicación entre un sistema de gestión de transacciones respectivo 208 y la capa de cadena de bloques 206. Más particularmente, cada una de las interfaces de cadena de bloques 210 permite a la respectiva entidad realizar transacciones registradas en una red de cadena de bloques 212 de la capa de cadena de bloques 206. En algunos ejemplos, la comunicación entre una interfaz de cadena de bloques 210 y la capa de cadena de bloques 206 se realiza utilizando llamadas a procedimientos remotos (RPC). En algunos ejemplos, las interfaces de cadena de bloques 210 "alojan" nodos de cadena de bloques para los respectivos sistemas de gestión de transacciones 208. Por ejemplo, las interfaces de cadena de bloques 210 proporcionan la interfaz de programación de aplicaciones (API) para acceder a la red de cadena de bloques 212.

Como se describe en el presente documento, la red de cadena de bloques 212 se proporciona como una red de igual a igual que incluye una pluralidad de nodos 214 que registran de forma inmutable información en una cadena de bloques 216. Aunque se representa esquemáticamente una única cadena de bloques 216, se proporcionan múltiples copias de la cadena de bloques 216, que se mantienen en la red de cadena de bloques 212. Por ejemplo, cada uno de los nodos 214 almacena una copia de la cadena de bloques 216. En algunas implementaciones, la cadena de bloques 216 almacena información asociada a transacciones que se realizan entre dos o más entidades que participan en la cadena de bloques pública.

La FIG. 3 representa un ejemplo de un proceso 300 de validación con privacidad protegida de una transacción de cadena de bloques en base a HE. En un nivel alto, el proceso 300 se lleva a cabo por un nodo de usuario A 302, un nodo de usuario B (no mostrado en la FIG. 3) y un nodo de cadena de bloques 304, también denominado nodo de consenso. Tanto la cuenta del nodo de usuario A 302 como la cuenta del nodo de usuario B pueden tener un modelo de mantenimiento de registros basado en un modelo de cuenta genérico. Es decir, los registros de cuentas del nodo de usuario A 302 y del nodo de usuario B se mantienen como una pluralidad de activos. Una transacción, tal como una transferencia de valor, se puede realizar desde el nodo de usuario A 302 al nodo de usuario B. El nodo de usuario

A 302 puede seleccionar uno o más activos de cuenta que tengan un valor total mayor que o igual al importe de transacción para cubrir la transacción. La diferencia entre un valor total del uno o más activos y el importe de transacción puede considerarse como el cambio de la transacción que queda en el nodo de usuario A 302.

Para proteger la privacidad de las cuentas, el nodo de usuario A 302 puede generar compromisos de valores de los activos utilizados para cubrir la transacción. El nodo de usuario A 302 también puede generar un compromiso del importe de transacción de la transacción. El nodo de usuario A 302 también puede usar HE para cifrar el importe de transacción, el cambio y los números aleatorios utilizados para generar los compromisos. Para verificar la validez de la transacción, el nodo de cadena de bloques 304 puede comparar el importe de transacción, el cambio y los números aleatorios ocultos en los compromisos y cifrados mediante HE en base a una ZKP. Si el importe de transacción, el cambio y los números aleatorios coinciden, se determina que la transacción es válida por el nodo de cadena de bloques

304. Más detalles del proceso 300 de ejemplo se analizan en la siguiente descripción de la FIG. 3.

En 306, el nodo de usuario A 302 selecciona una pluralidad de activos para transferir un importe de transacción al nodo de usuario B. El nodo de usuario A 302 y el nodo de usuario B pueden ser nodos de consenso de cadena de bloques o nodos de usuario que utilizan la red de cadena de bloques sin participar en el proceso de consenso. Tal como se analizó anteriormente, el nodo de usuario A 302 puede usar un modelo de cuenta genérico para mantener registros. En lugar de mantener el saldo de cuenta para su registro bajo el modelo de saldo de cuenta, el valor de cuenta del nodo de usuario A 302 se mide por el valor total de los activos que posee. El nodo de usuario A 302 puede seleccionar una pluralidad de activos que tienen valor suficiente para cubrir el importe de transacción. Por ejemplo, si el importe de transacción es de 7,5 dólares estadounidenses, el nodo de usuario A 302 puede seleccionar tres activos que valen 5, 2 y 1 dólares estadounidenses, respectivamente, para cubrir el importe de transacción.

En algunas implementaciones, cada activo puede asociarse a una dirección de transacción o ID de activo que identifica el activo correspondiente. El ID de activo puede ser el valor hash de la información de activo. Los ID de activo de k activos seleccionados pueden representarse como ID¹, ..., ID^k .

En 308, el nodo de usuario A 302 calcula un cambio en base a un valor total de la pluralidad de activos y el importe de transacción. Debido a que los activos se seleccionan para tener un valor total mayor que el importe de transacción, el cambio se puede calcular como el valor total de los activos seleccionados deducido por el importe de transacción.

Usando t para representar el importe de transacción y t⁰ para representar el cambio, el cálculo del cambio puede expresarse como t^ü = a¹ + ... a^k - t, donde a¹, ..., a^k son, respectivamente, seleccionados por el nodo de usuario A 302 para cubrir el importe de transacción t.

En 310, el nodo de usuario A 302 genera un número aleatorio correspondiente al importe de transacción y un número aleatorio correspondiente al cambio. El número aleatorio correspondiente al importe de transacción t puede denotarse como r. El número aleatorio correspondiente al cambio t⁰ puede denotarse como r⁰. En algunas implementaciones, se puede generar una pluralidad de números aleatorios para producir compromisos de los valores de activo. Por ejemplo, supóngase que a¹, ..., a^k son los valores de activo, los números aleatorios que corresponden a los valores de activo se pueden expresar como r^a1, ... , r^ak.

En algunas implementaciones, el número aleatorio r⁰ puede calcularse en lugar de generarse aleatoriamente. El cálculo se puede expresar como r⁰ = r^a1 +... r^ak - r, donde r es el número aleatorio generado para producir compromiso para el importe de transacción t. Mediante el uso del número aleatorio calculado r⁰ , el nodo de usuario A 302 no necesita generar una ZKP adicional para demostrar que el valor total de los activos transferidos es igual al valor total de los activos recibidos. En algunas implementaciones, otro número aleatorio r' puede calcularse como r' = r¹+ ... r^k

- r - r⁰ , para ayudar a la ZKP.

En 312, el nodo de usuario A 302 genera compromisos del importe de transacción y el cambio, y cifra los números aleatorios correspondientes en base a un HE probabilístico. En algunas implementaciones, se pueden utilizar esquemas de compromiso homomórficos, tal como PC, para generar los compromisos. Utilizando el PC como ejemplo no limitativo, el PC del importe de transacción t puede generarse utilizando el número aleatorio r, que puede expresarse como PC(r, t) = g ^rh^t, donde g y h pueden ser generadores de una curva elíptica, y PC(r, t) es una multiplicación escalar de puntos de curva. De manera similar, el PC del cambio t⁰ puede expresarse como PC(r⁰ , t⁰) = g ^r0h^t0.

El número aleatorio r puede cifrarse utilizando la clave pública del nodo de usuario B en base a un esquema de HE probabilístico, tal como un esquema de cifrado de Okamoto-Uchiyama (OU). Debe entenderse que otros esquemas de HE, tales como Boneh-Goh-Nissim, también pueden utilizarse. Utilizando OU como ejemplo no limitativo, el número aleatorio puede cifrarse en base a OU al tratar el importe de transacción t como un número aleatorio, que puede expresarse como OU^B(r, t) = u^rv^t , o simplemente OU^B(t), donde u es un generador de (Z/nZ)* que cumple las condiciones v = un mod n y n = p x q, donde p y q son dos números primos. Un OU probabilístico puede satisfacer la propiedad de que OU(a b) = OU(a) x OU(b), donde a y b son el texto plano utilizado para OU.

El número aleatorio r⁰ puede cifrarse utilizando la clave pública del nodo de usuario A 302. El número aleatorio puede cifrarse en base a OU tratando el cambio t⁰ como un número aleatorio, que puede expresarse como OU^A (r⁰ , t^ü).

El texto cifrado del importe de transacción puede expresarse entonces como T = (PC(t, r), OU^B(r, t)), y el texto cifrado del cambio puede expresarse como T⁰ = (PC(t⁰ , r⁰), OU^A (r⁰ , t⁰)). De manera similar, el texto cifrado de los k activos seleccionados puede expresarse como T ⁱ = (PC(t^¡, ⁿ ), OU^a (^h , t ⁱ)), donde i = 1, ..., k.

En 314, el nodo de usuario A 302 genera una o más pruebas de intervalo. En algunas implementaciones, se puede generar una primera prueba de intervalo, RP¹, para mostrar que el importe de transacción t > 0. Se puede generar una segunda prueba de intervalo, RP² , para mostrar que el cambio t⁰ > 0, o, en otras palabras, que el valor total de la pluralidad de activos es mayor que, o igual a, el importe de transacción.

En 316, el nodo de usuario A 302 genera una ZKP. La ZKP puede utilizarse para mostrar que el número aleatorio y el importe de transacción ocultos en PC(r, t) son los mismos que el número aleatorio y el importe de transacción cifrados en OU^B(r, t), y el número aleatorio y el importe de transacción ocultos en PC(r⁰ , t⁰) son los mismos que el número aleatorio y el importe de transacción cifrados en OU^A (r⁰ , t⁰). Para generar la ZKP, se pueden seleccionar dos números aleatorios t'¹ y r'¹. Los dos números aleatorios se pueden utilizar para generar tres valores, que son P = PC(t'¹, r'¹), P' = OU^B(r'¹, t '¹), P" = OU^A (r'¹, t '¹). Los tres valores se pueden utilizar para generar un valor hash expresado como x = Hash(P, P', P"). El valor hash x se puede utilizar para calcular t'² = t'¹ + xt, r'² = r'¹ + xr, t'³ = t'¹ + xt y r'³ = r'¹ + xr⁰. La ZKP puede expresarse entonces como (P, P', t'² , r'² , P", t'³ , r'³).

En 318, el nodo de usuario A 302 utiliza una clave privada para generar una firma digital para firmar datos de transacción. En algunas implementaciones, los datos de transacción pueden incluir los ID de activo de los k activos seleccionados (ID¹, ..., ID^k), el texto cifrado del importe de transacción (T), el texto cifrado del cambio (T⁰), las pruebas de intervalo (RP¹ y RP²), el número aleatorio r' y la ZKP.

En 320, el nodo de usuario A 302 envía la copia firmada digitalmente de los datos de transacción a una red de cadena de bloques.

En 322, el nodo de cadena de bloques 304 verifica la firma digital. La verificación de la firma digital se puede realizar para garantizar que los datos de transacción sean enviados por el nodo de usuario A 302. En algunas implementaciones, el nodo de cadena de bloques 304 incluye un mecanismo de evitación de doble gasto que puede verificar si la transacción ya se ha realizado. De ser así, el nodo de cadena de bloques 304 puede rechazar la transacción.

En 324, el nodo de cadena de bloques 304 verifica si los activos seleccionados están asociados a la cuenta del nodo de usuario A. La verificación puede basarse en los ID de activo de los activos.

En 326, el nodo de cadena de bloques 304 verifica que el valor total de la pluralidad seleccionada de activos es igual a la suma del importe de transacción y del cambio. En otras palabras, la cadena de bloques verifica que a¹ +... a^k = t t⁰. Como se analizó anteriormente, bajo el modelo de cuenta genérico, los activos se pueden mantener en la cadena de bloques como PC para proteger la privacidad de datos. De acuerdo con el homomorfismo de PC, PC(r^a1, a¹) x ... x PC(r^ak, a^k) = PC(r^a1 + ... r^ak, a¹ + ... a^k), y PC(r, t) x PC(r⁰ , to) = PC(r r⁰ , t to). Por lo tanto, al demostrarse que PC(r^a1, a¹) x ... x PC(r^ak, a^k) = PC(r, t) x PC(r⁰ , to) x g ^r', puede probarse que a¹ + ... a^k = t t⁰.

En 328, el nodo de cadena de bloques 304 verifica la una o más pruebas de intervalo.

En 330, el nodo de cadena de bloques 304 verifica la ZKP. Tal como se analizó anteriormente, la ZKP puede generarse para verificar si el número aleatorio correspondiente al importe de transacción cifrado utilizando la clave pública del nodo de usuario B es el mismo que el número aleatorio correspondiente oculto por el PC, y si el número aleatorio correspondiente al cambio cifrado utilizando la clave pública del nodo de usuario A 302 es el mismo que el número aleatorio correspondiente oculto por el PC. En algunas implementaciones, para verificar la ZKP, el nodo de cadena de bloques 304 puede calcular primero el valor hash x como x = Hash(P, P', P"). El nodo de cadena de bloques 304 puede verificar entonces si las condiciones PC(t'² , r'²) = P x PC(t, r)^x , OU^B(r'² , t'²) = P' x OU^B(r, t)^x , PC(t'³ , r'³) = P x PC(t⁰ , r⁰)^x y OU^A (r'³ , t'³) = P" x OU^A (r⁰ , to)^x son todas verdaderas. Si todas son verdaderas, el proceso 300 de ejemplo avanza hasta 332. De lo contrario, el nodo de cadena de bloques 304 puede rechazar la transacción.

En 332, el nodo de cadena de bloques 304 actualiza las cuentas del nodo de usuario A 302 y del nodo de usuario B. Debido a que las cuentas del nodo de usuario A 302 y del nodo de usuario B mantienen activos como registros bajo el modelo de cuenta genérico, después de la transacción, la pluralidad de activos transferidos desde el nodo de usuario A 302 pueden eliminarse de la cuenta del nodo de usuario A 302. El cambio se puede agregar nuevamente a la cuenta del nodo de usuario A 302. El importe de transacción y el ID de activo correspondiente se pueden agregar como un nuevo activo a la cuenta del nodo de usuario B. En algunas implementaciones, la actualización se puede realizar en base a la actualización de listas de activos mantenidas por cuentas correspondientes del nodo de usuario A 302 y el nodo de usuario B. En algunas implementaciones, la actualización se puede realizar en base a la adición de textos cifrados del importe de transacción y el cambio en los valores de activo cifrados mantenidos por el nodo de usuario A 302 y el nodo de usuario B. La actualización de las cuentas se describe en más detalle en el presente documento con referencia a la FIG. 4.

La FIG. 4 representa un ejemplo de una transacción de cadena de bloques 400 de acuerdo con las implementaciones de la memoria descriptiva. Como se muestra en la transacción de cadena de bloques 400 de ejemplo, un nodo de usuario A 402 transfiere un importe de transacción t a un nodo de usuario B 404. Antes de la transacción, el nodo de usuario A 402 tiene n activos que incluyen (ID¹, T¹), (ID² , T²), (IDⁿ, Tⁿ).

Utilizando como ejemplo los esquemas de compromiso, los esquemas de cifrado y el proceso de transacción descritos en el presente documento con referencia a la FIG. 3, el nodo de usuario A 402 puede generar los datos de transacción 408, que pueden incluir los ID de activo de los k activos seleccionados, ID, ID² , ..., ID^k . Los datos de transacción 408 pueden incluir además T⁰ , T, RP¹, RP² , r' y la ZKP. Después de que se generen los datos de transacción 408, el nodo de usuario A 402 puede añadir su firma digital y enviar los datos de transacción firmados digitalmente a la red de cadena de bloques 406 para su consenso.

Después de la transacción, los k activos seleccionados pueden eliminarse de la cuenta del activo de usuario A 402. El cambio se puede volver a añadir al nodo de usuario A 402. Por lo tanto, el nodo de usuario A 402 puede tener los siguientes activos expresados como (ID^k+1, T^k+1), (ID^k+2, T^k+2), ..., (IDⁿ, Tⁿ), (ID⁰ , T⁰), donde ID⁰ representa el ID de activo del cambio t^ü .

Antes de la transacción, el nodo de usuario B 404 tiene m activos, que pueden expresarse como (ID^r , T¹ ), (ID?, T?), (ID^m', T^m ). Después de la transacción, el importe de transacción se puede añadir al nodo de usuario B 404. El nodo de usuario B 404 puede tener los siguientes activos expresados como (ID^r , T ^r ), (ID?, T?), (ID^m', T^m'), (ID^t , ^t ), donde ID^t representa el ID de activo del importe de transacción t.

La FIG. 5 representa un ejemplo de un proceso 500 de validación con privacidad protegida de una transacción de cadena de bloques en base a HE. En un nivel alto, el proceso 500 de ejemplo se lleva a cabo por un nodo de usuario A 502, un nodo de usuario B (no mostrado en la FIG. 5) y un nodo de cadena de bloques 504, también denominado nodo de consenso. Tanto la cuenta del nodo de usuario A 502 como la cuenta del nodo de usuario B pueden estar basados en un modelo de cuenta genérico. Una transacción, tal como una transferencia de valor, se puede realizar desde el nodo de usuario A 502 al nodo de usuario B. El nodo de usuario A 502 puede seleccionar uno o más activos de cuenta que tengan un valor total mayor que o igual al importe de transacción para cubrir la transacción. La diferencia entre un valor total del uno o más activos y el importe de transacción puede considerarse como el cambio de la transacción que queda en el nodo de usuario A 502.

Para proteger la privacidad de las cuentas, el nodo de usuario A 502 puede generar compromisos de valores de los activos utilizados para cubrir la transacción y el importe de la transacción utilizando un esquema de compromiso, tal como PC. El nodo de usuario A 502 también puede utilizar HE determinista lineal para cifrar números aleatorios utilizados para generar los compromisos. El HE determinista lineal puede tener las siguientes propiedades: HE(s t) = HE(s) x He(t) y HE(kt) = HE(t)^k . Para verificar la validez de la transacción, el nodo de cadena de bloques 504 puede comparar los números aleatorios ocultos en el compromiso y cifrados por HE en base a una ZKP. Si los números aleatorios coinciden, el nodo de cadena de bloques 504 puede determinar que la transacción es válida. Más detalles del proceso 500 de ejemplo se analizan en la siguiente descripción de la FIG. 5.

En 506, el nodo de usuario A 502 selecciona una pluralidad de activos para transferir un importe de transacción al nodo de usuario B. El nodo de usuario A 502 y el nodo de usuario B pueden ser nodos de consenso de cadena de bloques o nodos de usuario que utilizan la red de cadena de bloques sin participar en el proceso de consenso. El nodo de usuario A 502 puede seleccionar una pluralidad de activos que tienen valor suficiente para cubrir el importe de transacción.

En algunas implementaciones, cada activo puede asociarse a una dirección de transacción o ID de activo que identifica el activo correspondiente. El ID de activo puede ser el valor hash de la información de activo. Los ID de activo de k activos seleccionados pueden representarse como ID¹, ..., ID^k .

En 508, el nodo de usuario A 502 calcula un cambio en base a un valor total de la pluralidad de activos y el importe de transacción. Debido a que los activos se seleccionan para tener un valor total mayor que el importe de transacción, el cambio se puede calcular como el valor total de los activos seleccionados deducido por el importe de transacción.

Usando t para representar el importe de transacción y t⁰ para representar el cambio, el cálculo del cambio puede expresarse como t⁰ = a¹ + ... a^k - t, donde a¹, ..., a^k son, respectivamente, los valores de activo de k activos seleccionados por el nodo de usuario A 502 para cubrir un importe de transacción t.

En 510, el nodo de usuario A 502 genera un número aleatorio correspondiente al importe de transacción y un número aleatorio correspondiente al cambio. El número aleatorio correspondiente al importe de transacción t puede denotarse como r. El número aleatorio correspondiente al cambio t^ü puede denotarse como r⁰. En algunas implementaciones, se puede generar una pluralidad de números aleatorios para producir compromisos de los valores de activo. Por ejemplo, supóngase que a¹, ..., a^k son los valores de activo, los números aleatorios que corresponden a los valores de activo se pueden expresar como r^a1, ... , r^ak.

En algunas implementaciones, el número aleatorio r⁰ puede calcularse en lugar de generarse aleatoriamente. El cálculo se puede expresar como r⁰ = r^a1 +... r^ak - r, donde r es el número aleatorio generado para producir compromiso para el importe de transacción t. Calculando el r⁰ , el nodo de usuario A 502 no necesita generar una ZKP adicional para demostrar que el valor total de los activos transferidos es igual al valor total de los activos recibidos. En algunas implementaciones, un número aleatorio r' puede calcularse como r' = n+ ... r^k - r - r⁰.

En 512, el nodo de usuario A 502 genera compromisos del importe de transacción y el cambio, y cifra los números aleatorios correspondientes en base a un HE determinista. En algunas implementaciones, se pueden utilizar esquemas de compromiso homomórficos, tal como PC, para generar los compromisos. Utilizando el PC como ejemplo no limitativo, el PC del importe de transacción t puede generarse utilizando el número aleatorio r, que puede expresarse como PC(r, t) = g ^rh^t, donde g y h pueden ser generadores de una curva elíptica, y PC(r, t) es una multiplicación escalar de puntos de curva. De manera similar, el PC del cambio t⁰ puede expresarse como PC(r⁰ , t⁰) = g ^r0h^t0.

El número aleatorio r puede cifrarse utilizando la clave pública del nodo de usuario B en base a un HE determinista lineal. El HE determinista lineal se puede obtener de un HE probabilístico, tal como HE de Paillier, Benaloh, OU, de Naccache-Stern, de Boneh-Goh-Nissim, de Damgard-Jurik o de misma probabilidad, fijando el número aleatorio en el esquema de HE a 0 o 1 u otro número apropiado. El número aleatorio cifrado puede expresarse como HE(r).

El número aleatorio r⁰ puede cifrarse utilizando la clave pública del nodo de usuario A. El número aleatorio puede cifrarse en base a un HE determinista lineal. El número aleatorio cifrado puede expresarse como HE(r⁰).

El texto cifrado del importe de transacción t puede expresarse entonces como T = (g^rh^t , HE^B(r)), y el texto cifrado del cambio puede expresarse como T⁰ = (g^r0h^t0 , HE^a (^)). De manera similar, el texto cifrado de los k activos seleccionados puede expresarse como Tⁱ = (g^rih^{t i}, HE(rⁱ), donde i = 1, ..., k.

En 514, el nodo de usuario A 502 genera una o más pruebas de intervalo. En algunas implementaciones, se puede generar una primera prueba de intervalo, RP¹, para mostrar que el importe de transacción t > 0. Se puede generar una segunda prueba de intervalo, RP² , para mostrar que el cambio t⁰ > 0, o, en otras palabras, que el valor total de la pluralidad de activos es mayor que, o igual a, el importe de transacción.

En 516, el nodo de usuario A 502 genera una ZKP. La ZKP se puede utilizar para mostrar que el número aleatorio oculto en PC(r, t) es el mismo que el número aleatorio cifrado en HE(r), y el número aleatorio oculto en PC(r⁰ , to) es el mismo que el número aleatorio cifrado en HE(r⁰). Para generar la ZKP, se pueden seleccionar dos números aleatorios t'¹ y r'¹. Los dos números aleatorios se pueden utilizar para generar tres valores, que son P = g^{r 1} hf ¹, P' = HE^b ^ ) , P" = HE^a (^¹). Los tres valores se pueden utilizar para generar un valor hash expresado como x = Hash(P, P', P"). El valor hash x se puede utilizar para calcular t'² = t'¹ + xt, r'² = r'¹ + xr, t'³ = t'¹ + xt y r'³ = r'¹ + xr⁰. La ZKP puede expresarse entonces como (P, P', t'² , r'² , P", t'³ , r'³).

En 518, el nodo de usuario A 502 utiliza una clave privada para generar una firma digital para firmar datos de transacción. En algunas implementaciones, los datos de transacción pueden incluir los ID de activo de los k activos seleccionados (ID¹, ..., ID^k), el texto cifrado del importe de transacción (T), el texto cifrado del cambio (T⁰), las pruebas de intervalo (RP¹ y RP²), el número aleatorio r' y la ZKP.

En 520, el nodo de usuario A 502 envía la copia firmada digitalmente de los datos de transacción a una red de cadena de bloques.

En 522, el nodo 504 de cadena de bloques verifica la firma digital. La verificación de la firma digital se puede realizar para garantizar que los datos de transacción sean enviados por el nodo de usuario A 502. En algunas implementaciones, el nodo de cadena de bloques 504 incluye un mecanismo de evitación de doble gasto que puede verificar si la transacción ya se ha realizado. De ser así, el nodo de cadena de bloques 504 puede rechazar la transacción.

En 524, el nodo de cadena de bloques 504 verifica si los activos seleccionados están asociados a la cuenta del nodo de usuario A. La verificación puede basarse en los ID de activo de los activos.

En 526, el nodo de cadena de bloques 504 verifica que el valor total de la pluralidad seleccionada de activos es igual a la suma del importe de transacción y del cambio. En otras palabras, el nodo de cadena de bloques 504 verifica que a¹ +... a^k = t t⁰. Como se analizó anteriormente, bajo el modelo de cuenta genérico, los activos se pueden mantener en la cadena de bloques como PC para proteger la privacidad de datos. De acuerdo con el homomorfismo de PC, PC(r^{a i} , aⁱ ) x ... x PC(r^ak, a^k) = PC(r^{a i} + ... r^ak, a ⁱ + ... a^k), y PC(r, t) x PC(r⁰ , t^ü) = PC(r r⁰ , t t^ü). Por lo tanto, al demostrarse que PC(r^{a i} , a ⁱ ) x ... x PC(r^ak, a^k) = PC(r, t) x pC(r⁰ , t⁰) x g^r', puede probarse que a ⁱ + ... a^k = t t⁰.

En 528, el nodo de cadena de bloques 504 verifica la una o más pruebas de intervalo.

En 530, el nodo de cadena de bloques 504 verifica la ZKP. Tal como se analizó anteriormente, la ZKP puede generarse para verificar si el número aleatorio correspondiente al importe de transacción cifrado utilizando la clave pública del nodo de usuario B es el mismo que el número aleatorio correspondiente oculto por el PC, y si el número aleatorio correspondiente al cambio cifrado utilizando la clave pública del nodo de usuario A 502 es el mismo que el número aleatorio correspondiente oculto por el PC. En algunas implementaciones, para verificar la ZKP, el nodo de cadena de bloques 504 puede calcular primero el valor hash x como x = Hash(P, P', P"). El nodo de cadena de bloques 504 puede verificar entonces si las condiciones g^r'2hf²= P x (g^rh^t)^x , HE^B(r') = P' x HE (r)^x , g^r'3hf³ = P x (g^r0h^t0)^x y HE^A (r'³) = P" x HE^A (r⁰)^x son todas verdaderas. Si todas son verdaderas, el proceso 500 de ejemplo avanza hasta 532. De lo contrario, el nodo de cadena de bloques 504 puede rechazar la transacción.

En 532, el nodo de cadena de bloques 504 actualiza las cuentas del nodo de usuario A 502 y del nodo de usuario B. Debido a que las cuentas del nodo de usuario A 502 y del nodo de usuario B mantienen activos como registros bajo el modelo de cuenta genérico, después de la transacción, la pluralidad de activos transferidos desde el nodo de usuario A 502 pueden eliminarse de la cuenta del nodo de usuario A 502. El cambio se puede agregar nuevamente a la cuenta del nodo de usuario A 502. El importe de transacción y el ID de activo correspondiente se pueden agregar como un nuevo activo a la cuenta del nodo de usuario B. En algunas implementaciones, la actualización se puede realizar en base a la actualización de listas de activos mantenidas por cuentas correspondientes del nodo de usuario A 502 y el nodo de usuario B. En algunas implementaciones, la actualización se puede realizar en base a la adición de textos cifrados del importe de transacción y el cambio en los valores de activo cifrados mantenidos por el nodo de usuario A 502 y el nodo de usuario B. Una transacción de cadena de bloques 400 de ejemplo y las actualizaciones de cuenta correspondientes se describen en la descripción de la Fig. 4.

La FIG. 6 representa un ejemplo de un proceso 600 que puede ser ejecutado de acuerdo con implementaciones de la memoria descriptiva. Para mayor claridad de presentación, la siguiente descripción describe generalmente el procedimiento 600 en el contexto de las otras figuras de esta descripción. Sin embargo, se entenderá que el proceso 600 de ejemplo puede realizarse, por ejemplo, mediante cualquier sistema, entorno, software y hardware, o una combinación de sistemas, entornos, software y hardware, según sea apropiado. En algunas implementaciones, las etapas del proceso 600 de ejemplo pueden ejecutarse en paralelo, en combinación, en bucles o en cualquier orden.

En 602, un nodo de consenso recibe datos de transacción asociados a la transacción. En algunos ejemplos, los datos de transacción comprenden datos representativos de una pluralidad de activos, un primer compromiso que oculta un primer número aleatorio y un importe de transacción de la transacción, un segundo compromiso que oculta un segundo número aleatorio y un cambio calculado en base a deducir el importe de transacción de un valor total de la pluralidad de activos, el importe de transacción y un tercer número aleatorio ambos cifrados por una clave pública del segundo nodo en base a un esquema de HE probabilístico, el cambio y un cuarto número aleatorio ambos cifrados por una clave pública del primer nodo en base al esquema de HE probabilístico, una o más pruebas de intervalo, una ZKP y una firma digital generada en base a una clave privada correspondiente a la clave pública del primer nodo.

En algunas implementaciones, cada uno de la pluralidad de activos está asociado a uno o más de un tipo de activo, un valor de activo oculto en un compromiso y un número aleatorio utilizado para generar el compromiso. En algunas implementaciones, el nodo de consenso determina que cada uno de la pluralidad de activos está asociado a un mismo tipo de activo. En algunas implementaciones, el primer compromiso, el segundo compromiso y el compromiso que oculta el valor de activo se generan en base a un esquema de compromiso que es homomórfico.

En algunas implementaciones, el tercer número aleatorio está cifrado en base al esquema de HE probabilístico al tratar el importe de transacción como un número aleatorio, y el cuarto número aleatorio está cifrado en base al esquema de HE probabilístico al tratar el cambio como un número aleatorio. En algunas implementaciones, el primer compromiso y el segundo compromiso se generan en base a un esquema de compromiso de Pedersen, y el esquema de HE probabilístico es un esquema de cifrado de OU.

En algunas implementaciones, la ZKP comprende un compromiso de Pedersen que oculta un quinto número aleatorio y un sexto número aleatorio, un texto cifrado del quinto número aleatorio y el sexto número aleatorio cifrados por la clave pública de la segunda cuenta en base al esquema de cifrado de OU, y un texto cifrado del quinto número aleatorio y el sexto número aleatorio cifrados por la clave pública de la primera cuenta en base al esquema de cifrado de OU.

En 604, el nodo de consenso verifica la firma digital en base a la clave pública del primer nodo.

i i

En 606, el nodo de consenso determina que la una o más pruebas de intervalo demuestran que el importe de transacción y el cambio son cada uno mayores que, o iguales a, cero.

En 608, el nodo de consenso determina que el valor total de la pluralidad de billetes es igual a la suma del importe de transacción y del cambio. En algunas implementaciones, determinar que el valor total de la pluralidad de activos es igual a la suma del importe de transacción y del cambio se realiza en base al homomorfismo del esquema de compromiso.

En 610, el nodo de consenso determina, en base a la ZKP, que la transacción es válida al determinar que el primer número aleatorio es igual al tercer número aleatorio, que el segundo número aleatorio es igual al cuarto número aleatorio y que el importe de transacción oculto en el primer compromiso es igual al importe de transacción cifrado por la clave pública del segundo nodo.

En algunas implementaciones, la transacción se realiza entre una cuenta asociada al primer nodo y una cuenta asociada al segundo nodo, y el procedimiento comprende además actualizar, después de determinar que la transacción es válida, la cuenta asociada al primer nodo y la cuenta asociada al segundo nodo en base al importe de transacción y el cambio. En algunas implementaciones, la ZKP se genera y se utiliza para determinar que la transacción es válida en base a propiedades del HE probabilístico. En algunas implementaciones, determinar que la transacción es válida se realiza en base a la ZKP sin interacciones entre el primer nodo y el segundo nodo a través del exterior de la red de cadena de bloques.

La FIG. 7 representa un proceso 700 de ejemplo que puede ser ejecutado de acuerdo con implementaciones de la memoria descriptiva. Para mayor claridad de presentación, la siguiente descripción describe generalmente el procedimiento 700 en el contexto de las otras figuras de esta descripción. Sin embargo, se entenderá que el proceso 700 de ejemplo puede realizarse, por ejemplo, mediante cualquier sistema, entorno, software y hardware, o una combinación de sistemas, entornos, software y hardware, según sea apropiado. En algunas implementaciones, las etapas del proceso 700 de ejemplo pueden ejecutarse en paralelo, en combinación, en bucles o en cualquier orden.

En 702, un nodo de consenso recibe datos de transacción asociados a la transacción. En algunos ejemplos, los datos de transacción comprenden datos representativos de una pluralidad de activos, un primer compromiso que oculta un primer número aleatorio y un importe de transacción de la transacción, un segundo compromiso que oculta un segundo número aleatorio y un cambio calculado en base a deducir el importe de transacción de un valor total de la pluralidad de activos, el importe de transacción y un tercer número aleatorio ambos cifrados por una clave pública del segundo nodo en base a un esquema de HE determinista lineal, el cambio y un cuarto número aleatorio ambos cifrados por una clave pública del primer nodo en base al esquema de HE determinista lineal, una o más pruebas de intervalo, una ZKP y una firma digital generada en base a una clave privada correspondiente a la clave pública del primer nodo.

En algunas implementaciones, cada uno de la pluralidad de activos está asociado a uno o más de un tipo de activo, un valor de activo oculto en un compromiso y un número aleatorio utilizado para generar el compromiso. En algunas implementaciones, el nodo de consenso determina que cada uno de la pluralidad de activos está asociado a un mismo tipo de activo. En algunas implementaciones, el primer compromiso, el segundo compromiso y el compromiso que oculta el valor de activo se generan en base a un esquema de compromiso que es homomórfico.

En algunas implementaciones, el esquema de HE determinista lineal deriva de un esquema de HE probabilístico basado en cambiar un número aleatorio asociado al esquema de HE probabilístico en un número fijo.

En algunas implementaciones, la ZKP comprende un compromiso que oculta un quinto número aleatorio y un sexto número aleatorio, un texto cifrado del quinto número aleatorio y el sexto número aleatorio cifrados por la clave pública de la segunda cuenta en base al esquema de HE determinista lineal, y un texto cifrado del quinto número aleatorio y el sexto número aleatorio cifrados por la clave pública de la primera cuenta en base al esquema de HE determinista lineal.

En 704, el nodo de consenso verifica la firma digital en base a la clave pública del primer nodo.

En 706, el nodo de consenso determina que la una o más pruebas de intervalo demuestran que el importe de transacción y el cambio son cada uno mayores que, o iguales a, cero.

En 708, el nodo de consenso determina que el valor total de la pluralidad de billetes es igual a la suma del importe de transacción y del cambio. En algunas implementaciones, determinar que el valor total de la pluralidad de activos es igual a la suma del importe de transacción y del cambio se realiza en base al homomorfismo del esquema de compromiso.

En 710, el nodo de consenso determina, en base a la ZKP, que la transacción es válida al determinar que el primer número aleatorio es igual al tercer número aleatorio, que el segundo número aleatorio es igual al cuarto número aleatorio y que el importe de transacción oculto en el primer compromiso es igual al importe de transacción cifrado por la clave pública del segundo nodo.

En algunas implementaciones, la transacción se realiza entre una cuenta asociada al primer nodo y una cuenta asociada al segundo nodo, y el procedimiento comprende además actualizar, después de determinar que la transacción es válida, la cuenta asociada al primer nodo y la cuenta asociada al segundo nodo en base al importe de transacción y el cambio. En algunas implementaciones, la ZKP se genera y se utiliza para determinar que la transacción es válida en base a propiedades del HE determinista lineal. En algunas implementaciones, determinar que la transacción es válida se realiza en base a la ZKP sin interacciones entre el primer nodo y el segundo nodo a través del exterior de la red de cadena de bloques.

La FIG. 8 representa un ejemplo de un nodo de cadena de bloques 800 que puede llevar a cabo un proceso de acuerdo con implementaciones de la memoria descriptiva. En un nivel alto, el nodo de cadena de bloques 800 incluye una unidad de recepción 802, una unidad de verificación 804, una primera unidad de determinación 806, una segunda unidad de determinación 808 y una tercera unidad de determinación 810.

En algunas implementaciones, la unidad de recepción 802 puede funcionar para recibir datos de transacción asociados a la transacción. En algunos ejemplos, los datos de transacción comprenden datos representativos de una pluralidad de activos, un primer compromiso que oculta un primer número aleatorio y un importe de transacción de la transacción, un segundo compromiso que oculta un segundo número aleatorio y un cambio calculado en base a deducir el importe de transacción de un valor total de la pluralidad de activos, el importe de transacción y un tercer número aleatorio ambos cifrados por una clave pública del segundo nodo en base a un esquema de HE probabilístico, el cambio y un cuarto número aleatorio ambos cifrados por una clave pública del primer nodo en base al esquema de HE probabilístico, una o más pruebas de intervalo, una ZKP y una firma digital generada en base a una clave privada correspondiente a la clave pública del primer nodo.

En algunas implementaciones, la unidad de recepción 802 se puede hacer funcionar para recibir datos de transacción asociados a la transacción, donde los datos de transacción comprenden: datos representativos de una pluralidad de activos, un primer compromiso que oculta un primer número aleatorio y un importe de transacción de la transacción, un segundo compromiso que oculta un segundo número aleatorio y un cambio calculado en base a deducir el importe de transacción de un valor total de la pluralidad de activos, el importe de transacción y un tercer número aleatorio ambos cifrados por una clave pública del segundo nodo en base a un esquema de HE determinista lineal, el cambio y un cuarto número aleatorio ambos cifrados por una clave pública del primer nodo en base al esquema de HE determinista lineal, una o más pruebas de intervalo, una ZKP y una firma digital generada en base a una clave privada correspondiente a la clave pública del primer nodo.

En algunas implementaciones, cada uno de la pluralidad de activos está asociado a uno o más de un tipo de activo, un valor de activo oculto en un compromiso y un número aleatorio utilizado para generar el compromiso. En algunas implementaciones, el nodo de cadena de bloques 800 determina que cada uno de la pluralidad de activos está asociado a un mismo tipo de activo. En algunas implementaciones, el primer compromiso, el segundo compromiso y el compromiso que oculta el valor de activo se generan en base a un esquema de compromiso que es homomórfico. En algunas implementaciones, el esquema de HE determinista lineal deriva de un esquema de HE probabilístico basado en cambiar un número aleatorio asociado al esquema de HE probabilístico en un número fijo.

En algunas implementaciones, el tercer número aleatorio está cifrado en base al esquema de HE probabilístico al tratar el importe de transacción como un número aleatorio, y el cuarto número aleatorio está cifrado en base al esquema de HE probabilístico al tratar el cambio como un número aleatorio. En algunas implementaciones, el primer compromiso y el segundo compromiso se generan en base a un esquema de compromiso de Pedersen, y el esquema de HE probabilístico es un esquema de cifrado de OU.

En algunas implementaciones, la ZKP comprende un compromiso de Pedersen que oculta un quinto número aleatorio y un sexto número aleatorio, un texto cifrado del quinto número aleatorio y el sexto número aleatorio cifrados por la clave pública de la segunda cuenta en base al esquema de cifrado de OU, y un texto cifrado del quinto número aleatorio y el sexto número aleatorio cifrados por la clave pública de la primera cuenta en base al esquema de cifrado de OU. En algunas implementaciones, la ZKP comprende un compromiso que oculta un quinto número aleatorio y un sexto número aleatorio, un texto cifrado del quinto número aleatorio y el sexto número aleatorio cifrados por la clave pública de la segunda cuenta en base al esquema de HE determinista lineal, y un texto cifrado del quinto número aleatorio y el sexto número aleatorio cifrados por la clave pública de la primera cuenta en base al esquema de HE determinista lineal.

La unidad de verificación 804 puede hacerse funcionar para verificar la firma digital en base a la clave pública del primer nodo.

La primera unidad de determinación 806 puede hacerse funcionar para determinar que la una o más pruebas de intervalo demuestran que el importe de transacción y el cambio son cada uno mayores que, o iguales a, cero.

La segunda unidad de determinación 808 puede hacerse funcionar para determinar que el valor total de la pluralidad de billetes es igual a la suma del importe de transacción y del cambio. En algunas implementaciones, determinar que el valor total de la pluralidad de activos es igual a la suma del importe de transacción y del cambio se realiza en base al homomorfismo del esquema de compromiso.

La tercera unidad de determinación 810 puede hacerse funcionar para determinar, en base a la ZKP, que la transacción es válida al determinar que el primer número aleatorio es igual al tercer número aleatorio, que el segundo número aleatorio es igual al cuarto número aleatorio y que el importe de transacción oculto en el primer compromiso es igual al importe de transacción cifrado por la clave pública del segundo nodo.

En algunas implementaciones, la transacción se realiza entre una cuenta asociada al primer nodo y una cuenta asociada al segundo nodo, y el nodo de cadena de bloques 800 puede incluir una unidad de actualización que puede hacerse funcionar para actualizar, después de que la tercera unidad de determinación 810 determine que la transacción es válida, la cuenta asociada al primer nodo y la cuenta asociada al segundo nodo en base al importe de transacción y el cambio. En algunas implementaciones, la ZKP se genera y se utiliza para determinar que la transacción es válida en base a propiedades del HE probabilístico. En algunas implementaciones, la ZKP se genera y se utiliza para determinar que la transacción es válida en base a propiedades de1HE determinista lineal. En algunas implementaciones, determinar que la transacción es válida se realiza en base a la ZKP sin interacciones entre el primer nodo y el segundo nodo a través del exterior de la red de cadena de bloques.

Las implementaciones de la materia objeto descrita en esta memoria descriptiva pueden implementarse para lograr ventajas o efectos técnicos particulares. Por ejemplo, las implementaciones de la memoria descriptiva permiten que el saldo de cuenta y el importe de transacción de nodos de cadena de bloques sean privados durante las transacciones. El destinatario de una transferencia de fondos no necesita confirmar la transacción o utilizar un número aleatorio para verificar un compromiso; la validación de transacción puede ser no interactiva. Un nodo de cadena de bloques puede validar la transacción en base a HE y esquemas de compromiso para permitir una prueba de conocimiento nulo.

La metodología descrita permite mejorar la seguridad de cuenta/datos de diversos dispositivos informáticos móviles. El saldo de las cuentas y los importes de transacción pueden cifrarse en base a HE y ocultarse mediante esquemas de compromiso. Por lo tanto, un nodo de consenso puede actualizar los saldos de cuenta en el libro mayor después de la transacción en base a las propiedades de HE sin revelar el saldo de cuenta real de la cuenta. Debido a que no es necesario enviar el número aleatorio a un destinatario para confirmar la transacción, se puede reducir el riesgo de fuga de datos y se necesitan menos recursos de cálculo y de memoria para gestionar el número aleatorio.

Las implementaciones y las operaciones descritas en esta memoria descriptiva se pueden implementar en circuitos de electrónica digital, o en software, firmware o hardware de ordenador, incluidas las estructuras divulgadas en esta memoria descriptiva o en combinaciones de una o más de las mismas. Las operaciones pueden implementarse como operaciones realizadas por un aparato de procesamiento de datos sobre datos almacenados en uno o más dispositivos de almacenamiento legibles por ordenador o recibidos desde otras fuentes. Un aparato de procesamiento de datos, ordenador o dispositivo informático puede abarcar aparatos, dispositivos y máquinas para el procesamiento de datos, incluidos, a modo de ejemplo, un procesador programable, un ordenador, un sistema en un chip, o múltiples chips, o combinaciones de lo anterior. El aparato puede incluir circuitos de lógica de propósito especial, por ejemplo, una unidad central de procesamiento (CPU), una matriz de puertas programables in situ (FPGA) o un circuito integrado específico de la aplicación (ASIC). El aparato también puede incluir código que crea un entorno de ejecución para el programa informático en cuestión, por ejemplo, código que constituye el firmware de procesador, una pila de protocolo, un sistema de gestión de bases de datos, un sistema operativo (por ejemplo, un sistema operativo o una combinación de sistemas operativos), un entorno de ejecución multiplataforma, una máquina virtual o una combinación de uno o más de los mismos. El aparato y el entorno de ejecución pueden realizar varias infraestructuras de modelos de computación diferentes, tales como servicios web, computación distribuida e infraestructuras de computación en red.

Un programa informático (también conocido, por ejemplo, como programa, software, aplicación de software, módulo de software, unidad de software, secuencia de comandos o código) se puede escribir en cualquier forma de lenguaje de programación, incluidos los lenguajes compilados o interpretados, los lenguajes declarativos o procedimentales, y se puede implementar en cualquier forma, incluso como un programa autónomo o como un módulo, componente, subrutina, objeto u otra unidad adecuada para su uso en un entorno informático. Un programa se puede almacenar en una porción de un archivo que contiene otros programas o datos (por ejemplo, una o más secuencias de comandos almacenadas en un documento de lenguaje de marcado), en un solo archivo dedicado al programa en cuestión, o en múltiples archivos coordinados (por ejemplo, archivos que almacenan uno o más módulos, subprogramas o porciones de código). Un programa informático se puede ejecutar en un ordenador o en múltiples ordenadores que están ubicados en un emplazamiento o distribuidos en múltiples emplazamientos e interconectados por una red de comunicaciones.

Los procesadores para la ejecución de un programa informático incluyen, a modo de ejemplo, microprocesadores tanto de propósito general como especial, y uno o más procesadores de cualquier tipo de ordenador digital. Por lo general, un procesador recibirá instrucciones y datos de una memoria de sólo lectura o de una memoria de acceso aleatorio, o de ambas. Los elementos esenciales de un ordenador son un procesador para realizar acciones de acuerdo con instrucciones y uno o más dispositivos de memoria para almacenar instrucciones y datos. Por lo general, un ordenador también incluirá, o se acoplará de forma operativa para recibir datos desde o transferir datos a, o ambas cosas, uno o más dispositivos de almacenamiento masivo para almacenar datos. Un ordenador se puede integrar en otro dispositivo, por ejemplo, un dispositivo móvil, un asistente digital personal (PDA), una consola de juegos, un receptor del sistema de posicionamiento global (GPS) o un dispositivo de almacenamiento portátil. Dispositivos adecuados para almacenar instrucciones y datos de programa informático incluyen memorias no volátiles, medios y dispositivos de memoria, incluidos, a modo de ejemplo, dispositivos de memoria de semiconductores, discos magnéticos y discos magneto-ópticos. El procesador y la memoria se pueden complementar mediante, o incorporar en, circuitos lógicos de propósito especial.

Los dispositivos móviles pueden incluir microteléfonos, equipos de usuario (UE), teléfonos móviles (por ejemplo, teléfonos inteligentes), tabletas, dispositivos para llevar puestos (por ejemplo, relojes inteligentes y gafas inteligentes), dispositivos implantados dentro del cuerpo humano (por ejemplo, biosensores, implantes cocleares), u otros tipos de dispositivos móviles. Los dispositivos móviles se pueden comunicar de forma inalámbrica (por ejemplo, utilizando señales de radiofrecuencia (RF)) con diversas redes de comunicación (descritas a continuación). Los dispositivos móviles pueden incluir sensores para determinar características del entorno actual del dispositivo móvil. Los sensores pueden incluir cámaras, micrófonos, sensores de proximidad, sensores GPS, sensores de movimiento, acelerómetros, sensores de luz ambiental, sensores de humedad, giroscopios, brújulas, barómetros, sensores de huellas dactilares, sistemas de reconocimiento facial, sensores de RF (por ejemplo, radios Wi-Fi y celulares), sensores térmicos u otros tipos de sensores. Por ejemplo, las cámaras pueden incluir una cámara orientada hacia delante o hacia atrás con lentes móviles o fijas, un flash, un sensor de imagen y un procesador de imágenes. La cámara puede ser una cámara de megapíxeles que puede capturar detalles para el reconocimiento facial y/o del iris. La cámara, junto con un procesador de datos y la información de autenticación almacenada en memoria o a la que se accede de forma remota, puede formar un sistema de reconocimiento facial. El sistema de reconocimiento facial o uno o más sensores, por ejemplo, micrófonos, sensores de movimiento, acelerómetros, sensores GPS o sensores RF, se pueden utilizar para la autenticación del usuario.

Para proporcionar interacción con un usuario, las implementaciones se pueden implementar en un ordenador que tenga un dispositivo de visualización y un dispositivo de entrada, por ejemplo, una pantalla de cristal líquido (LCD) o una pantalla de diodos orgánicos emisores de luz (OLED)/realidad virtual (VR)/realidad aumentada (AR) para mostrar información al usuario y una pantalla táctil, un teclado y un dispositivo señalador mediante el cual el usuario puede proporcionar datos de entrada al ordenador. También se pueden utilizar otros tipos de dispositivos para permitir la interacción con un usuario; por ejemplo, la retroalimentación proporcionada al usuario puede ser cualquier forma de retroalimentación sensorial, por ejemplo, retroalimentación visual, retroalimentación auditiva o retroalimentación táctil; y la entrada del usuario se puede recibir de cualquier forma, incluida la entrada acústica, de voz o táctil. Además, un ordenador puede interactuar con un usuario enviando documentos a y recibiendo documentos desde un dispositivo utilizado por el usuario; por ejemplo, enviando páginas web a un navegador web en el dispositivo cliente de un usuario en respuesta a las solicitudes recibidas desde el navegador web.

Las implementaciones se pueden implementar utilizando dispositivos informáticos interconectados mediante cualquier forma o medio de comunicación cableada o inalámbrica de datos digitales (o una combinación de los mismos), por ejemplo, una red de comunicaciones. Ejemplos de dispositivos interconectados son un cliente y un servidor generalmente remotos entre sí que normalmente interactúan a través de una red de comunicaciones. Un cliente, por ejemplo, un dispositivo móvil, puede realizar transacciones por sí mismo, con un servidor, o a través de un servidor, por ejemplo, realizando transacciones de compra, venta, pago, entrega, envío o préstamo, o autorizando las mismas. Dichas transacciones pueden ser en tiempo real de modo que una acción y una respuesta sean temporalmente próximas; por ejemplo, una persona percibe que la acción y la respuesta se producen casi simultáneamente, la diferencia de tiempo para una respuesta después de la acción de la persona es inferior a 1 milisegundo (ms) o inferior a 1 segundo (s), o la respuesta no tiene un retardo intencionado teniendo en cuenta las limitaciones de procesamiento del sistema.

Ejemplos de redes de comunicaciones incluyen una red de área local (LAN), una red de acceso por radio (RAN), una red de área metropolitana (MAN) y una red de área amplia (WAN). La red de comunicación puede incluir toda o una parte de Internet, otra red de comunicaciones o una combinación de redes de comunicaciones. La información se puede transmitir en la red de comunicaciones de acuerdo con diversos protocolos y normas, incluidos Evolución a Largo Plazo (LTE), 5G, IEEE 802, Protocolo de Internet (IP) u otros protocolos o combinaciones de protocolos. La red de comunicaciones puede transmitir datos de voz, vídeo, biométricos o de autenticación u otra información entre los dispositivos informáticos conectados.

Las características descritas como implementaciones separadas pueden implementarse, en combinación, en una sola implementación, mientras que las características descritas como una sola implementación pueden implementarse en múltiples implementaciones, por separado, o en cualquier subcombinación adecuada. No debe entenderse que las operaciones descritas y reivindicadas en un orden particular requieren ese orden particular, ni que todas las operaciones ilustradas deben realizarse (algunas operaciones pueden ser opcionales). Según corresponda, se puede realizar multitarea o procesamiento en paralelo (o una combinación de multitarea y procesamiento en paralelo).

Claims (11)

REIVINDICACIONES

1. Un procedimiento implementado por ordenador realizado por un nodo de consenso para validar una transacción (400) entre un primer nodo y un segundo nodo dentro de una red de cadena de bloques (102), estando caracterizando el procedimiento por:

recibir datos de transacción (408) asociados a la transacción (400), donde los datos de transacción comprenden: datos representativos de una pluralidad de activos, un primer compromiso que oculta un primer número aleatorio y un importe de transacción de la transacción, un segundo compromiso que oculta un segundo número aleatorio y un cambio calculado en base a deducir el importe de transacción de un valor total de la pluralidad de activos, el importe de transacción y un tercer número aleatorio ambos cifrados por una clave pública del segundo nodo en base a un esquema de cifrado homomórfico - HE - determinista lineal, el cambio y un cuarto número aleatorio ambos cifrados por una clave pública del primer nodo en base al esquema de HE determinista lineal, una o más pruebas de intervalo, una prueba de conocimiento nulo - ZKP - y una firma digital generada en base a una clave privada correspondiente a la clave pública del primer nodo;

verificar (322) la firma digital en base a la clave pública del primer nodo;

determinar (328) que la una o más pruebas de intervalo demuestran que el importe de transacción y el cambio son cada uno mayores que, o iguales a, cero;

determinar (326) que el valor total de la pluralidad de activos es igual a una suma del importe de transacción y del cambio; y

determinar (330), en base a la ZKP, que la transacción (400) es válida al determinar que el primer número aleatorio es igual al tercer número aleatorio, que el segundo número aleatorio es igual al cuarto número aleatorio y que el importe de transacción oculto en el primer compromiso es igual al importe de transacción cifrado por la clave pública del segundo nodo.

2. El procedimiento implementado por ordenador de la reivindicación 1, en el que la transacción (400) se realiza entre una cuenta asociada al primer nodo y una cuenta asociada al segundo nodo, y el procedimiento comprende además actualizar, después de determinar que la transacción (400) es válida, la cuenta asociada al primer nodo y la cuenta asociada al segundo nodo en base al importe de transacción y el cambio.

3. El procedimiento implementado por ordenador de la reivindicación 1, en el que cada uno de la pluralidad de activos está asociado a uno o más de un tipo de activo, un valor de activo oculto en un compromiso y un número aleatorio utilizado para generar el compromiso.

4. El procedimiento implementado por ordenador de la reivindicación 3, que comprende además determinar que cada uno de la pluralidad de activos está asociado a un mismo tipo de activo.

5. El procedimiento implementado por ordenador de la reivindicación 3, en el que el primer compromiso, el segundo compromiso y el compromiso que oculta el valor de activo se generan en base a un esquema de compromiso que es homomórfico, y en el que la determinación de que el valor total de la pluralidad de activos es igual a la suma del importe de transacción y del cambio se realiza en base al homomorfismo del esquema de compromiso.

6. El procedimiento implementado por ordenador de la reivindicación 1, en el que el esquema de HE determinista lineal deriva de un esquema de HE probabilístico basado en cambiar un número aleatorio asociado al esquema de HE probabilístico en un número fijo.

7. El procedimiento implementado por ordenador de la reivindicación 1, en el que la ZKP comprende un compromiso que oculta un quinto número aleatorio y un sexto número aleatorio, un texto cifrado del quinto número aleatorio y el sexto número aleatorio cifrados por la clave pública de la segunda cuenta en base al esquema de HE determinista lineal, y un texto cifrado del quinto número aleatorio y el sexto número aleatorio cifrados por la clave pública de la primera cuenta en base al esquema de HE determinista lineal.

8. El procedimiento implementado por ordenador de la reivindicación 1, en el que la ZKP se genera y se utiliza para determinar que la transacción (400) es válida en base a propiedades del HE determinista lineal.

9. El procedimiento implementado por ordenador de la reivindicación 1, en el que determinar que la transacción (400) es válida se realiza en base a la ZKP sin interacciones entre el primer nodo y el segundo nodo a través del exterior de la red de cadena de bloques (102).

10. Un medio de almacenamiento no transitorio legible por ordenador acoplado a uno o más ordenadores y configurado con instrucciones ejecutables por el uno o más ordenadores para realizar operaciones de acuerdo con el procedimiento de una o más de las reivindicaciones 1-9.

11. Un sistema, que comprende:

uno o más ordenadores; y

una o más memorias legibles por ordenador acopladas al uno o más ordenadores y configuradas con instrucciones ejecutables por el uno o más ordenadores para realizar operaciones de acuerdo con el procedimiento de una o más de las reivindicaciones 1-9.