BR112019016474A2 - método implementado por computador, meio de armazenamento não transitório legível por computador e sistema - Google Patents

método implementado por computador, meio de armazenamento não transitório legível por computador e sistema Download PDF

Info

Publication number
BR112019016474A2
BR112019016474A2 BR112019016474-0A BR112019016474A BR112019016474A2 BR 112019016474 A2 BR112019016474 A2 BR 112019016474A2 BR 112019016474 A BR112019016474 A BR 112019016474A BR 112019016474 A2 BR112019016474 A2 BR 112019016474A2
Authority
BR
Brazil
Prior art keywords
transaction
random number
node
commitment
assets
Prior art date
Application number
BR112019016474-0A
Other languages
English (en)
Inventor
Wenbin Zhang
Baoli Ma
Huanyu Ma
Original Assignee
Alibaba Group Holding Limited
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 Alibaba Group Holding Limited filed Critical Alibaba Group Holding Limited
Publication of BR112019016474A2 publication Critical patent/BR112019016474A2/pt

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3218Cryptographic 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102Entity profiles
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/123Applying verification of the received information received data contents, e.g. message integrity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/126Applying verification of the received information the source of the received data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/008Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving homomorphic encryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3236Cryptographic 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/3239Cryptographic 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic 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/3247Cryptographic 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)

Abstract

MÉTODO IMPLEMENTADO POR COMPUTADOR, MEIO DE ARMAZENAMENTO NÃO TRANSITÓRIO LEGÍVEL POR COMPUTADORE SISTEMA. As implementações da invenção incluem o recebimento de dados de transação associados à transação, os dados da transação compreendendo: dados representativos de uma pluralidade de ativos, um primeiro compromisso que oculta um primeiro número aleatório e um valor de transação da transação, um segundo compromisso que oculta um segundo número aleatório e uma alteração, o valor da transação e um terceiro número aleatório ambos criptografados por uma chave pública do segundo nó com base em um esquema de criptografia homomórfica probabilística (HE), a alteração e um quarto número aleatório ambos criptografados por uma chave pública do primeiro nó com base no esquema HE probabilístico e uma prova de conhecimento zero (ZKP); determinar, com base no ZKP, se a transação é válida com base na determinação se o primeiro número aleatório é igual ao terceiro número aleatório, o segundo número aleatório é igual ao quarto número aleatório e o valor da transação oculto no primeiro compromisso é igual à quantidade de transação criptografada pela chave pública do segundo nó.

Description

“MÉTODO IMPLEMENTADO POR COMPUTADOR, MEIO DE ARMAZENAMENTO NÃO TRANSITÓRIO LEGÍVEL POR COMPUTADOR E SISTEMA” ANTECEDENTES DA INVENÇÃO
[001] As redes de protocolo de confiança (blockchain), que também podem ser chamadas de sistemas de protocolo de confiança, redes de consenso, redes de sistema de contabilidade distribuída ou protocolo de confiança, permitem que as entidades participantes armazenem dados de forma segura e imutável. Um protocolo de confiança pode ser descrito como um registro de transações e várias cópias do protocolo de confiança são armazenadas através de uma rede de protocolo de confiança. Exemplos de tipos de protocolos de confiança podem incluir protocolos de confiança públicos, protocolos de confiança do consórcio e protocolos de confiança privados. Um protocolo de confiança público está aberto para todas as entidades usarem o protocolo de confiança e participarem do processo de consenso. Um protocolo de confiança de consórcio é um protocolo de confiança onde o processo de consenso é controlado por um conjunto pré- selecionado de nós, tais como certas organizações ou instituições. Um protocolo de confiança privado é fornecido para uma entidade privada, que controla centralmente as permissões de leitura e gravação.
[002] Os protocolos de confiança podem usar modelos de manutenção de registros diferentes para registrar transações entre usuários.
Exemplos de modelos de manutenção de registros incluem o modelo de saída de transação não utilizada (UTXO) e o modelo de saldo da conta. No modelo UTXO, cada transação gasta a saída de transações anteriores e gera novas saídas que podem ser gastas em transações subsequentes. As transações não gastas de um usuário são rastreadas e um saldo disponível para gastar é calculado como a soma das transações não gastas. No modelo de saldo da conta, o saldo da conta de cada usuário é rastreado como um estado global.
Para cada transação, um saldo de uma conta de despesas é verificado para garantir que seja maior ou igual ao valor da transação. Isso é comparável ao banco tradicional.
[003] Um protocolo de confiança inclui uma série de blocos, cada um contendo uma ou mais transações executadas na rede. Cada bloco pode ser convertido em uma página do registro, enquanto o protocolo de confiança em si é uma cópia completa do registro. Transações individuais são confirmadas e adicionadas a um bloco, que é adicionado ao protocolo de confiança. Cópias do protocolo de confiança são replicadas por meio de nós da rede. Desta forma, existe um consenso global sobre o estado do protocolo de confiança. Além disso, o protocolo de confiança está aberto para todos os nós verem, pelo menos no caso de redes públicas. Para proteger a privacidade dos usuários do protocolo de confiança, as tecnologias de criptografia são implementadas.
[004] No modelo de saldo da conta, os esquemas de comprometimento podem ser usados para ocultar valores com os quais ambas as partes de uma transação se comprometem. Os esquemas de compromisso podem surgir da necessidade de as partes se comprometerem com uma escolha ou valor e, posteriormente, comunicar esse valor às outras partes envolvidas. Por exemplo, em um esquema interativo de compromisso Pedersen (PC), um primeiro usuário poderá submeter a um valor da transação t, enviando um valor compromisso PC (t, r) que é gerado com base em um valor aleatório r. O valor de compromisso é gerado e um segundo usuário pode apenas revelar o valor da transação t obtendo o número aleatório r. Para garantir que o valor da transação seja válido, uma prova de intervalo pode ser criada para provar que o valor da transação é maior ou igual a zero e menor ou igual ao saldo da conta.
[005] Em alguns casos, várias transações podem ser feitas de um usuário. Como a prova do intervalo está associada ao saldo restante da conta, as várias transações precisam ser verificadas sequencialmente no protocolo de confiança. Como tal, as provas de intervalo correspondentes podem ser corretamente associadas aos saldos remanescentes da conta após cada transação. No entanto, verificar várias transações sequencialmente pode consumir muito tempo. Um modelo de manutenção de registros que permita verificações paralelas de transações seria vantajoso, especialmente para tarefas sensíveis ao tempo.
DESCRIÇÃO RESUMIDA DA INVENÇÃO
[006] As implementações da invenção incluem métodos implementados por computador para verificações de preservação da privacidade não interativas de transações de protocolo de confiança. Mais particularmente, as implementações da invenção são direcionados para um método implementado por computador capaz de validar múltiplas transações associadas a uma conta de um nó de protocolo de confiança em paralelo, baseado em esquemas de comprometimento e criptografia homomórfica sem revelar informação privada, tais como valor da transação, saldo em conta, ou números aleatórios para gerar compromissos, para outros nós do protocolo de confiança.
[007] Em algumas implementações, as ações incluem receber dados da transação associado com a transação, os dados da transação compreendem: dados representativos de uma pluralidade de ativos, um primeiro compromisso que esconde um primeiro número aleatório e o valor da transação de uma transação, um segundo compromisso que oculta um segundo número aleatório e uma alteração calculada com base na dedução do valor da transação de um valor total da pluralidade de ativos, o valor da transação e um terceiro número aleatório, ambos criptografados por uma chave pública do segundo nó baseado em um esquema de criptografia homomórfica probabilística (HE), a alteração e um quarto número aleatório, ambos criptografados por uma chave pública do primeiro nó com base no esquema probabilístico HE, uma ou mais provas de intervalo, uma prova de conhecimento zero (ZKP) e uma assinatura digital gerada com base em uma chave privada correspondente à chave pública do primeiro nó; verificar a assinatura digital com base na chave pública do primeiro nó; Determinar que uma ou mais provas de alcance comprovam que o valor da transação e a alteração são cada um maior ou igual a zero; determinar que o valor total da pluralidade de ativos é igual à soma do valor da transação e da alteração; e determinar, com base no ZKP, que a transação é válida determinando que o primeiro número aleatório é igual ao terceiro número aleatório, o segundo número aleatório é igual ao quarto número aleatório, e o valor da transação oculto no primeiro compromisso é igual à quantidade de transação criptografada pela chave pública do segundo nó. Outras implementações incluem sistemas, aparelhos e programas de computador correspondentes, configurados para executar as ações dos métodos, codificados em dispositivos de armazenamento de computador.
[008] Essas e outras implementações podem incluir, opcionalmente, um ou mais dos seguintes ativos: a transação é executada entre uma conta associada ao primeiro nó e uma conta associada ao segundo nó, e o método compreende ainda a atualização, após determinar que a transação é válida, a conta do primeiro nó e a conta do segundo nó são baseadas no valor da transação e da alteração; cada pluralidade de ativos está associado a um ou mais tipos de ativos, um valor de ativo oculto em um comprometimento, e um número aleatório usado para gerar o comprometimento; determinando que cada pluralidade de ativos está associada a um mesmo tipo de ativo; o primeiro compromisso, o segundo compromisso e o compromisso que oculta o valor do ativo são gerados com base em um esquema de compromisso que é homomórfico, em que a determinação de que o valor total da pluralidade de ativos é igual à soma do valor da transação e a alteração é realizada com base no homomorfismo do esquema de comprometimento; o terceiro número aleatório é criptografado com base no esquema probabilístico HE, tratando o valor da transação como um número aleatório, e o quarto número aleatório é criptografado com base no esquema probabilístico HE, tratando a alteração como um número aleatório; o primeiro compromisso e o segundo compromisso são gerados com base no esquema de comprometimento de Pedersen, e o esquema probabilístico HE é um esquema de criptografia de Okamoto-Uchiyama (OU); o ZKP compreende um compromisso Pedersen que oculta um quinto número aleatório e um sexto número aleatório, um texto cifrado do quinto número aleatório e o sexto número aleatório criptografado pela chave pública da segunda conta com base no esquema de criptografia UO, e um texto cifrado de o quinto número aleatório e o sexto número aleatório criptografado pela chave pública da primeira conta com base no esquema de criptografia da UO; o ZKP é gerado e usado para determinar se a transação é válida com base nas propriedades probabilísticas HE; a determinação de que a transação é válida é realizada com base ZKP sem interações entre o primeiro e o segundo nó através da rede de fora do protocolo de confiança.
[009] A especificação também fornece uma ou mais mídias de armazenamento não transitórias legíveis por computador acopladas a um ou mais processadores e tendo instruções armazenadas nela que, quando executadas por um ou mais processadores, fazem com que um ou mais processadores executem operações de acordo com implementações dos métodos aqui fornecidos.
[0010] A especificação fornece ainda um sistema para implementar os métodos aqui fornecidos. O sistema inclui um ou mais processadores, e um suporte de armazenamento legível por computador acoplado a um ou mais processadores tendo instruções armazenadas nele que, quando executados por um ou mais processadores, fazem com que um ou mais processadores executem operações de acordo com implementações dos métodos aqui fornecidos.
[0011] As implementações do assunto descrito nesta descrição podem ser implementadas de modo a realizar vantagens particulares ou efeitos técnicos. Por exemplo, implementações da invenção permitem que o saldo da conta e o valor da transação dos nós do protocolo de confiança sejam privados durante as transações. O destinatário da transferência de fundos não precisa confirmar a transação ou usar um número aleatório para verificar um compromisso, a validação da transação pode ser não interativa. Um nó do protocolo de confiança pode validar a transação com base nos esquemas HE e de comprometimento para permitir a prova de conhecimento zero.
[0012] A metodologia descrita permite o aprimoramento da segurança de conta/dados de vários dispositivos de computação móvel. O saldo das contas e os valores das transações podem ser criptografados com base em HE e ocultados por esquemas de comprometimento. Assim sendo, um nó de consenso pode atualizar os saldos de conta no registro após a transação com base nas propriedades do HE, sem revelar o saldo atual da conta. Como o número aleatório não precisa ser enviado a um destinatário para confirmar a transação, o risco de vazamento de dados pode ser reduzido e menos ativos de computação e memória precisam ser usados para gerenciar o número aleatório.
[0013] Entende-se que os métodos de acordo com a especificação podem incluir qualquer combinação dos aspectos e características aqui descritas. Ou seja, os métodos de acordo com a especificação não estão limitados às combinações de aspectos e características especificamente descritos aqui, mas também incluem qualquer combinação dos aspectos e características fornecidos.
[0014] Os detalhes de uma ou mais implementações da invenção são apresentados nos desenhos anexos e na descrição abaixo. Outras características e vantagens da invenção serão evidentes a partir da descrição e desenhos, e das reivindicações.
DESCRIÇÃO DOS DESENHOS
[0015] A Figura 1 ilustra um exemplo de um ambiente que pode ser usado para executar implementações da invenção.
[0016] A Figura 2 descreve um exemplo de uma arquitetura conceitual de acordo com implementações da invenção.
[0017] A Figura 3 descreve um exemplo de um processo de validação protegida por privacidade de uma transação de protocolo de confiança baseada em criptografia homomórfica.
[0018] A Figura 4 ilustra um exemplo de uma transação de protocolo de confiança de acordo com implementações da invenção.
[0019] A Figura 5 ilustra outro exemplo de um processo de validação protegido por privacidade de uma transação de protocolo de confiança baseada em criptografia homomórfica.
[0020] A Figura 6 ilustra um exemplo de um método que pode ser executado de acordo com as implementações da invenção.
[0021] A Figura 7 ilustra outro exemplo de um método que pode ser executado de acordo com as implementações da invenção.
[0022] A Figura 8 descreve um exemplo de um nó de protocolo de confiança que pode executar um processo de acordo com implementações da invenção.
[0023] Como os símbolos de referência nos vários desenhos indicam elementos semelhantes.
DESCRIÇÃO DETALHADA DA INVENÇÃO
[0024] As implementações da invenção incluem métodos implementados por computador para verificações de preservação da privacidade não interativas de transações de protocolo de confiança. Mais particularmente, implementações da invenção são direcionadas a um método implementado por computador capaz de validar múltiplas transações associadas a uma conta de um nó de protocolo de confiança em paralelo, baseado em esquemas de comprometimento e criptografia homomórfica sem revelar informações de privacidade, como quantidade de transações, saldos de contas, ou números aleatórios para gerar compromissos, para outros nós do protocolo de confiança. Em algumas implementações, as ações incluem o recebimento de dados de transação associados à transação, os dados da transação compreendem: dados representativos de uma pluralidade de ativos, um primeiro compromisso que oculta um primeiro número aleatório e um valor de transação da transação, um segundo compromisso que oculta um segundo número aleatório e uma alteração calculada com base na dedução do valor da transação de um valor total da pluralidade de ativos, o valor da transação e um terceiro número aleatório criptografado por uma chave pública do segundo nó com base em um esquema de criptografia homomórfica probabilística (HE), a alteração e um quarto número aleatório, ambos criptografados por uma chave pública do primeiro nó com base no esquema probabilístico HE, uma ou mais provas de intervalo, uma prova de conhecimento zero (ZKP) e uma assinatura digital gerada com base em uma chave privada correspondente à chave pública do primeiro nó; verificar a assinatura digital com base na chave pública do primeiro nó; Determinar que as provas de alcance de uma ou mais séries provam que o valor da transação e a alteração são cada um maior ou igual a zero; determinar que o valor total da pluralidade de ativos é igual à soma do valor da transação e da alteração; e determinar, com base no ZKP, que a transação é válida determinando que o primeiro número aleatório é igual ao terceiro número aleatório, o segundo número aleatório é igual ao quarto número aleatório, e o valor da transação oculto no primeiro compromisso é igual à quantidade de transação criptografada pela chave pública do segundo nó. Outras implementações incluem sistemas, aparelhos e programas de computador correspondentes, configurados para executar as ações dos métodos, codificados em dispositivos de armazenamento de computador.
[0025] Para fornecer mais contexto para implementações da invenção, e como apresentado acima, os sistemas de registro distribuído (DLSs), que também podem ser chamados de redes de consenso (por exemplo, compostas de nós peer-to-peer), e redes de protocolo de confiança, permitem que as entidades participantes fiquem seguras, e imutáveis para realizar transações e armazenar dados. O protocolo de confiança é aqui utilizado para referir-se geralmente a um DLS sem referência a qualquer caso de uso particular.
[0026] Um protocolo de confiança é uma estrutura de dados que armazena transações de forma que as transações são imutáveis e podem ser verificadas subsequentemente. Um protocolo de confiança inclui um ou mais blocos. Cada bloco na cadeia está ligado a um bloco anterior imediatamente antes dele na cadeia, incluindo um hash criptográfico do bloco anterior. Cada bloco também inclui um registro de data e hora, seu próprio hash criptográfico e uma ou mais transações. As transações, que já foram verificadas pelos nós da rede de protocolo de confiança, são hashed e codificadas em uma árvore Merkle. Uma árvore Merkle é uma estrutura de dados na qual os dados nos nós das folhas da árvore são hashed e todos os hashes em cada ramificação da árvore são concatenados na raiz da ramificação. Esse processo continua subindo a árvore até a raiz da árvore inteira, que armazena um hash que é representativo de todos os dados na árvore. Um hash que pretende ser de uma transação armazenada na árvore pode ser rapidamente verificado determinando se é consistente com a estrutura da árvore.
[0027] Enquanto um protocolo de confiança é uma estrutura de dados para armazenar transações, uma rede de protocolo de confiança é uma rede de nós de computação que gerencia, atualiza e mantém um ou mais protocolos de confiança. Conforme apresentado acima, uma rede de protocolo de confiança pode ser fornecida como uma rede de protocolo de confiança pública, uma rede de protocolo de confiança privada ou uma rede de protocolo de confiança de consórcio.
[0028] Em um protocolo de confiança público, o processo de consenso é controlado por nós da rede de consenso. Por exemplo, centenas, milhares e até milhões de entidades podem participar de um protocolo de confiança público, cada um operando pelo menos um nó no protocolo de confiança público. Assim, o protocolo de confiança público pode ser considerado uma rede pública em relação às entidades participantes. Em alguns exemplos, a maioria das entidades (nós) deve assinar cada bloco para que o bloco seja válido e adicionado ao protocolo de confiança. Exemplo, a rede de protocolo de confiança pública inclui especial rede de pagamentos peer-to-peer que alavanca um registro distribuído, referido como protocolo de confiança. Como observado acima, o termo protocolo de confiança, no entanto, é usado para referir-se geralmente a registros distribuídos sem referência particular a qualquer rede de protocolo de confiança em particular.
[0029] Em geral, um protocolo de confiança público suporta transações públicas. Uma transação pública é compartilhada com todos os nós dentro do protocolo de confiança, e o protocolo de confiança é replicado em todos os nós. Ou seja, todos os nós estão em perfeito estado de consenso em relação ao protocolo de confiança. Para chegar a um consenso (por exemplo,
concordar com a adição de um bloco a um protocolo de confiança), um protocolo de consenso é implementado dentro da rede de protocolo de confiança. Exemplo protocolo de consenso inclui, sem limitação, prova-de-obra (POW), prova-de-aposta (POS), e prova-de-autoridade (POA). POW é aqui referenciado como um exemplo não limitativo.
[0030] As implementações da invenção incluem métodos implementados por computador para verificações de preservação da privacidade não interativas de transações do protocolo de confiança. Mais particularmente, implementações da invenção são direcionadas a um método implementado por computador capaz de validar múltiplas transações associadas a uma conta de um nó de protocolo de confiança em paralelo, baseado em esquemas de comprometimento e criptografia homomórfica sem revelar informações de privacidade, como quantidade de transações, saldos de contas, ou números aleatórios para gerar compromissos, para outros nós do protocolo de confiança.
[0031] De acordo com as implementações da invenção, os nós de protocolo de confiança podem usar um modelo de conta genérico que possa suportar verificações de transação paralelas como um método de manutenção de registros. Em comparação com o modelo de saldo da conta, os nós de protocolo de confiança que adotam o modelo de conta genérica podem manter registros de uma pluralidade de ativos, em vez de saldos de contas. Cada um da pluralidade de ativos pode ser associado a pelo menos um tipo de ativo, um ID de ativo ou um valor de ativo. O ativo sob o modelo de conta genérica pode estar em qualquer forma ou tipo, como monetário ou fixo. Ativos monetários podem incluir moeda real ou criptomoeda. Em algumas implementações, os ativos fixos podem ser convertidos em ativos monetários associados a um valor monetário. O valor monetário pode então ser usado para realizar transações entre contas de uma rede de protocolo de confiança. Para fins de ilustração,
assume-se que os ativos descritos nas implementações da invenção são convertidos para o mesmo tipo de moeda e salvos nas contas de protocolo de confiança no modelo de conta genérica.
[0032] Para proteger a privacidade dos dados, as transações podem ser registradas em um protocolo de confiança (registro) com base no comprometimento sem revelar o valor da transação ou as informações de valor monetário associadas às contas de usuário do protocolo de confiança. Um esquema de compromisso pode ser usado para gerar um compromisso de um valor de transação usando um número aleatório. Um exemplo de esquema de compromisso inclui, sem limitação, o esquema de PC. Como o valor da transação está oculto no compromisso, uma ou mais provas de intervalo podem ser usadas para provar que o valor da transação não excede o valor da conta de usuário do protocolo de confiança.
[0033] No modelo de saldo da conta, as provas de intervalo estão associadas ao saldo da conta. Se mais de uma transação for feita, mas nem todas as transações forem validadas e registradas no protocolo de confiança, as provas de intervalo podem estar associadas a saldos de conta incorretos, portanto, podem ser inválidas. Em comparação, sob o modelo de conta genérica, o valor da conta pode ser calculado como a soma de uma pluralidade de ativos. Quando uma quantia de transação é para ser transferida entre contas de usuário protocolo de confiança, pelo menos uma parte da pluralidade de ativos com valor combinado maior ou igual ao valor da transação pode ser usada para cobrir o valor da transação. Transferências adicionais podem ser feitas sob a condição de que os restantes ativos possuam um valor combinado maior que a quantia a ser transferida. Mesmo se as transações não são validadas e registradas no protocolo de confiança, as provas de alcance que mostram que o valor combinado dos restantes ativos é maior do que, ou igual a, o valor da transação pode ainda ser válido. Portanto, mais de uma verificação de transação pode ser executada em paralelo no modelo de conta genérico.
[0034] De acordo com as implementações da invenção, as transações de protocolo de confiança podem ser validadas e registradas em um protocolo de confiança (registro) baseado em comprometimento, sem revelar o saldo da conta de transação, o valor da transação ou o número aleatório usado para gerar o compromisso. Um esquema de compromisso, como o esquema de PC, pode ser usado para gerar um compromisso de um valor de transação com base em um número aleatório. O valor da transação e o número aleatório podem ser criptografados usando probabilístico ou determinístico linear HE. A quantia da transação e o número aleatório também pode ser utilizado para gerar um conjunto de valores como ZKP para validar a transação com base nas propriedades do esquema HE utilizado. O compromisso da transação montante, o valor da transação criptografada e número aleatório, e o ZKP podem ser utilizados por um nó do protocolo de confiança para verificar se a transação é válida sem o saldo da conta, o valor da transação, ou o número aleatório sendo revelado.
[0035] A Figura 1 ilustra um exemplo de um ambiente (100) que pode ser usado para executar implementações da invenção. Em alguns exemplos, o ambiente de exemplo (100) permite que entidades participem de um protocolo de confiança público (102). O ambiente de exemplo (100) inclui sistemas de computação (106), (108) e uma rede (110). Em alguns exemplos, a rede (110) inclui uma rede de área local (LAN), rede de longa distância (WAN), a Internet ou uma combinação dos mesmos, e conecta sites da Web, dispositivos de usuário (por exemplo, dispositivos de computação) e sistemas de back-end. Em alguns exemplos, a rede (110) pode ser acessada através de um link de comunicação com fio e/ou sem fio.
[0036] No exemplo descrito, os sistemas de computação (106),
(108) podem incluir, cada um, qualquer sistema de computação apropriado que permita a participação como um nó no protocolo de confiança público (102).
Exemplos de dispositivos de computação incluem, sem limitação, um servidor, um computador de mesa, um computador laptop, um dispositivo de computação em tablet e um smartphone. Em alguns exemplos, os sistemas de computação (106), (108) hospedam um ou mais serviços implementados por computador para interagir com o protocolo de confiança público (102). Por exemplo, o sistema de computação (106) pode hospedar serviços implementados por computador de uma primeira entidade (por exemplo, usuário A), como um sistema de gerenciamento de transações que a primeira entidade usa para gerenciar suas transações com uma ou mais entidades (por exemplo, outros usuários). O sistema de computação (108) pode hospedar serviços implementados por computador de uma segunda entidade (por exemplo, usuário B), como um sistema de gerenciamento de transações que a segunda entidade usa para gerenciar suas transações com uma ou mais outras entidades (por exemplo, outros usuários). No exemplo da Figura 1, o protocolo de confiança público (102) é representado como uma rede peer-to-peer de nós, e os sistemas de computação (106), (108) fornecem nós da primeira entidade, e segunda entidade respectivamente, que participam no protocolo de confiança público (102).
[0037] A Figura 2 ilustra um exemplo de uma arquitetura conceitual (200) de acordo com implementações da invenção. A arquitetura conceitual de exemplo (200) inclui uma camada de entidade (202), uma camada de serviços hospedados (204) e uma camada de protocolo de confiança pública (206). No exemplo representado, a camada de entidade (202) inclui três entidades, Entidade_1 (E1), Entidade_2 (E2) e Entidade 3 (E3), cada entidade possuindo um respectivo sistema de gestão de transações (208).
[0038] No exemplo representado, a camada de serviços hospedados (204) inclui interfaces de protocolo de confiança (210) para cada sistema de gestão de transação (208). Em alguns exemplos, um sistema de gestão de transação (208) se comunica com uma respectiva interface do protocolo de confiança (210) por uma rede (por exemplo, a rede (110) da Figura 1) usando um protocolo de comunicação (por exemplo, protocolo de transferência de hipertexto seguro (HTTPS)). Em alguns exemplos, cada interface do protocolo de confiança (210) fornece uma conexão de comunicação entre um respectivo sistema de gerenciamento de transação (208) e a camada de protocolo de confiança (206). Mais particularmente, cada interface de protocolo de confiança (210) permite que a entidade respectiva conduza transações registradas em uma rede de protocolo de confiança (212) da camada de protocolo de confiança (206). Em alguns exemplos, a comunicação entre uma interface de protocolo de confiança (210) e a camada de protocolo de confiança (206) é conduzida usando chamadas de procedimento remoto (RPCs). Em alguns exemplos, as interfaces de protocolo de confiança (210) “hospedam” nós de protocolo de confiança para os respectivos sistemas de gerenciamento de transação (208). Por exemplo, as interfaces de protocolo de confiança (210) fornecem a interface de programação de aplicativos (API) para acesso à rede de protocolo de confiança (212).
[0039] Como aqui descrito, a rede de protocolo de confiança (212) é fornecida como uma rede peer-to-peer, incluindo uma pluralidade de nós (214) que gravam informação imutável em um protocolo de confiança (216).
Embora um único protocolo de confiança (216) seja representado esquematicamente, múltiplas cópias do protocolo de confiança (216) são fornecidos e são mantidos através da rede de protocolo de confiança (212). Por exemplo, cada nó (214) armazena uma cópia do protocolo de confiança (216).
Em algumas implementações, o protocolo de confiança (216) armazena informações associadas a transações que são realizadas entre duas ou mais entidades participantes no protocolo de confiança público.
[0040] A Figura 3 ilustra um exemplo de um processo (300) de validação protegida por privacidade de uma transação de protocolo de confiança baseada em HE. Em um nível elevado, o processo (300) é realizado por um nó do usuário A (302), um nó do usuário B (não mostrado na Figura 3) e um nó de cadeia de blocos (304), também referido como um nó de consenso.
Tanto a conta do nó do usuário A (302), quanto a conta do nó do usuário B podem ter um modelo de manutenção de registros baseado em um modelo de conta genérico. Ou seja, os registros da conta do nó do usuário A (302) e do nó do usuário B são mantidos como uma pluralidade de ativos. Uma transação, como uma transferência de valor, pode ser feita do nó do usuário A (302) para o nó do usuário B. O nó do usuário A (302) pode selecionar um ou mais ativos da conta que tenham um valor total maior ou igual ao valor da transação para cobrir a transação. A diferença entre um valor total de um ou mais ativos e o valor da transação pode ser considerada como a alteração da transação deixada para o nó do usuário A (302).
[0041] Para proteger a privacidade da conta, o nó do usuário A (302) pode gerar compromissos de valores dos bens utilizados para cobrir a transação. O nó do usuário A (302) também pode gerar um compromisso do valor da transação da transação. O nó do usuário A (302) também pode usar HE para criptografar o valor da transação, a alteração e os números aleatórios usados para gerar os compromissos. Para verificar a validade da transação, o nó do protocolo de confiança (304) pode comparar o valor da transação, a alteração, e os números aleatórios ocultos nos compromissos e criptografados por HE baseado em um ZKP. Se o valor da transação, a alteração e os números aleatórios coincidirem, a transação é determinada como sendo válida pelo nó do protocolo de confiança (304). Mais detalhes do processo (300) são discutidos na seguinte descrição da Figura 3.
[0042] Em (306), o nó do usuário A (302) seleciona uma pluralidade de ativos para a transferência de um valor da transação para o nó do usuário B. O nó do usuário A (302) e um nó do usuário B podem ser nós de consenso do protocolo de confiança ou nós de usuários que utilizam a rede de protocolo de confiança sem participar do processo de consenso. Como discutido anteriormente, o nó do usuário A (302) pode usar um modelo de conta genérico para manter registros. Em vez de manter o saldo da conta para registro no modelo de saldo da conta, o valor da conta do nó do usuário A (302) é medido pelo valor total dos ativos que possui. O nó do usuário A (302) pode selecionar uma pluralidade de ativos que tenham valor suficiente para cobrir o valor da transação. Por exemplo, se o montante da transação é de 7,5 dólares dos EUA, o nó do usuário A (302) pode selecionar um de três ativos que valem 5, 2 e 1 dólares americanos, respectivamente, para cobrir o valor da transação.
[0043] Em algumas implementações, cada ativo pode ser associado a um endereço de transação ou ID que identifica o ativo correspondente. O ID do ativo pode ser o hashing de informações do ativo. Os IDs do ativo de k ativos selecionados podem ser representados como ID 1,..., IDk.
[0044] Em (308), o nó do usuário A (302) calcula uma alteração com base em um valor total da pluralidade de ativos e o valor da transação.
Como os ativos são selecionados para ter um valor total maior que o valor da transação, a alteração pode ser calculada como o valor total dos ativos selecionados deduzido pelo valor da transação. Usando t para representar o valor da transação e t0 para representar a alteração, o cálculo da alteração pode ser expresso como t0 = a1 +...+ ak - t, onde a1,..., ak, são, respectivamente,
os valores dos ativos de ativos k selecionados pelo nó do usuário A (302) que cobre o valor da transação t.
[0045] Em (310), o nó do usuário A (302) gera um número aleatório correspondente ao valor da transação e um número aleatório que correspondente à alteração. O número aleatório correspondente ao valor da transação t pode ser denotado como r. O número aleatório correspondente à alteração t0 pode ser denotado como r0. Em algumas implementações, uma pluralidade de números aleatórios pode ser gerada para produzir compromissos dos valores do ativo. Por exemplo, suponha a1,..., ak são os valores do ativo, os números aleatórios que correspondem aos valores do ativo podem ser expressos como ra1,…, rak.
[0046] Em algumas implementações, o número aleatório r0 pode ser calculado em vez de gerado aleatoriamente. O cálculo pode ser expresso como r0 = ra1 +... + rak - r, em que r é o número aleatório gerado para produzir comprometimento para o valor da transação t. Ao utilizar o número aleatório calculado r0, o nó do usuário A (302) não necessita gerar um ZKP adicional para provar que o valor total de ativo transferido é igual ao valor total de ativo recebido. Em algumas implementações, um outro número aleatório r' pode ser calculado como r' = r1 +... + rk - r - r0, para ajudar com a ZKP.
[0047] Em (312), o nó do usuário A (302) gera compromissos do valor da transação e da alteração, e criptografa os números aleatórios correspondentes com base probabilística HE. Em algumas implementações, esquemas de comprometimento homomórfico, como PC, podem ser usados para gerar os compromissos. Usando o PC como um exemplo não limitativo, o PC do valor da transação t pode ser gerado usando o número aleatório r, que pode ser expresso como PC (r, t) = gr ht, onde g e h podem ser geradores de uma curva elíptica, e PC (r, t) é uma multiplicação escalar de pontos de curva.
Do mesmo modo, o PC da alteração t0 pode ser expressa como o PC (r0, t0) = gr0 ht0.
[0048] O número aleatório r pode ser criptografado usando a chave pública do nó do usuário B com base em um esquema probabilístico HE, como um esquema de criptografia Okamoto-Uchiyama (OU). É para ser entendido que outros esquemas de HE, como Boneh-Goh-Nissim, também podem ser usados. Usando UO como um exemplo não limitativo, o número aleatório pode ser criptografado com base em UO tratando o valor da transação t como um número aleatório, o que pode ser expressado como UOB(r, t) = urvt, ou simplesmente OUB(t), onde u é um gerador de (Z/ nZ)* satisfazendo a condições que v = un mod n, e n = p × q, onde p e q são dois números primos. Probabilística OU pode satisfazer a propriedade que OU(a + b) = OU(a) × OU(b), onde a e b são o texto simples usado para OU.
[0049] O número aleatório r0 pode ser criptografado usando a chave pública do nó do usuário A (302). O número aleatório pode ser criptografado com base na OU tratando a alteração t 0 como um número aleatório, que pode ser expresso como OUA (r0, t0).
[0050] O texto cifrado do valor de transação pode então ser expresso como T = (PC (t, r), OUB (r, t)), e o texto cifrado da alteração pode ser expresso como T0 = (PC (t0, r0), OUA (r0, t0)). Similarmente, o texto cifrado do k ativo selecionado pode ser expresso como T i = (PC (ti, ri), OUA (ri, ti)), onde i = 1,.. k.
[0051] Em (314), o nó do usuário A (302) gera uma ou mais provas de intervalo. Em algumas implementações, uma primeira prova de intervalo, RP1, pode ser gerada para mostrar que o valor de transação t ≥ 0.
Uma segunda prova de intervalo, RP2, pode ser gerada para mostrar que a alteração t0 ≥ 0, ou em outras palavras, o valor total da pluralidade de ativo é maior do que, ou igual a, o valor da transação.
[0052] No (316), o nó do usuário A (302) gera um ZKP. O ZKP pode ser usado para mostrar que o número aleatório e o valor da transação oculto no PC(r, t) é o mesmo que o número aleatório e o valor da transação criptografado em UOB(r, t), e o número aleatório e o valor da transação oculto no PC (r0, t0) é o mesmo que o número aleatório e o valor da transação criptografado em OUA (r0, t0). Para gerar o ZKP, dois números aleatórios t'1 e r'1 podem ser selecionados. Os dois números aleatórios podem ser usados para gerar três valores, que são P = PC (t'1, r'1), P' = OUB (r'1, t'1), P'' = OUA (r'1, t'1).
Os três valores podem então ser usados para gerar um hash expresso como x = Hash (P, P', P''). O valor de hash x pode ser utilizado para calcular t'2 = t'1 + xt, r'2 = r'1 + xr, t'3 = t'1 + xt, e r'3 = r'1 + xr0. O ZKP pode então ser expresso como (P, P', t'2, r'2, P'', t'3, r'3).
[0053] Em (318), o nó do usuário A (302) usa uma chave privada para gerar uma assinatura digital para assinar dados de transação. Em algumas implementações, os dados da transação podem incluir os ativos IDs do k ativo selecionado (ID1,..., IDk), o texto cifrado do valor de transação (T), o texto cifrado da alteração (T0), as provas de alcance (RP1 e RP2), o número aleatório r', e o ZKP.
[0054] Em (320), o nó do usuário A (302) envia a cópia assinada digitalmente dos dados de transação para uma rede de protocolo de confiança.
[0055] Em (322), o nó de protocolo de confiança (304) verifica a assinatura digital. A verificar a assinatura digital pode ser realizada para garantir que os dados da transação sejam enviados pelo nó do usuário A (302).
Em algumas implementações, o nó protocolo de confiança (304) inclui um mecanismo de gasto duplo que pode verificar se a transação já foi executada.
Nesse caso, o nó do protocolo de confiança (304) pode rejeitar a transação.
[0056] Em (324), o nó do protocolo de confiança (304) verifica se os ativos selecionados estão associados à conta do nó do usuário A. A verificação pode ser baseada nos ativos IDs dos ativos.
[0057] Em (326), o nó do protocolo de confiança (304) verifica que o valor total da pluralidade de ativos selecionados é igual à soma do valor da transação e da alteração. Em outras palavras, o protocolo de confiança verifica que a1 +... + ak = t + t0. Como discutido anteriormente, sob o modelo de conta genérica, os ativos podem ser mantidos no protocolo de confiança como PCs para proteger a privacidade dos dados. Com base no homomorfismo de PC, PC(ra1, a1) × . . . × PC(rak, ak) = PC(ra1 + . . . + rak, a1 + . . . + ak), and PC(r, t) × PC(r0, t0) = PC(r + r0, t + t0). Portanto, mostrando que PC(ra1, a1) × . . . × PC(rak, ak) = PC(r, t) × PC(r0, t0) × gr’, pode ser comprovado que a1 + . . . + ak = t + t0.
[0058] Em (328), o nó do protocolo de confiança (304) verifica uma ou mais provas de intervalo.
[0059] No (330), o nó do protocolo de confiança (304) verifica o ZKP. Como discutido acima, o ZKP pode ser gerado para verificar se o número aleatório corresponde ao valor de transação criptografada usando a chave pública do nó do usuário B é o mesmo que o número aleatório correspondente oculto pelo PC, e se o número aleatório correspondente a alteração criptografada usando a chave pública do nó do usuário A (302) é o mesmo que o número aleatório correspondente oculto pelo PC. Em algumas implementações, para verificar o ZKP, o nó do protocolo de confiança (304) pode primeiro calcular valor de hash x como x = Hash (P, P', P''). O nó do protocolo de confiança (304) pode então verificar se PC(t'2, r'2) = P × PC(t, r)x, OUB(r'2, t'2) = P' × OUB(r, t)x, PC(t'3, r'3) = P × PC(t0, r0)x e UOA (r'3, t'3) = P'' × OUA(r0, t0)x são todos verdadeiros. Se todos forem verdadeiros, o processo de exemplo (300) prossegue para (332). Caso contrário, o nó protocolo de confiança (304) pode rejeitar a transação.
[0060] Em (332), o nó protocolo de confiança (304) atualiza as contas do nó do usuário A (302) e do nó do usuário B. Porque as contas do nó do usuário A (302) e do nó do usuário B mantêm os ativos como registros no modelo de conta genérica, após o transação, a pluralidade de ativos transferidos do nó do usuário A (302) podem ser removidas da conta do nó do usuário A (302). A alteração pode ser adicionada novamente à conta do nó do usuário A (302). O valor da transação, e o correspondente ativo ID podem ser adicionados como um novo ativo para a conta do nó do usuário B. Em algumas implementações, a atualização pode ser realizada com base na atualização das listas de ativos mantidos por correspondentes contas do nó do usuário A (302) e o nó do usuário B. Em algumas implementações, a atualização pode ser realizada com base na adição de textos cifradis do valor da transação e da alteração nos valores do ativo criptografado mantidos pelo nó do usuário A (302) e pelo nó do usuário B. A atualização das contas é descrita em mais detalhes aqui com referência à Figura 4.
[0061] A Figura 4 ilustra um exemplo de uma transação de protocolo de confiança (400) de acordo com implementações da invenção.
Como mostrado no exemplo de transação de protocolo de confiança (400), um nó do usuário A (402) transfere uma quantidade de transação t para um nó do usuário B (404). Antes da transação, o nó do usuário A (402) tem n ativos incluindo (ID1, T1), (ID2, T2), (IDn, Tn).
[0062] Utilizando os esquemas de compromisso, esquemas de criptografia e processo de transação descritos aqui com referência à Figura 3 como um exemplo, o nó do usuário A (402) pode gerar os dados de transação (408), que podem incluir IDs de ativos dos ativos k selecionados, ID, ID2,…, IDk.
Os dados de transação (408) podem ainda incluir T 0, T, RP1, RP2, r', e o ZKP.
Depois dos dados de transação (408) serem gerados, o nó do usuário A (402) pode adicionar a sua assinatura digital e submeter os dados de transação assinados digitalmente à rede de protocolo de confiança (406) para consenso.
[0063] Após a transação, os ativos k selecionados podem ser removidos da conta do ativo do usuário A (402). A alteração pode ser incluída novamente no nó do usuário A (402). Portanto, o nó do usuário A (402) pode ter os seguintes ativos expressos como (IDk + 1, Tk + 1), (IDk +2, Tk +2),…, (IDn, Tn), (ID0, T0) onde ID0 representa o ID do ativo do mude t0.
[0064] Antes da transação, o nó do usuário B (404) possui m ativos, que podem ser expressos como (ID1’, T1’), (ID2’, T2’), (IDm’, Tm’). Após a transação, o valor da transação pode ser adicionado ao nó do usuário B (404).
O nó do usuário B (404) pode ter os seguintes ativos expressos como (ID1’, T1’), (ID2’, T2’), (IDm’, Tm’), (IDt, T) onde IDt representa o ID do ativo do valor da transação t.
[0065] A Figura 5 representa um exemplo de um processo (500) de validação protegida por privacidade de uma transação de protocolo de confiança baseada em HE. Em um nível alto, o processo de exemplo (500) é executado por um nó do usuário A (502), um nó do usuário B (não mostrado na Figura 5), e um nó de protocolo de confiança (504), também referido como um nó de consenso. Ambas as contas do nó do usuário A (502) e a conta do nó do usuário B podem ser baseadas em um modelo de conta genérico. Uma transação, como uma transferência de valor, pode ser feita do nó do usuário A (502) para o nó do usuário B. O nó do usuário A (502) pode selecionar um ou mais ativos da conta que tenham um valor total maior ou igual ao valor da transação para cobrir a transação. A diferença entre o valor total de um ou mais ativos e o valor da transação pode ser considerada como a alteração da transação deixada para o nó do usuário A (502).
[0066] Para proteger a privacidade da conta, o nó do usuário A (502) pode gerar compromissos de valores dos ativos usados para cobrir a transação e o valor da transação usando um esquema de comprometimento, como o PC. O nó do usuário A (502) também pode utilizar HE determinístico linear para criptografar números aleatórios usados para gerar os compromissos. O HE determinístico linear pode ter as seguintes propriedades:
HE(s + t) = HE(s) × HE(t), e HE(KT) = HE(t)k. Para verificar a validade da transação, o nó de protocolo de confiança (504) pode comparar os números aleatórios ocultos no compromisso e criptografados por HE com base em um ZKP. Se os números aleatórios coincidirem, a transação pode ser determinada como sendo válida pelo nó de protocolo de confiança (504). Mais detalhes do processo de exemplo (500) são discutidos na seguinte descrição da Figura 5.
[0067] Em (506), o nó do usuário A (502) seleciona uma pluralidade de ativos para transferir um valor de transação para o nó do usuário B. O nó do usuário A (502) e o nó do usuário B podem ser o nó de consenso do protocolo de confiança ou nós de usuário que usam a rede de protocolo de confiança sem participar do processo de consenso. O nó do usuário A (502) pode selecionar uma pluralidade de ativos que tenham valor suficiente para cobrir o valor da transação.
[0068] Em algumas implementações, cada ativo pode ser associado a um endereço de transação ou ID do ativo que identifica o ativo correspondente. O ID do ativo pode ser o hash de informações do ativo. Os IDs ativos de ativos k selecionados podem ser representados como ID1, . . ., IDk.
[0069] No (508), o nó do usuário A (502) calcula uma alteração com base em um valor total da pluralidade de ativos e o valor da transação.
Como os ativos são selecionados para ter um valor total maior que o valor da transação, a alteração pode ser calculada como o valor total dos ativos selecionados deduzidos pelo valor da transação. Usando t para representar o valor da transação e t0 para representar a modificação, o cálculo da modificação pode ser expresso como t0 = a1 +... + ak - t, onde a1,..., ak são, respectivamente, os valores de ativos de ativos k selecionados pelo nó do usuário A (502) para cobrir um valor de transação t.
[0070] Em (510), o nó do usuário A (502) gera um número aleatório correspondendo ao valor de transação e um número aleatório que corresponde à alteração. O número aleatório correspondente ao valor da transação t pode ser denotado como r. O número aleatório correspondente à alteração t0 pode ser denotado como r0. Em algumas implementações, uma pluralidade de números aleatórios pode ser gerada para produzir compromissos dos valores do ativo. Por exemplo, suponha a1, . . ., ak são os valores do ativo, os números aleatórios que correspondem aos valores do ativo podem ser expressos como ra1, … , rak.
[0071] Em algumas implementações, o número aleatório r0 pode ser calculado em vez de gerado aleatoriamente. O cálculo pode ser expresso como r0 = ra1 + . . . + rak – r, onde r é o número aleatório gerado para produzir comprometimento para o valor da transação t. Ao calcular r 0, o nó do usuário A (502) não precisa gerar um ZKP adicional para mostrar que o valor total do ativo transferido é igual ao valor total do ativo recebido. Em algumas implementações, um número aleatório r' pode ser calculado como r’ = r1+ …+ rk – r – r0.
[0072] Em (512), o nó do usuário A (502) gera compromissos do valor da transação e da alteração, e criptografa os números aleatórios correspondentes com base no HE determinístico. Em algumas implementações, esquemas de comprometimento homomórfico, como PC, podem ser usados para gerar os compromissos. Usando o PC como um exemplo não limitativo, o PC do valor da transação t pode ser gerado usando o número aleatório r, que pode ser expresso como PC(r, t) = grht, onde g e h podem ser geradores de uma curva elíptica, e PC (r, t) é uma multiplicação escalar de pontos de curva. Do mesmo modo, o PC da alteração t0 pode ser expressa como o PC(r0, t0) = gr0ht0.
[0073] O número aleatório r pode ser criptografado usando a chave pública do nó do usuário B com base no HE determinístico linear. O determinístico linear HE pode ser obtido a partir de HE probabilístico, como
Paillier, Benaloh, OU, Naccache-Stern, Boneh-Goh-Nissim, Damgard-Jurik, ou probabilidade-igual HE, fixando o número aleatório no esquema HE em 0 ou 1 ou outro número apropriado. O número aleatório criptografado pode ser expresso como HE(r).
[0074] O número aleatório r0 pode ser criptografado usando a chave pública do nó do usuário A. O número aleatório pode ser criptografado com base no HE determinístico linear. O número aleatório criptografado pode ser expresso como HE (r0).
[0075] O texto cifrado do valor da transação t pode então ser expressa como T = (grht, HEB(r)) e o texto cifrado da alteração pode ser expressa como T0 = (gr0ht0, HEA(r0)). Da mesma forma, o texto cifrado dos ativos k selecionado pode ser expresso como Ti = (gri hti, HE (ri), onde i = 1,..., k.
[0076] Em (514), o nó do usuário A (502) gera uma ou mais provas de intervalo. Em algumas implementações, uma primeira prova de intervalo, RP1, pode ser gerada para mostrar que o valor de transação t ≥ 0.
Uma segunda prova de intervalo, RP2, pode ser gerada para mostrar que a alteração t0 ≥ 0, ou em outras palavras, o valor total da pluralidade de ativos é maior ou igual ao valor da transação.
[0077] Em (516), o nó do usuário A (502) gera um ZKP. O ZKP pode ser usado para mostrar que o número aleatório oculto em PC(r, t) é o mesmo que o número aleatório criptografado em HE(r), e o número aleatório oculto em PC(r0, t0) é o mesmo como o número aleatório criptografado em HE (r0). Para gerar o ZKP, dois números aleatórios t'1 e r'1 podem ser selecionados.
Os dois números aleatórios podem ser usados para gerar três valores, que são P = gr'1 ht'), P' = HEB (r'1), P'' = HEA (r'1). Os três valores podem então ser usados para gerar um hash expresso como x = Hash(P, P', P''). O valor hash x pode ser utilizado para calcular t'2 = T'1 + xt, r'2 = r'1 + x r, t'3 = t'1 + xt, e r'3 = r'1 + xr0. O ZKP pode então ser expresso como (P, P', t'2, r'2, P'', t'3, r'3).
[0078] Em (518), o nó do usuário A (502) usa uma chave privada para gerar uma assinatura digital para assinar dados de transação. Em algumas implementações, os dados da transação podem incluir os IDs do ativo dos ativos k selecionados (ID1,..., IDk), o texto cifrado do valor de transação (T), o texto cifrado da alteração (T0), as provas de alcance (RP1 e RP2), o número aleatório r' e o ZKP.
[0079] Em (520), o nó do usuário A (502) envia a cópia assinada digitalmente dos dados da transação para uma rede de protocolo de confiança.
[0080] Em (522), o nó de protocolo de confiança (504) verifica a assinatura digital. A verificar a assinatura digital pode ser realizada para garantir que os dados da transação sejam enviados pelo nó do usuário A (502).
Em algumas implementações, o nó de protocolo de confiança (504) inclui um mecanismo de defesa dupla que pode verificar se a transação já foi realizada.
Nesse caso, o nó protocolo de confiança (504) pode rejeitar a transação.
[0081] Em (524), o nó de protocolo de confiança (504) verifica se os ativos selecionados estão associados à conta do nó do usuário A. A verificação pode ser baseada nos IDs do ativo dos ativos.
[0082] Em (526), o nó protocolo de confiança (504) verifica que o valor total da pluralidade de ativos selecionado é igual à soma do valor da transação e da alteração. Em outras palavras, o nó de protocolo de confiança (504) verifica que a1 +... + ak = t + t0. Como discutido anteriormente, sob o modelo de conta genérica, os ativos podem ser mantidos no protocolo de confiança como PCs para proteger a privacidade dos dados. Com base no homomorfismo de PC, PC, PC(ra1, a1) × . . . × PC(rak, ak) = PC(ra1 + . . . + rak, a1 + . . . + ak), e o PC(r, t) × PC(r0, t0) = PC(r + r0, t + t0). Portanto, mostrando que PC(ra1, a1) × . . . × PC(rak, ak) = PC(r, t) × PC(r0, t0) × gr’, pode ser comprovado que a1 +... + ak = t + t0.
[0083] Em (528), o nó protocolo de confiança (504) verifica uma ou mais provas de intervalo.
[0084] Em (530), o nó protocolo de confiança (504) verifica o ZKP.
Como discutido anteriormente, o ZKP pode ser gerado para verificar se o número aleatório correspondente à quantidade de transação criptografada usando a chave pública do nó do usuário B é o mesmo que o número aleatório correspondente oculto pelo PC, e se o número aleatório correspondente a alteração criptografada usando a chave pública do nó do usuário A (502) é igual ao número aleatório correspondente oculto pelo PC. Em algumas implementações, para verificar o ZKP, o nó protocolo de confiança (504) pode calcular o primeiro o valor de hashx como x = Hash(P, P', P''). O nó de protocolo de confiança (504) pode, em seguida, verificar se gr’2ht’2= P × (grht)x, HEB(r') = P' × HE (r) x, gr’3ht’3 = P × (gr0ht0)x, HEA(r'3) = P'' × HEA(r0)x são todos verdadeiros. Se cada um for verdadeiro, o processo de exemplo (500) prossegue para (532). Caso contrário, o nó de protocolo de confiança (504) pode rejeitar a transação.
[0085] Em (532), o nó de protocolo de confiança (504) atualiza as contas do nó do usuário A (502) e do nó do usuário B. Como as contas do nó do usuário A (502) e do nó do usuário B mantêm ativos como registros no modelo de conta genérica, após a transação, a pluralidade de ativos transferidos do nó do usuário A (502) pode ser removida da conta do nó do usuário A (502). A alteração pode ser incluída novamente na conta do nó do usuário A (502). O valor da transação, e o ativo correspondente ID pode ser adicionado como um novo ativo para a conta do nó do usuário B. Em algumas implementações, a atualização pode ser realizada com base na atualização das listas de ativos mantidos por correspondentes contas do nó do usuário A (502) e do nó do usuário B. Em algumas implementações, a atualização pode ser realizada com base na adição de textos cifrados do valor da transação e da alteração nos valores de ativos criptografados mantidos pelo nó do usuário A
(502) e pelo nó do usuário B. Um exemplo de transação de protocolo de confiança (400) e atualizações de conta correspondentes são descritos na descrição da Figura 4.
[0086] A Figura 6 ilustra um exemplo de um processo (600) que pode ser executado de acordo com implementações da invenção. Para clareza de apresentação, a descrição que se segue geralmente descreve o método (600) no contexto das outras figuras nesta descrição. No entanto, será entendido que o processo de exemplo (600) pode ser realizado, por exemplo, por qualquer sistema, ambiente, software e hardware, ou uma combinação de sistemas, ambientes, software e hardware, como apropriado. Em algumas implementações, as etapas do processo de exemplo (600) podem ser executadas em paralelo, em combinação, em loops ou em qualquer ordem.
[0087] No (602), um nó de consenso recebe dados de transação associados à transação. Em alguns exemplos, os dados de transação compreendem dados representativos de uma pluralidade de ativos, um primeiro compromisso que oculta um primeiro número aleatório e um valor de transação da transação, um segundo compromisso que oculta um segundo número aleatório e uma alteração calculada com base na dedução do valor da transação de um valor total da pluralidade de ativos, o valor da transação e um terceiro número aleatório criptografado por uma chave pública do segundo nó com base em um esquema probabilístico HE, a alteração e um quarto número aleatório criptografados por uma chave pública do primeiro nó com base no esquema probabilístico HE, uma ou mais provas de intervalo, um ZKP e uma assinatura digital gerada com base em uma chave privada correspondente à chave pública do primeiro nó.
[0088] Em algumas implementações, cada uma da pluralidade de ativos é associada a um ou mais tipos de ativos, um valor de ativo oculto em um comprometimento e um número aleatório usados para gerar o comprometimento. Em algumas implementações, o nó de consenso determina que cada um da pluralidade de ativos está associado a um mesmo tipo de ativo. Em algumas implementações, o primeiro compromisso, o segundo compromisso e o compromisso que oculta o valor do ativo são gerados com base em um esquema de compromisso que é homomórfico.
[0089] Em algumas implementações, o terceiro número aleatório é criptografado com base no esquema probabilístico HE, tratando o valor da transação como um número aleatório, e o quarto número aleatório é criptografado com base no esquema probabilístico HE, tratando a alteração como um número aleatório. Em algumas implementações, o primeiro compromisso e o segundo compromisso são gerados com base em um esquema de compromisso do Pedersen, e o esquema probabilístico de HE é um esquema de criptografia de UO.
[0090] Em algumas implementações, o ZKP compreende um compromisso Pedersen que oculta um quinto número aleatório e um sexto número aleatório, um texto cifrado do quinto número aleatório e o sexto número aleatório criptografados pela chave pública da segunda conta com base no esquema de criptografia da UO, e um texto cifrado do quinto número aleatório e do sexto número aleatório criptografados pela chave pública da primeira conta com base no esquema de criptografia da UO.
[0091] Em (604), o nó de consenso verifica a assinatura digital com base na chave pública do primeiro nó.
[0092] Em (606), o nó de consenso determina que uma ou mais provas de intervalo provam que o valor da transação e a alteração são maiores, ou iguais a, zero.
[0093] Em (608), o nó de consenso determina que o valor total da pluralidade de notas é igual à soma do valor da transação e da alteração. Em algumas implementações, a determinação de que o valor total da pluralidade de ativos é igual à soma do valor da transação e a alteração é realizada com base no homomorfismo do esquema de comprometimento.
[0094] Em (610), o nó de consenso determina, com base no ZKP, que a transação é válida determinando que o primeiro número aleatório é igual ao terceiro número aleatório, o segundo número aleatório é igual ao quarto número aleatório e o valor da transação oculto no primeiro compromisso é igual à quantidade de transação criptografada pela chave pública do segundo nó.
[0095] Em algumas implementações, a transação é executada entre uma conta associada ao primeiro nó e uma conta associada ao segundo nó, e o método compreende ainda a atualização, depois de determinar que a transação é válida, a conta associada ao primeiro nó e a conta associado ao segundo nó com base no valor da transação e na alteração. Em algumas implementações, o ZKP é gerado e usado para determinar que a transação é válida com base nas propriedades probabilísticas de HE. Em algumas implementações, a determinação de que a transação é válida é executada com base no ZKP sem interações entre o primeiro e o segundo nó através da rede de protocolo de confiança.
[0096] A Figura 7 ilustra um exemplo de processo (700) que pode ser executado de acordo com implementações da invenção. Para clareza de apresentação, a descrição que se segue geralmente descreve o método (700) no contexto das outras figuras nesta descrição. No entanto, será entendido que o processo de exemplo (700) pode ser realizado, por exemplo, por qualquer sistema, ambiente, software e hardware, ou uma combinação de sistemas, ambientes, software e hardware, como apropriado. Em algumas implementações, as etapas do processo de exemplo (700) podem ser executadas em paralelo, em combinação, em loops ou em qualquer ordem.
[0097] No (702), um nó de consenso recebe dados de transação associados à transação. Em alguns exemplos, os dados de transação compreendem dados representativos de uma pluralidade de ativos, um primeiro compromisso que oculta um primeiro número aleatório e um valor de transação da transação, um segundo compromisso que oculta um segundo número aleatório e uma alteração calculada com base na dedução do valor da transação de um valor total da pluralidade de ativos, o valor da transação e um terceiro número aleatório criptografado por uma chave pública do segundo nó com base em um esquema determinístico linear HE, a alteração e um quarto número aleatório criptografados por uma chave pública de primeiro nó com base no esquema determinístico linear HE, uma ou mais provas de intervalo, um ZKP e uma assinatura digital gerada com base em uma chave privada correspondente à chave pública do primeiro nó.
[0098] Em algumas implementações, cada pluralidade de ativos é associada a um ou mais tipos de ativos, a um valor de ativo oculto em um comprometimento, e a um número aleatório usado para gerar o comprometimento. Em algumas implementações, o nó de consenso determina que cada pluralidade de ativos está associado a um mesmo tipo de ativo. Em algumas implementações, o primeiro compromisso, o segundo compromisso e o compromisso que oculta o valor do ativo são gerados com base em um esquema de compromisso que é homomórfico.
[0099] Em algumas implementações, o esquema linear determinístico de HE é derivado de um esquema probabilístico HE baseado na alteração de um número aleatório associado ao esquema probabilístico HE para um número fixo.
[00100] Em algumas implementações, o ZKP compreende um compromisso que oculta um quinto número aleatório e um sexto número aleatório, um texto cifrado do quinto número aleatório e o sexto número aleatório criptografados pela chave pública da segunda conta com base no esquema determinístico linear HE, e um texto cifrado do quinto número aleatório e o sexto número aleatório criptografados pela chave pública da primeira conta com base no esquema de determinístico linear HE.
[00101] No (704), o nó de consenso verifica a assinatura digital com base na chave pública do primeiro nó.
[00102] Em (706), o nó de consenso determina que uma ou mais provas de intervalo provam que o valor da transação e a alteração são cada um maior que, ou igual a, zero.
[00103] Em (708), o nó de consenso determina que o valor total da pluralidade de notas é igual à soma do valor da transação e da alteração. Em algumas implementações, a determinação de que o valor total da pluralidade de ativos é igual à soma do valor da transação e a alteração é realizada com base no homomorfismo do esquema de comprometimento.
[00104] Em (710), o nó de consenso determina, com base no ZKP, que a transação é válida determinando que o primeiro número aleatório é igual ao terceiro número aleatório, o segundo número aleatório é igual ao quarto número aleatório e o valor da transação oculto no primeiro compromisso é igual à quantidade de transação criptografada pela chave pública do segundo nó.
[00105] Em algumas implementações, a transação é executada entre uma conta associada ao primeiro nó e uma conta associada ao segundo nó, e o método compreende ainda a atualização, depois de determinar que a transação é válida, a conta associada ao primeiro nó e a conta associado ao segundo nó com base no valor da transação e na alteração. Em algumas implementações, o ZKP é gerado e usado para determinar que a transação é válida com base nas propriedades do determinístico linear HE. Em algumas implementações, a determinação de que a transação é válida é executada com base no ZKP sem interações entre o primeiro e o segundo nó através da rede de protocolo de confiança.
[00106] Figura 8 ilustra um exemplo de um nó de protocolo de confiança (800) que pode executar um processo de acordo com implementações da invenção. A um nível elevado, o nó protocolo de confiança (800) inclui uma unidade receptora (802), uma unidade de verificação (804), uma primeira unidade de determinação (806), uma segunda unidade de determinação (808) e uma terceira unidade de determinação (810).
[00107] Em algumas implementações, a unidade receptora (802) é operável para receber dados de transação associados à transação. Em alguns exemplos, os dados de transação compreendem dados representativos de uma pluralidade de ativos, um primeiro compromisso que oculta um primeiro número aleatório e um valor de transação da transação, um segundo compromisso que oculta um segundo número aleatório e uma alteração calculada com base na dedução do valor da transação de um valor total da pluralidade de ativos, o valor da transação e um terceiro número aleatório, ambos criptografados por uma chave pública do segundo nó com base em um esquema probabilístico HE, a alteração e um quarto número aleatório, ambos criptografados por uma chave pública do primeiro nó com base no esquema probabilístico HE, uma ou mais provas de intervalo, um ZKP e uma assinatura digital gerada com base em uma chave privada correspondente à chave pública do primeiro nó.
[00108] Em algumas implementações, a unidade receptora (802) é operável para receber dados de transação associados à transação, os dados da transação compreendem: dados representativos de uma pluralidade de ativos, um primeiro compromisso que oculta um primeiro número aleatório e um valor de transação da transação, segundo compromisso que oculta um segundo número aleatório e uma alteração calculada com base na dedução do valor da transação de um valor total da pluralidade de ativos, o valor da transação e um terceiro número aleatório ambos criptografado por uma chave pública do segundo nó com base em um esquema determinístico linear HE, a alteração e um quarto número aleatório ambos criptografados por uma chave pública do primeiro nó com base no esquema determinístico linear HE, uma ou mais provas de intervalo, um ZKP e uma assinatura digital gerada com base em uma chave privada correspondente a chave pública do primeiro nó.
[00109] Em algumas implementações, cada pluralidade de ativos é associada a um ou mais tipos de ativos, a um valor de ativo oculto em um comprometimento e a um número aleatório usado para gerar o comprometimento. Em algumas implementações, o nó de protocolo de confiança (800) determina que cada pluralidade de ativos está associado a um mesmo tipo de ativo. Em algumas implementações, o primeiro compromisso, o segundo compromisso e o compromisso que oculta o valor do ativo são gerados com base em um esquema de compromisso que é homomórfico. Em algumas implementações, o esquema determinístico linear de HE é derivado de um esquema probabilístico HE baseado na alteração de um número aleatório associado ao esquema probabilístico HE para um número fixo.
[00110] Em algumas implementações, o terceiro número aleatório é criptografado com base no esquema probabilístico HE, tratando o valor da transação como um número aleatório, e o quarto número aleatório é criptografado com base no esquema probabilístico HE, tratando a alteração como um número aleatório. Em algumas implementações, o primeiro compromisso e o segundo compromisso são gerados com base em um esquema de compromisso do Pedersen, e o esquema probabilístico de HE é um esquema de criptografia da UO.
[00111] Em algumas implementações, o ZKP compreende um compromisso Pedersen que oculta um quinto número aleatório e um sexto número aleatório, um texto cifrado do quinto número aleatório e o sexto número aleatório criptografados pela chave pública da segunda conta com base no esquema de criptografia da UO, e um texto cifrado do quinto número aleatório e do sexto número aleatório criptografado pela chave pública da primeira conta com base no esquema de criptografia da UO. Em algumas implementações, o ZKP compreende um compromisso que oculta um quinto número aleatório e um sexto número aleatório, um texto cifrado do quinto número aleatório e o sexto número aleatório criptografados pela chave pública da segunda conta com base no esquema determinístico linear HE, e um texto cifrado do quinto número aleatório e o sexto número aleatório criptografados pela chave pública da primeira conta com base no esquema de determinístico linear HE.
[00112] A unidade de verificação (804) é operável para verificar a assinatura digital baseado em chave pública do primeiro nó.
[00113] A primeira unidade de determinação (806) é operável para determinar uma ou mais provas de intervalo que provam que o valor da transação e a alteração são cada um maior que, ou igual a, zero.
[00114] A segunda unidade de determinação (808) é operável para determinar que o valor total da pluralidade de notas é igual à soma do valor da transação e da alteração. Em algumas implementações, a determinação de que o valor total da pluralidade de ativos é igual à soma do valor da transação e a alteração é realizada com base no homomorfismo do esquema de comprometimento.
[00115] A terceira unidade de determinação (810) é operável para determinar, com base no ZKP, que a transação é válida determinando que o primeiro número aleatório é igual ao terceiro número aleatório, o segundo número aleatório é igual ao quarto número aleatório e o valor da transação oculto no primeiro compromisso é igual ao valor de transação criptografado pela chave pública do segundo nó.
[00116] Em algumas implementações, a transação é realizada entre uma conta associada ao primeiro nó e uma conta associada ao segundo nó, e o nó de protocolo de confiança (800 )pode incluir uma unidade de atualização operável para atualização, após a terceira unidade de determinação (810) determinar que a transação é válida, a conta associada ao primeiro nó e a conta associada ao segundo nó com base no valor da transação e na alteração. Em algumas implementações, o ZKP é gerado e usado para determinar que a transação é válida com base nas propriedades probabilísticas HE. Em algumas implementações, o ZKP é gerado e usado para determinar que a transação é válida com base nas propriedades do determinístico linear HE. Em algumas implementações, a determinação de que a transação é válida é executada com base no ZKP sem interações entre o primeiro e o segundo nó através da rede de protocolo de confiança.
[00117] As implementações do assunto descrito nesta especificação podem ser implementadas de modo a realizar vantagens particulares ou efeitos técnicos. Por exemplo, implementações da invenção permitem que o saldo da conta e o valor da transação dos nós do protocolo de confiança sejam privados durante as transações. O destinatário da transferência de fundos não precisa confirmar a transação ou usar um número aleatório para verificar um compromisso, a validação da transação pode ser não interativa. Um nó de protocolo de confiança pode validar a transação com base nos esquemas HE e de comprometimento para permitir a prova de conhecimento zero.
[00118] A metodologia descrita permite o aprimoramento da segurança de conta/dados de vários dispositivos de computação móvel. O saldo da conta e valores da transação podem ser criptografados com base em HE e ocultos por esquemas de confirmação. Como tal, um nó de consenso pode atualizar os saldos de conta no registro após a transação com base nas propriedades do HE, sem revelar o saldo atual da conta. Como o número aleatório não precisa ser enviado a um destinatário para confirmar a transação,
o risco de vazamento de dados pode ser reduzido e menos ativos de computação e memória precisam ser usados para gerenciar o número aleatório.
[00119] As implementações e as operações descritas nesta especificação podem ser implementadas em circuitos eletrônicos digitais, ou em software de computador, firmware ou hardware, incluindo as estruturas divulgadas nesta especificação ou em combinações de uma ou mais delas. As operações podem ser implementadas como operações realizadas por um aparelho de processamento de dados em dados armazenados em um ou mais dispositivos de armazenamento legíveis por computador ou recebidos de outras fontes. Um dispositivo de processamento de dados, computador ou dispositivo de computação pode abranger aparelhos, dispositivos e máquinas para processamento de dados, incluindo, por exemplo, um processador programável, um computador, um sistema em um chip ou vários, ou combinações, dos precedentes. O aparelho pode incluir circuitos lógicos para fins especiais, por exemplo, uma unidade central de processamento (CPU), uma matriz de portas de campo programáveis (FPGA) ou um circuito integrado específico para aplicações (ASIC). O aparelho também pode incluir código que cria um ambiente de execução para o programa de computador em questão, por exemplo, código que constitui firmware do processador, uma pilha de protocolos, um sistema de gerenciamento de banco de dados, um sistema operacional (por exemplo, um sistema operacional ou uma combinação de sistemas operacionais), um ambiente de tempo de execução entre plataformas, uma máquina virtual ou uma combinação de um ou mais deles. O ambiente de aparelho e execução pode realizar vários modelos de infraestruturas de computação diferentes, como serviços da Web, computação distribuída e infraestruturas de computação em grade.
[00120] Um programa de computador (também conhecido,
por exemplo, como um programa, software, aplicativo de software, módulo de software, unidade de software, script ou código) pode ser escrito em qualquer forma de linguagem de programação, incluindo linguagens compiladas ou interpretadas, linguagens declarativas ou procedurais e pode ser implantado de qualquer forma, inclusive como um programa autônomo ou como um módulo, componente, sub-rotina, objeto ou outra unidade adequada para uso em um ambiente de computação. Um programa pode ser armazenado em uma parte de um arquivo que contém outros programas ou dados (por exemplo, um ou mais scripts armazenados em um documento de linguagem de marcação), em um único arquivo dedicado ao programa em questão ou em vários arquivos coordenados (por exemplo, arquivos que armazenam um ou mais módulos, subprogramas ou partes do código). Um programa de computador pode ser executado em um computador ou em vários computadores localizados em um site ou distribuídos em vários sites e interconectados por uma rede de comunicação.
[00121] Os processadores para execução de um programa de computador incluem, a título de exemplo, microprocessadores de propósito geral e especial, e qualquer um ou mais processadores de qualquer tipo de computador digital. Geralmente, um processador receberá instruções e dados de uma memória somente leitura ou de uma memória de acesso aleatório ou de ambos. Os elementos essenciais de um computador são um processador para executar ações de acordo com as instruções e um ou mais dispositivos de memória para armazenar instruções e dados. Geralmente, um computador também incluirá, ou estará acoplado operacionalmente para receber dados ou transferir dados para, ou ambos, um ou mais dispositivos de armazenamento em massa para armazenamento de dados. Um computador pode ser incorporado em outro dispositivo, por exemplo, um dispositivo móvel, um assistente digital pessoal (PDA), um console de jogos, um receptor de Sistema de Posicionamento Global (GPS) ou um dispositivo de armazenamento portátil.
Dispositivos adequados para armazenar instruções e dados de programas de computador incluem memória não volátil, mídia e dispositivos de memória, incluindo, a título de exemplo, dispositivos de memória semicondutores, discos magnéticos e discos magneto-ópticos. O processador e a memória podem ser complementados por, ou incorporados em, circuitos lógicos de propósito especial.
[00122] Os dispositivos móveis podem incluir aparelho telefônico, equipamentos de usuário (UE), telefones celulares (por exemplo, smartphones), tablets, dispositivos vestíveis (por exemplo, relógios inteligentes e óculos inteligentes), dispositivos implantados no corpo humano (por exemplo, biosensores, implantes cocleares) ou outros tipos de dispositivos móveis. Os dispositivos móveis podem se comunicar sem fio (por exemplo, usando sinais de radiofreqüência (RF)) para várias redes de comunicação (descritas abaixo).
Os dispositivos móveis podem incluir sensores para determinar as características do ambiente atual do dispositivo móvel. Os sensores podem incluir câmeras, microfones, sensores de proximidade, sensores GPS, sensores de movimento, acelerômetros, sensores de luz ambiente, sensores de umidade, giroscópios, bússolas, barômetros, sensores de impressão digital, sistemas de reconhecimento facial, sensores RF (por exemplo, Wi-Fi e celular rádios), sensores térmicos ou outros tipos de sensores. Por exemplo, as câmeras podem incluir uma câmera voltada para frente ou para trás com lentes móveis ou fixas, um flash, um sensor de imagem e um processador de imagem. A câmera pode ser uma câmera megapixel capaz de capturar detalhes para reconhecimento facial e/ ou de íris. A câmera, juntamente com um processador de dados e informações de autenticação armazenadas na memória ou acessadas remotamente, podem formar um sistema de reconhecimento facial. O sistema de reconhecimento facial ou um ou mais sensores, por exemplo, microfones, sensores de movimento, acelerômetros, sensores de GPS ou sensores de RF, podem ser usados para autenticação do usuário.
[00123] Para proporcionar a interação com um usuário, as implementações podem ser implementadas em um computador com um dispositivo de exibição e um dispositivo de entrada, por exemplo, um monitor de cristal líquido (LCD) ou diodo orgânico emissor de luz (OLED)/ realidade virtual (VR)/ exibição de realidade aumentada (AR) para exibir informações para o usuário e uma tela sensível ao toque, teclado e um dispositivo apontador pelo qual o usuário pode fornecer entrada para o computador.
Outros tipos de dispositivos também podem ser usados para fornecer interação com um usuário; por exemplo, o feedback fornecido ao usuário pode ser qualquer forma de feedback sensorial, por exemplo, feedback visual, feedback auditivo ou feedback tátil; e a entrada do usuário pode ser recebida de qualquer forma, incluindo entrada acústica, de fala ou tátil. Além disso, um computador pode interagir com um usuário enviando documentos e recebendo documentos de um dispositivo usado pelo usuário; por exemplo, enviando páginas da web para um navegador da web no dispositivo do cliente de um usuário em resposta a solicitações recebidas do navegador da web.
[00124] As implementações podem ser implementadas usando dispositivos de computação interconectados por qualquer forma ou meio de comunicação de dados digitais com fio ou sem fio (ou combinação dos mesmos), por exemplo, uma rede de comunicação. Exemplos de dispositivos interconectados são um cliente e um servidor geralmente remotos entre si que normalmente interagem através de uma rede de comunicação. Um cliente, por exemplo, um dispositivo móvel, pode realizar transações em si, com um servidor ou através de um servidor, por exemplo, realizando transações de compra, venda, pagamento, entrega, envio ou empréstimo, ou autorizando o mesmo. Tais transações podem ser em tempo real, de modo que uma ação e uma resposta estejam temporariamente próximas; por exemplo, um indivíduo percebe a ação e a resposta ocorrendo substancialmente simultaneamente, a diferença de tempo para uma resposta após a ação do indivíduo é menor que 1 milissegundo (ms) ou menor que 1 segundo (s), ou a resposta é sem atrasos intencionais das limitações de processamento da conta do sistema.
[00125] Exemplos de redes de comunicação incluem uma rede local (LAN), uma rede de acesso de rádio (RAN), uma rede de área metropolitana (MAN) e uma rede de longa distância (WAN). A rede de comunicação pode incluir toda ou parte da Internet, outra rede de comunicação ou uma combinação de redes de comunicação. As informações podem ser transmitidas na rede de comunicação de acordo com vários protocolos e padrões, incluindo Evolução a Longo Prazo (LTE), 5G, IEEE 802, Protocolo Internet (IP) ou outros protocolos ou combinações de protocolos. A rede de comunicação pode transmitir voz, vídeo, dados biométricos ou de autenticação de dados ou outras informações entre os dispositivos de computação conectados.
[00126] Os recursos descritos como implementações separadas podem ser implementados, em combinação, em uma única implementação, enquanto os recursos descritos como uma implementação única podem ser implementados em várias implementações, separadamente ou em qualquer subcombinação adequada. As operações descritas e reivindicadas em uma ordem específica não devem ser entendidas como exigindo que a ordem específica, nem que todas as operações ilustradas sejam executadas (algumas operações podem ser opcionais). Conforme apropriado, a multitarefa ou o processamento paralelo (ou uma combinação de multitarefa e processamento paralelo) podem ser executados.

Claims (12)

REIVINDICAÇÕES
1. MÉTODO IMPLEMENTADO POR COMPUTADOR realizado por um nó de consenso para validar uma transação entre um primeiro nó e um segundo nó dentro de uma rede de protocolo de confiança, o método caracterizado por compreender: receber dados de transação associados à transação, os dados da transação compreendem: dados representativos de uma pluralidade de ativos, um primeiro compromisso que oculta um primeiro número aleatório e um valor de transação da transação, um segundo compromisso que oculta um segundo número aleatório e uma alteração calculada com base na dedução do valor da transação de um valor total da pluralidade de ativos, o valor da transação e um terceiro número aleatório ambos criptografados por uma chave pública do segundo nó com base em um esquema de criptografia homomórfica probabilística (HE), a alteração e um quarto número aleatório ambos criptografados por uma chave pública do primeiro nó com base no esquema probabilístico HE, uma ou mais provas de intervalo, uma prova de conhecimento zero (ZKP) e uma assinatura digital gerada com base em uma chave privada correspondente à chave pública do primeiro nó; verificar a assinatura digital com base na chave pública do primeiro nó; determinar que uma ou mais provas de intervalo provam que o valor da transação e a alteração são cada um maior que, ou igual a, zero; determinar que o valor total da pluralidade de ativos é igual a uma soma do valor da transação e a alteração; e determinar, com base no ZKP, que a transação é válida determinando que o primeiro número aleatório é igual ao terceiro número aleatório, o segundo número aleatório é igual ao quarto número aleatório, e o valor da transação oculto no primeiro compromisso é igual ao valor de transação criptografado pela chave pública do segundo nó.
2. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 1, caracterizado pela operação ser realizada entre uma conta associada com o primeiro nó e uma conta associada com o segundo nó, e o método compreendendo ainda a atualização, depois de determinar que a transação é válida, da conta associada ao primeiro nó e da conta associada ao segundo nó com base no valor da transação e na alteração.
3. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 1, caracterizado por cada pluralidade de ativos estar associada com um ou mais de um tipo de ativo, um valor de ativo oculto em um compromisso, e um número aleatório usado para gerar o compromisso.
4. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 3, caracterizado por compreender ainda a determinação de que cada pluralidade de ativos está associada a um mesmo tipo de ativo.
5. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 3, caracterizado pelo primeiro compromisso, pelo segundo compromisso e pelo compromisso que oculta o valor do ativo serem gerados com base em um esquema de compromisso que é homomórfico, e em que a determinação de que o valor total da pluralidade de ativos é igual à soma do valor da transação e a alteração é realizada com base no homomorfismo do esquema de comprometimento.
6. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 1, caracterizado pelo terceiro número aleatório ser criptografado com base no esquema probabilístico HE, tratando a quantidade de transação como um número aleatório, e o quarto número aleatório ser criptografado com base no esquema probabilístico HE, tratando a alteração como um número aleatório.
7. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 1, caracterizado pelo primeiro compromisso e o segundo compromisso serem gerados com base em um esquema de comprometimento Pedersen e o esquema probabilística HE ser um esquema de criptografia Okamoto-Uchiyama (OU).
8. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 7, caracterizado pelo ZKP compreender um compromisso Pedersen que oculta um quinto número aleatório e um sexto número aleatório, um texto cifrado do quinto número aleatório e o sexto número aleatório criptografado pela chave pública da segunda conta baseada no esquema de criptografia OU, e um texto cifrado do quinto número aleatório e sexto número aleatório criptografado pela chave pública da primeira conta com base no esquema de criptografia da OU.
9. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 1, caracterizado pelo ZKP ser gerado e utilizado para determinar que a transação é válida com base nas propriedades probabilísticas HE.
10. MÉTODO IMPLEMENTADO POR COMPUTADOR, de acordo com a reivindicação 1, caracterizado pela determinação de que a transação é válida ser realizada com base no ZKP sem interações entre o primeiro nó e o segundo nó através da rede de protocolo de confiança.
11. MEIO DE ARMAZENAMENTO NÃO TRANSITÓRIO LEGÍVEL POR COMPUTADOR, caracterizado por ser acoplado a um ou mais computadores e configurado com instruções executáveis por um ou mais computadores para realizar operações de acordo com o método, conforme definido em qualquer uma das reivindicações 1 a 10.
12. SISTEMA, caracterizado por compreender:
um ou mais computadores; e uma ou mais memórias legíveis por computador acopladas a um ou mais computadores e configuradas com instruções executáveis por um ou mais computadores para realizar operações de acordo com o método,
conforme definido em qualquer uma das reivindicações 1 a 10.
BR112019016474-0A 2018-12-21 2018-12-21 método implementado por computador, meio de armazenamento não transitório legível por computador e sistema BR112019016474A2 (pt)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2018/122539 WO2019072300A2 (en) 2018-12-21 2018-12-21 BLOCK CHAIN DATA PROTECTION BASED ON A GENERIC ACCOUNT MODEL AND A HOMOMORPHIC ENCRYPTION

Publications (1)

Publication Number Publication Date
BR112019016474A2 true BR112019016474A2 (pt) 2021-06-29

Family

ID=66100147

Family Applications (1)

Application Number Title Priority Date Filing Date
BR112019016474-0A BR112019016474A2 (pt) 2018-12-21 2018-12-21 método implementado por computador, meio de armazenamento não transitório legível por computador e sistema

Country Status (14)

Country Link
US (2) US10680800B2 (pt)
EP (1) EP3566197B1 (pt)
JP (1) JP6811334B2 (pt)
KR (1) KR102213414B1 (pt)
CN (1) CN111602161B (pt)
AU (1) AU2018347201B2 (pt)
BR (1) BR112019016474A2 (pt)
CA (1) CA3052997C (pt)
MX (1) MX2019009412A (pt)
PH (1) PH12019501849A1 (pt)
RU (1) RU2719451C1 (pt)
SG (1) SG11201907281WA (pt)
WO (1) WO2019072300A2 (pt)
ZA (1) ZA201905220B (pt)

Families Citing this family (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10708234B2 (en) * 2016-03-24 2020-07-07 International Business Machines Corporation System, method, and recording medium for preventing back propogation of data protection
US10644876B2 (en) * 2017-01-20 2020-05-05 Enveil, Inc. Secure analytics using homomorphic encryption
US11196541B2 (en) 2017-01-20 2021-12-07 Enveil, Inc. Secure machine learning analytics using homomorphic encryption
US11507683B2 (en) 2017-01-20 2022-11-22 Enveil, Inc. Query processing with adaptive risk decisioning
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
US10972251B2 (en) 2017-01-20 2021-04-06 Enveil, Inc. Secure web browsing via homomorphic encryption
EP3628113B1 (en) * 2018-05-08 2023-08-23 Visa International Service Association Sybil-resistant identity generation
US10902133B2 (en) 2018-10-25 2021-01-26 Enveil, Inc. Computational operations in enclave computing environments
US10817262B2 (en) 2018-11-08 2020-10-27 Enveil, Inc. Reduced and pipelined hardware architecture for Montgomery Modular Multiplication
PL3560144T3 (pl) 2018-12-21 2021-10-25 Advanced New Technologies Co., Ltd. Ochrona danych łańcucha bloków oparta na ogólnym modelu konta i szyfrowaniu homomorficznym
RU2719451C1 (ru) 2018-12-21 2020-04-17 Алибаба Груп Холдинг Лимитед Защита данных цепочек блоков на основе общей модели на основе счетов и гомоморфного шифрования
CN110070443B (zh) * 2019-04-23 2023-07-11 深圳前海微众银行股份有限公司 一种基于区块链的票据处理方法及装置
CN110223063B (zh) * 2019-05-07 2023-06-20 平安科技(深圳)有限公司 基于零知识证明的供应链数据管理方法及装置
CN110414985A (zh) * 2019-06-12 2019-11-05 阿里巴巴集团控股有限公司 一种异常账户的检测方法及装置
US10778410B2 (en) 2019-06-18 2020-09-15 Alibaba Group Holding Limited Homomorphic data encryption method and apparatus for implementing privacy protection
CN110348231B (zh) * 2019-06-18 2020-08-14 阿里巴巴集团控股有限公司 实现隐私保护的数据同态加解密方法及装置
US10790990B2 (en) * 2019-06-26 2020-09-29 Alibaba Group Holding Limited Ring signature-based anonymous transaction
US20200175509A1 (en) * 2019-06-28 2020-06-04 Alibaba Group Holding Limited Transferring method and system based on blockchain smart contract
CN110545279A (zh) * 2019-09-05 2019-12-06 国网区块链科技(北京)有限公司 兼具隐私和监管功能的区块链交易方法、装置及系统
CN111078787B (zh) * 2019-11-11 2023-07-21 重庆邮电大学 一种基于随机数映射的区块链共识方法
CN111104968B (zh) * 2019-12-02 2023-04-18 北京理工大学 一种基于区块链的安全svm训练方法
CN113032478B (zh) * 2019-12-24 2023-10-31 航天信息股份有限公司 区块链系统及数据上链方法、装置、设备和介质
WO2020098833A2 (en) 2020-02-03 2020-05-22 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain-based trustable gurantees
EP3799644B1 (en) * 2020-02-03 2022-11-02 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain-based trustable guarantees
CN111433799B (zh) * 2020-02-03 2022-03-25 支付宝(杭州)信息技术有限公司 基于区块链的可信保函
CN111311265B (zh) * 2020-02-13 2023-07-25 布比(北京)网络技术有限公司 区块链私密交易证明方法、装置、计算机设备和存储介质
CN111538782B (zh) * 2020-04-14 2023-08-08 浙江浙燃能源有限公司 基于区块链的能源大数据管理系统
CN112464178B (zh) * 2020-09-27 2024-04-19 中国科学技术大学苏州研究院 一种基于区块链和同态加密的数据交易版权保护方法
US11601258B2 (en) 2020-10-08 2023-03-07 Enveil, Inc. Selector derived encryption systems and methods
NL2026713B1 (en) * 2020-10-20 2021-12-14 Shenzhen Polytechnic A Blockchain Privacy Protection System and Its Method
CN114553426B (zh) * 2020-11-26 2023-08-15 中移物联网有限公司 签名验证方法、密钥管理平台、安全终端及电子设备
WO2022153377A1 (ja) * 2021-01-13 2022-07-21 富士通株式会社 制御方法、情報処理システム、情報処理装置および制御プログラム
CN113159762B (zh) * 2021-01-28 2024-04-09 武汉天喻信息产业股份有限公司 基于Paillier和博弈论的区块链交易方法
CN112765667B (zh) * 2021-01-29 2022-04-26 北京市计算中心有限公司 基于区块链的隐私保护方法、装置及系统
CN112906073A (zh) * 2021-03-18 2021-06-04 上海能链众合科技有限公司 一种区块链机密计算通用模型的实现方法
CN113254954A (zh) * 2021-04-30 2021-08-13 中核武汉核电运行技术股份有限公司 一种基于区块链的核电数据安全方法和装置
CN113268777B (zh) * 2021-05-21 2023-05-12 中国联合网络通信集团有限公司 基于区块链的投标信息的处理方法及模块、电子设备
KR102671062B1 (ko) * 2021-07-07 2024-05-30 라인플러스 주식회사 보안 거래를 위한 방법 및 시스템
CN114117503B (zh) * 2022-01-24 2022-06-24 连连宝(杭州)信息技术有限公司 一种加密数据处理方法、装置、系统及存储介质
CN114760071B (zh) * 2022-06-13 2022-10-28 深圳市永达电子信息股份有限公司 基于零知识证明的跨域数字证书管理方法、系统和介质
JP2024022339A (ja) 2022-08-05 2024-02-16 富士通株式会社 対価分配プログラム、対価分配方法及び対価分配装置
JP2024024554A (ja) 2022-08-09 2024-02-22 富士通株式会社 対価分配プログラム、対価分配方法及び情報管理装置
CN115118411B (zh) * 2022-08-29 2022-11-29 人民法院信息技术服务中心 链下多方可信计算方法、装置、设备及存储介质
CN116821936B (zh) * 2023-06-30 2024-09-17 北京海泰方圆科技股份有限公司 一种数据交集的确定方法及装置

Family Cites Families (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5394116A (en) 1993-12-29 1995-02-28 At&T Corp. Fractional phase shift ring oscillator arrangement
IT1284718B1 (it) 1996-07-31 1998-05-21 Cselt Centro Studi Lab Telecom Dispositivo e procedimento per allineare temporalmente segnali numerici, ad esempio un segnale di orologio ed un flusso di dati.
FR2800220B1 (fr) * 1999-10-26 2002-02-15 France Telecom Procede de transaction electronique securisee
US20090327141A1 (en) 2007-04-18 2009-12-31 Rabin Michael O Highly efficient secrecy-preserving proofs of correctness of computation
US20090177591A1 (en) 2007-10-30 2009-07-09 Christopher Thorpe Zero-knowledge proofs in large trades
EP2590126A1 (en) * 2011-11-01 2013-05-08 Nederlandse Organisatie voor toegepast -natuurwetenschappelijk onderzoek TNO Recommender system for providing recommendations to groups of users
WO2014201059A1 (en) * 2013-06-10 2014-12-18 Certimix, Llc Secure storing and offline transfering of digitally transferable assets
US20150242825A1 (en) * 2014-02-24 2015-08-27 Peter Burton Mills Generation, storage, and validation of encrypted electronic currency
WO2016076934A2 (en) * 2014-08-22 2016-05-19 Thomas John K Verification system for secure transmission in a distributed processing network
WO2016049406A1 (en) * 2014-09-26 2016-03-31 Technicolor Usa, Inc. Method and apparatus for secure non-interactive threshold signatures
US10257173B2 (en) * 2014-10-22 2019-04-09 Openeye Scientific Software, Inc. Secure comparison of information
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
RU2015145232A (ru) * 2015-10-21 2017-05-03 Дмитрий Сергеевич Ермолаев Способ учёта и хранения временных учётных единиц в одноуровневых средах на блокчейн
WO2017127564A1 (en) * 2016-01-19 2017-07-27 Priv8Pay, Inc. Network node authentication
US10846984B2 (en) * 2016-02-24 2020-11-24 Uplay1 Casino crypto currency systems and methods
US10046228B2 (en) 2016-05-02 2018-08-14 Bao Tran Smart device
US9635000B1 (en) * 2016-05-25 2017-04-25 Sead Muftic Blockchain identity management system based on public identities ledger
CN107438002B (zh) 2016-05-27 2022-02-11 索尼公司 基于区块链的系统以及系统中的电子设备和方法
JP6663809B2 (ja) * 2016-07-07 2020-03-13 株式会社日立製作所 監査装置、監査機能付匿名送金方法及びプログラム
US10243731B2 (en) * 2017-01-27 2019-03-26 Accenture Global Solutions Limited Hardware blockchain acceleration
KR101879353B1 (ko) * 2017-01-31 2018-07-17 권양호 가상화폐 중개 서비스 시스템 및 방법
US10832230B2 (en) 2017-04-04 2020-11-10 International Business Machines Corporation Scalable and distributed shared ledger transaction management
US10277395B2 (en) 2017-05-19 2019-04-30 International Business Machines Corporation Cryptographic key-generation with application to data deduplication
US10761877B2 (en) 2017-07-21 2020-09-01 Intel Corporation Apparatuses, methods, and systems for blockchain transaction acceleration
CN108418783B (zh) * 2017-09-01 2021-03-19 矩阵元技术(深圳)有限公司 一种保护区块链智能合约隐私的方法、介质
CN107656812A (zh) 2017-09-27 2018-02-02 咪咕文化科技有限公司 区块链处理方法、系统、节点设备、终端和存储介质
CN107766540A (zh) * 2017-10-31 2018-03-06 上海分布信息科技有限公司 一种分区的区块链网络及其实现分区存储的方法
CN108021821A (zh) * 2017-11-28 2018-05-11 北京航空航天大学 多中心区块链交易隐私保护系统及方法
US10833861B2 (en) 2017-11-28 2020-11-10 International Business Machines Corporation Protection of confidentiality, privacy and ownership assurance in a blockchain based decentralized identity management system
CN108418689B (zh) * 2017-11-30 2020-07-10 矩阵元技术(深圳)有限公司 一种适合区块链隐私保护的零知识证明方法和介质
WO2019109003A1 (en) * 2017-11-30 2019-06-06 Visa International Service Association Blockchain system for confidential and anonymous smart contracts
EP3741082B1 (en) * 2018-01-19 2021-12-29 Qed-It Systems Ltd. Proof chaining and decomposition
EP3522064B1 (en) * 2018-02-02 2021-12-22 Università Degli Studi Di Trento A method and apparatus for distributed, privacy-preserving and integrity-preserving exchange, inventory and order book
US20190251527A1 (en) * 2018-02-14 2019-08-15 Christopher Walter Surdak System, Method, and Computer Program Product for a Distributed, Cryptographically Secured Proof-of-Intent Transaction Network
GB201803815D0 (en) * 2018-03-09 2018-04-25 Nchain Holdings Ltd Computer-implemented methods and systems
CN108764874B (zh) * 2018-05-17 2021-09-07 深圳前海微众银行股份有限公司 基于区块链的匿名转账方法、系统及存储介质
CN109035029A (zh) * 2018-07-27 2018-12-18 阿里巴巴集团控股有限公司 基于区块链的资产转移方法及装置、电子设备
CN109039648B (zh) 2018-08-03 2021-09-03 克洛斯比尔有限公司 一种区块链的创建方法、设备及可读存储介质
PL3560144T3 (pl) 2018-12-21 2021-10-25 Advanced New Technologies Co., Ltd. Ochrona danych łańcucha bloków oparta na ogólnym modelu konta i szyfrowaniu homomorficznym
RU2719451C1 (ru) 2018-12-21 2020-04-17 Алибаба Груп Холдинг Лимитед Защита данных цепочек блоков на основе общей модели на основе счетов и гомоморфного шифрования

Also Published As

Publication number Publication date
CA3052997C (en) 2021-01-26
PH12019501849A1 (en) 2020-03-09
JP6811334B2 (ja) 2021-01-13
WO2019072300A3 (en) 2019-10-24
WO2019072300A2 (en) 2019-04-18
CN111602161A (zh) 2020-08-28
KR102213414B1 (ko) 2021-02-09
US20190327078A1 (en) 2019-10-24
CA3052997A1 (en) 2019-04-18
KR20200079219A (ko) 2020-07-02
EP3566197A4 (en) 2020-03-11
US10708039B1 (en) 2020-07-07
ZA201905220B (en) 2020-05-27
EP3566197A2 (en) 2019-11-13
US20200195419A1 (en) 2020-06-18
RU2719451C1 (ru) 2020-04-17
AU2018347201A1 (en) 2020-07-09
SG11201907281WA (en) 2019-09-27
US10680800B2 (en) 2020-06-09
AU2018347201B2 (en) 2020-08-27
EP3566197B1 (en) 2022-03-30
CN111602161B (zh) 2023-08-22
JP2020515885A (ja) 2020-05-28
MX2019009412A (es) 2019-10-02

Similar Documents

Publication Publication Date Title
BR112019016474A2 (pt) método implementado por computador, meio de armazenamento não transitório legível por computador e sistema
US11063769B2 (en) Blockchain data protection based on generic account model and homomorphic encryption
ES2863559T3 (es) Protección de datos de cadena de bloques en base al modelo de billete de cuenta con prueba de conocimiento cero
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

Legal Events

Date Code Title Description
B25A Requested transfer of rights approved

Owner name: ADVANTAGEOUS NEW TECHNOLOGIES CO., LTD. (KY)

B25A Requested transfer of rights approved

Owner name: ADVANCED NEW TECHNOLOGIES CO., LTD. (KY)

B08F Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette]

Free format text: REFERENTE A 5A ANUIDADE.

B08K Patent lapsed as no evidence of payment of the annual fee has been furnished to inpi [chapter 8.11 patent gazette]

Free format text: EM VIRTUDE DO ARQUIVAMENTO PUBLICADO NA RPI 2754 DE 17-10-2023 E CONSIDERANDO AUSENCIA DE MANIFESTACAO DENTRO DOS PRAZOS LEGAIS, INFORMO QUE CABE SER MANTIDO O ARQUIVAMENTO DO PEDIDO DE PATENTE, CONFORME O DISPOSTO NO ARTIGO 12, DA RESOLUCAO 113/2013.