ES2863559T3 - Protección de datos de cadena de bloques en base al modelo de billete de cuenta con prueba de conocimiento cero - Google Patents

Protección de datos de cadena de bloques en base al modelo de billete de cuenta con prueba de conocimiento cero Download PDF

Info

Publication number
ES2863559T3
ES2863559T3 ES18867086T ES18867086T ES2863559T3 ES 2863559 T3 ES2863559 T3 ES 2863559T3 ES 18867086 T ES18867086 T ES 18867086T ES 18867086 T ES18867086 T ES 18867086T ES 2863559 T3 ES2863559 T3 ES 2863559T3
Authority
ES
Spain
Prior art keywords
transaction amount
account
commitment
transaction
random number
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES18867086T
Other languages
English (en)
Inventor
Baoli Ma
Wenbin Zhang
Huanyu Ma
Zheng Liu
Lichun Li
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Advanced New Technologies Co Ltd
Original Assignee
Advanced New Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Advanced New Technologies Co Ltd filed Critical Advanced New Technologies Co Ltd
Application granted granted Critical
Publication of ES2863559T3 publication Critical patent/ES2863559T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G06Q20/0658—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed locally
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/008—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving homomorphic encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • Signal Processing (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Power Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)
  • Devices For Executing Special Programs (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Un método (300, 500) implementado por computadora realizado por un nodo de consenso de una red de cadena de bloques, que comprende: recibir (320, 502), desde una primera cuenta, una copia firmada digitalmente de una pluralidad de identificadores (ID) de billete que identifican una pluralidad correspondiente de billetes asociados con la primera cuenta, un compromiso de una cantidad de transacción de una transacción entre la primera cuenta y una segunda cuenta pagada por al menos una parte de la pluralidad de billetes, un compromiso de un cambio de deducir la cantidad de transacción de un valor total de la pluralidad de billetes, un primer número aleatorio utilizado para generar (312) el compromiso de la cantidad de transacción cifrada por una clave pública de la segunda cuenta, la cantidad de transacción cifrada por la clave pública de la segunda cuenta, un segundo número aleatorio utilizado para generar (312, 314, 316) el compromiso del cambio cifrado por la clave pública de la primera cuenta, el cambio cifrado por la clave pública de la primera cuenta, una pluralidad de pruebas de rango y una prueba de conocimiento cero generada (310) en base a uno o más números aleatorios seleccionados, en donde la pluralidad de las pruebas de rango incluyen una primera prueba (RP1) de rango generada (314) para demostrar que la cantidad de transacción es mayor o igual a cero, y una segunda prueba (RP2) de rango generada (314) para demostrar que la cantidad de cambio es mayor o igual a cero; verificar (322, 504) una firma digital correspondiente a la copia firmada digitalmente utilizando la clave pública de la primera cuenta; determinar (328, 506) que la pluralidad de pruebas de rango prueba que la cantidad de transacción y el cambio son mayores o iguales a cero; determinar (326, 508) que el valor total de la pluralidad de billetes es igual a la suma de la cantidad de transacción y del cambio; determinar (510) si la cantidad de transacción en el compromiso es la misma que la cantidad de transacción que está cifrada, y si un número aleatorio utilizado para generar el compromiso de la cantidad de transacción es el mismo que el primer número aleatorio; y actualizar (334, 512) la primera cuenta y la segunda cuenta en base a la pluralidad de billetes, la cantidad de transacción y el cambio si la cantidad de transacción en el compromiso es la misma que la cantidad de transacción que está cifrada, y el número aleatorio utilizado para generar el compromiso de la cantidad de transacción es el mismo que el primer número aleatorio.

Description

DESCRIPCIÓN
Protección de datos de cadena de bloques en base al modelo de billete de cuenta con prueba de conocimiento cero
ANTECEDENTES
Las redes de cadena de bloques, que también pueden denominarse sistemas de cadena de bloques, redes de consenso, redes de sistemas de contabilidad distribuida o cadena de bloques, permiten a las entidades participantes almacenar datos de forma segura e inmutable. Una cadena de bloques se puede describir como un libro mayor de transacciones y se almacenan múltiples copias de la cadena de bloques en la red de la cadena de bloques. Los 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. Se proporciona una cadena de bloques privada para una entidad particular, que controla de forma centralizada los permisos de lectura y escritura.
Las cadenas de bloques se utilizan en redes de criptomonedas, que permiten a los participantes realizar transacciones para comprar/vender bienes/servicios utilizando una criptomoneda. Una criptomoneda común incluye Bitcoin. En las redes de criptomonedas, los modelos de mantenimiento de registros se utilizan para registrar transacciones entre usuarios. Los modelos de mantenimiento de registros de ejemplo incluyen el modelo de salida de transacciones no gastadas (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 realiza un seguimiento de las transacciones no gastadas de un usuario y el saldo que el usuario tiene que gastar se calcula como la suma de las transacciones no gastadas. En el modelo de saldo de la cuenta, el saldo de la cuenta de cada uno de los usuarios se registra como un estado global. Para cada una de las transacciones, se verifica el saldo de una cuenta de gastos para asegurarse de que sea mayor o igual a la cantidad de 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 replican 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 la vean todos los nodos, al menos en el caso de las redes públicas. Para proteger la privacidad de los usuarios de cadena de bloques, se implementan tecnologías de cifrado.
El documento CN 108764874 A describe un método de transferencia anónima en base a una cadena de bloques. El método incluye que un primer nodo inicie una solicitud de transacción de transferencia a un segundo nodo y reciba información de clave pública devuelta por el segundo nodo. Enviar al segundo nodo, la información de transacción incluye el nuevo compromiso de moneda generado en base a la información de clave pública, la cantidad de transacción cifrada en base a la información de clave pública y la prueba de conocimiento cero. El segundo nodo verifica la cantidad de transacción cifrada en base a la información de clave pública. Si se pasa, la información de transacción se publica en la red de cadena de bloques para que el nodo minero verifique y registre la transacción. El nodo minero verifica el contenido de la prueba en el certificado de conocimiento cero. Si se pasa la verificación, se determina que la transacción es válida, la información de la transacción se registra en la cadena de bloques.
Ian Miers et al.: ''Zerocoin: Anonymous Distributed E-Cash from Bitcoin", Simposio de IEEE sobre seguridad y privacidad (SP) de 2013, IEEE, 19 de mayo de 2013, páginas 397-411, ISBN: 978-1-4673-6166-8 describe "Zerocoin", una extensión criptográfica de Bitcoin que aumenta el protocolo para permitir transacciones de divisa completamente anónimas. Zerocoin utiliza supuestos criptográficos estándar y no introduce nuevas partes de confianza ni cambia el modelo de seguridad de Bitcoin. El documento detalla la construcción criptográfica de Zerocoin, su integración en Bitcoin y examina su rendimiento tanto en términos de cálculo como de impacto en el protocolo Bitcoin.
Según el modelo de saldo de cuenta, los esquemas de compromiso se pueden utilizar para ocultar valores a los que se comprometen ambas partes de una transacción. Los esquemas de compromiso pueden surgir de la necesidad de que las partes se comprometan con una elección o valor, y luego comuniquen ese valor a las otras partes involucradas. Por ejemplo, en un esquema interactivo de Compromiso de Pedersen (PC), un primer usuario puede comprometerse con una cantidad t de transacción enviando un valor PC(t, r) de compromiso que se genera en base al valor r aleatorio. Se genera el valor de compromiso y un segundo usuario solo puede revelar la cantidad t de transacción obteniendo el número r aleatorio. Para asegurarse de que la cantidad de transacción sea válida, se puede crear una prueba de rango para probar que la cantidad de transacción es mayor o igual a cero y menor o igual que el saldo de la cuenta.
En algunos casos, se pueden realizar múltiples transacciones desde un usuario. Debido a que la prueba de rango está asociada con el saldo restante de la cuenta, es importante que las transacciones múltiples se verifiquen secuencialmente en la cadena de bloques. Como tal, las pruebas de rango correspondientes se pueden asociar correctamente con los saldos restantes de la cuenta después de cada una de las transacciones.
RESUMEN
Las implementaciones de la presente divulgación incluyen métodos implementados por computadora para verificaciones no interactivas que preservan la privacidad de las transacciones de cadena de bloques con prueba de conocimiento cero en base al modelo de billete de cuenta. Más particularmente, las implementaciones de la presente divulgación están dirigidas a validar transacciones entre cuentas de cadena de bloques bajo el modelo de billete de cuenta. En algunas implementaciones, en el modelo de billete de cuenta, los saldos de cuenta se almacenan como una agregación de billetes. De acuerdo con las implementaciones de la presente divulgación, la validación de la transacción se puede realizar en base a esquemas de compromiso y esquema de cifrado de clave pública o esquema de cifrado integrado sin revelar la cantidad de transacción, el valor de billete o números aleatorios para generar compromisos.
En algunas implementaciones, las acciones incluyen recibir, desde una primera cuenta, una copia firmada digitalmente de una pluralidad de identificadores (ID) de billete que identifican una pluralidad correspondiente de billetes, un compromiso de una cantidad de transacción de una transacción entre la primera cuenta y una segunda cuenta. pagado por al menos una parte de la pluralidad de billetes, un compromiso de un cambio de deducir la cantidad de transacción de un valor total de la pluralidad de billetes, un primer número aleatorio utilizado para generar el compromiso de la cantidad de transacción cifrada por una clave pública de la segunda cuenta, la cantidad de transacción cifrada por la clave pública de la segunda cuenta, un segundo número aleatorio utilizado para generar el compromiso del cambio cifrado por la clave pública de la primera cuenta, el cambio cifrado por la clave pública de la primera cuenta, una o más pruebas de rango y una prueba de conocimiento cero generada en base a uno o más números aleatorios seleccionados; verificar una firma digital correspondiente a la copia firmada digitalmente utilizando la clave pública de la primera cuenta; determinar que una o más pruebas de rango prueban que la cantidad de transacción y el cambio son mayores o iguales a cero; determinar que el valor total de la pluralidad de billetes es igual a la suma de la cantidad de transacción y del cambio; determinar si la cantidad de transacción en el compromiso es la misma que la cantidad de transacción que está cifrada, y si un número aleatorio utilizado para generar el compromiso de la cantidad de transacción es el mismo que el primer número aleatorio; y actualizar la primera cuenta y la segunda cuenta en base a la pluralidad de billetes, la cantidad de transacción y el cambio si la cantidad de transacción en el compromiso es la misma que la cantidad de transacción que está cifrada, y el número aleatorio utilizado para generar el compromiso de la cantidad de transacción es el mismo que el primer número aleatorio. Otras implementaciones incluyen sistemas, aparatos y programas informáticos correspondientes, configurados para realizar las acciones de los métodos codificados en dispositivos de almacenamiento informáticos.
Cada una de estas y otras implementaciones puede incluir opcionalmente una o más de las siguientes características: cada una de la pluralidad de billetes incluye uno o más de un tipo de billete, un compromiso de un valor de billete, el valor de billete cifrado mediante cifrado de clave pública o cifrado integrado; y un número aleatorio utilizado para generar el compromiso cifrado por el cifrado de clave pública o el cifrado integrado; determinar que cada una de la pluralidad de billetes tiene el mismo tipo de billete; el compromiso de la cantidad de transacción, el compromiso del cambio y el compromiso del valor de billete se generan utilizando un esquema de compromiso que es homomórfico; la determinación de si el valor total de la pluralidad de billetes es igual a la suma de la cantidad de transacción y del cambio es en base a comparar una suma del compromiso de cada uno de los valores de billete y una suma del compromiso de la cantidad de transacción y el compromiso del cambio; cada uno de la pluralidad de ID de billete incluye una dirección de transacción y un número de índice que indica un orden del billete correspondiente en la salida de transacción, y en donde la dirección de transacción se genera resumiendo la información de transacción de la transacción; determinar que cada uno de la pluralidad de ID de billetes está asociado con la primera cuenta; el primer número aleatorio y la cantidad de transacción están cifrados por una clave pública de la segunda cuenta en base al cifrado de Paillier o el cifrado de Okamoto-Uchiyama; la determinación de si la cantidad de transacción en el compromiso es la misma que la cantidad de transacción que está cifrada, y si un número aleatorio utilizado para generar el compromiso de la cantidad de transacción es el mismo que el primer número aleatorio es en base a una prueba de conocimiento cero sin interacciones entre la primera cuenta y la segunda cuenta fuera de la red de cadena de bloques.
La presente divulgación también proporciona uno o más medios de almacenamiento legibles por computadora no transitorios acoplados a uno o más procesadores y que tienen instrucciones almacenadas en los mismos que, cuando son ejecutadas por el uno o más procesadores, hacen que el uno o más procesadores realicen operaciones de acuerdo con implementaciones de los métodos proporcionados en el presente documento.
La presente divulgación proporciona además un sistema para implementar los métodos proporcionados en el presente documento. El sistema incluye uno o más procesadores, y un medio de almacenamiento legible por computadora acoplado al uno o más procesadores que tienen instrucciones almacenadas en el mismo que, cuando son ejecutadas por el uno o más procesadores, hacen que el uno o más procesadores realicen operaciones de acuerdo con las implementaciones de los métodos proporcionados en el presente documento.
Se aprecia que los métodos de acuerdo con la presente divulgación pueden incluir cualquier combinación de los aspectos y características descritos en el presente documento. Es decir, los métodos de acuerdo con la presente divulgación no se limitan a las combinaciones de aspectos y características descritas específicamente 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 presente divulgación se establecen en los dibujos adjuntos y la descripción a continuación. Otras características y ventajas de la presente divulgación resultarán evidentes a partir de la descripción y los dibujos, y de las reivindicaciones.
DESCRIPCION DE LOS DIBUJOS
La FIG. 1 representa un entorno de ejemplo que puede utilizarse para ejecutar implementaciones de la presente divulgación.
La FIG. 2 representa un ejemplo de arquitectura conceptual de acuerdo con implementaciones de la presente divulgación.
La FIG. 3 representa un proceso de ejemplo de validación protegida por privacidad de una transacción de cadena de bloques en base a un modelo de billete de cuenta de acuerdo con implementaciones de la presente divulgación.
La FIG. 4 representa una transacción de cadena de bloques de ejemplo en base al modelo de billete de cuenta de acuerdo con implementaciones de la presente divulgación.
La FIG. 5 representa un proceso de ejemplo que se puede ejecutar de acuerdo con implementaciones de la presente divulgación.
Los símbolos de referencia similares en los diversos dibujos indican elementos similares.
DESCRIPCIÓN DETALLADA
Las implementaciones de la presente divulgación incluyen métodos implementados por computadora para verificaciones no interactivas protegidas por privacidad de transacciones de cadena de bloques con prueba de conocimiento cero en base al modelo de billete de cuenta. Más particularmente, las implementaciones de la presente divulgación están dirigidas a validar transacciones entre cuentas de cadena de bloques bajo un modelo de billete de cuenta. En algunas implementaciones, en el modelo de billete de cuenta, los saldos de cuenta se almacenan como una agregación de billetes. De acuerdo con las implementaciones de la presente divulgación, la validación de la transacción se puede realizar en base a esquemas de compromiso y esquema de cifrado de clave pública o esquema de cifrado integrado sin revelar la cantidad de transacción, el valor de billete o números aleatorios para generar compromisos. En algunas implementaciones, las acciones incluyen recibir, desde una primera cuenta, una copia firmada digitalmente de una pluralidad de identificadores (ID) de billete que identifican una pluralidad correspondiente de billetes, un compromiso de una cantidad de transacción de una transacción entre la primera cuenta y una segunda cuenta. pagado por al menos una parte de la pluralidad de billetes, un compromiso de un cambio de deducir la cantidad de transacción de un valor total de la pluralidad de billetes, un primer número aleatorio utilizado para generar el compromiso de la cantidad de transacción cifrada por una clave pública de la segunda cuenta, la cantidad de transacción cifrada por la clave pública de la segunda cuenta, un segundo número aleatorio utilizado para generar el compromiso del cambio cifrado por la clave pública de la primera cuenta, el cambio cifrado por la clave pública de la primera cuenta, una o más pruebas de rango y una prueba de conocimiento cero generada en base a uno o más números aleatorios seleccionados; verificar una firma digital correspondiente a la copia firmada digitalmente utilizando la clave pública de la primera cuenta; determinar que una o más pruebas de rango prueban que la cantidad de transacción y el cambio son mayores o iguales a cero; determinar que el valor total de la pluralidad de billetes es igual a la suma de la cantidad de transacción y el cambio; determinar si la cantidad de transacción en el compromiso es la misma que la cantidad de transacción que está cifrada, y si un número aleatorio utilizado para generar el compromiso de la cantidad de transacción es el mismo que el primer número aleatorio; y actualizar la primera cuenta y la segunda cuenta en base a la pluralidad de billetes, la cantidad de transacción y el cambio si la cantidad de transacción en el compromiso es la misma que la cantidad de transacción que está cifrada, y el número aleatorio utilizado para generar el compromiso de la cantidad de transacción es el mismo que el primer número aleatorio.
Para proporcionar un contexto adicional para las implementaciones de la presente divulgación, y como se introdujo anteriormente, las redes de cadena de bloques, que también pueden denominarse redes de consenso (p. ej., compuestas por nodos de igual a igual), sistema de contabilidad distribuida o simplemente cadena de bloques, permiten que las entidades participantes realicen transacciones y almacenen datos de forma segura e inmutable. Una cadena de bloques se puede proporcionar como una cadena de bloques pública, una cadena de bloques privada o una cadena de bloques de consorcio. Las implementaciones de la presente divulgación se describen con más detalle en el presente documento con referencia a una cadena de bloques pública, que es pública entre las entidades participantes. Sin embargo, se contempla que las implementaciones de la presente divulgación se puedan realizar en cualquier tipo apropiado de cadena de bloques.
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. Un ejemplo de cadena de bloques pública incluye la cadena de bloques utilizada en la red Bitcoin, que es una red de pago de igual a igual (red de criptomonedas). Aunque el término cadena de bloques se hace referencia comúnmente a la red de Bitcoin, como se utiliza en el presente documento, cadena de bloques generalmente se refiere a libros de contabilidad distribuidos sin una referencia particular a la red de Bitcoin.
En general, una cadena de bloques pública soporta transacciones públicas. Una transacción pública se comparte con todos los nodos dentro de la cadena de bloques y la cadena de bloques se replica en todos los nodos. Es decir, todos los nodos están en perfecto estado de consenso con respecto al 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 dentro de la red de la cadena de bloques. Un ejemplo de protocolo de consenso incluye, sin limitación, prueba de trabajo (POW) implementado en la red Bitcoin.
Las implementaciones de la presente divulgación se describen con más detalle en el presente documento, en vista del contexto anterior. Más particularmente, y como se introdujo anteriormente, las implementaciones de la presente divulgación están dirigidas a validar transacciones entre cuentas de cadena de bloques bajo el modelo de billete de cuenta, donde los saldos de cuenta se almacenan como una agregación de billetes. En algunas implementaciones, y como se describe con más detalle en el presente documento, la validación de transacción se puede realizar en base a esquemas de compromiso y HE sin revelar la cantidad de transacción, el valor de billete o números aleatorios para generar compromisos.
De acuerdo con las implementaciones de la presente divulgación, los nodos de cadena de bloques pueden utilizar el modelo de billete de cuenta como método 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 billete de cuenta mantienen registros de una pluralidad de billetes en lugar de saldos de cuenta. Cada una de la pluralidad de billetes está asociada con un tipo de billete y un valor de billete. El tipo de billete puede ser un tipo de divisa o activo asociado con el billete. El tipo de divisa puede ser cualquier tipo de divisa real o criptomoneda. El valor de billete puede indicar el valor nominal de billete con el tipo de billete correspondiente.
Para proteger la privacidad de datos, las transacciones se pueden registrar en una cadena de bloques (libro mayor) en base al compromiso sin revelar la cantidad de transacción o la información de cantidad monetaria asociada con las cuentas de usuario de la cadena de bloques. Se puede utilizar un esquema de compromiso para generar un compromiso de una cantidad de transacción utilizando un número aleatorio. Un esquema de compromiso de ejemplo incluye, sin limitación, el esquema de Compromiso de Pedersen (PC). Debido a que la cantidad de transacción está oculta en el compromiso, se pueden utilizar una o más pruebas de rango para demostrar que la cantidad 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 rango están asociadas con el 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 rango pueden estar asociadas con saldos de cuenta incorrectos y, por lo tanto, pueden no ser válidas. En comparación, según el modelo de billete de cuenta, el valor de cuenta se calcula mediante la suma de una pluralidad de billetes. Cuando se va a transferir una cantidad de transacción entre cuentas de usuario de cadena de bloques, una parte de la pluralidad de billetes con un valor combinado mayor o igual que la cantidad de transacción se puede utilizar para realizar la transferencia. Se pueden realizar transferencias adicionales con la condición de que los billetes restantes, tengan un valor combianado mayor que las cantidades transferidas. Como tal, incluso si las transacciones no se validan y registran en la cadena de bloques, las pruebas de rango que muestran que el valor combinado de los billetes restantes es mayor o igual que la cantidad de transacción aún puede ser válido.
Para validar una transacción entre un usuario A (nodo) y un usuario B (nodo), por ejemplo, el usuario A puede cifrar la cantidad de transacción y el número aleatorio utilizando un esquema de cifrado de clave pública (p. ej., EIGamal) o esquema de cifrado integrado (p. ej., ECIES) en base a una clave pública del usuario B. La cantidad de transacción y el número aleatorio también se pueden utilizar para generar una prueba de conocimiento cero (ZKP) para validar la transacción. El compromiso de la transacción, la cantidad de transacción cifrada, el número aleatorio cifrado y la ZKP pueden utilizarse por un nodo de cadena de bloques para verificar si la transacción es válida. Durante el proceso de validación, el saldo de cuenta, la cantidad de transacción o el número aleatorio no necesitan ser revelados o enviados al usuario B.
La FIG. 1 representa un entorno 100 de ejemplo que puede utilizarse para ejecutar implementaciones de la presente divulgación. En algunos ejemplos, el entorno 100 de ejemplo permite a las entidades participar en una cadena 102 de bloques pública. El entorno 100 de ejemplo incluye sistemas 106, 108 informáticos y una red 110. En algunos ejemplos, la red 110 incluye una red de área local (LAN), red de área amplia (WAN), el Internet o una combinación de las mismas, y conecta sitios web, dispositivos de usuario (p. ej., dispositivos informáticos) y sistemas de servidor. 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, cada uno de los sistemas 106, 108 informáticos puede incluir cualquier sistema informático apropiado que permita la participación como un nodo en la cadena 102 de bloques pública. Los dispositivos informáticos de ejemplo incluyen, sin limitación, un servidor, una computadora de escritorio, una computadora portátil, un dispositivo informático tableta y un teléfono inteligente. En algunos ejemplos, los sistemas 106, 108 informáticos alojan uno o más servicios implementados por computadora para interactuar con la cadena 102 de bloques pública. Por ejemplo, el sistema 106 informático puede alojar servicios implementados por computadora de una primera entidad (p. ej., el usuario A), tal como un sistema de gestión de transacciones que utiliza la primera entidad para gestionar sus transacciones con una o más entidades (p. ej., otros usuarios). El sistema 108 informático puede alojar servicios implementados por computadora 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 una o más entidades (p. ej., otros usuarios) distintas. En el ejemplo de la FIG. 1, la cadena 102 de bloques pública se representa como una red de nodos de igual a igual, y los sistemas 106, 108 informáticos proporcionan nodos de la primera entidad y la segunda entidad, respectivamente, que participan en la cadena 102 de bloques pública.
La FIG. 2 representa un ejemplo de arquitectura 200 conceptual de acuerdo con implementaciones de la presente divulgación. La arquitectura 200 conceptual de ejemplo incluye una capa 202 de entidad, una capa 204 de servicios alojados y una capa 206 de cadena de bloques pública. En el ejemplo representado, la capa 202 de entidad incluye tres entidades, Entidad_1 (E1), Entidad_2 (E2) y Entidad_3 ( E3), teniendo cada una de las entidades un respectivo sistema 208 de gestión de transacciones.
En el ejemplo representado, la capa 204 de servicios alojados incluye interfaces 210 de cadena de bloques para cada uno de los sistemas 208 de gestión de transacciones. En algunos ejemplos, un respectivo sistema 208 de gestión de transacciones se comunica con una respectiva interfaz 210 de cadena de bloques a través de una red (p. ej., la red 110 de la FIG. 1) utilizando un protocolo de comunicaciones (p. ej., protocolo de transferencia de hipertexto seguro (HTTPS)). En algunos ejemplos, cada una de las interfaces 210 de cadena de bloques proporciona una conexión de comunicación entre un respectivo sistema 208 de gestión de transacciones y la capa 206 de cadena de bloques. Más particularmente, cada una de las interfaces 210 de cadena de bloques permite a la respectiva entidad realizar transacciones registradas en una red 212 de cadena de bloques de la capa 206 de cadena de bloques. En algunos ejemplos, la comunicación entre una interfaz 210 de cadena de bloques y la capa 206 de cadena de bloques se realiza utilizando llamadas a procedimientos remotos (RPC). En algunos ejemplos, las interfaces 210 de cadena de bloques "alojan" nodos de cadena de bloques para los respectivos sistemas 208 de gestión de transacciones. Por ejemplo, las interfaces 210 de cadena de bloques proporcionan la interfaz de programación de aplicaciones (API) para acceder a la red 212 de cadena de bloques.
Como se describe en el presente documento, la red 212 de cadena de bloques se proporciona como una red de igual a igual, que incluye una pluralidad de nodos 214 que registran información de manera inmutable en una cadena 216 de bloques. Aunque se representa esquemáticamente una única cadena 216 de bloques, se proporcionan múltiples copias de la cadena 216 de bloques y se mantienen a través de la red 212 de cadena de bloques. Por ejemplo, cada uno de los nodos 214 almacena una copia de la cadena 216 de bloques. En algunas implementaciones, la cadena 216 de bloques almacena información asociada con transacciones que se realizan entre dos o más entidades que participan en la cadena de bloques pública.
La FIG. 3 representa un método 300 de ejemplo de validación protegida por privacidad de una transacción de cadena de bloques en base a un modelo de billete de cuenta de acuerdo con implementaciones de la presente divulgación. En un nivel alto, el método 300 de ejemplo se realiza por un nodo 302 A de usuario, un nodo B de usuario (no mostrado en la FIG. 3) y un nodo 304 de cadena de bloques, también denominado nodo de consenso. Tanto la cuenta del nodo 302 A de usuario como la cuenta del nodo de usuario son en base al modelo de billete de cuenta. Es decir, las divisas del nodo 302 A de usuario y el nodo B de usuario se mantienen como una pluralidad de billetes. Se puede realizar una transacción, tal como una transferencia de valor, desde el nodo 302 A de usuario al nodo B de usuario. El nodo 302 A de usuario puede seleccionar un conjunto de billetes de su cuenta para cubrir la cantidad de transacción. La diferencia entre el valor total del conjunto de billetes y la cantidad de transacción se pueden calcular como cambio del nodo 302 A de usuario.
Para proteger la privacidad de la cuenta, el nodo 302 A de usuario puede generar un compromiso de una cantidad t de transacción utilizando un esquema de compromiso, tal como un PC, en base a un número r aleatorio. El nodo 302 A de usuario puede cifrar la cantidad de transacción y el número aleatorio utilizando un esquema de cifrado de clave pública o un esquema de cifrado integrado en base a una clave pública del nodo B de usuario. El nodo 302 A de usuario también puede cifrar el cambio y un número aleatorio correspondiente al cambio utilizando un esquema de cifrado de clave pública o esquema de cifrado integrado en base a la clave pública del nodo A de usuario. Para verificar la validez de la transacción, el nodo 304 de cadena de bloques puede verificar la cantidad de transacción y el número aleatorio cifrados con la correspondiente cantidad de transacción y número aleatorio en el compromiso en base a la ZKP. Si las cantidades de transacción y los números aleatorios coinciden, el nodo 304 de la cadena de bloques determina que la transacción es válida. Más detalles del método 300 de ejemplo se discuten en la siguiente descripción de la FIG. 3.
En 306, el nodo 302 A de usuario selecciona una pluralidad de billetes para transferir una cantidad de transacción al nodo B de usuario. El nodo 302 A de usuario y el nodo B de usuario pueden ser un nodo 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. Como se discutió anteriormente, el nodo 302 A de usuario puede utilizar un modelo de billete de cuenta para mantener registros. En lugar de mantener registrado el saldo de cuenta según el modelo de saldo de cuenta, el valor de cuenta del nodo 302 A de usuario se mide por el valor total de sus billetes. El nodo 302 A de usuario puede seleccionar una pluralidad de billetes de los billetes que tiene que sean suficientes para cubrir la cantidad de transacción. Por ejemplo, si la cantidad de transacción es 7,5 bitcoin, el nodo 302 A de usuario puede seleccionar tres billetes que valen 5, 2 y 1 bitcoin respectivamente para cubrir la cantidad de transacción.
En algunas implementaciones, cada uno de los billetes puede tener un tipo de billete que identifica el tipo de divisa o activo del billete. Cada uno de los billetes también puede tener un ID de billete que incluye un ID de transacción y un número de índice. El ID de transacción puede ser el resumen de la información de transacción. El índice puede indicar un orden del billete correspondiente en la salida de transacción. Por ejemplo, al enviar los tres billetes con una cantidad de 5, 2 y 1 bitcoin, el billete de 2 bitcoin puede ser la segunda salida de transacción con un número de índice de 2. En algunos ejemplos, se seleccionan k billetes, sus tipos de billete e ID de billete se pueden expresar como NoteType1, NoteIdaa1,..., NoteTypek, NoteIdak. En algunos ejemplos, se puede seleccionar el mismo tipo de billetes para realizar la transferencia de la cantidad de transacción. En algunos casos, los ID de billete correspondientes al cambio y la cantidad de transacción no se pueden obtener antes de que se cree la transacción. En tales casos, dichos identificadores de billete se pueden generar en de base un contrato de cadena de bloques que puede realizar actualizaciones de consenso y de contrato.
En 308, el nodo 302 A de usuario calcula un cambio en base al valor total de la pluralidad de billetes y la cantidad de transacción. Debido a que los billetes se seleccionan para tener un valor total mayor que la cantidad de transacción, el cambio se puede calcular como el valor total de los billetes seleccionados deducido por la cantidad de transacción. Utilizando t para representar la cantidad de transacción y tü para representar el cambio, el cálculo del cambio se puede expresar como t0 = ai ... ak - t, donde a1,..., ak son los valores de billete de k billetes seleccionados por el nodo 302 A de usuario para cubrir la cantidad t de transacción.
En 310, el nodo 302 A de usuario genera una pluralidad de números aleatorios correspondientes a la pluralidad de billetes y calcula un número aleatorio correspondiente al cambio. Se puede generar la pluralidad de números aleatorios para producir compromisos de los valores de los billetes. Por ejemplo, a1,..., ak son los valores de los billetes, y los números aleatorios que corresponden a los valores de los billetes se pueden expresar como ra1,... , rak. Los compromisos de los billetes se pueden expresar como PC(ra1, a1), ..., PC(rak, ak).
En algunas implementaciones, se puede calcular un número r0 aleatorio para que corresponda con el cambio t0. El cálculo se puede expresar como r0 = ra1 +... rak - r, donde r es el número aleatorio generado para producir un compromiso por la cantidad t de transacción. Al calcular r0 , el nodo 302 A de usuario no necesita generar una ZKP adicional para mostrar que el valor total de los billetes transferidos es igual al valor total de los billetes recibidos.
En 312, el nodo 302 A de usuario genera compromisos y textos cifrados de clave pública de la cantidad de transacción y del cambio. Para proteger la privacidad de los datos, los valores monetarios, incluidos los valores de billete, la cantidad de transacción y el cambio, pueden ocultarse mediante compromisos en base a esquemas de compromiso. La cadena de bloques puede mantener los compromisos como un registro. En algunas implementaciones, se pueden utilizar esquemas de compromiso homomórficos, tal como PC, para generar los compromisos. Utilizando el PC como un ejemplo no limitante, el PC de una transacción t se puede generar utilizando un número r aleatorio, que se puede expresar como T = PC(r, t) = grht, donde g y h pueden ser generadores de una curva elíptica, y PC(r, t) es una multiplicación escalar de puntos de la curva. Debe entenderse que otros esquemas de compromiso basados en HE, tal como el esquema de compromiso Fujisaki-Okamoto, también se pueden utilizar para generar el valor de compromiso.
La cantidad de transacción y el número aleatorio también se pueden cifrar utilizando la clave pública del nodo B de usuario. El cifrado puede basarse en un esquema de cifrado de clave pública, tal como el algoritmo de Paillier o de ElGamal, o un esquema de cifrado integrado tal como ECIES. Como tal, el nodo B de usuario puede utilizar su clave privada correspondiente para revelar la cantidad de transacción y el número aleatorio. El número aleatorio cifrado de la clave pública y la cantidad de transacción se pueden expresar como Pb = E(PkB, r), Qb = E(PkB, t), respectivamente, donde PkB representa la clave pública del nodo B de usuario.
De manera similar, el compromiso del cambio se puede expresar como T0 = PC(r0 , to). El número aleatorio r0 y la cantidad t0 de cambio también pueden cifrarse por la clave pública del nodo 302 de usuario A expresada como Pa = E(PkA, r0), Qa = E(PkA, to), respectivamente, donde PkA representa la clave pública del nodo 302 A de usuario.
En 314, el nodo 302 A de usuario genera una o más pruebas de rango. En algunas implementaciones, se puede generar una primera prueba RP1 de rango, para mostrar que la cantidad de transacción t > 0. Se puede generar una segunda prueba RP2 rango, para mostrar que el cambio t0 > 0, o, en otras palabras, el valor total de la pluralidad de billetes es mayor o igual a la cantidad de transacción.
En 316, el nodo 302 A de usuario genera una ZKP. En algunas implementaciones, la ZKP se puede utilizar para demostrar que el número r aleatorio y la cantidad t de transacción incluidos en Pb y Qb son iguales al número aleatorio correspondiente y a la cantidad de transacción incluidos en el compromiso T. En algunas implementaciones, la ZKP puede generarse utilizando argumento sucinto de conocimiento cero no interactivo (ZK-SNARK).
En 318, el nodo 302 A de usuario utiliza una clave privada para generar una firma digital de los datos de transacción. En algunas implementaciones, los datos de transacción pueden incluir NoteType1, NoteIda1,..., NoteTypek, Noteldak; Tü, T, Pb, Qb, Pa, Qa, RP1, RP2 y la ZKP.
En 320, el nodo 302 A de usuario envía la copia firmada digitalmente de los datos de transacción a una red de cadena de bloques.
En 322, el nodo 304 de cadena de bloques verifica la firma digital. La verificación de la firma digital puede garantizar que los datos de transacción sean enviados por el nodo 302 A de usuario.
En 324, el nodo 304 de cadena de bloques verifica el tipo de billete de la pluralidad de billetes. En otras palabras, el nodo 304 de cadena de bloques verifica que NoteType1 y NoteTypek sean iguales.
En 326, el nodo 304 de cadena de bloques verifica que el valor total de la pluralidad de billetes seleccionada es igual a la suma de la cantidad de transacción y del cambio. En otras palabras, la cadena de bloques verifica que a1 +... ak = t to. Como se discutió anteriormente, bajo el modelo de billete de cuenta, los billetes se pueden guardar en la cadena de bloques como PC para proteger la privacidad de los datos. En base al homomorfismo de PC, PC(ra1, a1) ... PC(rak, ak) = PC(ra1 + ... rak, a1 + ... ak), y PC(r, t) PC(ro, to) = PC(r ro, t to). Por lo tanto, al mostrar que PC(ra1, a1) ... PC(rak, ak) = PC(r, t) PC(ro, to), se puede probar que a1 +... ak = t to.
En 328, el nodo 304 de cadena de bloques verifica una o más pruebas de rango.
En 330, el nodo 304 de cadena de bloques verifica la ZKP, si la ZKP se verifica con éxito, la cantidad de transacción y el número aleatorio cifrados utilizando la clave pública del nodo B de usuario son los mismos que la cantidad de transacción y el número aleatorio correspondientes ocultos por el PC. Como se discutió anteriormente, la ZKP puede generarse utilizando zk-SNARK.
En algunas implementaciones, la ZKP también se puede generar en base a protocolos Sigma. Utilizando el cifrado de clave pública de Paillier como ejemplo, Pb y Qb se pueden expresar como Pb = E(PkB, r) = uryn, Qb = E(Pk, t) = utzn, respectivamente, donde u y n son claves públicas, y y z son números aleatorios.
Para generar la ZKP en base a protocolos Sigma, el nodo 302 A de usuario puede generar cuatro números r*, t*, y* y z* aleatorios adicionales para calcular tres textos C, D y E cifrados. C, D y E se pueden expresar como C = gr*ht*, D = ur*y*n, y E = ut*z*n. Un valor de resumen x se puede calcular resumiendo T, Pb, Qb, g, h, u, n, C, D, y E, que se puede expresar como x = Resumen(T, Pb, Qb, g, h, u, n, C, D, E). Se pueden calcular cuatro textos a, b, c y d cifrados adicionales como a = r* xr, b = t* xt, c = y*yx, d = z*zx. Finalmente, la ZKP se puede formar como ZKP = (C, D, E, a, b, c, d).
Para verificar la ZKP, el nodo 304 de cadena de bloques puede calcular primero x = Resumen(T, PB, QB, g, h, u, n, C, D, E). El nodo 304 de cadena de bloques puede verificar si gahb = CTx, uacn = DPx, y ubdn = EQx. Si es así, se verifica la ZKP y se prueba que la cantidad de transacción y el número aleatorio cifrados utilizando la clave pública del nodo B de usuario son los mismos que la cantidad de transacción correspondiente y el número aleatorio ocultos por el PC.
En otro ejemplo, el cifrado de clave pública de OU se puede utilizar para cifrar la cantidad de transacción y el número aleatorio. Pb y Qb se pueden expresar como Pb = E(PkB, r) = urvy, Qb = E(Pk, t) = utvz, respectivamente, donde u, v y n son las claves públicas, r, y y z son números aleatorios.
Para generar la ZKP en base a protocolos Sigma, el nodo 302 A de usuario puede generar cuatro números r*, t*, y* y z* aleatorios adicionales para calcular tres textos C, D y E cifrados. Los textos C, D, y E cifrados se puede calcular como C = gr*ht*, D = ur*v*y y E = ut*v*z. Un valor de resumen x se puede calcular resumiendo T, Pb, Qb, g, h, u, v, n, C, D y E, que se puede expresar como x = Resumen(T, Pb, Qb, g, h, u, v, n, C, D, E). Se pueden calcular cuatro textos a, b, c y d cifrados adicionales como a = r* xr, b = t* xt, c = y* xy, d = z* xz. Finalmente, la ZKP se puede formar como ZKP = (C, D, E, a, b, c, d).
Para verificar la ZKP, el nodo 304 de cadena de bloques puede calcular x = Resumen(T, Pb, Qb, g, h, u, v, n, C, D, E). El nodo 304 de cadena de bloques puede verificar si gahb = CTx, uavc = DPx y ubvd = EQx. Si es así, se verifica la ZKP y se prueba que la cantidad de transacción y el número aleatorio cifrados utilizando la clave pública del nodo B de usuario son los mismos que la cantidad de transacción y el número aleatorio correspondientes ocultos por el PC.
En 332, el nodo 304 de cadena de bloques verifica que la pluralidad de billetes pertenece al nodo 302 A de usuario. La verificación puede basarse en los ID de billete, Noteldai, donde i = 1,..., k.
En 334, el nodo 304 de cadena de bloques actualiza las cuentas del nodo 302 A de usuario y del nodo B de usuario.
Debido a que las cuentas del nodo 302 A de usuario y del nodo B de usuario mantienen billetes como registros bajo el modelo de billete de cuenta, después de la transacción, la pluralidad de billetes transferidos fuera del nodo 302 A de usuario se pueden eliminar de la cuenta del nodo 302 A de usuario. El cambio se puede volver a añadir a la cuenta del nodo A de usuario. La cantidad de transacción y el tipo de billete y el ID de billete correspondientes se pueden añadir como un nuevo billete a la cuenta del nodo B de usuario. La actualización de las cuentas se describe con más detalle en el presente documento con referencia a la FIG. 4.
La FIG. 4 representa una transacción 400 de cadena de bloques de ejemplo en base a un modelo de billete de cuenta de acuerdo con implementaciones de la presente divulgación. Como se muestra en la transacción 400 de cadena de bloques de ejemplo, un nodo 402 A de usuario transfiere una cantidad t de transacción a un nodo 404 B de usuario.
Antes de la transacción, el nodo 402 A de usuario tiene m billetes que incluyen NoteIda1, PC(ra1, a1), E(PkA, ra1), E(PkA, ai); NoteIda2, PC(ra2 , a2), E(PkA, ra2), E(PKa, a2); ... ; NoteIdam, PC(ram, am), E(PkA, ram), E(PKa, am).
Utilizando los esquemas de compromiso, esquemas de cifrado y proceso de transacción descritos en el presente documento con referencia a la FIG. 3 como ejemplo, el nodo 402 A de usuario genera los datos 408 de transacción, que pueden incluir ID de billete de los k billetes seleccionados y su tipo expresado como NoteType1, NoteIda1, ..., NoteTypek, NoteIdak. Los datos 408 de transacción pueden incluir además T0 , T, Pb, Qb, Pa, Qa, RP1, RP2 y la ZKP.
Después de que se generen los datos 408 de transacción, el nodo 402 A de usuario puede añadir su firma digital y enviar los datos de transacción firmados digitalmente a la red 406 de cadena de bloques para consenso.
Después de la transacción, los k billetes seleccionados se pueden eliminar de la cuenta del nodo 402 A de usuario. El cambio se puede volver a añadir al nodo 402 A de usuario. Por lo tanto, el nodo 402 A de usuario puede tener los siguientes billetes expresados como NoteIda(k+1), PC(ra(k+1), a(k+1)), E(PkA, ra(k+1)), E(PkA, a(k+1)),..., NoteIdam, PC(ram, am), E(PkA, ram), E(PkA, am), NoteIda(m+1), PC(r0 , tü), E(PkA, rü), E(PkA, tü), donde NoteIda(m+1) representa el ID de billete del cambio t0.
Antes de la transacción, el nodo 404 B de usuario tiene m billetes, que se pueden expresar como NoteIdb1, PC(rb1, b1), E(PkB, rb1), E(PkB, b1); NoteIdb2 , PC(rb2 , b2), E(PkB, M , E(PkB, b2); ... ; NoteIdbm, PC(rbm, bm), E(PkB, rbm), E(PkB, bm).
Después de la transacción, la cantidad de transacción se puede añadir al nodo 404 B de usuario. El nodo 404 B de usuario puede tener los siguientes billetes expresados como NoteIdb1, PC(rb1, b1), E(PkB, rb1), E(PkB, b1), ..., NoteIdbm, PC(rbm, bm), E(PkB, rbm), E(PkB, bm), NoteIdb(m+1), PC(r, t), E(PkB, r), E(PkB, t), donde NoteIdb(m+1) representa el ID de billete de la cantidad t de transacción.
La FIG. 5 representa un proceso 500 de ejemplo que puede ejecutarse de acuerdo con implementaciones de la presente divulgación. Para mayor claridad de presentación, la descripción que sigue describe generalmente el proceso
500 de ejemplo en el contexto de las otras figuras en esta descripción. Sin embargo, se entenderá que el proceso 500 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, diversos pasos del proceso 500 de ejemplo se pueden ejecutar en paralelo, en combinación, en bucles o en cualquier orden.
En 502, un nodo de consenso recibe, desde una primera cuenta, una copia firmada digitalmente de una pluralidad de
ID de billete que identifican una pluralidad correspondiente de billetes. En algunos ejemplos, los nodos de consenso pueden recibir además un compromiso de una cantidad de transacción de una transacción entre la primera cuenta y una segunda cuenta pagada por al menos una parte de la pluralidad de billetes. En algunos ejemplos, los nodos de consenso pueden recibir además un compromiso de cambio al deducir la cantidad de transacción de un valor total de la pluralidad de billetes. En algunos ejemplos, los nodos de consenso pueden recibir además un primer número aleatorio utilizado para generar el compromiso de la cantidad de transacción cifrada por una clave pública de la segunda cuenta, y la cantidad de transacción cifrada por la clave pública de la segunda cuenta. En algunos ejemplos, el nodo de consenso puede recibir además un segundo número aleatorio utilizado para generar el compromiso del cambio cifrado por la clave pública de la primera cuenta, el cambio cifrado por la clave pública de la primera cuenta, una o más pruebas de rango y una prueba de conocimiento cero generada en base a uno o más números aleatorios seleccionados.
En algunas implementaciones, cada uno de la pluralidad de billetes incluye uno o más de un tipo de billete, un compromiso de un valor de billete, el valor de billete cifrado mediante un esquema de cifrado de clave pública o un esquema de cifrado integrado, y un número aleatorio utilizado para generar el compromiso cifrado mediante un esquema de cifrado de clave pública o un esquema de cifrado integrado. En algunas implementaciones, el compromiso de la cantidad de transacción, el compromiso del cambio y el compromiso del valor de billete se generan utilizando un esquema de compromiso que es homomórfico. En algunas implementaciones, cada uno de la pluralidad de ID de billetes incluye una dirección de transacción y un número de índice que indica un orden del billete correspondiente en la salida de transacción, y en donde la dirección de la transacción se genera resumiendo la información de transacción de la transacción. En algunas implementaciones, el primer número aleatorio y la cantidad de transacción se cifran por una clave pública de la segunda cuenta en base a un esquema de cifrado tal como EIGamal, ECIES.
En 504, el nodo de consenso verifica una firma digital correspondiente a la copia firmada digitalmente utilizando la clave pública de la primera cuenta.
En 506, el nodo de consenso determina que una o más pruebas de rango prueban que la cantidad de transacción y el cambio son mayores o iguales a cero.
En 508, el nodo de consenso determina que el valor total de la pluralidad de billetes es igual a la suma de la cantidad de transacción y del cambio. En algunas implementaciones, determinar si el valor total de la pluralidad de billetes es igual a la suma de la cantidad de transacción y del cambio es en base a comparar una suma del compromiso de cada uno de los valores de billete y una suma del compromiso de la cantidad de transacción y del compromiso del cambio.
En 510, el nodo de consenso determina si la cantidad de transacción en el compromiso es la misma que la cantidad de transacción que está cifrada, y si un número aleatorio utilizado para generar el compromiso de la cantidad de transacción es el mismo que el primer número aleatorio. En algunas implementaciones, el nodo de consenso determina además que cada uno de la pluralidad de billetes tiene el mismo tipo de billete. En algunas implementaciones, el nodo de consenso determina además que cada uno de la pluralidad de ID de billete está asociado con la primera cuenta. En algunas implementaciones, determinar si la cantidad de transacción en el compromiso es la misma que la cantidad de transacción que está cifrada, y si un número aleatorio utilizado para generar el compromiso de la cantidad de transacción es el mismo que el primer número aleatorio es en base a prueba de conocimiento cero sin interacciones entre la primera cuenta y la segunda cuenta fuera de la red de cadena de bloques.
En 512, el nodo de consenso actualiza la primera cuenta y la segunda cuenta en base a la pluralidad de billetes, la cantidad de transacción y el cambio si la cantidad de transacción en el compromiso es la misma que la cantidad de transacción que está cifrada, y el número aleatorio utilizado para generar el compromiso de la cantidad de transacción es el mismo que el primer número aleatorio.
Las implementaciones de la materia objeto descrita en esta memoria descriptiva se pueden implementar para obtener ventajas o efectos técnicos particulares. Por ejemplo, las implementaciones de la presente divulgación permiten que el saldo de cuenta y la cantidad de transacción de los nodos de la cadena de bloques sean privados durante las transacciones. El destinatario de la 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 al esquema de cifrado de clave pública y los esquemas de compromiso para permitir una prueba de conocimiento cero.
La metodología descrita permite mejorar la seguridad de cuenta/datos de diversos dispositivos informáticos móviles. Los esquemas de compromiso pueden ocultar el saldo de las cuentas y las cantidades de transacción. Como tal, un nodo de consenso puede actualizar los saldos de cuenta en el libro mayor después de la transacción sin revelar el saldo 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 circuitería electrónica digital, o en software, firmware o hardware de computadora, incluidas las estructuras descritas en esta memoria descriptiva o en combinaciones de una o más de ellas. 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 computadora o recibidos desde otras fuentes. Un aparato, computadora o dispositivo informático de procesamiento de datos puede incluir aparatos, dispositivos y máquinas para procesar datos, incluyendo, a modo de ejemplo, un procesador programable, una computadora, un sistema en un chip, o múltiples o combinaciones de los anteriores. El aparato puede incluir circuitería lógica de propósito especial, por ejemplo, una unidad central de procesamiento (CPU), una matriz de puertas programables en campo (FPGA) o un circuito integrado de aplicación específica (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 del 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), un entorno de ejecución multiplataforma, una máquina virtual o una combinación de uno o más de ellos. El aparato y el entorno de ejecución pueden realizar diversas infraestructuras de modelos informáticos diferentes, tales como servicios web, informática distribuida e infraestructuras de computación en malla.
Un programa informático (también conocido, por ejemplo, como un 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 desplegar 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 parte 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 partes de código). Un programa informático se puede ejecutar en una computadora o en múltiples computadoras que están ubicadas en un sitio o distribuidas en múltiples sitios e interconectadas por una red de comunicaciones.
Los procesadores para la ejecución de un programa informático incluyen, a modo de ejemplo, microprocesadores tanto de uso general como especial, y uno o más procesadores de cualquier tipo de computadora digital. Generalmente, un procesador recibirá instrucciones y datos desde una memoria de solo lectura o una memoria de acceso aleatorio o ambas. Los elementos esenciales de una computadora son un procesador para realizar acciones de acuerdo con instrucciones y uno o más dispositivos de memoria para almacenar instrucciones y datos. Generalmente, una computadora también incluirá, o estará acoplada operativamente para recibir datos desde o transferir datos a, o ambos, uno o más dispositivos de almacenamiento masivo para almacenar datos. Una computadora puede integrarse 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. Los dispositivos adecuados para almacenar instrucciones y datos de programas informáticos incluyen memoria no volátil, dispositivos de medios y memoria, que incluyen, a modo de ejemplo, dispositivos de memoria semiconductores, discos magnéticos y discos magneto-ópticos. El procesador y la memoria pueden complementarse o incorporarse en circuitería lógica de propósito especial.
Los dispositivos móviles pueden incluir teléfonos, equipos de usuario (UE), teléfonos móviles (por ejemplo, teléfonos inteligentes), tabletas, dispositivos ponibles (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 pueden comunicarse de forma inalámbrica (por ejemplo, utilizando señales de radiofrecuencia (RF)) con diversas redes de comunicaciones (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, Wi-Fi y radios móviles), sensores térmicos u otros tipos de sensores. Por ejemplo, las cámaras pueden incluir una cámara orientada hacia adelante o hacia atrás con lentes móviles o fijas, un flash, un sensor de imagen y un procesador de imagen. La cámara puede ser una cámara de megapíxeles capaz de capturar detalles para reconocimiento facial y/o de iris. La cámara junto con un procesador de datos y la información de autenticación almacenada en memoria o al que se accede de forma remota pueden 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 de RF, se pueden utilizar para la autenticación del usuario.
Para proporcionar interacción con un usuario, las implementaciones se pueden implementar en una computadora 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 diodo orgánico emisor de luz (OLED)/realidad virtual (VR)/realidad aumentada (AR) para visualizar información al usuario y una pantalla táctil, un teclado y un dispositivo señalador mediante el cual el usuario puede proporcionar entrada a la computadora. También se pueden utilizar otros tipos de dispositivos para permitir 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, una computadora puede interactuar con un usuario enviando documentos a y recibiendo documentos desde un dispositivo que se utiliza 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 por cualquier forma o medio de comunicación de datos digital cableado o inalámbrico (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. Tales transacciones pueden ser en tiempo real, de manera que una acción y una respuesta sean próximas temporalmente; por ejemplo, un individuo percibe que la acción y la respuesta ocurren sustancialmente de forma simultánea, la diferencia de tiempo para una respuesta después de la acción del individuo es menos de 1 milisegundo (ms) o menos de 1 segundo (s), o la respuesta es sin retardo intencional teniendo en cuenta limitaciones de procesamiento de cuentas del sistema.
Los 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 comunicaciones puede incluir todo 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 estándares, 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. Las operaciones descritas y reivindicadas en un orden particular no deben entenderse como que requieren que el orden particular, ni que todas las operaciones ilustradas deban 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).
El alcance de la protección está definido por las reivindicaciones.

Claims (11)

REIVINDICACIONES
1. Un método (300, 500) implementado por computadora realizado por un nodo de consenso de una red de cadena de bloques, que comprende:
recibir (320, 502), desde una primera cuenta, una copia firmada digitalmente de una pluralidad de identificadores (ID) de billete que identifican una pluralidad correspondiente de billetes asociados con la primera cuenta, un compromiso de una cantidad de transacción de una transacción entre la primera cuenta y una segunda cuenta pagada por al menos una parte de la pluralidad de billetes, un compromiso de un cambio de deducir la cantidad de transacción de un valor total de la pluralidad de billetes, un primer número aleatorio utilizado para generar (312) el compromiso de la cantidad de transacción cifrada por una clave pública de la segunda cuenta, la cantidad de transacción cifrada por la clave pública de la segunda cuenta, un segundo número aleatorio utilizado para generar (312, 314, 316) el compromiso del cambio cifrado por la clave pública de la primera cuenta, el cambio cifrado por la clave pública de la primera cuenta, una pluralidad de pruebas de rango y una prueba de conocimiento cero generada (310) en base a uno o más números aleatorios seleccionados, en donde la pluralidad de las pruebas de rango incluyen una primera prueba (RP1) de rango generada (314) para demostrar que la cantidad de transacción es mayor o igual a cero, y una segunda prueba (RP2) de rango generada (314) para demostrar que la cantidad de cambio es mayor o igual a cero;
verificar (322, 504) una firma digital correspondiente a la copia firmada digitalmente utilizando la clave pública de la primera cuenta;
determinar (328, 506) que la pluralidad de pruebas de rango prueba que la cantidad de transacción y el cambio son mayores o iguales a cero;
determinar (326, 508) que el valor total de la pluralidad de billetes es igual a la suma de la cantidad de transacción y del cambio;
determinar (510) si la cantidad de transacción en el compromiso es la misma que la cantidad de transacción que está cifrada, y si un número aleatorio utilizado para generar el compromiso de la cantidad de transacción es el mismo que el primer número aleatorio; y
actualizar (334, 512) la primera cuenta y la segunda cuenta en base a la pluralidad de billetes, la cantidad de transacción y el cambio si la cantidad de transacción en el compromiso es la misma que la cantidad de transacción que está cifrada, y el número aleatorio utilizado para generar el compromiso de la cantidad de transacción es el mismo que el primer número aleatorio.
2. El método (300, 500) implementado por computadora de la reivindicación 1, en donde cada uno de la pluralidad de billetes incluye uno o más de un tipo de billete, un compromiso de un valor de billete, el valor de billete cifrado mediante cifrado de clave pública o cifrado integrado, y un número aleatorio utilizado para generar el compromiso cifrado mediante el cifrado de clave pública o el cifrado integrado.
3. El método (300, 500) implementado por computadora de la reivindicación 2, que comprende además determinar (324) que cada uno de la pluralidad de billetes tiene el mismo tipo de billete.
4. El método (300, 500) implementado por computadora de la reivindicación 2, en donde el compromiso de la cantidad de transacción, el compromiso del cambio y el compromiso del valor de billete se generan utilizando un esquema de compromiso que es homomórfico.
5. El método (300, 500) implementado por computadora de la reivindicación 4, en donde la determinación (326) si el valor total de la pluralidad de billetes es igual a la suma de la cantidad de transacción y del cambio es en base a comparar una suma del compromiso del valor de cada uno de los billetes y una suma del compromiso de la cantidad de transacción y del compromiso del cambio.
6. El método (300, 500) implementado por computadora de la reivindicación 1, en donde cada uno de la pluralidad de ID de billete incluye una dirección de transacción y un número de índice que indica un orden del billete correspondiente en la salida de transacción, y en donde se genera la dirección de transacción resumiendo información de transacción de la transacción.
7. El método (300, 500) implementado por computadora de la reivindicación 1, que comprende además determinar que cada uno de la pluralidad de ID de billete está asociado con la primera cuenta.
8. El método (300, 500) implementado por computadora de la reivindicación 1, en donde el primer número aleatorio y la cantidad de transacción se cifran por una clave pública de la segunda cuenta en base a cifrado de Paillier o cifrado de Okamoto-Uchiyama.
9. El método (300, 500) implementado por computadora de la reivindicación 1, en donde la determinación de si la cantidad de transacción en el compromiso es la misma que la cantidad de transacción que está cifrada, y si un número aleatorio utilizado para generar el compromiso de la cantidad de transacción es el mismo que el primer número aleatorio, se basan en pruebas de conocimiento cero sin interacciones entre la primera cuenta y la segunda cuenta fuera de la red de cadena de bloques.
10. Un medio de almacenamiento legible por computadora no transitorio acoplado a uno o más procesadores y que tiene instrucciones almacenadas en el mismo que, cuando son ejecutadas por el uno o más procesadores, hacen que el uno o más procesadores realicen operaciones de acuerdo con el método (300, 500) de una o más de las reivindicaciones 1-9.
11. Un sistema que comprende:
un dispositivo informático; y
un dispositivo de almacenamiento legible por computadora acoplado al dispositivo informático y que tiene instrucciones almacenadas en el mismo que, cuando son ejecutadas por el dispositivo informático, hacen que el dispositivo informático realice operaciones de acuerdo con el método (300, 500) de una o más de las reivindicaciones 1-9.
ES18867086T 2018-11-07 2018-11-07 Protección de datos de cadena de bloques en base al modelo de billete de cuenta con prueba de conocimiento cero Active ES2863559T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2018/114420 WO2019072268A2 (en) 2018-11-07 2018-11-07 BLOCK CHAIN DATA PROTECTION BASED ON A TICKET MODEL FROM ACCOUNTS USING ZERO KNOWLEDGE PROOF

Publications (1)

Publication Number Publication Date
ES2863559T3 true ES2863559T3 (es) 2021-10-11

Family

ID=66100031

Family Applications (1)

Application Number Title Priority Date Filing Date
ES18867086T Active ES2863559T3 (es) 2018-11-07 2018-11-07 Protección de datos de cadena de bloques en base al modelo de billete de cuenta con prueba de conocimiento cero

Country Status (17)

Country Link
US (1) US20190251553A1 (es)
EP (2) EP3829104B1 (es)
JP (1) JP6817429B2 (es)
KR (1) KR102215773B1 (es)
CN (1) CN110419055B (es)
AU (1) AU2018347190B2 (es)
BR (1) BR112019008160B1 (es)
CA (1) CA3041160C (es)
ES (1) ES2863559T3 (es)
MX (1) MX2019004658A (es)
PH (1) PH12019500890A1 (es)
PL (1) PL3542336T3 (es)
RU (1) RU2729595C1 (es)
SG (1) SG11201903586SA (es)
TW (1) TW202018572A (es)
WO (1) WO2019072268A2 (es)
ZA (1) ZA201902549B (es)

Families Citing this family (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11777729B2 (en) 2017-01-20 2023-10-03 Enveil, Inc. Secure analytics using term generation and homomorphic encryption
US20180212753A1 (en) 2017-01-20 2018-07-26 Enveil, Inc. End-To-End Secure Operations Using a Query Vector
US11507683B2 (en) 2017-01-20 2022-11-22 Enveil, Inc. Query processing with adaptive risk decisioning
US11196541B2 (en) 2017-01-20 2021-12-07 Enveil, Inc. Secure machine learning analytics using homomorphic encryption
US10644876B2 (en) * 2017-01-20 2020-05-05 Enveil, Inc. Secure analytics using homomorphic encryption
US10972251B2 (en) 2017-01-20 2021-04-06 Enveil, Inc. Secure web browsing via homomorphic encryption
CN111899001A (zh) * 2018-08-30 2020-11-06 创新先进技术有限公司 基于区块链的汇款方法及装置
US10902133B2 (en) 2018-10-25 2021-01-26 Enveil, Inc. Computational operations in enclave computing environments
BR112019008151A2 (pt) * 2018-11-07 2019-09-10 Alibaba Group Holding Ltd método implementado por computador, meio de armazenamento legível por computador não transitório e sistema
US10817262B2 (en) 2018-11-08 2020-10-27 Enveil, Inc. Reduced and pipelined hardware architecture for Montgomery Modular Multiplication
US10721217B2 (en) * 2018-11-08 2020-07-21 Accenture Global Solutions Limited Cryptographic datashare control for blockchain
CN110473105B (zh) * 2019-08-20 2024-01-16 深圳市迅雷网络技术有限公司 一种区块链交易结算方法、系统及相关设备
CN113065951A (zh) * 2020-01-02 2021-07-02 苏州同济区块链研究院有限公司 基于区块链的交易方法、系统、装置、设备及介质
CN111433799B (zh) * 2020-02-03 2022-03-25 支付宝(杭州)信息技术有限公司 基于区块链的可信保函
CN113826134B (zh) 2020-02-03 2024-05-28 支付宝(杭州)信息技术有限公司 基于区块链的可信保函
EP3799644B1 (en) 2020-02-03 2022-11-02 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain-based trustable guarantees
WO2020098835A2 (en) 2020-02-03 2020-05-22 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain-based trustable gurantees
SG11202012851YA (en) * 2020-02-03 2021-01-28 Alipay Hangzhou Inf Tech Co Ltd Blockchain-based trustable guarantees
CN111373431B (zh) * 2020-02-03 2022-06-07 支付宝(杭州)信息技术有限公司 基于区块链的可信保函
WO2020098833A2 (en) * 2020-02-03 2020-05-22 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain-based trustable gurantees
US11483154B2 (en) * 2020-02-19 2022-10-25 International Business Machines Corporation Artificial intelligence certification of factsheets using blockchain
CN111523892B (zh) * 2020-04-23 2021-07-27 深圳前海微众银行股份有限公司 一种区块链的跨链交易方法及装置
SG11202103226UA (en) 2020-06-08 2021-04-29 Alipay Labs Singapore Pte Ltd Blockchain-based smart contract pools
WO2020169125A2 (en) 2020-06-08 2020-08-27 Alipay Labs (singapore) Pte. Ltd. Blockchain-based document registration for custom clearance
CN111989707B (zh) 2020-06-08 2024-04-16 支付宝实验室(新加坡)有限公司 管理基于区块链的海关清关服务的用户权限
WO2020169127A2 (en) 2020-06-08 2020-08-27 Alipay Labs (singapore) Pte. Ltd. User management of blockchain-based custom clearance service platform
EP3837617B1 (en) 2020-06-08 2023-08-02 Alipay Labs (Singapore) Pte. Ltd. Distributed storage of custom clearance data
SG11202102402QA (en) 2020-06-08 2021-04-29 Alipay Labs Singapore Pte Ltd Blockchain-based import custom clearance data processing
CN111861714A (zh) * 2020-07-23 2020-10-30 浙江永旗区块链科技有限公司 企业票据拆分方法及系统
DE102020119569B3 (de) 2020-07-24 2021-12-09 Infineon Technologies Ag Bereitstellen einer kryptografischen Information
CN114338028A (zh) * 2020-09-28 2022-04-12 华为技术有限公司 门限签名方法、装置、电子设备和可读存储介质
EP4226573A1 (en) 2020-10-05 2023-08-16 Redcom Laboratories, Inc. Zkmfa: zero-knowledge based multi-factor authentication system
US11601258B2 (en) 2020-10-08 2023-03-07 Enveil, Inc. Selector derived encryption systems and methods
CN112287040B (zh) * 2020-10-30 2022-11-04 深圳前海微众银行股份有限公司 一种基于区块链的权益合并方法、装置、设备及介质
CN112436944B (zh) * 2020-11-06 2023-04-07 深圳前海微众银行股份有限公司 一种基于pow的区块链共识方法及装置
IT202000026488A1 (it) 2020-11-09 2021-02-09 Primecash S R L Metodo e sistema innovativo per pagamenti con denaro digitale e applicazione sulla blockchain
CN112487468B (zh) * 2020-12-21 2023-11-03 暨南大学 基于区块链的可追踪的完全匿名电子投票方法及系统
CN112633890B (zh) * 2020-12-22 2024-04-05 深圳前海微众银行股份有限公司 一种基于区块链的隐匿权益证明的验证方法及装置
CN112734423A (zh) * 2020-12-31 2021-04-30 杭州趣链科技有限公司 一种基于区块链的交易方法及终端设备
WO2022153377A1 (ja) * 2021-01-13 2022-07-21 富士通株式会社 制御方法、情報処理システム、情報処理装置および制御プログラム
CN112749967B (zh) * 2021-01-19 2024-07-30 矩阵元技术（深圳）有限公司 交易数据的处理方法、装置、用户终端和服务器
CN113037492B (zh) * 2021-02-04 2023-07-25 精英数智科技股份有限公司 传感器数据处理方法及装置
CN113630411B (zh) * 2021-08-05 2022-04-05 华中农业大学 一种对联盟区块链上多方隐私保护数据审计的方法及装置
CN113627910A (zh) * 2021-09-03 2021-11-09 杭州复杂美科技有限公司 一种区块链匿名红包发送方法、设备及储存介质
CN113627911A (zh) * 2021-09-03 2021-11-09 杭州复杂美科技有限公司 一种基于区块链匿名收发红包的方法、设备及储存介质
CN113570373B (zh) * 2021-09-23 2022-02-11 北京理工大学 一种基于区块链的可追责交易方法及系统
CN113988865B (zh) * 2021-12-29 2022-03-29 国网电子商务有限公司 电力结算隐私保护方法及装置
CN115660679B (zh) * 2022-10-14 2023-07-14 重庆移通学院 一种基于哈希锁定的去中心化安全交易方法
CN116633548A (zh) * 2023-04-03 2023-08-22 北京熠智科技有限公司 加密过程监管方法、装置、系统及存储介质

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5999625A (en) * 1997-02-27 1999-12-07 International Business Machines Corporation Method for electronic payment system with issuer control
EP2151947A1 (en) * 2008-08-05 2010-02-10 Irdeto Access B.V. Signcryption scheme based on elliptic curve cryptography
JP2010039890A (ja) * 2008-08-07 2010-02-18 Hitachi Ltd 認証端末、認証サーバ、認証システム、認証方法および認証プログラム
US8515058B1 (en) * 2009-11-10 2013-08-20 The Board Of Trustees Of The Leland Stanford Junior University Bootstrappable homomorphic encryption method, computer program and apparatus
CN105745678B (zh) * 2013-09-20 2022-09-20 维萨国际服务协会 包括消费者认证的安全远程支付交易处理
US11062303B2 (en) * 2015-06-08 2021-07-13 Blockstream Corporation Cryptographically concealing amounts transacted on a ledger while preserving a network's ability to verify the transaction
US10693658B2 (en) * 2016-02-12 2020-06-23 Visa International Service Association Methods and systems for using digital signatures to create trusted digital asset transfers
JP6663809B2 (ja) * 2016-07-07 2020-03-13 株式会社日立製作所 監査装置、監査機能付匿名送金方法及びプログラム
CN106911470B (zh) * 2017-01-23 2020-07-07 北京航空航天大学 一种比特币交易隐私增强方法
WO2018194736A1 (en) * 2017-04-18 2018-10-25 Tbcasoft, Inc. Anonymity and traceability of digital property transactions on a distributed transaction consensus network
US20190108517A1 (en) * 2017-10-06 2019-04-11 Allocrypt, Llc Digital currency for performing cash-equivalent transactions
CN107862216B (zh) * 2017-10-13 2021-04-06 布比（北京）网络技术有限公司 用于匿名跨链交易的隐私保护方法、装置和存储介质
CN107888375A (zh) * 2017-11-08 2018-04-06 深圳市携网科技有限公司 一种基于区块链技术的电子证据保全系统及方法
CN108021821A (zh) * 2017-11-28 2018-05-11 北京航空航天大学 多中心区块链交易隐私保护系统及方法
CN108418689B (zh) * 2017-11-30 2020-07-10 矩阵元技术（深圳）有限公司 一种适合区块链隐私保护的零知识证明方法和介质
CN108764874B (zh) * 2018-05-17 2021-09-07 深圳前海微众银行股份有限公司 基于区块链的匿名转账方法、系统及存储介质

Also Published As

Publication number Publication date
RU2729595C1 (ru) 2020-08-11
EP3542336A2 (en) 2019-09-25
KR20200054131A (ko) 2020-05-19
WO2019072268A3 (en) 2019-08-22
US20190251553A1 (en) 2019-08-15
BR112019008160A2 (pt) 2019-09-10
EP3542336A4 (en) 2019-11-20
WO2019072268A2 (en) 2019-04-18
CA3041160A1 (en) 2019-04-18
EP3829104B1 (en) 2022-07-06
JP2020503718A (ja) 2020-01-30
ZA201902549B (en) 2019-12-18
EP3829104A1 (en) 2021-06-02
KR102215773B1 (ko) 2021-02-17
AU2018347190A1 (en) 2020-05-21
BR112019008160B1 (pt) 2021-08-24
TW202018572A (zh) 2020-05-16
AU2018347190B2 (en) 2020-10-22
PH12019500890A1 (en) 2019-11-25
PL3542336T3 (pl) 2021-07-12
JP6817429B2 (ja) 2021-01-20
MX2019004658A (es) 2019-08-12
CN110419055B (zh) 2023-08-22
CA3041160C (en) 2022-11-29
EP3542336B1 (en) 2021-01-27
SG11201903586SA (en) 2019-05-30
CN110419055A (zh) 2019-11-05

Similar Documents

Publication Publication Date Title
ES2863559T3 (es) Protección de datos de cadena de bloques en base al modelo de billete de cuenta con prueba de conocimiento cero
ES2880458T3 (es) Protección de datos de cadena de bloques basada en un modelo de cuenta genérico y un cifrado homomórfico
ES2876926T3 (es) Protección de datos de cadena de bloques utilizando cifrado homomórfico
ES2881319T3 (es) Protección de datos de cadena de bloques mediante cifrado homomórfico
EP3566197B1 (en) Blockchain data protection based on generic account model and homomorphic encryption