BR112019016598A2 - Métodos implementado por computador, meios de armazenamento não transitório e sistemas - Google Patents

Métodos implementado por computador, meios de armazenamento não transitório e sistemas Download PDF

Info

Publication number
BR112019016598A2
BR112019016598A2 BR112019016598-3A BR112019016598A BR112019016598A2 BR 112019016598 A2 BR112019016598 A2 BR 112019016598A2 BR 112019016598 A BR112019016598 A BR 112019016598A BR 112019016598 A2 BR112019016598 A2 BR 112019016598A2
Authority
BR
Brazil
Prior art keywords
epoch
node
message
new
network
Prior art date
Application number
BR112019016598-3A
Other languages
English (en)
Inventor
Lin Peng
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 BR112019016598A2 publication Critical patent/BR112019016598A2/pt

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/142—Reconfiguring to eliminate the error
    • G06F11/1425—Reconfiguring to eliminate the error by reconfiguration of node membership
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1441—Resetting or repowering
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2041—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with more than one idle spare processing component
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/81—Threshold
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0659—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Power Engineering (AREA)
  • Hardware Redundancy (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

método para realizar uma alteração de um nó primário em uma rede de protocolo de confiança inclui um nó de cópia de segurança da rede de protocolo de confiança determinando que uma alteração de época precisa ser realizada, determinar um peso respectivo do nó de cópia de segurança associado com cada uma das três fases de um processo de consenso em uma época atual, determinar uma soma de peso para o nó de cópia de segurança com base nos respectivos pesos, enviando uma mensagem epoch_change para os outros nós de rede para solicitar um novo nó primário em uma nova época, receber mensagens new_epoch dos outros nós de rede, determinar se um número de mensagens new_epoch válidos excede um segundo limiar predeterminado, e determinar o nó de cópia de segurança como sendo o novo nó primário na nova época em resposta à determinação de que o número de mensagens new_epoch válidos excede o segundo limiar predeterminado.

Description

“MÉTODOS IMPLEMENTADO POR COMPUTADOR, MEIOS DE ARMAZENAMENTO NÃO TRANSITÓRIO E SISTEMAS” Referência Cruzada aos Depósitos Relacionados [001] Este pedido é uma continuação do pedido PCT ns PCT/CN2018/120873, depositado em 13 de dezembro de 2018, o qual é incorporado por referência em sua totalidade.
Antecedentes da Invenção [002] Os sistemas de contabilidade distribuída (DLSs), que também podem ser denominados redes de consenso e/ ou redes de protocolo de confiança (blockchain), permitem que as entidades participantes armazenem dados de forma segura e imutável. Os DLSs são comumente chamados de redes de protocolo de confiança sem fazer referência a nenhum caso de usuário específico. Exemplos de redes de protocolo de confiança podem incluir: redes de protocolo de confiança públicas, redes de protocolo de confiança privadas e redes de protocolo de confiança de consórcio. Uma rede de protocolo de confiança pública é aberta para todas as entidades usarem o DLS e participarem do processo de consenso. Uma rede de protocolo de confiança privada é fornecida para uma entidade específica, que controla centralmente as permissões de leitura e gravação. Uma rede de protocolo de confiança de consórcio é fornecida para um grupo seleto de entidades, que controlam o processo de consenso e incluem uma camada de controle de acesso.
[003] Mecanismos de consenso são um componente primário de sistemas distribuídos de protocolo de confiança. Um mecanismo de consenso é um processo em ciência da computação que é usado para alcançar um acordo sobre um único valor de dados entre processos ou sistemas distribuídos. Mecanismos de consenso são projetados para alcançar confiabilidade em uma rede envolvendo vários nós não confiáveis. Resolver esse problema Petição 870190097362, de 30/09/2019, pág. 9/134
2/91 conhecido como problema de consenso - é importante em sistemas de computação distribuída e de multi-agentes.
[004] O protocolo de confiança depende de mecanismos de consenso para chegar a acordo entre nós. Um protocolo de confiança é um banco de dados descentralizado gerenciado por computadores distribuídos em uma rede peer-to-peer (P2P). Cada parte (peer) mantém uma cópia do registro (ledger) para evitar um único ponto de falha (SPOF). Atualizações e validações são refletidas em todas as cópias simultaneamente.
[005] Embora várias técnicas existentes possam ser usadas para realizar o consenso entre os nós de rede de um sistema protocolo de confiança, uma solução mais eficiente para a realização de consenso seria vantajosa.
Descrição Resumida da Invenção [006] As implementações do presente relatório descritivo incluem métodos implementados por computador para resolver problemas de consenso em um sistema distribuído (por exemplo, uma rede de protocolo de confiança). Mais particularmente, as implementações da presente invenção destinam-se a realizar uma alteração do nó primário em um sistema distribuído.
[007] Em algumas implementações, as ações incluem: determinar por um nó de cópia de segurança de uma rede de protocolo de confiança que uma alteração de época precisa ser executada, em que a alteração de época causa uma alteração de uma época atual com um nó primário atual para uma nova época com um novo nó primário, em que a época atual inclui um processo de consenso para alcançar o consenso entre um número de nós de rede utilizando o nó primário e em que o processo de consenso inclui três fases; determinar, pelo nó de cópia de segurança, um peso respectivo do nó de cópia de segurança associado a cada uma das três fases do processo de consenso na época atual; determinar uma soma de peso
Petição 870190097362, de 30/09/2019, pág. 10/134
3/91 para o nó de cópia de segurança pelo nó de cópia de segurança com base no peso respectivo do nó de cópia de segurança associado a cada uma das três fases na época atual; enviar uma mensagem EPOCH_CHANGE pelo nó de cópia de segurança para o número de nós de rede diferente do nó de rede em resposta a determinação de que a soma de peso atinge um primeiro limiar predeterminado, em que a mensagem EPOCH_CHANGE indica uma solicitação para uma alteração da época atual com o nó primário atual para a nova época, com o nó de cópia de segurança sendo o novo nó primário, e a EPOCH-CHANGE inclui a soma de peso do nó de cópia de segurança; receber pelo menos uma mensagem NEW_EPOCH pelo nó de cópia de segurança de pelo menos um número de nós de rede diferente do nó de cópia de segurança, em que a mensagem NEW_EPOCH indica uma confirmação de que o nó de cópia de segurança é o novo nó primário; verificar pelo nó de cópia de segurança se a pelo menos uma mensagem NEW_EPOCH é válida; determinar pelo nó de cópia de segurança se um número de mensagens NEW_EPOCH válidas de pelo menos uma mensagem NEW_EPOCH excede um segundo limiar predeterminado; e determinar que o nó de cópia de segurança seja o novo nó primário na nova época pelo nó de cópia de segurança em resposta a determinação de que o número de mensagens NEW_EPOCH válidas excede o segundo limiar predeterminado.
[008] 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.
[009] Essas e outras implementações podem incluir, opcionalmente, um ou mais das seguintes características:
Uma primeira característica, combinável com qualquer uma das seguintes características, em que o nó de cópia de segurança determina um peso do nó de cópia de segurança para uma
Petição 870190097362, de 30/09/2019, pág. 11/134
4/91 primeira fase do processo de consenso como sendo um primeiro valor.
[0010] Uma segunda característica, combinável com qualquer uma das seguintes características, em que o nó de cópia de segurança determina um peso do nó de cópia de segurança para a segunda fase do processo de consenso como sendo um primeiro valor em resposta à determinação de uma falha na verificação de quórum em uma segunda fase do processo de consenso na época atual e o nó de cópia de segurança determina que o peso do nó de cópia de segurança para a segunda fase do processo de consenso seja um segundo valor maior que o primeiro valor em resposta à determinação do sucesso de uma verificação de quórum na segunda fase do processo de consenso na época atual.
[0011] Uma terceira característica, combinável com qualquer uma das seguintes características, em que a verificação do quórum na segunda fase do nó de rede inclui o recebimento de um número predeterminado de mensagens ECHO de outros nós de rede.
[0012] Uma quarta característica, combinável com qualquer uma das seguintes características, em que os nós de cópia de segurança determinam um peso do nó de cópia de segurança para a terceira fase do processo de consenso como sendo um terceiro valor em resposta à determinação de uma falha de uma verificação de quórum em uma terceira fase do processo de consenso na época atual, e o nó de cópia de segurança determina que o peso do nó de cópia de segurança para a terceira fase do processo de consenso seja um quarto valor maior que o terceiro valor em resposta à determinação do sucesso de uma verificação de quórum na terceira fase do processo de consenso na época atual.
[0013] Uma quinta característica, combinável com qualquer uma das seguintes características, em que a verificação de quórum na terceira fase
Petição 870190097362, de 30/09/2019, pág. 12/134
5/91 para o nó de rede compreende receber um número predeterminado de mensagens de aceitação de outros nós de rede, em que cada uma das mensagens de aceitação de outros nós de rede indica que cada um dos outros nós de rede aceitou um número predeterminado de mensagens ECHO.
[0014] Uma sexta característica, combinável com qualquer uma das seguintes características, em que a mensagem EPOCH_CHANGE inclui ainda um conjunto de assinaturas associadas a um conjunto de nós de rede do número de nós de rede e em que a mensagem NEW_EPOCH inclui um resumo da mensagem EPOCH_ CHANGE.
[0015] Uma sétima característica, combinável com qualquer uma das seguintes características, em que verificar se a pelo menos uma mensagem NEW_EPOCH válida é válida, inclui verificar se o resumo da mensagem EPOCH_CHANGE na pelo menos uma mensagem NEW_EPOCH é válido.
[0016] Uma oitava característica, combinável com qualquer uma das seguintes características, em que verificar se o resumo da mensagem EPOCH_CHANGE na pelo menos uma mensagem NEW_EPOCH é válido, inclui verificar se o conjunto de assinaturas na mensagem EPOCH_CHANGE é válido.
[0017] Uma nona característica, combinável com qualquer uma das seguintes características, em que os nós de cópia de segurança determinam que uma alteração de época precisa ser executada em resposta a determinação de que o consenso não foi alcançado na época antiga dentro de um período de tempo predeterminado.
[0018] Uma décima característica, combinável com qualquer uma das seguintes características, em que a nova época inclui um processo de consenso para obter consenso entre o número de nós de rede usando o novo nó primário.
Petição 870190097362, de 30/09/2019, pág. 13/134
6/91 [0019] Em algumas implementações, as ações incluem: receber, por um nó de rede de vários nós de rede, uma mensagem EPOCH_CHANGE de um nó de cópia de segurança diferente do nó de rede, em que a mensagem EPOCH_CHANGE inclui uma indicação de que uma alteração de época precisa ser executada, em que a alteração de época causa uma alteração de uma época atual com um nó primário atual para uma nova época com um novo nó primário; verificar, pelo nó de rede, se a mensagem EPOCH_CHANGE é válida; em resposta a verificar que a mensagem EPOCH_CHANGE é válida, enviar, pelo nó de rede, uma mensagem NEW_EPOCH para os outros nós de rede, em que a mensagem NEW_EPOCH inclui um resumo da mensagem EPOCH_CHANGE; receber, pelo nó de rede, pelo menos uma mensagem NEW_EPOCH de pelo menos um dos números de nós de rede diferentes do nó de rede; verificar, pelo nó de rede, se a pelo menos uma mensagem NEW_EPOCH é válida; determinar, pelo nó de cópia de segurança, se um número de mensagens NEW_EPOCH válidas de pelo menos uma mensagem NEW_EPOCH excede um limiar predeterminado; e em resposta a determinação de que o número de mensagens NEW_EPOCH válidas excede o limiar predeterminado, determinar, pelo nó de rede, o nó de cópia de segurança para ser o novo nó primário na nova época.
[0020] 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.
[0021] Essas e outras implementações podem incluir, opcionalmente, uma ou mais das seguintes características:
Uma primeira característica, combinável com qualquer uma das seguintes características, em que a mensagem EPOCH_CHANGE inclui uma soma de peso associada ao nó de cópia de segurança e um conjunto de
Petição 870190097362, de 30/09/2019, pág. 14/134
7/91 assinaturas associadas a um conjunto de nós de rede do número de nós de rede.
[0022] Uma segunda característica, combinável com qualquer uma das características a seguir, em que verificar se a mensagem EPOCH_CHANGE é válida inclui verificar se a soma de peso na mensagem EPOCH_CHANGE é válida, em que verificar se a soma de peso na mensagem EPOCH_CHANGE é válida inclui verificar se conjunto de assinaturas são válidas.
[0023] Uma terceira característica, combinável com qualquer uma das características a seguir, em que verificar se a pelo menos uma mensagem NEW_EPOCH é válida, inclui verificar se o resumo da mensagem EPOCH_CHANGE na pelo menos uma mensagem NEW_EPOCH é válido e em que verificar se o resumo da mensagem EPOCH_CHANGE na pelo menos uma mensagem NEW_EPOCH é válida inclui verificar se o conjunto de assinaturas na mensagem EPOCH_CHANGE é válido.
[0024] A presente invenção também fornece um ou mais meio de armazenamento legível por computador não transitório acoplado a um ou mais processadores e tendo instruções armazenadas no mesmo que, quando executado por um ou mais processadores, fazer com que os um ou mais processadores execute as operações em conformidade com implementações dos métodos aqui fornecidos.
[0025] A presente invenção fornece ainda um sistema para implementar os métodos aqui fornecidos. O sistema inclui um ou mais processadores, e um meio 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.
Petição 870190097362, de 30/09/2019, pág. 15/134
8/91 [0026] A presente invenção divulga melhores mecanismos de consenso, incluindo técnicas para alcançar o consenso entre os nós de rede em um sistema distribuído, realizar uma alteração de nó primário em um sistema distribuído e executar um processo de recuperação para um nó de rede em um sistema distribuído. Os mecanismos de consenso descritos podem alcançar várias vantagens em diferentes aplicações.
[0027] Por exemplo, o processo de consenso, conforme discutido abaixo, inclui muitos recursos que melhoram as operações do sistema de protocolo de confiança e ajudam a aliviar o gargalo da rede. Por exemplo, o processo de consenso descrito inclui converter uma solicitação de transação em um número de blocos de código de eliminação (EC) de acordo com um código EC e enviar um dos blocos EC para cada um dos nós de rede. O bloco EC é menor em tamanho que o pedido de transação original. Assim, o envio do bloco EC em vez da solicitação de transação completa para os nós de rede reduz o tamanho dos blocos de dados que são transmitidos entre os nós de rede da rede de protocolo de confiança, conservando assim a largura de banda da rede e reduzindo a carga da rede. Isso reduz ainda mais o tamanho dos dados que são gravados e lidos a partir do espaço de memória dos nós de rede, reduzindo assim a carga no espaço de memória dos nós de rede e melhorando a eficiência do sistema de protocolo de confiança geral.
[0028] Além disso, o presente relatório descritivo descreve um processo de alteração de época que inclui atribuir pesos respectivos a múltiplas fases do processo de consenso, determinar uma soma de peso com base nos respectivos pesos das múltiplas fases e determinar um novo nó primário com base na soma de peso. O processo de alteração de época baseado na soma de peso em vez de um método round robin pode facilitar a escolha de um novo nó primário que não seja defeituoso em tempo hábil. Ao contrário do método round robin, o processo de alteração de época no
Petição 870190097362, de 30/09/2019, pág. 16/134
9/91 presente relatório descritivo depende da soma de peso para selecionar o novo nó primário, o que pode reduzir a latência ou atraso na localização do novo nó primário que não está com defeito. Isso pode melhorar ainda mais a eficiência do sistema de protocolo de confiança geral no fornecimento de serviços protocolo de confiança.
[0029] Além disso, o presente relatório descritivo discute um processo de recuperação que inclui operações como o envio de uma mensagem de solicitação de estado por um nó de rede que se aplica para ser um novo nó primário e receber mensagens de resposta de estado dos outros nós de rede. Essas operações são executadas de tal forma que o processo de recuperação do nó de rede com falha não interfere com a operação normal do processo de consenso entre os outros nós de rede não defeituosos. Isso facilita a conservação de recursos de computação e de rede para recuperar o nó de rede com falha, reduzindo a complexidade do processo de recuperação.
[0030] É conhecido que os métodos de acordo com a presente invenção podem incluir qualquer combinação dos aspectos e características aqui descritas. Isto é, os métodos de acordo com a presente invençã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.
[0031] Os detalhes de uma ou mais implementações da presente invenção são apresentados nos desenhos em anexo e na descrição abaixo. Outras características e vantagens da presente invenção serão evidentes a partir da descrição e desenhos, e das reivindicações.
Descrição dos Desenhos [0032] A Figura 1 representa um exemplo de um ambiente que pode ser usado para executar implementações da presente invenção.
[0033] A Figura 2 representa um exemplo de uma arquitetura
Petição 870190097362, de 30/09/2019, pág. 17/134
10/91 conceituai de acordo com implementações da presente invenção.
[0034] A Figura 3 representa um exemplo de um processo de consenso que pode ser executado de acordo com implementações da presente invenção.
[0035] A Figura 4 representa um exemplo de um processo de consenso que pode ser executado de acordo com implementações da presente invenção.
[0036] A Figura 5 representa um exemplo de um hash tree de acordo com implementações da presente invenção.
[0037] A Figura 6 representa um exemplo de mensagens que são comunicadas entre nós de rede de um sistema distribuído de acordo com implementações da presente invenção.
[0038] A Figura 7 representa um exemplo de um processo de realização de uma alteração de um nó primário em um sistema distribuído de acordo com implementações da presente invenção.
[0039] A Figura 8 representa um exemplo de um processo de realização de uma alteração de um nó primário em um sistema distribuído de acordo com implementações da presente invenção.
[0040] A Figura 9 representa um exemplo de mensagens que são comunicadas entre nós de rede de um sistema distribuído de acordo com implementações da presente invenção.
[0041] A Figura 10 representa um exemplo de um processo de realização de um processo de recuperação de um nó de rede em um sistema distribuído de acordo com as implementações da presente invenção.
[0042] A Figura 11 representa um exemplo de um processo de realização de um processo de recuperação de um nó de rede em um sistema distribuído de acordo com implementações da presente invenção.
[0043] A Figura 12 representa um exemplo de mensagens que
Petição 870190097362, de 30/09/2019, pág. 18/134
11/91 são comunicadas entre nós de rede de um sistema distribuído de acordo com implementações da presente invenção.
[0044] A Figura 13 representa um exemplo de um diagrama que representa módulos de um aparelho de consenso, de acordo com uma implementação da presente invenção.
[0045] A Figura 14 representa um exemplo de um diagrama que representa módulos de um aparelho de consenso, de acordo com uma implementação da presente invenção.
[0046] A Figura 15 representa um exemplo de um diagrama que representa módulos de um aparelho de alteração de nó primário, de acordo com uma implementação da presente invenção.
[0047] A Figura 16 representa um exemplo de um diagrama que ilustra módulos de um aparelho de alteração de nó primário, de acordo com uma implementação da presente invenção.
[0048] A Figura 17 representa um exemplo de um diagrama que representa módulos de um aparelho de recuperação, de acordo com uma implementação da presente invenção.
[0049] Os símbolos de referência semelhantes nos vários desenhos indicam elementos semelhantes.
Descrição Detalhada da Invenção [0050] As implementações da presente descrição incluem métodos implementados por computador para resolver questões de consenso em um sistema distribuído (por exemplo, uma rede de protocolo de confiança). Mais particularmente, as implementações da presente invenção destinam-se a realizar uma alteração do nó primário em um sistema distribuído.
[0051] Em algumas implementações, as ações incluem: determinar por um nó de cópia de segurança de uma rede de protocolo de confiança que uma alteração de época precisa ser executada, em que a
Petição 870190097362, de 30/09/2019, pág. 19/134
12/91 alteração de época causa uma alteração de uma época atual com um nó primário atual para uma nova época com um novo nó primário, em que a época atual inclui um processo de consenso para alcançar o consenso entre um número de nós de rede utilizando o nó primário e em que o processo de consenso inclui três fases; determinar, pelo nó de cópia de segurança, um peso respectivo do nó de cópia de segurança associado a cada uma das três fases do processo de consenso na época atual; determinar uma soma de peso para o nó de cópia de segurança pelo nó de cópia de segurança com base no peso respectivo do nó de cópia de segurança associado a cada uma das três fases na época atual; enviar uma mensagem EPOCH_CHANGE pelo nó de cópia de segurança para o número de nós de rede diferente do nó de rede em resposta a determinação de que a soma de peso atinge um primeiro limiar predeterminado, em que a mensagem EPOCH_CHANGE indica uma solicitação para uma alteração da época atual com o nó primário atual para a nova época, com o nó de cópia de segurança sendo o novo nó primário, e a EPOCH-CHANGE inclui a soma de peso do nó de cópia de segurança; receber pelo menos uma mensagem NEW_EPOCH pelo nó de cópia de segurança de pelo menos um número de nós de rede diferente do nó de cópia de segurança, em que a mensagem NEW_EPOCH indica uma confirmação de que o nó de cópia de segurança é o novo nó primário; verificar pelo nó de cópia de segurança se a pelo menos uma mensagem NEW_EPOCH é válida; determinar pelo nó de cópia de segurança se um número de mensagens NEW_EPOCH válidas de pelo menos uma mensagem NEW_EPOCH excede um segundo limiar predeterminado; e determinar que o nó de cópia de segurança seja o novo nó primário na nova época pelo nó de cópia de segurança em resposta a determinação de que o número de mensagens NEW_EPOCH válidas excede o segundo limiar predeterminado.
[0052] Em algumas implementações, as ações incluem: receber,
Petição 870190097362, de 30/09/2019, pág. 20/134
13/91 por um nó de rede de vários nós de rede, uma mensagem EPCOH_CHANGE de um nó de cópia de segurança diferente do nó de rede, em que a mensagem EPOCH_CHANGE inclui uma indicação de que uma alteração de época precisa ser executada, em que a alteração de época causa uma alteração de uma época atual com um nó primário atual para uma nova época com um novo nó primário; verificar, pelo nó de rede, se a mensagem EPOCH_CHANGE é válida; em resposta a verificar que a mensagem EPOCH_CHANGE é válida, enviar, pelo nó de rede, uma mensagem NEW_EPOCH aos outros nós de rede, em que a mensagem NEW_EPOCH inclui um resumo da mensagem EPOCH_CHANGE; receber, pelo nó de rede, pelo menos uma mensagem NEW_EPOCH de pelo menos um dos vários de nós de rede diferentes do nó de rede; verificar, pelo nó de rede, se a pelo menos uma mensagem NEW_EPOCH é válida; determinar, pelo nó de cópia de segurança, se um número de mensagens NEW_EPOCH válidas de pelo menos uma mensagem NEW_EPOCH excede um limiar predeterminado; e em resposta a determinação de que o número de mensagens NEW_EPOCH válidas excede o limiar predeterminado, determinar, pelo nó de rede, o nó de cópia de segurança para ser o novo nó primário na nova época.
[0053] Para fornecer um contexto adicional para implementações da presente invenção, e como foi introduzido acima, os sistemas de contabilidade distribuída (DLSs), que também podem ser referidos como redes de consenso (por exemplo, constituídos por nós peer-to-peer) ou redes de protocolo de confiança, permitem que entidades participantes realizem transações de forma segura e imutável e armazenem dados. O termo protocolo de confiança é aqui utilizado para referir-se genericamente a um DLS sem referência a qualquer caso de uso particular. Conforme introduzido 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
Petição 870190097362, de 30/09/2019, pág. 21/134
14/91 de protocolo de confiança de consórcio.
[0054] Um protocolo de confiança é uma estrutura de dados que armazena transações de modo a permitir que transações futuras sejam verificadas quanto à consistência com todas as transações anteriores armazenadas na cadeia. 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 de rede de protocolo de confiança, são hashed (obscurecido de modo que não pode ser lido) e codificadas em uma árvore Merkle. Uma árvore Merkle é uma estrutura de dados na qual os dados nos nós de folhas da árvore são obscurecidas e todos os obscurecidos 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 supostamente de uma transação armazenada na árvore pode ser verificado rapidamente determinando se é consistente com a estrutura da árvore.
[0055] 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 uma ou mais estruturas de protocolo 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.
[0056] Em uma rede de protocolo de confiança pública, o processo de consenso é controlado por nós de rede de consenso. Por exemplo, centenas, milhares e até milhões de entidades podem cooperar em
Petição 870190097362, de 30/09/2019, pág. 22/134
15/91 uma rede de protocolo de confiança pública, cada uma operando pelo menos um nó na rede de protocolo de confiança pública. Assim, a rede pública protocolo de confiança pode ser considerada 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 (registro distribuído) da rede de protocolo de confiança. Exemplos de redes de protocolo de confiança públicas incluem redes de pagamento peerto-peer particulares que utilizam 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.
[0057] Em geral, uma rede de protocolo de confiança pública suporta transações públicas. Uma transação pública é compartilhada com todos os nós dentro da rede de protocolo de confiança pública e é armazenada em um protocolo de confiança global. Um protocolo de confiança global é um protocolo de confiança que é 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 global. 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 na rede pública de protocolo de confiança. Exemplos de protocolos de consenso incluem, sem limitação, prova de trabalho (POW), prova de participação (POS) e prova de autoridade (POA). POW é aqui referenciado como um exemplo não limitativo.
[0058] Em geral, uma rede de protocolo de confiança privada é fornecida para uma entidade específica, que controla centralmente as permissões de leitura e gravação. A entidade controla quais nós são capazes de participar da rede de protocolo de confiança, portanto, as redes de protocolo
Petição 870190097362, de 30/09/2019, pág. 23/134
16/91 de confiança privadas são geralmente chamadas de redes de permissão que colocam restrições sobre quem pode participar da rede e seu nível de participação (por exemplo, somente em determinadas transações). Vários tipos de mecanismos de controle de acesso podem ser usados (por exemplo, os participantes existentes votam na adição de novas entidades, uma autoridade reguladora pode controlar a admissão).
[0059] Em geral, uma rede de protocolo de confiança de consórcio é privada entre as entidades participantes. Em uma rede de protocolo de confiança de consórcio, o processo de consenso é controlado por um conjunto autorizado de nós, um ou mais nós sendo operados por uma entidade respectiva (por exemplo, uma instituição financeira, companhia de seguros). Por exemplo, um consórcio de dez (10) entidades (por exemplo, instituições financeiras, seguradoras) pode operar uma rede de protocolo de confiança de consórcio, cada uma operando pelo menos um nó na rede de protocolo de confiança de consórcio. Nesse sentido, a rede de protocolo de confiança de consórcio pode ser considerada uma rede privada em relação às entidades participantes. Em alguns exemplos, cada entidade (nó) deve assinar todos os blocos para que o bloco seja válido e adicionado ao protocolo de confiança. Em alguns exemplos, pelo menos um subconjunto de entidades (nós) (por exemplo, pelo menos 7 entidades) deve assinar todos os blocos para que o bloco seja válido e adicionado ao protocolo de confiança.
[0060] As implementações da presente descrição são aqui descritas em maior detalhe com referência a uma rede de protocolo de confiança de consórcio. Está contemplado, no entanto, que as implementações da presente invenção podem ser realizadas em qualquer tipo apropriado de rede de protocolo de confiança.
[0061] As implementações da presente descrição são descritas em maior detalhe aqui em vista do contexto acima. Mais particularmente, e
Petição 870190097362, de 30/09/2019, pág. 24/134
17/91 como apresentado acima, as implementações da presente invenção destinamse a realizar um processo de recuperação para um nó de rede em um sistema distribuído.
[0062] Um protocolo de confiança é um registro digital compartilhado à prova de adulteração que registra transações em uma rede peer-to-peer pública ou privada. O registro é distribuído para todos os nós membros da rede e o histórico de transações de ativos ocorrendo na rede é permanentemente registrado no bloco.
[0063] Mecanismos de consenso garantem que todos os nós de rede em uma rede de protocolo de confiança distribuída executem transações na mesma ordem e, em seguida, escrevam nos mesmos registros. Uma questão que os modelos de consenso pretendem resolver é superar as falhas bizantinas. Em uma falha bizantina, um componente como um servidor ou um nó de rede de uma rede de protocolo de confiança distribuída pode aparecer inconsistentemente tanto com falha quanto funcionando com sistemas de detecção de falhas, apresentando sintomas diferentes para observadores diferentes. É difícil para os outros nós de rede declarar que ele falhou e desligá-lo da rede, porque eles precisam primeiro chegar a um consenso sobre qual nó de rede falhou em primeiro lugar.
[0064] No contexto de sistemas distribuídos, a tolerância a falhas bizantinas (BFT) é a capacidade de uma rede de computadores distribuída funcionar como desejado e alcançar corretamente um consenso suficiente apesar de componentes maliciosos (isto é, nós de rede de uma rede de protocolo de confiança) do sistema falharem ou propagarem informações incorretas para outros pares. O objetivo é defender-se contra falhas catastróficas do sistema, mitigando a influência que esses nós maliciosos têm sobre o funcionamento correto da rede e o consenso correto alcançado pelos nós honestos no sistema.
Petição 870190097362, de 30/09/2019, pág. 25/134
18/91 [0065] No entanto, os mecanismos de BFT existentes mostraramse ineficientes em muitos aspectos. Por exemplo, os mecanismos BFT existentes adicionaram complexidade de implementação à rede de protocolo de confiança distribuída ao tentar superar as falhas bizantinas, de modo que a latência é aumentada para a comunicação entre os nós de rede da rede de protocolo de confiança distribuída. A Tolerância à Falhas Bizantinas Práticas (PBFT) é uma das otimizações que visa melhorar os mecanismos de consenso existentes no BFT. O modelo PBFT se concentra em fornecer uma replicação de máquina de estado bizantina prática que tolera falhas bizantinas (nós maliciosos) por meio da suposição de que existem falhas de nó independentes e mensagens manipuladas que são propagadas por nós específicos e independentes.
[0066] No modelo PBFT, todos os nós são ordenados em uma sequência, com um nó sendo o nó primário (líder) e os outros referidos como nós de cópia de segurança. Todos os nós dentro do sistema se comunicam entre si e o objetivo é que a maioria dos nós honestos chegue a um acordo sobre o estado do sistema. Os nós se comunicam entre si e não apenas precisam provar que as mensagens vieram de um nó específico, mas também precisam verificar se a mensagem não foi modificada durante a transmissão.
[0067] Para que o modelo PBFT funcione, presume-se que a quantidade de nós maliciosos na rede não pode igualar ou exceder simultaneamente 1/3 dos nós gerais no sistema em uma determinada janela de vulnerabilidade. Quanto mais nós no sistema, mais matematicamente é improvável que um número que se aproxima de 1/3 dos nós gerais seja malicioso. O algoritmo fornece efetivamente tanto a vivacidade quanto a segurança, desde que no máximo (n-1)/ 3 nós sejam maliciosos ou defeituosos ao mesmo tempo, em que n representa os nós totais.
[0068] Cada rodada de consenso de PBFT (chamados
Petição 870190097362, de 30/09/2019, pág. 26/134
19/91 visualizações) inclui 4 fases:
(1) Um cliente envia um pedido para o nó líder para invocar uma operação de serviço;
(2) O nó líder faz multi-transmite a solicitação para os nós de cópia de segurança;
(3) Os nós executam a solicitação e, em seguida, enviam uma resposta ao cliente; e (4) O cliente aguarda por f + 1 (f representa o número máximo de nós que podem estar com defeito) respostas de diferentes nós com o mesmo resultado.
[0069] O resultado final é que todos os nós honestos chegam a um acordo sobre a ordem do registro e eles o aceitam ou rejeitam. O nó líder é alterado em um esquema round robin durante cada visualização e pode até mesmo ser substituído por um protocolo chamado alteração de visualização se uma quantidade específica de tempo tiver passado sem o nó líder multitransmitindo a solicitação. A maioria dos nós honestos também pode decidir se um líder está com defeito e removê-los com o próximo líder na fila como substituto.
[0070] No entanto, existem algumas limitações ao mecanismo de consenso do PBFT. Por exemplo, o modelo PBFT pode funcionar bem em sua forma clássica, com tamanhos de grupos de consenso relativamente pequenos, devido à grande quantidade de comunicação necessária entre os nós. Os dados de bloco volumosos que são transmitidos entre os nós de rede causam um problema de carga de rede e levam a um gargalo na rede. Além disso, o uso de códigos de autenticação de método (MAC) como o formato para mensagens de autenticação no modelo PBFT pode ser ineficiente com a quantidade de comunicação necessária entre os nós em grandes grupos de consenso, como redes de criptomoedas e com MACs. Pode haver uma
Petição 870190097362, de 30/09/2019, pág. 27/134
20/91 incapacidade inerente de provar a autenticidade das mensagens para terceiros.
[0071] Além disso, encontrar nós mal-intencionados consecutivos ao alterar o nó líder usando um método round robin usado pelo PBFT afeta o serviço de protocolo de confiança, introduzindo latência ou atraso na localização de um nó líder que seja honesto. Por exemplo, ao selecionar um primeiro nó de rede como o novo nó líder, o primeiro nó de rede pode ser um nó mal-intencionado, portanto, não pode ser selecionado como o novo nó líder. Em um método round robin, um segundo nó de rede na linha pode ser selecionado como o novo nó líder. No entanto, se o segundo nó de rede também for um nó mal-intencionado, outro nó de rede na linha será verificado se ele é adequado para ser o nó líder. Esse processo continua até que um novo nó líder que seja honesto seja identificado. Essa alteração frequente do nó líder introduz uma latência significativa nos serviços de protocolo de confiança.
[0072] Além disso, os nós de rede em uma rede de protocolo de confiança podem sofrer falhas bizantinas ou falhas a qualquer momento. Por exemplo, um nó de rede pode ser comprometido por um invasor cibernético malicioso e se comportar incorretamente. Se os nós de rede que estão comprometidos não forem recuperados imediatamente, o invasor cibernético malicioso pode comprometer a rede de protocolo de confiança e os serviços corrompendo mais de 1/3 dos nós de rede sem ser detectado.
[0073] Para abordar as questões e preocupações acima descritas associadas aos mecanismos de consenso existentes no BFT e ao mecanismo de consenso do PBFT, a presente invenção revela mecanismos de consenso melhorados incluindo técnicas para alcançar o consenso entre os nós de rede em um sistema distribuído, realizando uma alteração de nó primário em um sistema distribuído e executando um processo de recuperação para um nó de rede em um sistema distribuído. Os mecanismos de consenso descritos podem
Petição 870190097362, de 30/09/2019, pág. 28/134
21/91 alcançar várias vantagens em diferentes aplicações.
[0074] Por exemplo, o processo de consenso, conforme discutido abaixo, inclui muitas características que melhoram as operações do sistema de protocolo de confiança e ajudam a aliviar o gargalo da rede. Por exemplo, o processo de consenso descrito inclui converter uma solicitação de transação em um número de blocos de código de eliminação (EC) de acordo com um código EC e enviar um dos blocos EC para cada um dos nós de rede. O bloco EC é menor em tamanho que a solicitação de transação original. Assim, o envio do bloco EC em vez da solicitação de transação completa para os nós de rede reduz o tamanho dos blocos de dados que são transmitidos entre os nós de rede da rede de protocolo de confiança, conservando assim a largura de banda da rede e reduzindo a carga da rede. Isso reduz ainda mais o tamanho dos dados que são gravados e lidos a partir do espaço de memória dos nós de rede, reduzindo assim a carga no espaço de memória dos nós de rede e melhorando a eficiência do sistema de protocolo de confiança geral.
[0075] Além disso, a presente invenção descreve um processo de alteração de época que inclui atribuir pesos respectivos a múltiplas fases do processo de consenso, determinar uma soma de peso com base nos respectivos pesos das múltiplas fases e determinar um novo nó primário com base na soma de peso. O processo de alteração de época baseado na soma de peso em vez de um método round robin pode facilitar a escolha de um novo nó primário que não seja defeituoso em tempo hábil. Um nó primário pode ser um nó líder que tenha autoridade para iniciar uma rodada de processo de consenso entre vários nós de rede, incluindo o nó primário. Os outros nós de rede da rede de protocolo de confiança podem ser referidos como nós de cópia de segurança. O processo de alteração de época pode ajudar a resolver o problema do método round robin que causa uma alteração frequente do nó primário quando vários nós de rede na linha para o novo nó primário estão com
Petição 870190097362, de 30/09/2019, pág. 29/134
22/91 defeito. Ao contrário do método round robin, o processo de alteração de época na invenção atual depende da soma de peso para selecionar o novo nó primário, o que pode reduzir a latência ou atraso na localização do novo nó primário que não está com defeito. Isso pode melhorar ainda mais a eficiência do sistema de protocolo de confiança geral no fornecimento de serviços de protocolo de confiança.
[0076] Além disso, a presente invenção discute um processo de recuperação que inclui operações como o envio de uma mensagem de solicitação de estado por um nó de rede que se aplica para ser um novo nó primário e receber mensagens de resposta de estado dos outros nós de rede. Essas operações são executadas de tal forma que o processo de recuperação do nó de rede com falha não interfere com a operação normal do processo de consenso entre os outros nós de rede não defeituosos. Isso facilita a conservação de recursos de computação e de rede para recuperar o nó de rede com falha, reduzindo a complexidade do processo de recuperação.
[0077] Figura 1 representa um exemplo de um ambiente (100) que pode ser utilizado para executar implementações da presente invenção. Em alguns exemplos, o ambiente (100) permite que entidades participem de uma rede de protocolo de confiança de consórcio (102). O ambiente (100) inclui dispositivos de computação ou sistemas (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 deles, 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. Em alguns exemplos, a rede (110) permite a comunicação com, e dentro da rede de protocolo de confiança de consórcio (102). Em geral, a rede (110) representa uma ou mais redes de comunicação. Em alguns casos, os dispositivos de computação (106,
Petição 870190097362, de 30/09/2019, pág. 30/134
23/91
108) podem ser nós de um sistema de computação em nuvem (não mostrado) ou podem cada dispositivo de computação (106, 108) ser um sistema de computação em nuvem separado incluindo uma pluralidade de computadores interconectados por uma rede e funcionando como um sistema de processamento distribuído.
[0078] No exemplo representado, os sistemas de computação (106, 108) podem incluir, cada um, qualquer sistema de computação apropriado que permita participação como um nó na rede de protocolo de confiança de consórcio (102). Exemplos de dispositivos de computação incluem, sem limitação, um servidor, um computador de mesa, um 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 a rede de protocolo de confiança de consórcio (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 o 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 o sistema de gerenciamento de transação 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, a rede de protocolo de confiança de consórcio (102) é representada como uma rede de nós peer-to-peer, e os sistemas de computação (106,108) fornecem nós da primeira entidade e segunda entidade, respectivamente, que participam na rede de protocolo de confiança de consórcio (102).
[0079] A Figura 2 representa um exemplo de uma arquitetura
Petição 870190097362, de 30/09/2019, pág. 31/134
24/91 conceituai (200) de acordo com implementações da presente invenção. O exemplo de uma arquitetura conceituai (200) inclui os sistemas participantes (202, 204, 206) que correspondem ao Participante A, Participante B e Participante C, respectivamente. Cada participante (por exemplo, usuário, empresa) participa de uma rede de protocolo de confiança (212) fornecida como uma rede peer-to-peer incluindo uma pluralidade de nós (214), pelo menos alguns dos quais gravam informação imutável em um protocolo de confiança (216). Embora um único protocolo de confiança (216) seja representado esquematicamente dentro da rede de protocolo de confiança (212), são fornecidas múltiplas cópias do protocolo de confiança (216) e são mantidas através da rede de protocolo de confiança (212), como aqui descrito com mais detalhe.
[0080] No exemplo representado, cada sistema participante (202, 204, 206) é fornecido por, ou em nome do Participante A, Participante B e Participante C, respectivamente, e funciona como um respectivo nó (214) dentro da rede de protocolo de confiança. Como usado aqui, um nó geralmente se refere a um sistema individual (por exemplo, computador, servidor) que está conectado à rede de protocolo de confiança (212), e permite que um participante respectivo participe da rede de protocolo de confiança. No exemplo da Figura 2, um participante corresponde a cada nó (214). Está contemplado, no entanto, que um participante pode operar múltiplos nós (214) dentro da rede de protocolo de confiança (212), e/ ou múltiplos participantes podem compartilhar um nó (214). Em alguns exemplos, os sistemas participantes (202, 204, 206) comunicar-se com, ou através da rede de protocolo de confiança (212) usando um protocolo (por exemplo, protocolo de transferência de hipertexto seguro (HTTPS)) e/ ou usando chamadas de procedimento remoto (RPCs).
[0081] Os nós (214) podem ter diferentes graus de participação
Petição 870190097362, de 30/09/2019, pág. 32/134
25/91 dentro da rede de protocolo de confiança (212). Por exemplo, alguns nós (214) podem participar no processo de consenso (por exemplo, como nós de monitoramento que adicionam blocos ao protocolo de confiança (216)), enquanto outros nós (214) não participam do processo de consenso. Como outro exemplo, alguns nós (214) armazenam uma cópia completa do protocolo de confiança (216), enquanto outros nós (214) apenas armazenam cópias de partes do protocolo de confiança (216). Por exemplo, privilégios de acesso a dados podem limitar os dados de protocolo de confiança que um respectivo participante armazena dentro de seu respectivo sistema. No exemplo da Figura 2, os sistemas participantes (202, 204, 206) armazenam respetivas cópias completas (216’, 216”, 216”’) do protocolo de confiança (216).
[0082] Um protocolo de confiança (por exemplo, o protocolo de confiança (216) da Figura 2) é feito de uma cadeia de blocos, cada bloco armazenando dados. Exemplos de dados incluem dados de transações representativos de uma transação entre dois ou mais participantes. Enquanto as transações são usadas aqui por meio de exemplo não limitativo, é contemplado que quaisquer dados apropriados possam ser armazenados em um protocolo de confiança (por exemplo, documentos, imagens, vídeos, áudio). Exemplos de transações podem incluir, sem limitação, trocas de algo de valor (por exemplo, ativos, produtos, serviços e moeda). Os dados da transação são imutáveis armazenados dentro do protocolo de confiança. Ou seja, os dados da transação não podem ser alterados.
[0083] Antes de armazenar em um bloco, os dados da transação são criptografados. Hashing é um processo de transformar os dados da transação (fornecidos como dados de string) em um valor de hash de comprimento fixo (também fornecido como dados de string). Não é possível unhash o valor de hash para obter os dados da transação. O hashing assegura que até mesmo uma pequena alteração nos dados da transação resulta em um
Petição 870190097362, de 30/09/2019, pág. 33/134
26/91 valor de hash completamente diferente. Além disso, e como observado acima, o valor de hash é de comprimento fixo. Ou seja, não importa o tamanho dos dados da transação, o tamanho do valor do hash é fixo. O hashing inclui o processamento dos dados da transação por meio de uma função hash para gerar o valor de hash. Um exemplo de função hash inclui, sem limitação, o algoritmo hash seguro (SHA)-256, que gera valores hash de 256 bits.
[0084] Dados de transação de múltiplas transações são criptografados e armazenados em um bloco. Por exemplo, os valores de hash de duas transações são fornecidos e são eles próprios hashed para fornecer outro hash. Esse processo é repetido até que, para que todas as transações sejam armazenadas em um bloco, um único valor de hash é fornecido. Esse valor de hash é referido como um hash de raiz Merkle e é armazenado em um cabeçalho do bloco. Uma alteração em qualquer uma das transações resultará em alterações no valor de hash e, por fim, em uma alteração no hash da raiz Merkle.
[0085] Os blocos são adicionados ao protocolo de confiança através de um protocolo de consenso. Múltiplos nós dentro da rede de protocolo de confiança participam do protocolo de consenso e competem para ter um bloco adicionado ao protocolo de confiança. Esses nós são referidos como mineradores (ou nós do observador). POW, introduzido acima, é usado como um exemplo não limitativo.
[0086] Os nós mineradores executam o processo de consenso para adicionar transações ao protocolo de confiança. Embora múltiplos nós mineradores participem do processo de consenso, apenas um nó minerador pode gravar o bloco no protocolo de confiança. Ou seja, os nós mineradores competem no processo de consenso para ter seu bloco adicionado ao protocolo de confiança. Mais detalhadamente, um nó minerador coleta periodicamente transações pendentes de um pool de transações (por exemplo,
Petição 870190097362, de 30/09/2019, pág. 34/134
27/91 até um limiar predefinido no número de transações que podem ser incluídas em um bloco, se houver). O pool de transações inclui mensagens de transação dos participantes da rede de protocolo de confiança. O nó minerador constrói um bloco e inclui as transações no bloco. Antes de adicionar as transações ao bloco, o nó minerador verifica se alguma das transações já está incluída em um bloco do protocolo de confiança. Se uma transação já estiver incluída em outro bloco, a transação será descartada.
[0087] O nó minerador gera um cabeçalho de bloco, hashes todas as transações no bloco e combina o valor de hash em pares para gerar mais valores de hash até que um único valor de hash seja fornecido para todas as transações no bloco (o hash de raiz Merkle). Este hash é adicionado ao cabeçalho do bloco. O minerador também determina o valor de hash do bloco mais recente no protocolo de confiança (ou seja, o último bloco adicionado ao protocolo de confiança). O nó minerador também inclui um valor nonce e um registro de data e hora para o cabeçalho do bloco. Em um processo de mineração, o nó minerador tenta encontrar um valor de hash que atenda aos parâmetros necessários. O nó minerador continua alterando o valor de nonce até encontrar um valor de hash que atenda aos parâmetros necessários.
[0088] Cada minerador na rede de protocolo de confiança tenta encontrar um valor de hash que atenda aos parâmetros necessários e, dessa forma, competir entre si. Eventualmente, um dos nós mineradores encontra um valor de hash que atende aos parâmetros necessários e anuncia isso para todos os outros nós mineradores na rede de protocolo de confiança. Os outros nós mineradores verificam o valor do hash e, se determinado como estando correto, verifica cada transação no bloco, aceita o bloco e anexa o bloco à sua cópia do protocolo de confiança. Dessa maneira, um estado global do protocolo de confiança é consistente em todos os nós mineradores dentro da rede de protocolo de confiança. O processo acima descrito é o protocolo de consenso
Petição 870190097362, de 30/09/2019, pág. 35/134
28/91 de POW.
[0089] Um exemplo não limitativo é fornecido com referência à Figura 2. Neste exemplo, o Participante A deseja enviar uma quantia de fundo para o Participante B. O Participante A gera uma mensagem de transação (por exemplo, incluindo os campos De, Para e Valor) e envia a mensagem de transação para a rede de protocolo de confiança, que adiciona a mensagem de transação para um pool de transações. Cada nó minerador na rede de protocolo de confiança cria um bloco e toma todas as transações do pool de transações (por exemplo, até um limiar predefinido no número de transações que podem ser adicionadas a um bloco, se houver) e adiciona as transações ao bloco. Dessa forma, a transação publicada pelo Participante A é adicionada aos blocos dos nós mineradores.
[0090] Em algumas redes de protocolo de confiança, a criptografia é implementada para manter a privacidade das transações. Por exemplo, se dois nós quiserem manter uma transação privada, de forma que outros nós na rede de protocolo de confiança não consigam discernir detalhes da transação, os nós podem criptografar os dados da transação. Exemplos de métodos criptográficos incluem, sem limitação, criptografia simétrica e criptografia assimétrica. A criptografia simétrica refere-se a um processo de criptografia que usa uma única chave para criptografia (geração de texto cifrado a partir de texto sem formatação) e descriptografia (geração de texto sem formatação a partir do texto cifrado). Na criptografia simétrica, a mesma chave está disponível para vários nós, portanto, cada nó pode criptografar os dados da transação.
[0091] A criptografia assimétrica usa pares de chaves que incluem uma chave privada e uma chave pública, sendo a chave privada conhecida apenas por um nó respectivo e a chave pública sendo conhecida por qualquer um ou todos os outros nós na rede de protocolo de confiança. Um nó pode
Petição 870190097362, de 30/09/2019, pág. 36/134
29/91 usar a chave pública de outro nó para criptografar dados e os dados criptografados podem ser descriptografados usando a chave privada de outro nó. Por exemplo, e referindo-se novamente à Figura 2, o Participante A pode usar a chave pública do Participante B para criptografar dados e enviar os dados criptografados para o Participante B. O Participante B pode usar sua chave privada para descriptografar os dados criptografados (texto cifrado) e extrair os dados originais (texto sem formatação). As mensagens criptografadas com a chave pública de um nó só podem ser descriptografadas usando a chave privada do nó.
[0092] A criptografia assimétrica é usada para fornecer assinaturas digitais, o que permite aos participantes de uma transação confirmar outros participantes da transação, bem como a validade da transação. Por exemplo, um nó pode assinar digitalmente uma mensagem e outro nó pode confirmar que a mensagem foi enviada pelo nó com base na assinatura digital do Participante A. As assinaturas digitais também podem ser usadas para garantir que as mensagens não sejam adulteradas em trânsito. Por exemplo, e novamente referenciando a Figura 2, o Participante A deve enviar uma mensagem para o Participante B. O Participante A gera um hash da mensagem e, usando sua chave privada, criptografa o hash para fornecer uma assinatura digital como o hash criptografado. O Participante A anexa a assinatura digital à mensagem e envia a mensagem com assinatura digital para o Participante B. O Participante B decriptografa a assinatura digital usando a chave pública do Participante A e extrai o hash. O participante B hashes a mensagem e compara os hashes. Se os hashes forem iguais, o Participante B poderá confirmar que a mensagem foi realmente do Participante A e não foi adulterada.
[0093] A Figura 3 representa um exemplo de um processo (300) para alcançar um consenso entre nós de rede (por exemplo, nó (214)) de um
Petição 870190097362, de 30/09/2019, pág. 37/134
30/91 sistema distribuído (por exemplo, rede de protocolo de confiança (102 e 212)) que pode ser executado de acordo com implementações da presente invenção. Especificamente, a Figura 3 representa um diagrama apresentando uma forma de realização exemplificativa de um método (300) de alcançar um consenso em um caso normal, de acordo com a presente invenção. Como ilustrado na Figura 3, o processo de consenso (300) inclui três fases ou etapas (310, 320 e 330) como discutido abaixo.
[0094] Em uma primeira fase (310) do processo de consenso (300), um nó primário (ou um nó líder) da rede de protocolo de confiança envia uma primeira mensagem para os outros nós de rede (isto é, os nós de cópia de segurança). A primeira mensagem indica que o nó primário está iniciando um processo de consenso. Por exemplo, como ilustrado na Figura 3, o nó primário Ro envia uma mensagem INICIAL aos outros nós de redes Ri, R2e Rana rede de protocolo de confiança. Note-se que o processo (300) é representado como incluindo quatro nós de rede Ro, Ri, R2 e R3 apenas para fins ilustrativos, 0 processo (300) pode incluir qualquer número adequado de nós de rede. A primeira fase e um formato da mensagem INICIAL serão discutidos abaixo em maior detalhe com referência às Figuras 4 a 6.
[0095] Em uma segunda fase (320) do processo de consenso (300), cada um dos nós de cópia de segurança recebe a primeira mensagem que é enviada pelo nó primário, prepara uma segunda mensagem em resposta à primeira mensagem e envia a segunda mensagem para 0 outro nó de rede. A segunda mensagem indica que 0 nó de cópia de segurança recebeu a primeira mensagem do nó primário e está enviando uma resposta em resposta à primeira mensagem. Por exemplo, como ilustrado na Figura 3, a cópia de segurança nó R1 recebe a mensagem inicial que é enviada pelo nó primário Ro, e responde ao nó primário Ro com uma mensagem ECHO como um exemplo da segunda mensagem. Enquanto isso, 0 nó de cópia de segurança R1
Petição 870190097362, de 30/09/2019, pág. 38/134
31/91 também multi-transmite a mensagem ECHO para os outros nós de cópia de segurança, tais como, os nódulos de cópia de segurança R2 e R3. Da mesma forma, 0 apoio nó de R2 e R3 cada um multi-transmite uma mensagem ECHO para os outros nós de rede incluindo 0 nó primário Ro.
[0096] Quando um nó de rede, por exemplo, como um nó primário ou um nó de cópia de segurança, recebe as mensagens ECHO dos outros nós de rede, 0 nó de rede pode verificar as informações nas mensagens ECHO. A segunda fase e um formato da mensagem ECHO serão discutidos abaixo em maior detalhe com referência às Figuras 4 a 6.
[0097] Em uma terceira fase (330) do processo de consenso (300), cada um dos nós de rede multi-transmite uma terceira mensagem para os outros nós de rede. A terceira mensagem indica que um nó de rede aceitou um número predeterminado das segundas mensagens. Em algumas implementações, a terceira mensagem pode indicar que 0 nó de rede está pronto para executar a transação. Em algumas implementações, a terceira mensagem pode indicar que a transação foi reconstruída com sucesso no nó de rede. Por exemplo, como ilustrado na Figura 3, 0 nó primário Ro multitransmite uma mensagem de ACCEPT para os nós de cópia de segurança R1, R2, e R3. Do mesmo modo, os nós de cópia de segurança R1, R2, e Rscada um multi-transmite uma mensagem de ACCEPT para os outros nós de rede. Em algumas implementações da presente invenção, antes da multi-transmissão da mensagem ACCEPT, um nó de rede determina se 0 ACCEPT enviado de acordo com um código de eliminação (EC) e as informações nas mensagens ECHO são as recebidas na segunda fase. A terceira fase, 0 código EC, e um formato da mensagem ACCEPT serão discutidos abaixo em maior detalhe com referência às Figuras 4 a 6.
[0098] Quando um nó de rede recebe mensagens ACCEPT suficientes dos outros nós de rede, 0 nó de rede determina que um consenso
Petição 870190097362, de 30/09/2019, pág. 39/134
32/91 foi alcançado. Por exemplo, se o nó primário Ro ou os nós de cópia de segurança Ri, R20U R3 receberem um número de quórum (por exemplo, 2f + 1, onde f representa um número de nós de rede defeituosos) de mensagens ACCEPT, um consenso é alcançado automaticamente entre os nós de rede.
[0099] A Figura 4 representa um exemplo de um processo (400) para obter consenso entre nós de rede (por exemplo, nó (214) ou nós Ro, R1, R2 e R3) de um sistema distribuído (por exemplo, rede de protocolo de confiança (102) ou (212)) que pode ser executado de acordo com implementações da presente invenção. Em algumas implementações, 0 processo (400) pode ser realizado usando um ou mais programas executáveis por computador executados usando um ou mais dispositivos de computação. Para clareza de apresentação, a descrição que se segue geralmente descreve 0 método (400) no contexto das outras Figuras nesta descrição. Será entendido que 0 método (400) pode ser executado, por exemplo, por qualquer sistema, ambiente, software e hardware adequados, ou uma combinação de sistemas, ambientes, software e hardware, conforme apropriado. Em algumas implementações, várias etapas do método (400) podem ser executadas em paralelo, em combinação, em loops ou em qualquer ordem.
[00100] No início, 0 processo (400) pode ser implementado em conjunto com 0 sistema (100-300), como ilustrado nas Figuras 1 a 3. Em algumas implementações da presente invenção, a rede de protocolo de confiança (102) e/ ou (212) inclui um nó principal (404) e um ou mais nós de cópia de segurança (406). A rede de protocolo de confiança (102) e/ ou (212) comunica com 0 sistema de computação (106) e/ ou (108), tal como, nós de cliente (402) através da rede (110) para fornecer serviços de protocolo de confiança. Cada um dos nós cliente (402), nó primário (404) e nó de cópia de segurança (406) pode ser um computador para fins especiais ou outro aparelho de processamento de dados configurado para realizar os processos aqui
Petição 870190097362, de 30/09/2019, pág. 40/134
33/91 discutidos. Por exemplo, o nó cliente (402) também pode ser referido como um terminal de cliente ou um dispositivo cliente que interage com uma rede de protocolo de confiança. O nó cliente (402) pode instalar, por exemplo, um aplicativo de cliente ou um kit de desenvolvimento de software cliente (SDK) em conexão com a rede de protocolo de confiança para acesso e comunicação com a rede de protocolo de confiança. O nó primário (404) e um ou mais nós de cópia de segurança (406) também podem ser referidos como nós de consenso ou nós de rede que obtêm consenso e registram informações imutáveis na rede de protocolo de confiança.
[00101] O processo (400) inicia em (408), em que o nó cliente (402) gera uma solicitação de transação. Em algumas implementações da presente invenção, a solicitação de transação pode incluir uma solicitação solicitando um serviço de protocolo de confiança da rede de protocolo de confiança (102) e/ ou (212).
[00102] Em (410), o nó cliente (402) envia a solicitação de transação ao nó primário (404) da rede de protocolo de confiança (102) e/ ou (212). Em algumas implementações da presente invenção, o nó primário (404) atribui um número de sequência à solicitação de transação para manter o controle de solicitações de transação depois de receber a solicitação de transação do nó cliente (402).
[00103] Em (412), o nó primário (404) gera um número de blocos EC depois de receber a solicitação de transação do nó cliente (402). Em algumas implementações da presente invenção, o nó primário (404) gera o número de blocos EC de acordo com um código EC usando a solicitação de transação. Por exemplo, referindo-se a Figura 5, o nó primário (404) aplica um código EC (504) em uma solicitação de transação (502) e transforma a solicitação de transação (502) em uma mensagem EC (506) utilizando o código EC (504). O código EC (504) é um código de correção antecipada de erros
Petição 870190097362, de 30/09/2019, pág. 41/134
34/91 (FEC) no pressuposto de apagamentos de bits. O código EC (504) transforma a solicitação de transação original (502) em uma mensagem EC mais comprida (506), de tal modo que a solicitação de transação original (502) pode ser recuperado de uma parte ou de um fragmento da mensagem EC (506).
[00104] Em algumas implementações da presente descrição, o código EC (504) é um código de rasura quase otimizado, tal como um código Tornado ou um código de verificação de paridade de baixa densidade. Em implementações alternativas da presente invenção, o código EC (504) é um código fonte quase ótimo, tal como, um código fonte, um código online, um código de transformação Luby (LT), ou um código de raptor. Em implementações alternativas da presente invenção, o código EC (504) é um código de rasura ótimo, tal como, um código de paridade, um código Parchive, um código Reed-Solomon ou um código de regeneração. Em algumas implementações da presente invenção, o código EC (504) pode ser qualquer tipo adequado de código de eliminação.
[00105] Depois de transformar a solicitação de transação (502) na mensagem EC (506), o nó primário (404) gera um número de blocos EC (508) utilizando a mensagem EC (506). Por exemplo, tal como ilustrado na Figura 5, o nó primário (404) gera quatro blocos EC (508), bloco EC A, bloco EC B, bloco EC C e bloco EC D dividindo a mensagem EC (506). Note que os blocos EC (508) estão ilustrados na Figura 5 como incluindo quatro blocos para fins ilustrativos, os blocos EC (508) podem ser gerados como incluindo qualquer número adequado de blocos EC (508). Os blocos EC (508) serão enviados para os respectivos nós de cópia de segurança (406) dentro das mensagens INICIAIS.
[00106] Em algumas implementações da presente invenção, os blocos EC (508) têm um mesmo tamanho. Contudo, em implementações alternativas, os blocos EC (508) podem ter tamanhos diferentes uns dos outros.
Petição 870190097362, de 30/09/2019, pág. 42/134
35/91 [00107] Em algumas implementações da presente invenção, o nó primário (404) gera uma árvore de hash (500) (por exemplo, uma árvore Merkle) usando os blocos EC (508). A árvore de hash (500) inclui um número de nó folha que são rotulados com o hash de blocos de dados e um número de nós não-folha que são rotulados com o hash criptográfico dos rótulos de seus nós filhos. Por exemplo, como ilustrado na Figura 5, a árvore de hash (500) é configurada como incluindo quatro nós de folhas (510), hash A, hash B, hashC e hash D que são gerados como um hash criptográfico de seus respectivos blocos EC (508), quatro nós não-folha (512) que são gerados como um hash da concatenação de seus respectivos nós filhos (510), e um nó não-folha (514) que é gerado como um hash de seus nós filhos (512) e é um hash de raiz da árvore de hash (500).
[00108] As árvores de hash (500) permitem uma verificação eficiente e protege verificação dos conteúdos de grandes estruturas de dados. As árvores de hash (500) podem ser usadas para verificar qualquer tipo de dados armazenados, manipulados e transferidos nos computadores e entre eles. Eles podem ajudar a garantir que os blocos de dados recebidos de outros pares em uma rede P2P sejam recebidos sem danos e inalterados, e até mesmo para verificar se os outros pares não enviam blocos falsos. A verificação de blocos de dados usando a árvore de hash (500) será discutida abaixo em maior detalhe com referência às seguintes etapas do processo de consenso (400).
[00109] Referindo-se novamente a Figura 4, o nó primário (404) gera uma primeira mensagem (por exemplo, uma mensagem INICIAL) depois de se gerar os blocos EC (508) e a árvore de hash (500). A primeira mensagem indica que o nó primário é o início de um processo de consenso. Em algumas implementações, a mensagem INICIAL, como um exemplo da primeira mensagem, é gerada usando as informações nos blocos EC (508) e
Petição 870190097362, de 30/09/2019, pág. 43/134
36/91 na árvore de hash (500). Em algumas implementações da presente invenção, referindo-se à Figura 6, a mensagem INICIAL tem um formato de <epoch, tx_root_/?as/?, ec_block_/?as/?, ec_block, seq, j>, onde “epoch” representa uma rodada de consenso na qual a mensagem está sendo enviada, “tx_root_/?as/?” representa a raiz hash (514) na haxixe (500), “ec_block_/?as/?” representa os hashes (510) e/ ou (512) na árvore de hash (500), “ec_block” representa os blocos EC (508) na árvore de hash (500), “seq” representa o número de sequência associado à solicitação de transação (502) e “j” representa o nó de rede que gera e envia a mensagem INICIAL. Em algumas implementações, a mensagem INICIAL pode ter um formato diferente, por exemplo, incluindo campos adicionais ou diferentes.
[00110] Referindo-se novamente à Figura 4, em (416), na primeira fase do processo de consenso, o nó primário (404) multi-transmite a mensagem INICIAL para os outros nós de rede (por exemplo, nós de cópia de segurança (406)). Em algumas implementações, as mensagens INICIAL que são enviadas para os nós de cópia de segurança (406) têm um formato de <epoch, tx_root_hash, ec_block_/?as/?, ec_block, seq, j>. Por exemplo, o nó primário (404) pode enviar uma primeira mensagem INICIAL <epoch 1, Hash ABCD, {Hash B, Hash C, Hash D}, bloco EC A, 1, 0> para um primeiro nó de cópia de segurança (406) e uma segunda mensagem INICIAL <epoch 1, Hash ABCD, {Hash A, Hash C, Hash D}, EC bloco B, 1, 0> para um segundo nó de cópia de segurança (406), e assim por diante. Observe que as informações na mensagem INICIAL, como “ec_block”, podem ser usadas com “ec_b\ock_hash para reconstruir a árvore de hash (500). Por exemplo, na primeira mensagem INICIAL <epoch 1, Hash ABCD, {Hash B, Hash C, Hash D}, bloco EC A, 1, 0>, o bloco EC (508) “EC block A” pode ser dividido para gerar um hash criptográfico (510) “Hash A, que é posteriormente usado com os outros hashes (510) “{Hash B, Hash C, Hash D}” para reconstruir a árvore de hash (500). A
Petição 870190097362, de 30/09/2019, pág. 44/134
37/91 árvore de hash reconstruída (500) será usada para verificar as mensagens ECHO, conforme discutido abaixo, em maiores detalhes com referência às etapas a seguir do processo de consenso.
[00111] Em (418), cada um dos nós de cópia de segurança (406) gera uma segunda mensagem (por exemplo, uma mensagem de ECHO) na segunda fase do processo de consenso após receber a mensagem inicial a partir do nó primário (404). A segunda mensagem indica que o nó de cópia de segurança recebeu a primeira mensagem do nó primário. A segunda mensagem é enviada como resposta em resposta à primeira mensagem. Em algumas implementações da presente invenção, a mensagem ECHO é gerada por um nó de cópia de segurança (406) como incluindo a mensagem INICIAL ou uma parte da mensagem INICIAL e uma assinatura do nó de cópia de segurança (406) associada à mensagem INICIAL. Por exemplo, o nó de cópia de segurança (406) pode gerar a assinatura assinando a mensagem INICIAL ou um resumo da mensagem INICIAL usando uma chave privada. A assinatura de chave privada pode ser usada por outros nós de rede usando uma chave pública emparelhada com a chave privada para autenticar a mensagem ECHO que inclui a assinatura de chave privada.
[00112] Em algumas implementações da presente invenção, referindo-se a Figura 6, a mensagem ECHO tem um formato de <epoch, tx_root_hash, ec_block_/?as/?, ec_block, seq, sign_proof, j>, onde “epoch” representa uma rodada de consenso na qual a mensagem está sendo enviada, “tx_root_/?as/?” representa a raiz hash (514) na árvore de hash (500), “ec_block_/?as/?” representa os hashes (510) e/ ou (512) na árvore de hash (500), “ec_block” representa os blocos EC (508) na árvore de hash (500) que são recebidos pelos respectivos nós de cópia de segurança (406), “seq” representa o número de sequência associado à solicitação de transação (502), “sign_proof” representa a assinatura dos nós de cópia de segurança (406)
Petição 870190097362, de 30/09/2019, pág. 45/134
38/91 associados às mensagens INICIAIS, e “j” representa o nó de rede que gera e envia a mensagem ECHO. Em algumas implementações, a mensagem ECHO pode ter um formato diferente, por exemplo, incluindo campos adicionais ou diferentes.
[00113] Referindo-se novamente a Figura 4, em (420), os nós de cópia de segurança (406) enviam as mensagens ECHO para o nó primário (404). Em (421), cada um dos nós de cópia de segurança (406) envia as mensagens ECHO para os outros nós de cópia de segurança (406). Em (423), cada um dos nós de cópia de segurança (406) pode receber as mensagens ECHO dos outros nós de cópia de segurança (406).
[00114] Em (422), o nó primário (404) verifica as mensagens ECHO que são enviadas pelos nós de cópia de segurança (406). Em algumas implementações da presente invenção, o nó primário (404) verifica se as mensagens ECHO são válidas de acordo com a árvore de hash (500). Por exemplo, o nó primário (404) pode receber uma primeira mensagem ECHO <epoch 1, Hash ABCD, {Hash B, Hash C, Hash D}, EC block A, 1, 1> de um primeiro nó de cópia de segurança (406). O nó primário (404) pode recuperar o bloco EC (508) “EC block A” da mensagem e o hash para gerar urn hash criptográfico (510) “Hash A. O nó primário (404) usa ainda o hash gerado (510) “Hash A” com os outros hashes (510) “{Hash B, Hash C, Hash D}” na mensagem para reconstruir a árvore de hash (500). Então, o nó primário (404) determina o hash de raiz (514) da árvore de hash reconstruída (500) e compara com o hash de raiz (514) na mensagem ECHO, como “Hash ABCD”. Se os dois hashes de raiz (514) correspondem, o nó primário (404) determina que a mensagem ECHO é válida. O nó primário (404) pode armazenar as mensagens ECHO válidas e descartar as mensagens ECHO que são consideradas inválidas.
[00115] No (424), o nó primário (404) determina se um
Petição 870190097362, de 30/09/2019, pág. 46/134
39/91 número de mensagens ECHO válidas excede um limiar predeterminado. Em algumas implementações da presente invenção, o nó primário (404) determina se o número de mensagens ECHO válidas atinge um número de quórum n-f ou 2f + 1, onde n é o número total de nós de rede e f é o número máximo de nós em falha que a rede pode tolerar.
[00116] Em (426), o nó primário (404) reconstrói a solicitação de transação (502) em resposta a determinação de que o número de mensagens ECHO válidas atinge o número de quórum. Em algumas implementações da presente invenção, o nó primário (404) reconstrói a solicitação de transação (502) com base em pelo menos um subconjunto de mensagens ECHO válidas de acordo com o código EC. Por exemplo, o nó primário (404) pode recuperar um número de n - 2f ou f + 1 dos blocos EC (508) que estão no número de quórum (por exemplo, n-f ou 2f + 1) de mensagens ECHO válidas, e usar os blocos EC recuperados (508) para reconstruir a solicitação de transação (502) de acordo com o código EC (504).
[00117] Em (428), na terceira fase do processo de consenso, o nó primário (404) gera uma terceira mensagem (por exemplo, uma mensagem ACCPET) em resposta a determinação de que a solicitação de transação (502) foi reconstruída com sucesso. A terceira mensagem indica que um nó de rede aceitou um número predeterminado das segundas mensagens. Em algumas implementações, a terceira mensagem pode indicar que o nó de rede está pronto para executar a transação. Em algumas implementações, a terceira mensagem pode indicar que a transação foi reconstruída com sucesso no nó de rede. Por exemplo, a mensagem ACCPET pode ser utilizada para indicar a outros nós de rede que a solicitação de transação (502) foi reconstruída com sucesso. Se o nó primário (404) falhar na reconstrução da solicitação de transação (502), o nó primário (404) pode não gerar a mensagem ACCEPT.
Petição 870190097362, de 30/09/2019, pág. 47/134
40/91 [00118] Em algumas implementações da presente invenção, referindo-se a Figura 6, a mensagem ACCEPT tem um formato de <epoch, tx_root_hash, seq, sign_proofs, j>, onde “epoch” representa uma rodada de consenso na qual a mensagem está sendo enviada, “tx_root_/?as/?” representa a raiz hash (514) na árvore de hash (500), “seq” representa o número de sequência associado à solicitação de transação (502), “sign_proofs” representa um conjunto de assinaturas nas mensagens ECHO válidas e “j” representa o nó de rede que gera e envia a mensagem ACCEPT. Em algumas implementações, a mensagem ACCEPT pode ter um formato diferente, por exemplo, incluindo campos adicionais ou diferentes.
[00119] Referindo-se novamente a Figura 4, em (430), o nó principal (404) envia a mensagem ACCPET aos nós de cópia de segurança (406).
[00120] Semelhante ao nó primário (404), cada um dos nós de cópia de segurança (406) pode reconstruir a solicitação de transação, por exemplo, executando etapas semelhantes às etapas (422-428) como o nó primário (404). Em (432), cada um dos nós de cópia de segurança (406) gera uma mensagem ACCEPT em resposta a determinação de que a solicitação de transação (502) foi reconstruída com sucesso pelo nó de cópia de segurança (406). Em algumas implementações, o nó primário (404) e o nó de cópia de segurança (406) podem executar as etapas (422-428) de uma maneira paralela, por exemplo, como indicado na Figura 3.
[00121] Em (434), os nós de cópia de segurança (406) enviam as mensagens ACCEPT para o nó primário (404). Entretanto, cada um dos nós de cópia de segurança (406) pode enviar as mensagens ACCEPT para os outros nós de cópia de segurança (406).
[00122] Em (436), o nó primário (404) executa a solicitação de transação (502) em resposta a determinação de que um número de
Petição 870190097362, de 30/09/2019, pág. 48/134
41/91 mensagens ACCEPT excede um limiar pré-determinado. Em algumas implementações da presente invenção, o nó primário (404) determina se as mensagens ACCEPT recebidas são idênticas e se um número de mensagens ACCEPT idênticas atinge um número de quórum (por exemplo, 2f + 1). Se o número de mensagens ACCEPT idênticas atingir o número de quórum, o nó primário (404) determina que foi alcançado um consenso entre todos os nós de rede e, em seguida, executa a solicitação de transação (502) localmente. Em algumas implementações da presente invenção, se o nó primário (404) determinar o número de mensagens ACCEPT idênticas não atingir o número de quórum, o nó primário (404) determina que não foi alcançado um consenso entre todos os nós de rede e, em seguida evita executar a solicitação de transação (502).
[00123] Em algumas implementações da presente invenção, cada um dos nós de cópia de segurança (406) pode executar as mesmas operações que são realizadas pelo nó primário (404), como descrito acima em (436), antes de executar a solicitação de transação (502). Se um nó de cópia de segurança (406) determinar que as mensagens ACCEPT que foram recebidas excede um limiar predeterminado, o nó de cópia de segurança (406) determina que um consenso foi alcançado entre os nós de rede e executa a solicitação de transação (502) localmente. Em algumas implementações da presente invenção, se o nó de cópia de segurança (406) determinar que o número de mensagens ACCEPT idênticas não atinge o número de quórum, o nó de cópia de segurança (406) determina que não foi alcançado um consenso entre todos os nós de rede e depois evita executar a solicitação de transação (502).
[00124] Em (438), o nó principal (404) envia um resultado de transação para o nó cliente (402) depois de executar a solicitação de transação (502). Os nós de cópia de segurança (406) que executaram com sucesso a
Petição 870190097362, de 30/09/2019, pág. 49/134
42/91 solicitação de transação (502) localmente também podem enviar seus respectivos resultados de transação para o nó cliente (402).
[00125] O processo de consenso, como discutido acima, inclui muitas características que melhoram a operação de todo o sistema de protocolo de confiança e ajudam a aliviar o gargalo da rede. Por exemplo, o processo de consenso na presente invenção inclui gerar um número de blocos EC de acordo com um código EC usando uma solicitação de transação e enviar um dos blocos EC para cada um dos nós de rede. O bloco EC é menor em tamanho que a solicitação de transação original. Portanto, o envio do bloco EC em vez da solicitação de transação para os nós de rede reduz o tamanho dos blocos de dados que são transmitidos entre os nós de rede da rede de protocolo de confiança, conservando assim a largura de banda da rede e reduzindo a carga da rede. Isso reduz ainda mais o tamanho dos dados que são gravados e lidos a partir do espaço de memória dos nós de rede, reduzindo assim a carga no espaço de memória dos nós de rede e melhorando a eficiência do sistema de protocolo de confiança geral.
[00126] Durante o processo de consenso, os nós de cópia de segurança estão aguardando uma solicitação do nó primário. No entanto, o nó primário pode encontrar uma falha bizantina ou uma falha de travamento para que o nó primário não possa transmitir a solicitação dentro de uma janela de tempo predeterminada. Quando uma quantidade específica de tempo passou sem a multi-transmissão principal da solicitação, um novo nó primário pode precisar ser escolhido para impedir que os nós de cópia de segurança esperem indefinidamente as solicitações a serem executadas.
[00127] A Figura 7 representa um exemplo de um processo (700) para realizar uma alteração de um nó primário (por exemplo, nó (214) ou (404)) de um sistema distribuído (por exemplo, rede de protocolo de confiança (102 e 212)) que pode ser executado de acordo com implementações da
Petição 870190097362, de 30/09/2019, pág. 50/134
43/91 presente invenção. Especificamente, a Figura 7 ilustra um diagrama apresentando uma forma de realização exemplificativa de um método (700) para realizar uma alteração de um nó primário, de acordo com a presente invenção. Em algumas implementações, um nó primário é associado a uma época que inclui um processo de consenso com o nó primário sendo o líder. Uma alteração de um nó primário pode resultar em uma alteração de época.
[00128] Em algumas implementações, em resposta à determinação de que um nó primário de uma época atual precisa ser alterado, um nó de cópia de segurança da rede de protocolo de confiança envia uma primeira mensagem para os outros nós de rede. A primeira mensagem indica que o nó de cópia de segurança gostaria de ser um novo nó primário em uma nova época. Por exemplo, como ilustrado na Figura 7, o nó de cópia de segurança Ro envia uma mensagem EPOCH_CHANGE para os outros nós de redes Ri, R2e Rana rede de protocolo de confiança em resposta em que o nó de cópia de segurança Ro determina que um nó primário atual está com defeito e que uma alteração de época precisa ser executada. A mensagem EPOCH_CHANGE é um exemplo da primeira mensagem indicando que o nó de cópia de segurança Ro se aplica como sendo o novo nó primário. A alteração de época pode causar uma alteração de uma época atual com um nó primário atual para uma nova época com um novo nó primário. Observe que o processo (700) é ilustrado como implementado em conjunto com quatro nós de rede apenas para fins ilustrativos. O processo (700) pode ser implementado em conjunto com qualquer número adequado de nós de rede.
[00129] Em seguida, cada um dos nós de rede recebe a primeira mensagem que é enviada pelo nó de cópia de segurança, prepara uma segunda mensagem em resposta à primeira mensagem e faz multitransmissões da segunda mensagem para os outros nós de rede. Por exemplo, como ilustrado na Figura 7, o nó de rede Ri recebe a mensagem
Petição 870190097362, de 30/09/2019, pág. 51/134
44/91
EPOCH_CHANGE que é enviada pelo nó de cópia de segurança Ro, e responde ao nó de cópia de segurança Rocom uma mensagem NEW_EPOCH indicando um reconhecimento de que o nó de cópia de segurança Ro pode se tornar o novo nó primário. Enquanto isso, o nó de rede de Ri também multitransmite a mensagem NEW_EPOCH para os outros nós de rede, tais como, os nós de rede R2e R3. Da mesma forma, 0 nó de rede R2e R3cada um multitransmite uma mensagem NEW_EPOCH para os outros nós de rede.
[00130] O processo de alteração de época como discutido acima, um formato da mensagem EPOCH_CHANGE, e um formato da mensagem NEW_EPOCH serão discutidos abaixo em maior detalhe com referência às Figuras 8 e 9.
[00131] A Figura 8 ilustra um exemplo de um processo (800) para realizar uma alteração de um nó primário em um sistema distribuído (por exemplo, rede de protocolo de confiança (102) ou (212)) que pode ser executado de acordo com implementações da presente invenção. Em algumas implementações, 0 processo exemplificativo (800) pode ser realizado usando um ou mais programas executáveis por computador executados usando um ou mais dispositivos de computação. Para clareza de apresentação, a descrição que se segue descreve geralmente 0 método (800) no contexto das outras Figuras nesta descrição. Será entendido que 0 método (800) pode ser realizado, por exemplo, por qualquer sistema, ambiente, software e hardware adequados, ou uma combinação de sistemas, ambientes, software e hardware, conforme apropriado. Em algumas implementações, várias etapas do método (800) podem ser executadas em paralelo, em combinação, em loops ou em qualquer ordem.
[00132] O processo (800) começa em (806), onde um nó de cópia de segurança (802) determina que uma alteração de época precisa ser executada. A alteração de época discutida aqui causa uma alteração de uma
Petição 870190097362, de 30/09/2019, pág. 52/134
45/91 época atual com um nó primário atual para uma nova época com um novo nó primário. Uma época exemplificativa pode incluir um processo de consenso (por exemplo, processo de consenso (300) ou (400)) para alcançar o consenso entre um número de nós de rede usando um nó primário como discutido acima com referência às Figuras 3 a 6.
[00133] Em algumas implementações da presente invenção, o nó de cópia de segurança (802) determina que uma alteração de época precisa ser executada em resposta a determinação de que o nó de cópia de segurança (802) ainda está aguardando uma solicitação do nó primário atual após uma quantidade específica de tempo ter passado sem receber a solicitação do nó primário atual. Por exemplo, o nó primário atual pode encontrar uma falha bizantina ou uma falha de travamento, de modo que o nó primário atual não possa fazer a multi-transmissão da solicitação em uma janela de tempo predeterminada. Portanto, a alteração de época é acionada por tempos limiares que impedem que os nós de cópia de segurança esperem indefinidamente por solicitações a serem executadas. O processo de alteração de época discutido aqui fornece vivacidade e reduz a latência da rede, permitindo que o sistema progrida quando o nó primário falha.
[00134] No (808), o nó de cópia de segurança (802) determina um peso respectivo do nó de cópia de segurança (802) associado a cada uma das fases do processo de consenso na época atual. Em algumas implementações, o processo de consenso inclui três fases como descrito acima com referência às Figuras 3 a 6 O peso é uma métrica de uma qualificação do nó de cópia de segurança (802) para ser o novo nó primário em uma nova época.
[00135] Em algumas implementações da presente invenção, o nó de cópia de segurança (802) determina um peso do nó de cópia de segurança (802) para uma primeira fase do processo de consenso na época
Petição 870190097362, de 30/09/2019, pág. 53/134
46/91 atual como sendo um primeiro valor. Por exemplo, o nó de cópia de segurança (802) pode receber um peso inicial de 10% se o nó de cópia de segurança (802) tiver entrado em uma primeira fase do processo de consenso (por exemplo, a primeira fase (310) do processo de consenso (300)). Em implementações alternativas da presente invenção, o nó de cópia de segurança (802) pode atribuir qualquer valor de peso adequado ao nó de cópia de segurança (802) para a primeira fase do processo de consenso atual.
[00136] Em algumas implementações da presente invenção, o nó de cópia de segurança (802) determina um peso do nó de cópia de segurança (802) para uma segunda fase do processo de consenso (por exemplo, a segunda fase (320) do processo de consenso (300)) na época atual com base em um processo de verificação de quórum. O processo de verificação de quórum é realizado determinando se o nó de cópia de segurança (802) recebe um número predeterminado (por exemplo, 2f + 1) de mensagens ECHO dos outros nós de rede na segunda fase do processo de consenso.
[00137] Em algumas implementações da presente invenção, se o nó de cópia de segurança (802) falhar na verificação do quórum (por exemplo, o nó de cópia de segurança (802) recebe um número de mensagens ECHO que é inferior a um limiar predeterminado), o nó de cópia de segurança (802) pode determinar o peso do nó de cópia de segurança (802) para a segunda fase do processo de consenso como sendo um primeiro valor. Se o nó de cópia de segurança (802) passar a verificação de quórum (por exemplo, o nó de cópia de segurança (802) recebe um número de mensagens ECHO que iguala ou excede um limiar predeterminado), o nó de cópia de segurança (802) pode determinar o peso do nó de cópia de segurança (802) para a segunda fase do processo de consenso é um segundo valor. Em algumas implementações da presente invenção, o segundo valor é determinado como maior que o primeiro valor. Por exemplo, se o nó de cópia de segurança (802)
Petição 870190097362, de 30/09/2019, pág. 54/134
47/91 falhar na verificação de quórum, o nó de cópia de segurança (802) pode ser designado um valor de peso zero para a segunda fase do processo de consenso. Se o nó de cópia de segurança (802) passar a verificação de quórum, o nó de cópia de segurança (802) pode ser designado um valor de peso de 45% para o nó de cópia de segurança (802) da segunda fase do processo de consenso. No entanto, em implementações alternativas da presente invenção, o nó de cópia de segurança (802) pode atribuir qualquer valor adequado ao nó de cópia de segurança (802) para a segunda fase do processo de consenso na época atual.
[00138] Em algumas implementações da presente descrição, a verificação de quórum inclui ainda verificar se as mensagens ECHO que o nó de cópia de segurança (802) recebe dos outros nós da rede durante a segunda fase do processo de consenso são validas. Por exemplo, o nó de cópia de segurança (802) pode autenticar as assinaturas de chave privada nas mensagens ECHO usando uma chave pública para determinar se as mensagens ECHO são válidas.
[00139] Semelhante a determinar o peso para a segunda fase, em algumas implementações, o nó de cópia de segurança (802) determina um peso do nó de cópia de segurança (802) para uma terceira fase do processo de consenso (por exemplo, a terceira fase (330) do processo de consenso (300)) na época atual baseada em um processo de verificação de quórum. O processo de verificação de quórum é realizado determinando se o nó de cópia de segurança (802) recebe um número predeterminado (por exemplo, 2f + 1) de mensagens de aceitação dos outros nós de rede na terceira fase do processo de consenso na época atual. Cada uma das mensagens de aceitação de outros nós de rede indica que cada um dos outros nós de rede aceitou um número predeterminado de mensagens ECHO. A mensagem de aceitação pode ser, por exemplo, as mensagens ACCEPT
Petição 870190097362, de 30/09/2019, pág. 55/134
48/91 descritas acima com referência à terceira fase (330) do processo de consenso (300).
[00140] Em algumas implementações da presente invenção, se o nó de cópia de segurança (802) falhar na verificação de quórum (por exemplo, o nó de cópia de segurança (802) recebe um número de mensagens ACCEPT que é inferior a um limiar predeterminado), o nó de cópia de segurança (802) pode determinar o peso do nó de cópia de segurança (802) para a terceira fase do processo de consenso como sendo um primeiro valor. Se o nó de cópia de segurança (802) passar a verificação de quórum (por exemplo, o nó de cópia de segurança (802) recebe um número de mensagens ACCEPT que iguala ou excede um limiar predeterminado), o nó de cópia de segurança (802) pode determinar o peso do nó de cópia de segurança (802) para a terceira fase do processo de consenso como sendo um segundo valor. Em algumas implementações, o segundo valor é determinado como maior que o primeiro valor. Por exemplo, se o nó de cópia de segurança (802) falhar na verificação de quórum, o nó de cópia de segurança (802) pode atribuir um valor de peso zero para o nó de cópia de segurança (802) da terceira fase do processo de consenso. Se o nó de cópia de segurança (802) passar a verificação de quórum, o nó de cópia de segurança (802) pode atribuir um valor de peso de 45% para o nó de cópia de segurança (802) da terceira fase do processo de consenso. No entanto, em implementações alternativas da presente invenção, o nó de cópia de segurança (802) pode atribuir qualquer valor adequado ao nó de cópia de segurança (802) para a terceira fase do processo de consenso na época atual.
[00141] Em (810), depois de determinar os respectivos pesos do nó de cópia de segurança (802) para as fases do processo de consenso na época atual, o nó de cópia de segurança (802) determina uma soma de peso do nó de cópia de segurança (802) para o processo de
Petição 870190097362, de 30/09/2019, pág. 56/134
49/91 consenso com base nos pesos respectivos. Em algumas implementações da presente invenção, a soma de peso é uma soma das somas respectivas dos nós de cópia de segurança associados a cada uma das fases do processo de consenso na época atual. Por exemplo, se o nó de cópia de segurança (802) determinou um primeiro valor de peso do nó de cópia de segurança (802) para a primeira fase como sendo 10%, um segundo valor de peso do nó de cópia de segurança (802) para a segunda fase será de 45% e um terceiro valor de peso do nó de cópia de segurança (802) para a terceira fase como sendo de 45%, o nó de cópia de segurança (802) determina a soma de peso como sendo 100%. Como outro exemplo, se o nó de cópia de segurança (802) determinou um primeiro valor de peso do nó de cópia de segurança (802) para a primeira fase como sendo 10%, um segundo valor de peso do nó de cópia de segurança (802) para a segunda fase como sendo de 45% e um terceiro valor de peso do nó de cópia de segurança (802) para a terceira fase como sendo 0, o nó de cópia de segurança (802) determina a soma de peso como sendo 55%.
[00142] Em (812), o nó de cópia de segurança (802) envia uma mensagem EPOCH_CHANGE para os outros nós de rede (804) se o nó de cópia de segurança (802) determinar que a soma de peso que foi determinada em (810) atinge ou excede um limiar predeterminado. Por exemplo, o nó de cópia de segurança (802) pode enviar uma mensagem EPOCH_CHANGE para os outros nós de rede (804) se a soma de peso conforme determinado em (810) atingir 100%. A mensagem EPOCH_CHANGE indica uma solicitação para uma alteração da época atual com o nó primário atual para a nova época, com o nó de cópia de segurança sendo o novo nó primário.
[00143] Em algumas implementações da presente invenção, referindo-se a Figura 9, a mensagem EPOCH_CHANGE tem um formato de <weight, epoch + 1, ECHO {}, ACCEPT {}, j>, onde “weight” representa a soma
Petição 870190097362, de 30/09/2019, pág. 57/134
50/91 de peso do nó de cópia de segurança (802) conforme determinado anteriormente em (810) para o processo de consenso, “ppoch + 1” representa uma rodada de novo consenso (isto é, uma nova época) associada a um novo nó primário, “ECHO {}” representa um conjunto de mensagens ECHO que o nó de cópia de segurança (802) recebe durante a segunda fase do processo de consenso, “ACCEPT {}” representa um conjunto de mensagens ACCEPT que o nó de cópia de segurança (802) recebe durante a terceira fase do processo de consenso, e “j” representa o nó de rede (por exemplo, nó de cópia de segurança (802)) que gera e envia a mensagem EPOCH_CHANGE. Em algumas implementações, a mensagem EPOCH_CHANGE pode ter um formato diferente, por exemplo, incluindo campos adicionais ou diferentes.
[00144] Referindo-se novamente a Figura 8, em (814), os nós de rede (804) diferentes do nó de cópia de segurança (802) verificam a mensagem EPOCH_CHANGE enviada pelo nó de cópia de segurança (802). Em algumas implementações, cada um dos nós de rede (804) verifica se a mensagem EPOCH_CHANGE é válida verificando se a soma de peso na mensagem EPOCH_CHANGE é válida. Em algumas implementações, verificar se a soma de peso na mensagem EPOCH_CHANGE é válida inclui verificar se o conjunto de assinaturas nas mensagens ECHO incluídas na mensagem EPOCH_CHANGE é válido. Por exemplo, cada um dos nós de rede (804) pode autenticar o conjunto de assinaturas de chave privada nas mensagens ECHO incluindo a mensagem EPOCH_CHANGE utilizando uma chave pública.
[00145] Em (816), cada um dos nós de rede (804) envia uma mensagem NEW_EPOCH para o nó de cópia de segurança (802) em resposta à verificação de que a mensagem EPOCH_CHANGE enviada pelo nó de cópia de segurança (802) é válida. A mensagem NEW_EPOCH indica uma confirmação de que o nó de cópia de segurança é o novo nó primário. Por exemplo, a mensagem NEW_EPOCH enviada por um nó de rede (804) inclui
Petição 870190097362, de 30/09/2019, pág. 58/134
51/91 uma indicação de que o nó de rede (804) reconhece que o nó de cópia de segurança (802) se tornará o novo nó primário na nova época. Enquanto isso, cada um dos nós de rede (804) também envia a mensagem NEW_EPOCH aos outros nós de rede (804).
[00146] Referindo-se a Figura 9, a mensagem NEW_EPOCH é gerada como tendo um formato de <epoch + 1, i, j, seq, ec_digest>, onde “epoch + 1” representa uma rodada de novo consenso (isto é, uma nova época) associada a um novo nó primário, “i” representa o novo nó primário na nova época, “j” representa um nó de rede (804) que envia a mensagem NEW_EPOCH e “ec_digest” representa um resumo da mensagem EPOCH_CHANGE. Em algumas implementações, o resumo da mensagem EPOCH_CHANGE inclui um valor de hash da mensagem EPOCH_CHANGE. Em algumas implementações, a mensagem NEW_EPOCH pode ter um formato diferente, por exemplo, incluindo campos adicionais ou diferentes.
[00147] Referindo-se novamente a Figura 8, em (818), o nó de cópia de segurança (802) verifica se as mensagens NEW_EPOCH que são enviadas pelos nós de rede (804) são válidas. Em algumas implementações, o nó de cópia de segurança (802) verifica as mensagens NEW_EPOCH, verificando se o resumo da mensagem EPOCH_CHANGE nas mensagens NEW_EPOCH é válido. Como o resumo inclui informações da mensagem EPOCH_CHANGE, o resumo também inclui as assinaturas na mensagem EPOCH_CHANGE. O nó de cópia de segurança (802) pode verificar o resumo da mensagem EPOCH_CHANGE, verificando se o conjunto de assinaturas na mensagem EPOCH_CHANGE é válido.
[00148] Em (820), o nó de cópia de segurança (802) determina se um número de mensagem NEW_EPOCH válida conforme determinado em (818) excede um limiar predeterminado. Em algumas implementações, o limiar predeterminado é um número de quórum (por
Petição 870190097362, de 30/09/2019, pág. 59/134
52/91 exemplo, 2f + 1).
[00149] No (822), o nó de cópia de segurança (802) determina que o nó de cópia de segurança (802) seja o novo nó primário na nova época em resposta à determinação de que o número de mensagem NEW_EPOCH válida conforme determinado excede o limiar predeterminado. Note-se que cada um dos nós de rede (804) realiza as mesmas etapas (818822) que o nó de cópia de segurança (802), e os nós de rede (804) e o nó de cópia de segurança (802) podem executar as etapas (818-822) de uma maneira paralela. Por exemplo, cada um dos nós de rede (804) pode verificar um conjunto de mensagens NEW_EPOCH enviadas de outros nós de rede (804), determinar se um número de mensagens NEW_EPOCH válidas excede um limiar predeterminado e determinar um novo nó primário.
[00150] O processo de alteração de época (por exemplo, processo (700) ou (800)), conforme discutido acima, inclui muitas características que melhoram a operação de todo o sistema de protocolo de confiança e ajudam a aliviar o gargalo da rede. Por exemplo, o processo de alteração de época na presente invenção inclui atribuir pesos respectivos às três fases do processo de consenso, determinar uma soma de peso com base nos pesos respectivos das três fases e determinar um novo nó primário com base na soma de peso. O processo de alteração de época baseado na soma de peso em vez de um método round robin pode facilitar a escolha de um novo nó primário que não seja defeituoso em tempo hábil. Um método round robin pode causar uma alteração frequente do nó primário quando vários nós de rede na linha para o novo nó primário estiverem com defeito. Isso afeta significativamente o serviço de protocolo de confiança, introduzindo latência ou atraso na localização de um nó primário sem falhas. Ao contrário do método round robin, o processo de alteração de época na invenção atual depende da soma de peso para selecionar o novo nó primário, o que pode reduzir o tempo
Petição 870190097362, de 30/09/2019, pág. 60/134
53/91 na localização do novo nó primário que não está com defeito. Isso pode melhorar ainda mais a eficiência do sistema de protocolo de confiança geral no fornecimento de serviços de protocolo de confiança.
[00151] Durante a operação de uma rede de protocolo de confiança, a velocidade de execução de alguns nós de rede pode ficar para trás da maioria dos nós de rede devido a agitação (Jittering) de rede, falha de energia súbita, falha de disco e similares. Nesse cenário, mais de 1/3 dos nós de rede no sistema podem falhar. O BFT fornece segurança e vivacidade se menos de 1/3 dos nós de rede falharem durante a vida útil do sistema. No entanto, essas garantias são insuficientes para sistemas de vida longa porque o limiar superior provavelmente será excedido no cenário descrito acima. Portanto, é desejável um processo de recuperação que faça com que os nós de rede com defeito se comportem corretamente novamente e continuem a participar de processos de consenso subsequentes para permitir que o sistema tolere mais de f falhas durante sua vida útil. Além disso, o processo de recuperação descrito pode recuperar um ou mais nós de redes que ainda estão executando um processo de consenso (por exemplo, o processo de consenso (300) ou (400)) e não precisam esperar até que o consenso seja alcançado entre todos os nós de rede. Como tal, o processo de recuperação descrito pode reduzir ainda mais a latência do sistema e melhorar a eficiência da rede de protocolo de confiança.
[00152] A Figura 10 ilustra um exemplo de um processo (1000) para realizar um processo de recuperação de um nó de rede (por exemplo, nó (214) ou (404)) de um sistema distribuído (por exemplo, rede de protocolo de confiança (102 e 212)) que pode ser executado de acordo com implementações da presente invenção. Especificamente, a Figura 10 ilustra um diagrama apresentando uma forma de realização exemplificativa de um método (1000) de execução de um processo de recuperação de um nó de rede, de
Petição 870190097362, de 30/09/2019, pág. 61/134
54/91 acordo com a presente invenção. Como ilustrado na Figura 10, o processo (1000) inclui algumas fases e etapas.
[00153] Em uma primeira fase (1010), um nó de rede (por exemplo, nó de rede Ro) que gostaria de recuperar uma transação alvo com um número de sequência alvo Ro multi-transmite uma mensagem de solicitação de estado (por exemplo, mensagem QUERY_STATE) para os outros nós de rede indicando que o nó de rede deve ser recuperado. A mensagem de pedido de estado pode incluir o número de sequência alvo que o nó de rede Ro gostaria de recuperar. Em uma segunda fase (1020), os outros nós de rede recebem a mensagem de solicitação de estado e enviam uma mensagem de resposta de estado (por exemplo, mensagem REPLY_STATE) para o nó de rede Ro. Em uma terceira fase (1030), o nó de rede Ro envia uma mensagem de solicitação (por exemplo, mensagem FETCH_ECHO) para os outros nós de rede solicitando uma mensagem ECHO de cada um dos outros nós de rede. A mensagem ECHO pode ser a mesma mensagem ECHO enviada pelos respectivos nós de rede na segunda fase (320) do processo de consenso (300) como descrito acima com referência Figuras 3 a 6. Em uma quarta fase (1040), cada um dos outros nós de rede envia uma mensagem de ECHO para o nó de rede Ro em resposta à mensagem de FETCH_ECHO. Em uma quinta fase (1050), o nó de rede Ro verifica as mensagens ECHO e recupera a transação alvo de acordo com um código EC, por exemplo, de acordo com as técnicas de reconstrução exemplificativas como descritas acima com referência Figura 4. Em uma sexta fase (1060), o nó de rede Ro envia uma mensagem ACCEPT para os outros nós de rede, indicando que o nó de rede tenha sido recuperada.
[00154] Observe que o processo (1000) é ilustrado como implementado em conjunto com quatro nós de rede apenas para fins ilustrativos. O processo (1000) pode ser implementado em conjunto com qualquer número adequado de nós de rede. O processo (1000), um formato da
Petição 870190097362, de 30/09/2019, pág. 62/134
55/91 mensagem QUERY_STATE e um formato da mensagem REPLY_STATE serão discutidos abaixo em maior detalhe com referência às Figuras 11 e 12.
[00155] A Figura 11 ilustra um exemplo de um processo (1100) para realizar um processo de recuperação de um nó de rede em um sistema de distribuição (por exemplo, rede de protocolo de confiança (102) ou (212)) que pode ser executado de acordo com implementações da presente invenção. Em algumas implementações, o processo (1100) pode ser executado usando um ou mais programas executáveis por computador executados usando um ou mais dispositivos de computação. Para clareza de apresentação, a descrição que se segue geralmente descreve o método (1100) no contexto das outras Figuras nesta descrição. Será entendido que o método (1100) pode ser executado, por exemplo, por qualquer sistema, ambiente, software e hardware adequados, ou uma combinação de sistemas, ambientes, software e hardware, conforme apropriado. Em algumas implementações, várias etapas do método (1100) podem ser executadas em paralelo, em combinação, em loops ou em qualquer ordem.
[00156] O processo (1100) começa em (1106), onde um nó de rede (1102) multi-transmite uma mensagem de solicitação de estado para os outros nós de rede (1104). A mensagem de solicitação de estado inclui uma indicação de que o nó de rede (1102) está para recuperar uma transação alvo com um número de sequência alvo. O nó de rede (1102) pode ser um nó primário ou um nó de cópia de segurança.
[00157] Em algumas implementações da presente invenção, referindo-se a Figura 12, a mensagem QUERY_STATE, como um exemplo da mensagem de solicitação de estado, tem um formato de <j, seq>, em que “j” representa um nó de rede (1102) que envia a mensagem QUERY_STATE e “seq” representa um maior número de sequência ou um número de sequência mais recente para o nó de rede (1102) no processo de consenso atual. Em
Petição 870190097362, de 30/09/2019, pág. 63/134
56/91 algumas implementações, a mensagem QUERY_STATE pode ter um formato diferente, por exemplo, incluindo campos adicionais ou diferentes.
[00158] Transmitindo a mensagem QUERY_STATE para os outros nós de rede (1104), o nó de rede (1102) está solicitando aos outros nós de rede (1104) para enviarem o seu número de sequência mais recente para o nó de rede (1102), obtendo assim a informação de bloco mais recente do sistema de protocolo de confiança. E obtendo a informação de bloco mais recente de todo o sistema de protocolo de confiança, o nó de rede (1102) pode ser capaz de sincronizar com o estado mais recente de todo o sistema, assim se recuperando e continuando a participar no processo de consenso.
[00159] Referindo-se novamente a Figura 11, em (1108), cada um dos outros nós de rede (1104) envia uma mensagem de resposta de estado (por exemplo, mensagem REPLY_STATE) para o nó de rede (1102) em resposta ao recebimento da mensagem de solicitação de estado. Em algumas implementações, a mensagem de resposta de estado inclui um número de sequência anterior associado aos nós de rede (1104).
[00160] Em algumas implementações, referindo-se à Figura 12, a mensagem REPLY_STATE, como um exemplo da mensagem de resposta de estado, tem um formato de <j, last_seq>, onde “j” representa um nó de rede (1104) que envia a mensagem REPLY_STATE e “last_seq” representa um número de sequência anterior para o nó de rede (1104) no processo de consenso atual. Em algumas implementações, a mensagem REPLY_STATE pode ter um formato diferente, por exemplo, incluindo campos adicionais ou diferentes.
[00161] Referindo-se novamente a Figura 11, em (1110), o nó de rede (1102) determina se um número das mensagens de resposta de estado recebido excede um limiar predeterminado. Por exemplo, o nó de rede (1102) pode determinar se um número de mensagens REPLY_STATE
Petição 870190097362, de 30/09/2019, pág. 64/134
57/91 recebidas excede um número de quórum (por exemplo, 2f + 1 ou n-f). Em algumas implementações, o nó de rede (1102) determina ainda se o número de quórum das mensagens REPLY_STATE recebidas inclui um número de sequência idêntico. O número de quórum das mensagens REPLY_STATE recebidas incluindo um número de sequência idêntico significa que a maioria dos nós de rede (1104) concorda com um estado comum de todo o sistema.
[00162] Em (1112), o nó de rede (1102) determina o número de sequência alvo com base em um número de sequência idêntico se o nó de rede (1102) determinar que o número de mensagens de resposta de estado incluindo o número de sequência idêntico recebido dos nós de rede (1104) excede o limiar predeterminado. Por exemplo, o nó de rede (1102) pode determinar que o número de sequência alvo como sendo um incremento (por exemplo, “last_seq + 1”) do mesmo número de sequência (por exemplo, “last_seq”).
[00163] Em (1114), o nó de rede (1102) envia uma mensagem de solicitação (por exemplo, mensagem FETCH_ECHO) para os outros nós de rede (1104). A mensagem FETCH_ECHO é enviada pelo nó de rede (1102) para solicitar uma mensagem ECHO de cada um dos outros nós de rede (1104). Como discutido acima com referência às Figuras 3 a 6, a mensagem ECHO é uma mensagem transmitida pelos nós de rede (1104) para obter um consenso entre os nós de rede (1104) em uma transação alvo. A mensagem ECHO inclui uma parte da transação alvo (por exemplo, um bloco EC) e uma assinatura do nó de rede (1104) que envia a mensagem ECHO.
[00164] Em algumas implementações, referindo-se à Figura 12, a mensagem FETCH_ECHO, como um exemplo da mensagem de solicitação, tem um formato de <j, last_seq + 1>, onde “j” representa um nó de rede (1102) que envia a mensagem FETCH_ECHO e “last_seq + 1” representa um número de sequência alvo associado às mensagens ECHO que o nó de
Petição 870190097362, de 30/09/2019, pág. 65/134
58/91 rede (1102) está solicitando aos outros nós de rede (1104). Em algumas implementações, a mensagem FETCH_ECHO pode ter um formato diferente, por exemplo, incluindo campos adicionais ou diferentes.
[00165] A mensagem FETCH_ECHO como aqui discutida é enviada pelo nó de rede (1102) para solicitar as mensagens ECHO incluindo um número de sequência mais recente ou um maior número de sequência dos outros nós de rede (1104). Coletando as mensagens ECHO incluindo um número de sequência mais recente ou um maior número de sequência dos outros nós de rede (1104), o nó de rede (1102) pode conseguir recuperar para o estado mais recente associado ao número de sequência mais recente.
[00166] Referindo-se novamente a Figura 11, em (1116), cada um dos nós de rede (1104) envia uma mensagem ECHO para o nó de rede (1102) em resposta ao recebimento da mensagem FETCH_ECHO. Em algumas implementações, cada um dos nós de rede (1104) verifica a mensagem FETCH_ECHO antes de enviar a mensagem ECHO para o nó de rede (1102). Em algumas implementações, cada um dos nós de rede (1104) verifica a mensagem FETCH_ECHO determinando se o número de sequência incluído nas mensagens FETCH_ECHO excede um número de sequência mais recente associado ao nó de rede (1104). Se o número de sequência incluído nas mensagens FETCH_ECHO for igual ao número de sequência mais recente associado ao nó de rede (1104), o nó de rede (1104) determina que a mensagem FETCH_ECHO é válida e uma mensagem ECHO será enviada para o nó de rede (1102). Se o número de sequência incluído nas mensagens FETCH_ECHO exceder o número de sequência mais recente associado ao nó de rede (1104), o nó de rede (1104) determina que a mensagem FETCH_ECHO é inválida e que uma mensagem ECHO não será enviado para o nó de rede (1102).
[00167] Em (1118), o nó de rede (1102) verifica se as
Petição 870190097362, de 30/09/2019, pág. 66/134
59/91 mensagens ECHO enviadas pelos nós de rede (1104) são válidas. Em algumas implementações, o nó de rede (1102) verifica as mensagens ECHO usando uma árvore Merkel. Por exemplo, o nó de rede (1102) pode usar os dados incluídos na mensagem ECHO para reconstruir uma árvore Merkel e determinar um valor de hash de raiz reconstruído da árvore Merkel reconstruída. O nó de rede (1102) pode então comparar o valor de hash de raiz reconstruído com um valor de hash de raiz incluído na mensagem ECHO. Se o valor de hash da raiz reconstruída corresponder ao valor de hash da raiz incluída na mensagem ECHO, o nó de rede (1102) determinará que a mensagem ECHO é válida. Se o valor de hash da raiz reconstruída não corresponder ao valor de hash da raiz incluído na mensagem ECHO, o nó de rede (1102) determina que a mensagem ECHO é inválida e pode descartar a mensagem ECHO inválida.
[00168] Em algumas implementações, o nó de rede (1102) verifica se a mensagem ECHO é válida verificando ainda se a assinatura na mensagem ECHO é válida. Por exemplo, o nó de rede (1102) pode autenticar a assinatura de chave privada na mensagem ECHO usando uma chave pública emparelhada com a chave privada para verificar a assinatura.
[00169] Em (1120), o nó de rede (1102) determina se um número de mensagens ECHO válidas recebidas dos outros nós de rede (1104) excede um limiar predeterminado. Por exemplo, o nó de rede (1102) pode determinar se um número de mensagens ECHO válidas recebidas dos outros nós de rede (1104) excede um número de quórum (por exemplo, 2f + 1).
[00170] Em (1122), o nó de rede (1102) recupera a transação alvo com o número de sequência alvo em resposta à determinação de que o número de mensagens ECHO válidas excede o limiar predeterminado. Em algumas implementações, o nó de rede (1102) recupera a transação alvo usando os dados incluídos no número de mensagens ECHO
Petição 870190097362, de 30/09/2019, pág. 67/134
60/91 válidas. Por exemplo, o nó de rede (1102) pode recuperar um subconjunto de blocos EC incluídos nas mensagens ECHO para reconstruir a transação alvo de acordo com um código EC.
[00171] Em (1124), o nó de rede (1102) envia uma mensagem ACCEPT para os outros nós de rede (1104) depois de recuperar a transação alvo. Por exemplo, o nó de rede (1102) pode fazer multitransmissões de uma mensagem ACCEPT para os outros nós de rede (1104) depois de reconstruir com sucesso a transação alvo. Em algumas implementações, a mensagem ACCEPT inclui um conjunto de assinaturas nas mensagens ECHO e o número de sequência alvo. Ao enviar a mensagem ACCEPT incluindo as assinaturas e o número de sequência alvo para os outros nós de rede (1104), o nó de rede (1102) indica aos outros nós de rede (1104) que o nó de rede (1102) se recuperou e sincronizou com o estado mais recente do sistema.
[00172] O processo de recuperação, conforme discutido acima na presente invenção, inclui muitas características que melhoram a operação dos computadores que implementam o processo de recuperação e ajudam a aliviar o gargalo da rede. Por exemplo, o processo de recuperação na presente invenção inclui operações incluindo enviar uma mensagem de solicitação de estado por um nó de rede que se aplica a ser um novo nó primário, receber mensagens de resposta de estado dos outros nós de rede e enviar uma mensagem FETCH_ECHO pelo nó de rede para solicitar mensagens ECHO dos outros nós de rede. Essas operações são executadas de tal forma que o processo de recuperação do nó de rede com falha não interfere com a operação normal do processo de consenso entre os outros nós de rede não defeituosos. Isso facilita a conservação de características de computação e de rede para recuperar o nó de rede com falha, reduzindo a complexidade do processo de recuperação.
Petição 870190097362, de 30/09/2019, pág. 68/134
61/91 [00173] Referindo-se a Figura 13, a Figura 13 é um diagrama que ilustra módulos de um aparelho de consenso (1300), de acordo com uma implementação da presente invenção. O aparelho (1300) para obter consenso pode ser aplicado a um sistema de consenso baseado em uma tecnologia de protocolo de confiança. Por exemplo, o aparelho (1300) pode corresponder às implementações mostradas nas Figuras 1 a 6. O aparelho (1300) pode ser implementado em um nó primário na rede de protocolo de confiança. O aparelho (1300) inclui o seguinte: uma unidade de recepção ou receptora (1302), configurada para receber uma solicitação de transação; uma unidade geradora (1304), configurada para gerar um número de blocos de código de apagamento (EC) de acordo com um código EC usando a solicitação de transação; um transmissor ou unidade de transmissão (1306), configurado para enviar um número de primeiras mensagens para um ou mais nós de cópia de segurança, respectivamente, em que cada número de primeiras mensagens inclui um valor de hash composto associado ao número de blocos EC; o receptor ou unidade de recepção (1302), ainda configurado para receber pelo menos uma segunda mensagem de pelo menos um dos nós de cópia de segurança, em que a pelo menos uma segunda mensagem inclui um do número de primeiras mensagens e uma assinatura de pelo menos um dos nós de cópia de segurança associados ao número do primeiro número de mensagens; uma unidade de verificação (1308), configurada para verificar se a pelo menos uma segunda mensagem é válida em resposta ao recebimento da pelo menos uma segunda mensagem do pelo menos um do nó de cópia de segurança; uma unidade de determinação (1310), configurada para determinar se um número de segundas mensagens válidas excede um limiar predeterminado; uma unidade de reconstrução (1312), configurada para reconstruir a solicitação de transação com base em um subconjunto do número de segundas mensagens válidas de acordo com o código EC em resposta à
Petição 870190097362, de 30/09/2019, pág. 69/134
62/91 determinação de que o número de segundas mensagens válidas excede o limiar predeterminado; o transmissor ou a unidade de transmissão (1306), adicionalmente configurada para enviar uma terceira mensagem, para os outros nós de rede em resposta à determinação de que a solicitação de transação foi reconstruída com sucesso, em que a terceira mensagem inclui um conjunto de assinaturas que estão nas segundas mensagens válidas; o receptor ou a unidade de recepção (1302), ainda configurado para receber pelo menos uma terceira mensagem de pelo menos um dos nós de cópia de segurança; e uma unidade de execução (1314), configurada para executar a solicitação de transação em resposta ao recebimento de um número predeterminado de terceiras mensagens que são idênticas.
[00174] Em uma implementação opcional, a solicitação de transação é associada a um número de sequência.
[00175] Em uma implementação opcional, a geração da pluralidade de blocos EC de acordo com um código EC inclui o seguinte: transformar a solicitação de transação em uma mensagem EC utilizando o código EC e dividindo a mensagem EC no número de bloco EC.
[00176] Em uma implementação opcional, o valor de hash composto do número de blocos EC é gerado usando uma árvore de hash.
[00177] Em uma implementação opcional, a árvore de hash inclui uma árvore Merkle e em que o valor de hash composto é um valor de hash raiz da árvore Merkle.
[00178] Em uma implementação opcional, a assinatura de pelo menos um dos nós de cópia de segurança associados a um do número de primeiras mensagens inclui uma assinatura de chave privada de pelo menos um dos nós de cópia de segurança associados ao número de primeiras mensagens.
[00179] Em uma implementação opcional, a pelo menos
Petição 870190097362, de 30/09/2019, pág. 70/134
63/91 uma segunda mensagem inclui ainda pelo menos um do número de blocos EC.
[00180] Em uma implementação opcional, a verificação se a pelo menos uma segunda mensagem é válida inclui o seguinte: gerar uma árvore de hash reconstruída utilizando pelo menos um do número de blocos EC na pelo menos uma segunda mensagem; determinar um valor de hash composto reconstruído da árvore de hash reconstruída; e determinar se o valor de hash composto reconstruído corresponde aos valores de hash compostos na pelo menos uma segunda mensagem.
[00181] Em uma implementação opcional, a unidade de determinação (1310) é ainda configurada para determinar que a pelo menos uma segunda mensagem é válida em resposta à determinação de que o valor de hash composto reconstruído corresponde aos valores de hash compostos nas segundas mensagens.
[00182] Em uma implementação opcional, o número predeterminado de terceiras mensagens idênticas inclui o número predeterminado das terceiras mensagens com um conjunto idêntico de assinaturas.
[00183] A Figura 13 é um diagrama esquemático ilustrando um módulo funcional interno e uma estrutura de um aparelho de consenso (1300). Um corpo de execução, em essência, pode ser um dispositivo eletrônico, e o dispositivo eletrônico inclui o seguinte: pelo menos um processador; e uma memória configurada para armazenar uma instrução executável de pelo menos um processador.
[00184] O pelo menos um processador é configurado para receber uma solicitação de transação; gerar um número de blocos de código de eliminação (EC) de acordo com um código EC usando a solicitação de transação; enviar um número de primeiras mensagens para um ou mais nós de cópia de segurança, respectivamente, em que cada número de primeiras
Petição 870190097362, de 30/09/2019, pág. 71/134
64/91 mensagens inclui um valor de hash composto associado ao número de blocos EC; receber pelo menos uma segunda mensagem de pelo menos um dos nós de cópia de segurança, em que a pelo menos uma segunda mensagem inclui um do número de primeiras mensagens e uma assinatura de pelo menos um dos nós de cópia de segurança associados ao número de primeiras mensagens; verificar se a pelo menos uma segunda mensagem é válida em resposta ao recebimento da pelo menos uma segunda mensagem do pelo menos um do nó de cópia de segurança; determinar se um número de segundas mensagens válidas excede um limiar predeterminado; reconstruir a solicitação de transação com base em um subconjunto do número de segundas mensagens válidas de acordo com o código EC, em resposta à determinação de que o número de segundas mensagens válidas excede o limiar predeterminado; enviar uma terceira mensagem para os outros nós de rede em resposta à determinação de que a solicitação de transação foi reconstruída com sucesso, em que a terceira mensagem inclui um conjunto de assinaturas que estão nas segundas mensagens válidas; receber pelo menos uma terceira mensagem de pelo menos um dos nós de cópia de segurança; e executar a solicitação de transação em resposta ao recebimento de um número predeterminado de terceira mensagens idênticas.
[00185] Opcionalmente, a solicitação de transação é associada a um número de sequência.
[00186] Opcionalmente, a geração da pluralidade de blocos EC de acordo com um código EC inclui o seguinte: transformar a solicitação de transação em uma mensagem EC usando o código EC e dividindo a mensagem EC no número de bloco EC.
[00187] Opcionalmente, o valor de hash composto do número de blocos EC é gerado usando uma árvore de hash.
[00188] Opcionalmente, a árvore hash inclui uma árvore
Petição 870190097362, de 30/09/2019, pág. 72/134
65/91
Merkle, e em que o valor de hash composto é um valor de hash raiz da árvore Merkle.
[00189] Opcionalmente, a assinatura de pelo menos um dos nós de cópia de segurança associados ao um do número de primeiras mensagens inclui uma assinatura de chave privada de pelo menos um dos nós de cópia de segurança associados ao um do número de primeiras mensagens.
[00190] Opcionalmente, a pelo menos uma segunda mensagem inclui ainda pelo menos um do número de blocos EC.
[00191] Opcionalmente, a verificação se a pelo menos uma segunda mensagem é válida inclui o seguinte: gerar uma árvore de hash reconstruída usando pelo menos um do número de blocos EC na pelo menos uma segunda mensagem; determinar um valor de hash composto reconstruído da árvore de hash reconstruída; e determinar se o valor de hash composto reconstruído corresponde aos valores hash compostos na pelo menos uma segunda mensagem.
[00192] Opcionalmente, o pelo menos um processador é ainda configurado para determinar que a pelo menos uma segunda mensagem é válida em resposta à determinação de que o valor de hash composto reconstruído corresponde aos valores de hash compostos nas segundas mensagens.
[00193] Opcionalmente, o número predeterminado de terceiras mensagens idênticas inclui o número predeterminado das terceiras mensagens com um conjunto idêntico de assinaturas.
[00194] Referindo-se a Figura 14, a Figura 14 é um diagrama que ilustra módulos de um aparelho de consenso (1400), de acordo com uma implementação da presente invenção. O aparelho (1400) para obter consenso pode ser aplicado a um sistema de consenso baseado em uma tecnologia protocolo de confiança. O aparelho (1400) pode corresponder às
Petição 870190097362, de 30/09/2019, pág. 73/134
66/91 implementações mostradas nas Figuras 1 a 6. Por exemplo, o aparelho (1400) pode ser implementado em um nó de cópia de segurança de uma rede de protocolo de confiança. O aparelho (1400) inclui o seguinte: uma unidade de recepção ou receptora (1402), configurada para receber uma primeira mensagem do nó primário, em que a primeira mensagem inclui um valor de hash composto associado a um número de blocos EC, em que o número de blocos EC é gerado pelo nó primário de acordo com um código EC usando uma solicitação de transação; um transmissor ou unidade de transmissão (1404), configurado para enviar, pelo nó de cópia de segurança, uma segunda mensagem para os outros nós de rede em resposta ao recebimento da primeira mensagem, em que a segunda mensagem inclui a primeira mensagem e uma assinatura do nó de cópia de segurança associado à primeira mensagem; o receptor ou unidade de recepção (1402), ainda configurado para receber pelo menos uma segunda mensagem de pelo menos um nó de cópia de segurança diferente do nó de cópia de segurança; uma unidade de verificação (1406), configurada para verificar se a pelo menos uma segunda mensagem é válida em resposta ao recebimento da pelo menos uma segunda mensagem do pelo menos um nó de cópia de segurança; uma unidade de determinação (1408), configurada para determinar se um número de segundas mensagens válidas excede um limiar predeterminado; uma unidade de reconstrução (1410), configurada para reconstruir a solicitação de transação com base em um subconjunto do número de segundas mensagens válidas de acordo com o código EC em resposta à determinação de que o número de segundas mensagens válidas excede o limiar predeterminado; o transmissor ou unidade de transmissão (1404), configurado para enviar uma terceira mensagem para os outros nós de rede em resposta à determinação de que a solicitação de transação foi reconstruída com sucesso, em que a terceira mensagem inclui um conjunto de assinaturas que estão nas segundas mensagens válidas; o
Petição 870190097362, de 30/09/2019, pág. 74/134
67/91 receptor ou unidade de recepção (1402), ainda configurado para receber pelo menos uma terceira mensagem de pelo menos um dos nós de cópia de segurança; e uma unidade de execução (1412), configurada para executar a solicitação de transação em resposta ao recebimento de um número predeterminado de terceiras mensagens que são idênticas.
[00195] Em uma implementação opcional, a geração da pluralidade de blocos EC de acordo com um código EC inclui o seguinte: transformar a solicitação de transação em uma mensagem EC utilizando o código EC; e dividir a mensagem EC no número de bloco EC.
[00196] Em uma implementação opcional, o valor de hash composto da pluralidade de blocos EC é gerado usando uma árvore de hash.
[00197] Em uma implementação opcional, a árvore de hash inclui uma árvore Merkle e o valor de hash composto é um valor de hash raiz da árvore Merkle.
[00198] Em uma implementação opcional, a assinatura do nó de cópia de segurança associado à primeira mensagem inclui uma assinatura de chave privada do nó de cópia de segurança associado à primeira mensagem.
[00199] Em uma implementação opcional, a pelo menos uma segunda mensagem inclui ainda pelo menos um do número de blocos EC.
[00200] Em uma implementação opcional, a verificação se a pelo menos uma segunda mensagem é válida inclui o seguinte: gerar uma árvore de hash reconstruída utilizando pelo menos um do número de blocos EC na pelo menos uma segunda mensagem; determinar um valor de hash composto reconstruído da árvore de hash reconstruída; comparar o valor de hash composto reconstruído com um valor de hash composto na pelo menos uma segunda mensagem; e determinar se o valor de hash composto reconstruído corresponde aos valores hash compostos na pelo menos uma
Petição 870190097362, de 30/09/2019, pág. 75/134
68/91 segunda mensagem.
[00201] Em uma implementação opcional, a unidade de determinação (1408) é ainda configurada para determinar que a pelo menos uma segunda mensagem é válida em resposta à determinação de que o valor de hash composto reconstruído corresponde aos valores de hash compostos nas segundas mensagens.
[00202] Em uma implementação opcional, o número predeterminado de terceiras mensagens que são idênticas inclui o número predeterminado das terceiras mensagens com um conjunto idêntico de assinaturas.
[00203] A Figura 14 é um diagrama esquemático ilustrando um módulo funcional interno e uma estrutura de um aparelho de consenso (1400). Um corpo de execução em essência pode ser um dispositivo eletrônico, e o dispositivo eletrônico inclui o seguinte: pelo menos um processador; e uma memória configurada para armazenar uma instrução executável de pelo menos um processador.
[00204] O pelo menos um processador está configurado para receber uma primeira mensagem do nó primário, em que a primeira mensagem inclui um valor de hash composto associado a um número de blocos EC, em que o número de blocos EC é gerado pelo nó primário de acordo com um código EC usando uma solicitação de transação; enviar, pelo nó de cópia de segurança, uma segunda mensagem para os outros nós de rede em resposta ao recebimento da primeira mensagem, em que a segunda mensagem inclui a primeira mensagem e uma assinatura do nó de cópia de segurança associado à primeira mensagem; receber pelo menos uma segunda mensagem de pelo menos um nó de cópia de segurança diferente do nó de cópia de segurança; verificar se a pelo menos uma segunda mensagem é válida em resposta ao recebimento da pelo menos uma segunda mensagem do
Petição 870190097362, de 30/09/2019, pág. 76/134
69/91 pelo menos um nó de cópia de segurança; determinar se um número de segundas mensagens válidas excede um limiar predeterminado; reconstruir a solicitação de transação com base em um subconjunto do número de segundas mensagens válidas de acordo com o código EC, em resposta à determinação de que o número de segundas mensagens válidas excede o limiar predeterminado; enviar uma terceira mensagem para os outros nós de rede em resposta à determinação de que a solicitação de transação foi reconstruída com sucesso, em que a terceira mensagem inclui um conjunto de assinaturas que estão nas segundas mensagens válidas; receber pelo menos uma terceira mensagem de pelo menos um dos nós de cópia de segurança; e executar a solicitação de transação em resposta ao recebimento de um número predeterminado de terceira mensagens idênticas.
[00205] Opcionalmente, a geração da pluralidade de blocos EC de acordo com um código EC inclui o seguinte: transformar a solicitação de transação em uma mensagem EC usando o código EC; e dividir a mensagem EC no número de bloco EC.
[00206] Opcionalmente, o valor de hash composto da pluralidade de blocos EC é gerado usando uma árvore de hash.
[00207] Opcionalmente, a árvore de hash inclui uma árvore Merkle e o valor de hash composto é um valor de hash raiz da árvore Merkle.
[00208] Opcionalmente, a assinatura do nó de cópia de segurança associado à primeira mensagem inclui uma assinatura de chave privada do nó de cópia de segurança associado à primeira mensagem.
[00209] Opcionalmente, a pelo menos uma segunda mensagem inclui ainda pelo menos um do número de blocos EC.
[00210] Opcionalmente, a verificação se a pelo menos uma segunda mensagem é válida inclui o seguinte: gerar uma árvore de hash reconstruída usando pelo menos um do número de blocos EC na pelo menos
Petição 870190097362, de 30/09/2019, pág. 77/134
70/91 uma segunda mensagem; determinar um valor de hash composto reconstruído da árvore de hash reconstruída; comparar o valor de hash composto reconstruído com um valor de hash composto na pelo menos uma segunda mensagem; e determinar se o valor de hash composto reconstruído corresponde aos valores hash compostos na pelo menos uma segunda mensagem.
[00211] Opcionalmente, o pelo menos um processador é ainda configurado para determinar que a pelo menos uma segunda mensagem é válida em resposta à determinação de que o valor de hash composto reconstruído corresponde aos valores de hash compostos nas segundas mensagens.
[00212] Opcionalmente, o número predeterminado de terceiras mensagens idênticas inclui o número predeterminado das terceiras mensagens com um conjunto idêntico de assinaturas.
[00213] Referindo-se a Figura 15, a Figura 15 é um diagrama que ilustra módulos de um aparelho de alteração de nó primário (1500), de acordo com uma implementação da presente invenção. O aparelho (1500) para mudar um nó primário pode ser aplicado a um sistema de consenso baseado em uma tecnologia protocolo de confiança. O aparelho (1500) pode corresponder às implementações mostradas nas Figuras 7 a 9. Por exemplo, o aparelho (1500) pode ser implementado em um nó de cópia de segurança de uma rede de protocolo de confiança. O aparelho (1500) inclui o seguinte: uma unidade de determinação (1502), configurada para determinar que uma alteração de época precisa ser executada, em que a alteração de época causa uma alteração de uma época atual com um nó primário atual para uma nova época com um novo nó primário, em que a época atual compreende um processo de consenso para alcançar o consenso entre o número de nós de rede usando o nó primário, o processo de consenso incluindo três fases; a
Petição 870190097362, de 30/09/2019, pág. 78/134
71/91 unidade de determinação (1502), ainda configurada para determinar um peso respectivo do nó de cópia de segurança associado a cada uma das três fases do processo de consenso na época atual, em que o peso é uma métrica de uma qualificação do nó de cópia de segurança para ser o novo nó primário; a unidade de determinação (1502), ainda configurada para determinar uma soma de peso para o nó de cópia de segurança com base no peso respectivo do nó de cópia de segurança associado a cada uma das três fases na época atual; um transmissor ou unidade de transmissão (1504), configurado para enviar uma mensagem EPOCH_CHANGE para o número de nós da rede diferentes do nó de rede em resposta determinação de que a soma de peso atinge um primeiro limiar predeterminado, em que a mensagem EPOCH_CHANGE indica uma solicitação de uma mudança da época atual com o nó primário atual para a nova época, com o nó de cópia de segurança sendo o novo nó primário, e a mensagem EPOCH_CHANGE inclui a soma de peso do nó de cópia de segurança; uma unidade de recepção ou receptora (1506), configurada para receber pelo menos uma mensagem NEW_EPOCH de pelo menos um do número nós de rede diferentes do nó de cópia de segurança, em que a mensagem NEW_EPOCH indica uma confirmação do nó de cópia de segurança como sendo o novo nó primário; uma unidade de verificação (1508), configurada para verificar se a pelo menos uma mensagem NEW_EPOCH é válida; a unidade de determinação (1502), ainda configurada para determinar se um número de mensagens NEW_EPOCH válidas de pelo menos uma mensagem NEW_EPOCH excede um segundo limiar predeterminado; e a unidade de determinação (1502), ainda configurada para determinar o nó de cópia de segurança como sendo o novo nó primário na nova época, em resposta à determinação de que o número de mensagens NEW_EPOCH válidas excede o segundo limiar predeterminado.
[00214] Em uma implementação opcional, a determinação
Petição 870190097362, de 30/09/2019, pág. 79/134
72/91 de um peso respectivo do nó de cópia de segurança associado a cada uma das três fases do processo de consenso na época atual inclui a determinação de um peso do nó de cópia de segurança para uma primeira fase do processo de consenso como primeiro valor.
[00215] Em uma implementação opcional, a determinação de um peso respectivo do nó de cópia de segurança associado a cada uma das três fases do processo de consenso na época atual inclui o seguinte: em resposta à determinação de uma falha na verificação de quórum em uma segunda fase do consenso processo na época atual, determinar um peso do nó de cópia de segurança para a segunda fase do processo de consenso como sendo um primeiro valor; e em resposta a determinar o sucesso de uma verificação de quórum na segunda fase do processo de consenso na época atual, determinar o peso do nó de cópia de segurança para a segunda fase do processo de consenso como um segundo valor, em que o primeiro valor é menor que o segundo valor.
[00216] Em uma implementação opcional, a verificação de quórum na segunda fase do nó de rede inclui o recebimento de um número predeterminado de mensagens ECHO de outros nós de rede.
[00217] Em uma implementação opcional, a determinação de um peso respectivo do nó de cópia de segurança associado a cada uma das três fases do processo de consenso na época atual inclui o seguinte: em resposta à determinação de uma falha na verificação de quórum em uma terceira fase do consenso processo na época atual, determinar um peso do nó de cópia de segurança para a terceira fase do processo de consenso como sendo um terceiro valor; e em resposta a determinar o sucesso de uma verificação de quórum na terceira fase do processo de consenso na época atual, determinar o peso do nó de cópia de segurança para a terceira fase do processo de consenso como um quarto valor, em que o terceiro valor é menor
Petição 870190097362, de 30/09/2019, pág. 80/134
73/91 que o quarto valor.
[00218] Em uma implementação opcional, a verificação de quórum na terceira fase para o nó de rede inclui o recebimento de um número predeterminado de mensagens aceitas de outros nós de rede, em que cada uma das mensagens aceitas de outros nós de rede indica que cada um dos outros nós de rede aceitou um número predeterminado de mensagens ECHO.
[00219] Em uma implementação opcional, a mensagem EPOCH_CHANGE inclui ainda um conjunto de assinaturas associadas a um conjunto de nós de rede a partir do número de nós de rede, e em que a mensagem NEW_EPOCH compreende um resumo da mensagem EPOCH_CHANGE.
[00220] Em uma implementação opcional, a verificação se a pelo menos uma mensagem NEW_EPOCH é válida inclui verificar se o resumo da mensagem EPOCH_CHANGE na pelo menos uma mensagem NEW_EPOCH é válido e verificar se o resumo da mensagem EPOCH_CHANGE na pelo menos uma mensagem NEW_EPOCH é válida e inclui verificar se o conjunto de assinaturas na mensagem EPOCH_CHANGE é válido.
[00221] Em uma implementação opcional, a determinação de que uma alteração de época precisa ser realizada inclui determinar que uma alteração de época precisa ser executada em resposta a determinação de que o consenso não foi alcançado na época antiga dentro de um período de tempo predeterminado.
[00222] Em uma implementação opcional, o aparelho de alteração de nó primário (1500) inclui ainda o seguinte: uma unidade de operação (1510), configurada para operar na nova época com o novo nó primário, em que a nova época compreende um processo de consenso para alcançar o consenso entre a pluralidade de nós de rede usando o novo nó
Petição 870190097362, de 30/09/2019, pág. 81/134
74/91 primário.
[00223] A Figura 15 é um diagrama esquemático ilustrando um módulo funcional interno e uma estrutura de um aparelho de alteração de nó primário (1500). Um corpo de execução em essência pode ser um dispositivo eletrônico, e o dispositivo eletrônico inclui o seguinte: pelo menos um processador; e uma memória configurada para armazenar uma instrução executável de pelo menos um processador.
[00224] O pelo menos um processador é configurado para determinar que uma alteração de época precisa ser executada, em que a alteração de época causa uma alteração de uma época atual com um nó primário atual para uma nova época com um novo nó primário, em que a época atual compreende processo de consenso para alcançar o consenso entre o número de nós de rede usando o nó primário, o processo de consenso incluindo três fases; determinar um peso respectivo do nó de cópia de segurança associado a cada uma das três fases do processo de consenso na época atual, em que o peso é uma métrica de uma qualificação do nó de cópia de segurança para ser o novo nó primário; determinar uma soma de peso para o nó de cópia de segurança com base no peso respectivo do nó de cópia de segurança associado a cada uma das três fases na época atual; enviar uma mensagem EPOCH_CHANGE para o número de nós de rede diferentes do nó de rede em resposta a determinação de que a soma de peso atinge um primeiro limiar predeterminado, em que a mensagem EPOCH_CHANGE indica uma solicitação para uma alteração da época atual com o nó primário atual para o nova época com o nó de cópia de segurança sendo o novo nó primário e a mensagem EPOCH_CHANGE inclui a soma de peso do nó de cópia de segurança; receber pelo menos uma mensagem NEW_EPOCH de pelo menos um do número de nós de rede diferentes do nó de cópia de segurança, em que a mensagem NEW_EPOCH indica uma confirmação do nó de cópia de
Petição 870190097362, de 30/09/2019, pág. 82/134
75/91 segurança como sendo o novo nó primário; verificar se a pelo menos uma mensagem NEW_EPOCH é válida; determinar se um número de mensagens NEW_EPOCH válidas de pelo menos uma mensagem NEW_EPOCH excede um segundo limiar predeterminado; e determinar que o nó de cópia de segurança seja o novo nó primário na nova época em resposta a determinação de que o número de mensagens NEW_EPOCH válidas excede o segundo limiar predeterminado.
[00225] Opcionalmente, a determinação de um peso respectivo do nó de cópia de segurança associado a cada uma das três fases do processo de consenso na época atual inclui a determinação de um peso do nó de cópia de segurança para uma primeira fase do processo de consenso como um primeiro valor.
[00226] Opcionalmente, a determinação de um peso respectivo do nó de cópia de segurança associado a cada uma das três fases do processo de consenso na época atual inclui o seguinte: em resposta à determinação de uma falha na verificação de quórum em uma segunda fase do processo de consenso na época atual, determinar um peso do nó de cópia de segurança para a segunda fase do processo de consenso como sendo um primeiro valor; e em resposta a determinar o sucesso de uma verificação de quórum na segunda fase do processo de consenso na época atual, determinar o peso do nó de cópia de segurança para a segunda fase do processo de consenso como um segundo valor, em que o primeiro valor é menor que o segundo valor.
[00227] Opcionalmente, a verificação de quórum na segunda fase para o nó de rede inclui o recebimento de um número predeterminado de mensagens ECHO de outros nós de rede.
[00228] Opcionalmente, a determinação de um peso respectivo do nó de cópia de segurança associado a cada uma das três fases
Petição 870190097362, de 30/09/2019, pág. 83/134
76/91 do processo de consenso na época atual inclui o seguinte: em resposta à determinação de uma falha na verificação de quórum em uma terceira fase do processo de consenso no época atual, determinar um peso do nó de cópia de segurança para a terceira fase do processo de consenso como sendo um terceiro valor; e em resposta a determinar o sucesso de uma verificação de quórum na terceira fase do processo de consenso na época atual, determinar o peso do nó de cópia de segurança para a terceira fase do processo de consenso como um quarto valor, em que o terceiro valor é menor que o quarto valor.
[00229] Opcionalmente, a verificação de quórum na terceira fase do nó de rede inclui receber um número predeterminado de mensagens de aceitação de outros nós de rede, em que cada uma das mensagens de aceitação de outros nós de rede indica que cada um dos outros nós de rede aceitou um número predeterminado de mensagens ECHO.
[00230] Opcionalmente, a mensagem EPOCH_CHANGE inclui ainda um conjunto de assinaturas associadas a um conjunto de nós de rede fora do número de nós de rede, e em que a mensagem NEW_EPOCH compreende um resumo da mensagem EPOCH_CHANGE.
[00231] Opcionalmente, a verificação se a pelo menos uma mensagem NEW_EPOCH é válida inclui a verificação de que o resumo da mensagem EPOCH_CHANGE na pelo menos uma mensagem NEW_EPOCH é válido e a verificação se o resumo da mensagem EPOCH_CHANGE na pelo menos uma mensagem NEW_EPOCH é válido inclui verificar se o conjunto de assinaturas na mensagem EPOCH_CHANGE é válido.
[00232] Opcionalmente, a determinação de que uma alteração de época precisa ser realizada inclui a determinação de que uma alteração de época precisa ser executada em resposta a determinação de que o consenso não foi alcançado na época antiga dentro de um período de tempo
Petição 870190097362, de 30/09/2019, pág. 84/134
77/91 predeterminado.
[00233] Opcionalmente, o pelo menos um processador é ainda configurado para operar na nova época com o novo nó primário, em que a nova época compreende um processo de consenso para obter consenso entre a pluralidade de nós de rede usando o novo nó primário.
[00234] Referindo-se a Figura 16, a Figura 16 é um diagrama que ilustra módulos de um aparelho de alteração de nó primário (1600), de acordo com uma implementação da presente invenção. O aparelho (1600) para mudar um nó primário pode ser aplicado a um sistema de consenso baseado em uma tecnologia protocolo de confiança. O aparelho (1600) corresponde às implementações mostradas nas Figuras 7 a 9. Por exemplo, o aparelho (1400) pode ser implementado em um nó de rede de uma rede de protocolo de confiança. O aparelho (1600) inclui o seguinte: uma unidade de recepção ou receptor (1602), configurada para receber uma mensagem EPOCH_CHANGE de um nós de cópia de segurança diferente do nó de rede, em que a mensagem EPOCH_CHANGE inclui uma indicação de que uma alteração de época precisa ser executada, em que a alteração de época causa uma alteração de uma época atual com um nó primário atual para uma nova época com um novo nó primário; uma unidade de verificação (1604), configurada para verificar se a mensagem EPOCH_CHANGE é válida; um transmissor ou unidade de transmissão (1606), configurado para enviar uma mensagem NEW_EPOCH aos outros nós de rede em resposta à verificação de que a mensagem EPOCH_CHANGE é válida, em que a mensagem NEW_EPOCH compreende um resumo da mensagem EPOCH_CHANGE; o receptor ou unidade de recepção (1602), ainda configurado para receber pelo menos uma mensagem NEW_EPOCH de pelo menos um do número de nó de rede diferentes do nó de rede; a unidade de verificação (1604), ainda configurada para verificar se a pelo menos uma mensagem NEW_EPOCH é
Petição 870190097362, de 30/09/2019, pág. 85/134
78/91 válida; uma unidade de determinação (1608), configurada para determinar se um número de mensagens NEW_EPOCH válidas de pelo menos uma mensagem NEW_EPOCH excede um limiar predeterminado; e a unidade de determinação (1608), ainda configurada para determinar o nó de cópia de segurança como sendo o novo nó primário na nova época, em resposta à determinação de que o número de mensagens NEW_EPOCH válidas excede o limiar predeterminado.
[00235] Em uma implementação opcional, a mensagem EPOCH_CHANGE inclui uma soma de peso associada ao nó de cópia de segurança e um conjunto de assinaturas associadas a um conjunto de nós de rede do número de nós de rede.
[00236] Em uma implementação opcional, a verificação se a mensagem EPOCH_CHANGE é válida inclui verificar se a soma de peso na mensagem EPOCH_CHANGE é válida e verificar se a soma de peso na mensagem EPOCH_CHANGE é válida, inclui verificar se o conjunto de assinaturas é válido.
[00237] Em uma implementação opcional, verificar se a mensagem de pelo menos uma NEW_EPOCH é válida inclui verificar se o resumo da mensagem EPOCH_CHANGE na pelo menos uma mensagem NEW_EPOCH é válido, e a verificação se o resumo da mensagem EPOCH_CHANGE na pelo menos uma mensagem NEW_EPOCH é válida inclui verificar se o conjunto de assinaturas na mensagem EPOCH_CHANGE é válido.
[00238] A Figura 16 é um diagrama esquemático que ilustra um módulo funcional interno e uma estrutura de um aparelho de alteração de nó primário (1600). Um corpo de execução em essência pode ser um dispositivo eletrônico, e o dispositivo eletrônico inclui o seguinte: um pelo menos um processador; e uma memória configurada para armazenar uma
Petição 870190097362, de 30/09/2019, pág. 86/134
79/91 instrução executável de pelo menos um processador.
[00239] O pelo menos um processador é configurado para receber uma mensagem EPOCH_CHANGE de um nó de cópia de segurança diferente do nó de rede, em que a mensagem EPOCH_CHANGE inclui uma indicação de que uma alteração de época precisa ser executada, em que a alteração de época causa uma alteração de uma época atual com um nó primário atual para uma nova época com um novo nó primário; verificar se a mensagem EPOCH_CHANGE é válida; enviar uma mensagem NEW_EPOCH aos outros nós de rede em resposta à verificação de que a mensagem EPOCH_CHANGE é válida, em que a mensagem NEW_EPOCH compreende um resumo da mensagem EPOCH_CHANGE; receber pelo menos uma mensagem NEW_EPOCH de pelo menos um dos vários de nós de rede diferentes do nó de rede; verificar se a pelo menos uma mensagem NEW_EPOCH é válida; determinar se um número de mensagens NEW_EPOCH válidas de pelo menos uma mensagem NEW_EPOCH excede um limiar predeterminado; e determinar que o nó de cópia de segurança seja o novo nó primário na nova época em resposta a determinação de que o número de mensagens NEW_EPOCH válidas excede o limiar predeterminado.
[00240] Opcionalmente, a mensagem EPOCH_CHANGE inclui uma soma de peso associada ao nó de cópia de segurança e um conjunto de assinaturas associadas a um conjunto de nós de rede do número de nós de rede.
[00241] Opcionalmente, a verificação de se a mensagem EPOCH_CHANGE é válida inclui verificar se a soma de peso na mensagem EPOCH_CHANGE é válida e a verificação se a soma de peso na mensagem EPOCH_CHANGE é válida inclui verificar se o conjunto de assinaturas é válido.
[00242] Opcionalmente, a verificação se a pelo menos uma
Petição 870190097362, de 30/09/2019, pág. 87/134
80/91 mensagem NEW_EPOCH é válida inclui a verificação de que o resumo da mensagem EPOCH_CHANGE na pelo menos uma mensagem NEW_EPOCH é válido e a verificação se o resumo da mensagem EPOCH_CHANGE na pelo menos uma mensagem NEW_EPOCH é válido inclui verificar se o conjunto de assinaturas na mensagem EPOCH_CHANGE é válido.
[00243] Referindo-se a Figura 17, a Figura 17 é um diagrama que ilustra módulos de um aparelho de recuperação (1700), de acordo com uma implementação da presente invenção. O aparelho (1700) para recuperação pode ser aplicado a um sistema de consenso baseado em uma tecnologia protocolo de confiança. O aparelho (1700) pode corresponder às implementações mostradas nas Figuras 10 a 12. Por exemplo, o aparelho (1700) pode ser implementado em um nó de rede de uma rede de protocolo de confiança. O aparelho (1700) inclui o seguinte: uma unidade de transmissão (1702), configurada para transmitir, por um nó de rede de uma rede de protocolo de confiança, uma mensagem de solicitação de estado para um número de outros nós de rede da rede de protocolo de confiança, em que o nó de rede deve recuperar uma transação alvo de um número de sequência alvo; um receptor (1704) ou uma unidade de recepção (1704), configurada para receber um número de mensagens de resposta de estado do número de outros nós de rede, em que cada um dos números de mensagens de resposta de estado inclui um número de sequência; uma unidade de identificação (1706), configurada para identificar o número de sequência alvo com base no número de sequência alvo em resposta à determinação de que um número de mensagens de resposta de estado excede um limiar predeterminado, em que cada um dos números das mensagens de resposta de estado compreende um número de sequência alvo; um transmissor (1708) ou uma unidade transmissora (1708), configurada para enviar uma mensagem de solicitação ao número de outros nós de rede, em que a mensagem de solicitação solicita uma
Petição 870190097362, de 30/09/2019, pág. 88/134
81/91 mensagem ECHO de cada um dos outros nós de rede, em que a mensagem ECHO é uma mensagem transmitida por o número de outros nós de rede para obter um consenso entre o número de outros nós de rede na transação alvo que possui o número de sequência alvo e a mensagem ECHO inclui uma parte da transação alvo e uma assinatura de cada um dos números de outros nós de rede; o receptor (1704) ou a unidade de recepção (1704), adicionalmente configurada para receber um número de mensagens ECHO do número de outros nós de rede; uma unidade de determinação (1710), configurada para determinar um número de mensagens ECHO válidas a partir do número de mensagens ECHO, em que cada um do número de mensagens ECHO válidas inclui o número sequencial alvo; uma unidade de recuperação (1712), configurada para recuperar a transação alvo com o número de sequência alvo no nó de rede com base no número de mensagens ECHO válidas em resposta a determinação de que o número de mensagens ECHO válidas excede um limiar predeterminado; e o transmissor (1708), ainda configurado para enviar uma mensagem para o número de outros nós de rede, indicando que o nó de rede foi recuperado.
[00244] Em uma implementação opcional, o número de nós de rede inclui um nó primário e um ou mais nós de cópia de segurança.
[00245] Em uma implementação opcional, o nó de rede é um nó primário ou um nó de cópia de segurança.
[00246] Em uma implementação opcional, a mensagem de solicitação inclui o número de sequência alvo.
[00247] Em uma implementação opcional, o aparelho de recuperação (1700) inclui ainda o seguinte: uma unidade de verificação (1714), configurada para verificar, por cada um do número de outros nós de rede diferentes do nó de rede, a mensagem de solicitação antes de enviar as mensagens ECHO ao nó de rede.
Petição 870190097362, de 30/09/2019, pág. 89/134
82/91 [00248] Em uma implementação opcional, a unidade de verificação (1714), é ainda configurada para verificar se cada uma das mensagens ECHO é válida, em que a verificação de se cada uma das mensagens ECHO é válida inclui a verificação se cada uma das mensagens ECHO é válida usando uma árvore Merkel.
[00249] Em uma implementação opcional, a verificação de se cada mensagem ECHO é válida inclui verificar se a assinatura na mensagem ECHO é válida.
[00250] Em uma implementação opcional, cada uma das mensagens ECHO inclui ainda pelo menos um de vários blocos de código de apagamento (EC) associados à transação alvo, em que o número de blocos EC é gerado de acordo com um código EC utilizando a transação alvo.
[00251] Em uma implementação opcional, a recuperação da transação alvo com o número de sequência alvo no nó de rede com base no número de mensagens ECHO válidas compreende reconstruir a transação alvo utilizando um subconjunto da pluralidade de blocos EC que estão no número de mensagens ECHO válidas.
[00252] Em uma implementação opcional, a mensagem para o número de outros nós de rede indicando que o nó de rede foi recuperado inclui um conjunto de assinaturas no número de mensagens ECHO válidas e o número de sequência alvo.
[00253] O sistema, aparelho, módulo ou unidade ilustrados nas implementações anteriores podem ser implementados usando um chip de computador ou uma entidade, ou podem ser implementados usando um produto tendo uma certa função. Um dispositivo de implementação típico é um computador, e o computador pode ser um computador pessoal, um laptop, um telefone celular, um celular com câmera, um smartphone, um assistente digital pessoal, um reprodutor de mídia, um dispositivo de navegação, um dispositivo
Petição 870190097362, de 30/09/2019, pág. 90/134
83/91 de que recebe e envia e-mail, um console de jogos, um computador tablet, um dispositivo que pode ser vestido ou qualquer combinação destes dispositivos.
[00254] Para um processo de implementação de funções e papéis de cada unidade no aparelho, podem ser feitas referências a um processo de implementação de etapas correspondentes no método anterior. Detalhes são omitidos aqui para simplificar.
[00255] Como uma implementação de aparelho corresponde basicamente a uma implementação de método, para partes relacionadas, referências podem ser feitas a descrições relacionadas na implementação do método. A implementação do aparelho descrita anteriormente é meramente um exemplo. As unidades descritas como partes separadas podem ou não estar fisicamente separadas, e as peças exibidas como unidades podem ou não ser unidades físicas, podem estar localizadas em uma posição, ou podem ser distribuídas em uma pluralidade de unidades de rede. Alguns ou todos os módulos podem ser selecionados com base nas demandas reais para alcançar os objetivos das soluções da presente invenção. Uma técnico no assunto pode compreender e implementar as implementações da presente aplicação sem esforços criativos.
[00256] A Figura 17 é um diagrama esquemático que ilustra um módulo funcional interno e uma estrutura de um aparelho de recuperação (1700). Um corpo de execução, em essência, pode ser um dispositivo eletrônico, e o dispositivo eletrônico inclui o seguinte: pelo menos um processador; e uma memória configurada para armazenar uma instrução executável de pelo menos um processador.
[00257] O pelo menos um processador é configurado para transmitir, por um nó de rede de uma rede de protocolo de confiança, uma mensagem de solicitação de estado para vários outros nós de rede da rede de protocolo de confiança, em que o nó de rede deve recuperar uma transação
Petição 870190097362, de 30/09/2019, pág. 91/134
84/91 alvo de um número de sequência alvo; receber um número de mensagens de resposta de estado do número de outros nós de rede, em que cada um dos números de mensagens de resposta de estado inclui um número de sequência; identificar o número de sequência alvo com base no número de sequência alvo em resposta a determinação de que um número de mensagens de resposta de estado excede um limiar predeterminado, em que cada um dos números de mensagens de resposta de estado compreende um número de sequência alvo; enviar uma mensagem de solicitação ao número de outros nós de rede, em que a mensagem de solicitação solicita uma mensagem ECHO de cada um dos outros nós de rede, em que a mensagem ECHO é uma mensagem transmitida por cada um do número de outros nós de rede para alcançar um consenso entre o número de outros nós de rede na transação alvo com o número de sequência alvo, e a mensagem ECHO inclui uma parte da transação alvo e uma assinatura de cada um dos números de outros nós de rede; receber um número de mensagens ECHO da pluralidade de outros nós de rede; determinar um número de mensagens ECHO válidas do número de mensagens ECHO, em que cada um do número de mensagens válidas de ECHO inclui o número de sequência alvo; recuperar a transação alvo com o número de sequência alvo no nó de rede com base no número de mensagens ECHO válidas em resposta à determinação de que o número de mensagens ECHO válidas excede um limiar predeterminado; e enviar uma mensagem para o número de outros nós de rede indicando que o nó de rede foi recuperado.
[00258] Opcionalmente, o número de nós de rede inclui um nó primário e um ou mais nós de cópia de segurança.
[00259] Opcionalmente, o nó de rede é um nó primário ou um nó de cópia de segurança.
[00260] Opcionalmente, a mensagem de solicitação inclui o número de sequência alvo.
Petição 870190097362, de 30/09/2019, pág. 92/134
85/91 [00261] Opcionalmente, o pelo menos um processador é ainda configurado para verificar, por cada um dos números de outros nós de rede diferentes do nó de rede, a mensagem de solicitação antes de enviar as mensagens ECHO para o nó de rede.
[00262] Opcionalmente, o pelo menos um processador é ainda configurado para verificar se cada uma das mensagens ECHO é válida, em que a verificação se cada uma das mensagens ECHO é válida inclui a verificação se cada uma das mensagens ECHO é válida usando uma árvore Merkel.
[00263] Opcionalmente, a verificação se cada mensagem ECHO é válida inclui a verificação da validade da assinatura na mensagem ECHO.
[00264] Opcionalmente, cada uma das mensagens ECHO inclui ainda pelo menos um de um número de blocos de código de apagamento (EC) associados à transação alvo, em que o número de blocos EC é gerado de acordo com um código EC usando a transação alvo.
[00265] Opcionalmente, a recuperação da transação alvo com o número de sequência alvo no nó de rede com base no número de mensagens ECHO válidas inclui a reconstrução da transação alvo usando um subconjunto do número de blocos EC que estão no número de mensagens ECHO válidas.
[00266] Opcionalmente, a mensagem para o número de outros nós de rede indicando que o nó de rede foi recuperado inclui um conjunto de assinaturas no número de mensagens ECHO válidas e o número de sequência alvo.
[00267] As implementações do assunto e as ações e operações descritas nesta descrição podem ser implementadas em circuitos eletrônicos digitais, em software ou firmware de computador tangivelmente
Petição 870190097362, de 30/09/2019, pág. 93/134
86/91 incorporado, em hardware de computador, incluindo as estruturas divulgadas nesta descrição e seus equivalentes estruturais, ou em combinações de um ou mais deles. As implementações da matéria objeto descritos nesta invenção podem ser implementadas como um ou mais programas de computador, por exemplo, um ou mais módulos de instruções de programas de computador, codificados em um veículo de programa de computador, para execução ou controle da operação de aparelho de processamento de dados. O veículo pode ser um meio de armazenamento de computador tangível não transitório. Alternativamente, ou em adição, o veículo pode ser um sinal propagado gerado artificialmente, por exemplo, um sinal elétrico, óptico, eletromagnético gerado por máquina que é gerado para codificar a informação para transmissão para o aparelho receptor adequado para ser executado por um aparelho de processamento de dados. O meio de armazenamento de computador pode ser ou ser parte de um dispositivo de armazenamento legível por máquina, um substrato de armazenamento legível por máquina, um dispositivo de memória de acesso aleatório ou serial, ou uma combinação de um ou mais deles. Um meio de armazenamento de computador não é um sinal propagado.
[00268] O termo “aparelho de processamento de dados” engloba todos os tipos de aparelhos, dispositivos e máquinas para processamento de dados, incluindo, por exemplo, um processador programável, um computador ou vários processadores ou computadores. Aparelho de processamento de dados pode incluir circuito lógico de propósito especial, por exemplo, um (matriz de portas lógicas programáveis) FPGA, um ASIC (circuito integrado específico de aplicação), ou uma GPU (unidade de processamento gráfico). O aparelho também pode incluir, além do hardware, código que cria um ambiente de execução para programas de computador, por exemplo, código que constitui o firmware do processador, uma pilha de protocolos, um sistema de gerenciamento de banco de dados, um sistema
Petição 870190097362, de 30/09/2019, pág. 94/134
87/91 operacional ou uma combinação de um ou mais eles.
[00269] Um programa de computador, que também pode ser referido ou descrito como um programa, software, aplicativo de software, aplicativo, módulo, módulo de software, mecanismo, script ou código, pode ser escrito em qualquer forma de linguagem de programação, incluindo linguagens compiladas ou interpretadas, ou linguagens declarativas ou processuais; e pode ser implementado em qualquer forma, incluindo como um programa suportado sozinho ou como um módulo, componente, motor, sub-rotina, ou outra unidade apropriada para a execução em um ambiente de computação, em que o ambiente pode incluir um ou mais computadores interligados por um conjunto de dados rede de comunicação em um ou mais locais.
[00270] Um programa de computador pode, mas não precisa, corresponder a um arquivo em um sistema de arquivos. Um programa de computador 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 múltiplos arquivos coordenados, por exemplo, arquivos que armazenam um ou mais módulos, sub - programas, ou partes do código.
[00271] Os processos e os fluxos lógicos descritos nesta invenção podem ser realizados por um ou mais computadores executando um ou mais programas de computador para realizar operações operando em dados de entrada e gerando saída. Os processos e fluxos lógicos também podem ser executados por circuitos lógicos de propósito especial, por exemplo, um FPGA, um ASIC ou uma GPU, ou por uma combinação de circuitos lógicos de propósito especial e um ou mais computadores programados.
[00272] Computadores adequados para a execução de um programa de computador podem ser baseados em microprocessadores de
Petição 870190097362, de 30/09/2019, pág. 95/134
88/91 propósito geral ou especial, ou em qualquer outro tipo de unidade de processamento central. Geralmente, uma unidade de processamento central receberá instruções e dados a partir de uma memória somente leitura ou uma memória de acesso aleatório ou ambos. Elementos de um computador podem incluir uma unidade de processamento central para executar instruções e um ou mais dispositivos de memória para armazenar instruções e dados. A unidade de processamento central e a memória podem ser complementadas por, ou incorporadas em circuitos lógicos de finalidade especial.
[00273] Geralmente, um computador será acoplado a pelo menos um meio de armazenamento não transitório legível por computador (também chamado de memória legível por computador). O meio de armazenamento acoplado ao computador pode ser um componente interno do computador (por exemplo, um disco rígido integrado) ou um componente externo (por exemplo, disco rígido de barramento serial universal (USB) ou um sistema de armazenamento acessado por uma rede). Exemplos de mídia de armazenamento podem incluir, por exemplo, discos magnéticos, magneto ópticos ou ópticos, unidades de estado sólido, fontes de armazenamento de rede, como sistemas de armazenamento em nuvem ou outros tipos de mídia de armazenamento. No entanto, um computador não precisa ter esses dispositivos. Além disso, um computador pode ser incorporado em outro dispositivo, por exemplo, um telefone celular, um assistente digital pessoal (PDA), um player de áudio ou vídeo, um console de jogos, um receptor GPS ou um dispositivo de armazenamento portátil, por exemplo, uma unidade flash de barramento serial universal (USB), para citar apenas alguns.
[00274] Para fornecer a interação com um usuário, implementações da matéria objeto descrita nesta invenção podem ser implementadas em, ou configuradas para se comunicar com, um computador tendo um dispositivo de exibição, por exemplo, um monitor LCD (display de
Petição 870190097362, de 30/09/2019, pág. 96/134
89/91 cristal líquido), para exibir informações para o usuário, e um dispositivo de entrada pelo qual o usuário pode fornecer entrada para o computador, por exemplo, um teclado e um dispositivo apontador, por exemplo, um mouse, um trackball ou touchpad. Outros tipos de dispositivos também podem ser usados para fornecer interação com um usuário; por exemplo, a retroalimentação fornecida ao usuário pode ser qualquer forma de retroalimentação sensorial, por exemplo, retroalimentação visual, retroalimentação auditiva ou retroalimentação 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 de um usuário em resposta a solicitações recebidas do navegador da Web ou interagindo com um aplicativo executado em um dispositivo de usuário, por exemplo, um smartphone ou tablet eletrônico. Além disso, um computador pode interagir com um usuário enviando mensagens de texto ou outras formas de mensagem para um dispositivo pessoal, por exemplo, um smartphone que está executando um aplicativo de mensagens e recebendo mensagens responsivas do usuário em troca.
[00275] Esta invenção usa o termo “configurado para” em conexão com sistemas, aparelhos e componentes de programas de computador. Para que um sistema de um ou mais computadores seja configurado para executar operações ou ações particulares significa que o sistema instalou nele software, firmware, hardware ou uma combinação deles que, em operação, fazem com que o sistema execute as operações ou ações. Para um ou mais programas de computador serem configurados para executar operações ou ações particulares significa que um ou mais programas incluem instruções que, quando executadas pelo aparelho de processamento de dados,
Petição 870190097362, de 30/09/2019, pág. 97/134
90/91 fazem com que o aparelho execute as operações ou ações. Para circuitos lógicos com finalidade especial a serem configurados para executar operações ou ações particulares significa que o circuito possui lógica eletrônica que realiza as operações ou ações.
[00276] Enquanto esta invenção contém muitos detalhes de implementação, estes não devem ser interpretados como limitações no escopo do que está sendo reivindicado, que é definido pelas próprias reivindicações, mas sim como descrições de características que podem ser específicas para implementações específicas. Certas características que são descritas nesta invenção no contexto de implementações separadas também podem ser realizadas em combinação em uma única implementação. Por outro lado, várias características que são descritas no contexto de uma única implementação também podem ser realizadas em várias implementações separadamente ou em qualquer sub-combinação adequada. Além disso, embora as características possam ser descritas acima como atuando em certas combinações e até mesmo inicialmente reivindicadas como tal, uma ou mais características de uma combinação reivindicada podem em alguns casos ser extirpadas da combinação, e a reivindicação pode ser direcionada para uma sub-combinação ou variação de uma sub-combinação.
[00277] Da mesma forma, enquanto as operações são ilustradas nos desenhos e recitadas nas reivindicações em uma ordem particular, isso não deve ser entendido como exigindo que tais operações sejam executadas na ordem particular mostrada ou em ordem sequencial, ou que todas as operações ilustradas sejam executadas, para alcançar resultados desejáveis. Em determinadas circunstâncias, a multitarefa e o processamento paralelo podem ser vantajosos. Além disso, a separação de vários módulos e componentes do sistema nas implementações descritas acima não deve ser entendida como exigindo tal separação em todas as implementações, e deve
Petição 870190097362, de 30/09/2019, pág. 98/134
91/91 ser entendido que os componentes e sistemas do programa descritos geralmente podem ser integrados em um único produto de software ou empacotados em vários produtos de software.
[00278] Implementações particulares do assunto foram descritas. Outras implementações estão dentro do escopo das seguintes reivindicações. Por exemplo, as ações citadas nas reivindicações podem ser realizadas em uma ordem diferente e ainda alcançar resultados desejáveis. Como um exemplo, os processos ilustrados nas Figuras anexas não requerem necessariamente a ordem particular mostrada, ou ordem sequencial, para alcançar os resultados desejados. Em alguns casos, a multitarefa e o processamento paralelo podem ser vantajosos.

Claims (42)

  1. Reivindicações
    1. MÉTODO IMPLEMENTADO POR COMPUTADOR para realizar uma alteração de um nó primário em uma rede de protocolo de confiança (blockchain), caracterizado por compreender uma pluralidade de nós de rede, em que a pluralidade de nós de rede compreende o nó primário e um ou mais nós de cópia de segurança, o método que compreender:
    determinar, por um nó de cópia de segurança, que uma alteração de época precisa ser executada, em que a alteração de época causa uma alteração de uma época atual com um nó primário atual para uma nova época com um novo nó primário, em que a época atual compreende um processo de consenso para alcançar o consenso entre a pluralidade de nós de rede usando o nó primário, o processo de consenso compreendendo três fases:
    determinar, pelo nó de cópia de segurança, um peso respectivo do nó de cópia de segurança associado a cada uma das três fases do processo de consenso na época atual, em que o peso é uma métrica de uma qualificação do nó de cópia de segurança para ser o novo nó primário;
    determinar, pelo nó de cópia de segurança, uma soma de peso para o nó de cópia de segurança com base no peso respectivo do nó de cópia de segurança associado a cada uma das três fases na época atual;
    em resposta à determinação de que a soma de peso atinge um primeiro limiar predeterminado, envia, pelo nó de cópia de segurança, uma mensagem EPOCH_CHANGE para a pluralidade de nós de rede que não o nó de rede, em que a mensagem EPOCH_CHANGE indica uma solicitação de alteração da época atual com o nó primário atual para a nova época, com o nó de cópia de segurança sendo o novo nó primário, e a mensagem EPOCH_CHANGE compreende a soma de peso do nó de cópia de segurança;
    receber, pelo nó de cópia de segurança, pelo menos uma mensagem NEW_EPOCH de pelo menos um da pluralidade de nós de rede
    Petição 870190097362, de 30/09/2019, pág. 100/134
  2. 2/17 diferentes do nó de cópia de segurança, em que a mensagem NEW_ EPOCH indica uma confirmação de que o nó de cópia de segurança é o novo nó primário;
    verificar, pelo nó de cópia de segurança, se a pelo menos uma mensagem NEW_EPOCH é válida;
    determinar, pelo nó de cópia de segurança, se um número de mensagens NEW_EPOCH válidas de pelo menos uma mensagem NEW_EPOCH excede um segundo limiar predeterminado; e em resposta a determinação de que o número de mensagens NEW_EPOCH válidas excede o segundo limiar predeterminado, determinar, pelo nó de cópia de segurança, que o nó de cópia de segurança seja o novo nó primário na nova época.
    2. MÉTODO, de acordo com a reivindicação 1, caracterizado pela determinação de um peso respectivo do nó de cópia de segurança associada a cada uma das três fases do processo de consenso na época atual compreende a determinação de um peso do nó de cópia de segurança para uma primeira fase do processo de consenso como um primeiro valor.
  3. 3. MÉTODO, de acordo com a reivindicação 1, caracterizado pela determinação de um peso respectivo do nó de cópia de segurança associado a cada uma das três fases do processo de consenso na época atual compreende:
    em resposta à determinação de uma falha na verificação de quórum em uma segunda fase do processo de consenso na época atual, determinar um peso do nó de cópia de segurança para a segunda fase do processo de consenso como um primeiro valor; e em resposta a determinar o sucesso de uma verificação de quórum na segunda fase do processo de consenso na época atual, determinar o peso do nó de cópia de segurança para a segunda fase do processo de
    Petição 870190097362, de 30/09/2019, pág. 101/134
    3/17 consenso como um segundo valor, em que o primeiro valor é menor do que o segundo valor.
  4. 4. MÉTODO, de acordo com a reivindicação 3, caracterizado pela verificação de quórum na segunda fase para o nó de rede compreender receber um número predeterminado de mensagens ECHO de outros nós de rede.
  5. 5. MÉTODO, de acordo com a reivindicação 1, caracterizado pela determinação de um peso respectivo do nó de cópia de segurança associado a cada uma das três fases do processo de consenso na época atual compreender:
    em resposta à determinação de uma falha na verificação de quórum em uma terceira fase do processo de consenso na época atual, determinar um peso do nó de cópia de segurança para a terceira fase do processo de consenso como um terceiro valor; e em resposta à determinação do sucesso de uma verificação de quórum na terceira fase do processo de consenso na época atual, determinar o peso do nó de cópia de segurança para a terceira fase do processo de consenso como um quarto valor, em que o terceiro valor é menor do que o quarto valor.
  6. 6. MÉTODO, de acordo com a reivindicação 5, caracterizado pela verificação de quórum na terceira fase para o nó de rede compreender receber um número predeterminado de mensagens de aceitação de outros nós de rede, em que cada uma das mensagens de aceitação de outros nós de rede indica que cada um dos outros nós de rede aceitou um número predeterminado de mensagens ECHO.
  7. 7. MÉTODO, de acordo com a reivindicação 1, caracterizado pela mensagem EPOCH_CHANGE compreender ainda um conjunto de assinaturas associadas a um conjunto de nó de rede a partir da pluralidade de
    Petição 870190097362, de 30/09/2019, pág. 102/134
    4/17 nós de rede, e em que a mensagem NEW_EPOCH compreende um resumo da mensagem EPOCH_CHANGE.
  8. 8. MÉTODO, de acordo com a reivindicação 7, caracterizado por verificar se a pelo menos uma mensagem NEW_EPOCH válida é válida, compreende verificar se o resumo da mensagem EPOCH_CHANGE na pelo menos uma mensagem NEW_EPOCH é válido, e em que verificar se o resumo da mensagem EPOCH_CHANGE na pelo menos uma mensagem NEW_EPOCH é válida compreende verificar se o conjunto de assinaturas na mensagem EPOCH_CHANGE é válido.
  9. 9. MÉTODO, de acordo com a reivindicação 1, caracterizado pela determinação de que uma alteração de época necessita ser realizada compreender a determinação de que uma alteração de época precisa ser executada em resposta a determinação de que o consenso não foi alcançado na época antiga dentro de um período de tempo predeterminado.
  10. 10. MÉTODO, de acordo com a reivindicação 1, caracterizado por compreender ainda operar na nova época com o novo nó primário, em que a nova época compreende um processo de consenso para alcançar um consenso entre a pluralidade de nós de rede utilizando o novo nó primário.
  11. 11. MÉTODO IMPLEMENTADO POR COMPUTADOR para realizar uma alteração de um nó primário em uma rede de protocolo de confiança que compreende uma pluralidade de nós de rede, em que a pluralidade de nós de rede compreende o nó primário e um ou mais nós de cópia de segurança, o método caracterizado por compreender:
    receber, por um nó de rede, uma mensagem EPCOH_CHANGE de um nó de cópia de segurança diferente do nó de rede, em que a mensagem EPOCH_CHANGE compreende uma indicação de que uma alteração de época precisa ser executada, em que a alteração de época causa uma alteração de uma época atual com um nó primário atual para uma nova época com um novo
    Petição 870190097362, de 30/09/2019, pág. 103/134
    5/17 nó primário;
    verificar, pelo nó de rede, se a mensagem EPOCH_CHANGE é válida;
    em resposta a verificar que a mensagem EPOCH_CHANGE é válida, enviar, pelo nó de rede, uma mensagem NEW_EPOCH aos outros nós de rede, em que a mensagem NEW_EPOCH compreende um resumo da mensagem EPOCH_CHANGE;
    receber, pelo nó de rede, pelo menos uma mensagem NEW_EPOCH de pelo menos um dentre a pluralidade de nós de rede diferentes do nó de rede;
    verificar, pelo nó de rede, se a pelo menos uma mensagem NEW-EPOCH é válida;
    determinar, pelo nó de cópia de segurança, se um número de mensagens NEW_EPOCH válidas de pelo menos uma mensagem NEW_EPOCH excede um limiar predeterminado; e em resposta a determinação de que o número de mensagens NEW_EPOCH válidas excede o limiar predeterminado, determinar, pelo nó de rede, o nó de cópia de segurança como o novo nó primário na nova época.
  12. 12. MÉTODO, de acordo com a reivindicação 11, caracterizado pela mensagem EPOCH_CHANGE compreender uma soma de peso associada ao nó de cópia de segurança e um conjunto de assinaturas associadas a um conjunto de nós de rede a partir da pluralidade de nós de rede.
  13. 13. MÉTODO, de acordo com a reivindicação 12, caracterizado por verificar se a mensagem EPOCH_CHANGE é válida compreender verificar se a soma de peso na mensagem EPOCH_CHANGE é válida, em que verificar se a soma de peso na mensagem EPOCH_CHANGE é válida compreender verificar se o conjunto de assinaturas é válido.
    Petição 870190097362, de 30/09/2019, pág. 104/134
    6/17
  14. 14. MÉTODO, de acordo com a reivindicação 12, caracterizado por verificar se a pelo menos uma mensagem NEW_EPOCH é válida, compreender verificar se o resumo da mensagem EPOCH_CHANGE na pelo menos uma mensagem NEW_EPOCH é válido, e em que verificar se o resumo da mensagem EPOCH_CHANGE em pelo menos uma mensagem NEW_EPOCH é válida compreende verificar se o conjunto de assinaturas na mensagem EPOCH_CHANGE é válido.
  15. 15. MEIO DE ARMAZENAMENTO NÃO TRANSITÓRIO, legível por computador, acoplado a um ou mais computadores e configurado com instruções executáveis por um ou mais computadores caracterizado por ser para:
    determinar, por um nó de cópia de segurança de uma rede de protocolo de confiança compreendendo uma pluralidade de nós de rede, que uma alteração de época precisa de ser realizada, em que a pluralidade de nós de rede compreende um nó primário e um ou mais nós de cópia de segurança, compreendendo o nó de cópia de segurança, em que a alteração de época causa uma alteração de uma época atual com um nó primário atual para uma nova época com um novo nó primário, em que a época atual compreende um processo de consenso para alcançar o consenso entre a pluralidade de nós de rede usando o nó primário, o processo de consenso compreendendo três fases;
    determinar, pelo nó de cópia de segurança, um peso respectivo do nó de cópia de segurança associado a cada uma das três fases do processo de consenso na época atual, em que o peso é uma métrica de uma qualificação do nó de cópia de segurança para ser o novo nó primário;
    determinar, pelo nó de cópia de segurança, uma soma de peso para o nó de cópia de segurança com base no peso respectivo do nó de cópia de segurança associado a cada uma das três fases na época atual;
    Petição 870190097362, de 30/09/2019, pág. 105/134
    7/17 em resposta à determinação de que a soma de peso atinge um primeiro limiar predeterminado, enviar, pelo nó de cópia de segurança, uma mensagem EPOCH_CHANGE para a pluralidade de nós de rede diferente do nó de rede, em que a mensagem EPOCH_CHANGE indica uma solicitação de alteração da época atual com o nó primário atual para a nova época, com o nó de cópia de segurança sendo o novo nó primário, e a mensagem EPOCH_CHANGE compreende a soma de peso do nó de cópia de segurança;
    receber, pelo nó de cópia de segurança, pelo menos uma mensagem NEW_EPOCH de pelo menos um da pluralidade de nós de rede diferentes do nó de cópia de segurança, em que a mensagem NEW_EPOCH indica uma confirmação de que o nó de cópia de segurança é o novo nó primário;
    verificar, pelo nó de cópia de segurança, se a pelo menos uma mensagem NEW_EPOCH é válida;
    determinar, pelo nó de cópia de segurança, se um número de mensagens NEW_EPOCH válidas de pelo menos uma mensagem NEW_EPOCH excede um segundo limiar predeterminado; e em resposta a determinação de que o número de mensagens NEW_EPOCH válidas excede o segundo limiar predeterminado, determinar, pelo nó de cópia de segurança, o nó de cópia de segurança para ser o novo nó primário na nova época.
  16. 16. MEIO DE ARMAZENAMENTO NÃO TRANSITÓRIO legível por computador, de acordo com a reivindicação 15, caracterizado pela determinação de um peso respectivo do nó de cópia de segurança associado com cada uma das três fases do processo de consenso na época atual compreender determinar um peso do nó de cópia de segurança para uma primeira fase do processo de consenso como sendo um primeiro valor.
  17. 17. MEIO DE ARMAZENAMENTO NÃO TRANSITÓRIO legível
    Petição 870190097362, de 30/09/2019, pág. 106/134
    8/17 por computador, de acordo com a reivindicação 15, caracterizado pela determinação de um respectivo peso do nó de cópia de segurança associado com cada uma das três fases do processo de consenso na época atual compreender:
    em resposta à determinação de uma falha na verificação de quórum em uma segunda fase do processo de consenso na época atual, determinar um peso do nó de cópia de segurança para a segunda fase do processo de consenso como um primeiro valor; e em resposta a determinar o sucesso de uma verificação de quórum na segunda fase do processo de consenso na época atual, determinar o peso do nó de cópia de segurança para a segunda fase do processo de consenso como um segundo valor, em que o primeiro valor é menor do que o segundo valor.
  18. 18. MEIO DE ARMAZENAMENTO NÃO TRANSITÓRIO legível por computador, de acordo com a reivindicação 17, caracterizado pela verificação de quórum na segunda fase para o nó de rede compreender receber um número predeterminado de mensagens ECHO de outros nós de rede.
  19. 19. MEIO DE ARMAZENAMENTO NÃO TRANSITÓRIO legível por computador, de acordo com a reivindicação 15, caracterizado pela determinação de um respectivo peso do nó de cópia de segurança associado com cada uma das três fases do processo de consenso na época atual compreender:
    em resposta à determinação de uma falha na verificação de quórum em uma terceira fase do processo de consenso na época atual, determinar um peso do nó de cópia de segurança para a terceira fase do processo de consenso como um terceiro valor; e em resposta à determinação do sucesso de uma verificação de
    Petição 870190097362, de 30/09/2019, pág. 107/134
    9/17 quórum na terceira fase do processo de consenso na época atual, determinar o peso do nó de cópia de segurança para a terceira fase do processo de consenso como um quarto valor, em que o terceiro valor é menor do que o quarto valor.
  20. 20. MEIO DE ARMAZENAMENTO NÃO TRANSITÓRIO legível por computador, de acordo com a reivindicação 19, caracterizado pela verificação de quórum na terceira fase para o nó de rede compreender receber um número predeterminado de mensagens de aceitação de outros nós de rede, em que cada uma das mensagens de aceitação de outros nós de rede indica que cada um dos outros nós de rede aceitou um número predeterminado de mensagens ECHO.
  21. 21. MEIO DE ARMAZENAMENTO NÃO TRANSITÓRIO legível por computador, de acordo com a reivindicação 15, caracterizado pela mensagem EPOCH_CHANGE compreender ainda um conjunto de assinaturas associadas com um conjunto de nós de rede fora da pluralidade de nós de rede, e em que a mensagem NEW_EPOCH compreende um resumo da mensagem EPOCH_CHANGE.
  22. 22. MEIO DE ARMAZENAMENTO NÃO TRANSITÓRIO legível por computador, de acordo com a reivindicação 21, caracterizado por verificar se a pelo menos uma mensagem NEW_EPOCH válida é válida, compreender verificar se o resumo da mensagem EPOCH_CHANGE na pelo menos uma mensagem NEW_EPOCH é válido e em que verificar se o resumo da mensagem EPOCH_CHANGE na pelo menos uma mensagem NEW_EPOCH é válida e consiste em verificar se o conjunto de assinaturas na mensagem EPOCH_CHANGE é válido.
  23. 23. MEIO DE ARMAZENAMENTO NÃO TRANSITÓRIO legível por computador, de acordo com a reivindicação 15, caracterizado por determinar que uma alteração de época precisa ser realizada compreender
    Petição 870190097362, de 30/09/2019, pág. 108/134
    10/17 determinar que uma alteração de época precisa ser executada em resposta a determinação de que o consenso não foi alcançado na época antiga dentro um período de tempo predeterminado.
  24. 24. MEIO DE ARMAZENAMENTO NÃO TRANSITÓRIO legível por computador de acordo com a reivindicação 15, caracterizado por ainda ser configurado com instruções executáveis por um ou mais computadores para:
    operar na nova época com o novo nó primário, em que a nova época compreende um processo de consenso para obter consenso entre a pluralidade de nós de rede usando o novo nó primário.
  25. 25. SISTEMA, caracterizado por incluir:
    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:
    determinar, por um nó de cópia de segurança de uma rede de protocolo de confiança compreendendo uma pluralidade de nós de rede, que uma alteração época precisa de ser realizada, em que a pluralidade de nós de rede compreendem um nó primário e um ou mais nós de cópia de segurança, compreendendo o nó de cópia de segurança, em que a alteração de época causa uma alteração de uma época atual com um nó primário atual para uma nova época com um novo nó primário, em que a época atual compreende um processo de consenso para alcançar o consenso entre a pluralidade de nós de rede usando o nó primário, o processo de consenso compreendendo três fases;
    determinar, pelo nó de cópia de segurança, um peso respectivo do nó de cópia de segurança associado a cada uma das três fases do processo de consenso na época atual, em que o peso é uma métrica de uma qualificação do nó de cópia de segurança para ser o novo nó primário;
    Petição 870190097362, de 30/09/2019, pág. 109/134
    11/17 determinar, pelo nó de cópia de segurança, uma soma de peso para o nó de cópia de segurança com base no peso respectivo do nó de cópia de segurança associado a cada uma das três fases na época atual;
    em resposta à determinação de que a soma de peso atinge um primeiro limiar predeterminado, enviar, pelo nó de cópia de segurança, uma mensagem EPOCH_CHANGE para a pluralidade de nós de rede diferente do nó de rede, em que a mensagem EPOCH_CHANGE indica uma solicitação de alteração da época atual com o nó primário atual para a nova época, com o nó de cópia de segurança sendo o novo nó primário, e a mensagem EPOCH_CHANGE compreende a soma de peso do nó de cópia de segurança;
    receber, pelo nó de cópia de segurança, pelo menos uma mensagem NEW_EPOCH de pelo menos um da pluralidade de nós de rede diferentes do nó de cópia de segurança, em que a mensagem NEW_EPOCH indica uma confirmação de que o nó de cópia de segurança é o novo nó primário;
    verificar, pelo nó de cópia de segurança, se a pelo menos uma mensagem NEW_EPOCH é válida;
    determinar, pelo nó de cópia de segurança, se um número de mensagens NEW_EPOCH válidas de pelo menos uma mensagem NEW_EPOCH excede um segundo limiar predeterminado; e em resposta a determinação de que o número de mensagens NEW_EPOCH válidas excede o segundo limiar predeterminado, determinar, pelo nó de cópia de segurança, o nó de cópia de segurança para ser o novo nó primário na nova época.
  26. 26. SISTEMA, de acordo com a reivindicação 25, caracterizado pela determinação de um peso respectivo do nó de cópia de segurança associado com cada uma das três fases do processo de consenso na época atual compreender determinar um peso do nó de cópia de segurança
    Petição 870190097362, de 30/09/2019, pág. 110/134
    12/17 para uma primeira fase do processo de consenso ser um primeiro valor.
  27. 27. SISTEMA, de acordo com a reivindicação 25, caracterizado pela determinação de um respectivo peso do nó de cópia de segurança associada com cada uma das três fases do processo de consenso na época atual compreender:
    em resposta à determinação de uma falha na verificação de quórum em uma segunda fase do processo de consenso na época atual, determinar um peso do nó de cópia de segurança para a segunda fase do processo de consenso como um primeiro valor; e em resposta a determinar o sucesso de uma verificação de quórum na segunda fase do processo de consenso na época atual, determinar o peso do nó de cópia de segurança para a segunda fase do processo de consenso como um segundo valor, em que o primeiro valor é menor do que o segundo valor.
  28. 28. SISTEMA, de acordo com a reivindicação 27, caracterizado pela verificação de quórum na segunda fase para o nó de rede compreender receber um número predeterminado de mensagens ECHO de outros nós de rede.
  29. 29. SISTEMA, de acordo com a reivindicação 25, caracterizado pela determinação de um respectivo peso do nó de cópia de segurança associada com cada uma das três fases do processo de consenso na época atual compreender:
    em resposta à determinação de uma falha na verificação de quórum em uma terceira fase do processo de consenso na época atual, determinar um peso do nó de cópia de segurança para a terceira fase do processo de consenso como um terceiro valor; e em resposta à determinação do sucesso de uma verificação de quórum na terceira fase do processo de consenso na época atual, determinar o
    Petição 870190097362, de 30/09/2019, pág. 111/134
    13/17 peso do nó de cópia de segurança para a terceira fase do processo de consenso como sendo um quarto valor, em que o terceiro valor é menor do que o quarto valor.
  30. 30. SISTEMA, de acordo com a reivindicação 29, caracterizado pela verificação de quórum na terceira fase para o nó de rede compreender a recepção de um número pré-determinado de mensagens de aceitação de outros nós de rede, em que cada uma das mensagens de aceitação de outros nós de rede indica que cada um dos outros nós de rede aceitou um número predeterminado de mensagens ECHO.
  31. 31. SISTEMA, de acordo com a reivindicação 25, caracterizado pela mensagem EPOCH_CHANGE compreender ainda um conjunto de assinaturas associadas a um conjunto de nós de rede a partir da pluralidade de nós de rede, e em que a mensagem NEW_EPOCH compreende um resumo da mensagem EPOCH_CHANGE.
  32. 32. SISTEMA, de acordo com a reivindicação 31, caracterizado por verificar se a pelo menos uma mensagem válida NEW_EPOCH é válida, compreender verificar se o resumo da mensagem EPOCH_CHANGE na pelo menos uma mensagem NEW_EPOCH é válida, e em que verificar se o resumo da mensagem EPOCH_CHANGE na pelo menos uma mensagem NEW_EPOCH é válida e compreende verificar se o conjunto de assinaturas na mensagem EPOCH_CHANGE é válido.
  33. 33. SISTEMA, de acordo com a reivindicação 25, caracterizado pela determinação de que uma alteração de época precisa ser realizada compreender determinar que uma alteração de época precisa ser executada em resposta a determinação de que o consenso não foi alcançado na época antiga dentro de um período de tempo predeterminado.
  34. 34. SISTEMA, de acordo com a reivindicação 25, caracterizado pelas memórias de computador serem ainda configuradas com
    Petição 870190097362, de 30/09/2019, pág. 112/134
    14/17 instruções executáveis por um ou mais computadores para:
    operar na nova época com o novo nó primário, em que a nova época compreende um processo de consenso para obter o consenso entre a pluralidade de nós de rede usando o novo nó primário.
  35. 35. MEIO DE ARMAZENAMENTO NÃO TRANSITÓRIO legível por computador acoplado a um ou mais computadores e configurado com instruções executáveis por um ou mais computadores, caracterizado por ser para:
    receber, por um nó de rede de uma rede de protocolo de confiança compreendendo uma pluralidade de nós de rede, uma mensagem EPCOH_CHANGE de um nó de cópia de segurança do nó de rede de protocolo de confiança diferente do nó de rede, em que a pluralidade de nós de rede compreende um nó primário e um ou mais nós de cópia de segurança, em que a mensagem EPOCH_CHANGE compreende uma indicação de que uma alteração de época precisa ser executada, em que a alteração de época causa uma alteração de uma época atual com um nó primário atual para uma nova época com um novo nó primário;
    verificar, pelo nó de rede, se a mensagem EPOCH_CHANGE é válida;
    em resposta a verificar que a mensagem EPOCH_ CHANGE é válida, enviar, pelo nó de rede, uma mensagem NEW_EPOCH para os outros nós de rede, em que a mensagem NEW_EPOCH compreende um resumo da mensagem EPOCH_CHANGE;
    receber, pelo nó de rede, pelo menos uma mensagem NEW_EPOCH de pelo menos um dentre a pluralidade de nós de rede diferentes do nó de rede;
    verificar, pelo nó de rede, se a pelo menos uma mensagem NEW_EPOCH é válida;
    Petição 870190097362, de 30/09/2019, pág. 113/134
    15/17 determinar, pelo nó de cópia de segurança, se um número de mensagens NEW_EPOCH válidas de pelo menos uma mensagem NEW_EPOCH excede um limiar predeterminado; e em resposta a determinação de que o número de mensagens NEW_EPOCH válidas excede o limiar predeterminado, determinar, pelo nó de rede, o nó de cópia de segurança para ser o novo nó primário na nova época.
  36. 36. MEIO DE ARMAZENAMENTO NÃO TRANSITÓRIO legível por computador, de acordo com a reivindicação 35, caracterizado pela mensagem EPOCH_CHANGE compreender uma soma de peso associada ao nó de cópia de segurança e um conjunto de assinaturas associado a um conjunto de nós de rede da pluralidade de nós de rede.
  37. 37. MEIO DE ARMAZENAMENTO NÃO TRANSITÓRIO legível por computador, de acordo com a reivindicação 36, caracterizado pela verificação de se a mensagem EPOCH_CHANGE é válida compreender verificar se a soma de peso na mensagem EPOCH_CHANGE é válida, em que a verificação se a soma de peso na mensagem EPOCH_CHANGE é válida verificar se o conjunto de assinaturas é válido.
  38. 38. MEIO DE ARMAZENAMENTO NÃO TRANSITÓRIO legível por computador, de acordo com a reivindicação 36, caracterizado por verificar se a pelo menos uma mensagem NEW_EPOCH é válida, compreender verificar se o resumo da mensagem EPOCH_CHANGE na pelo menos uma mensagem NEW_EPOCH é válido e em que verificar se o resumo da mensagem EPOCH_CHANGE na pelo menos uma mensagem NEW_EPOCH é válida compreende verificar se o conjunto de assinaturas na mensagem EPOCH_CHANGE é válido.
  39. 39. SISTEMA, caracterizado por incluir:
    um ou mais computadores; e uma ou mais memórias legíveis por computador acopladas a um
    Petição 870190097362, de 30/09/2019, pág. 114/134
    16/17 ou mais computadores e configuradas com instruções executáveis por um ou mais computadores para:
    receber, por um nó de rede de uma rede de protocolo de confiança compreendendo uma pluralidade de nós de rede, uma mensagem EPCOH_CHANGE de um nó de cópia de segurança do nó de rede de protocolo de confiança diferente do nó de rede, em que a pluralidade de nós de rede compreende um nó primário e um ou mais nós de cópia de segurança, em que a mensagem EPOCH_CHANGE compreende uma indicação de que uma alteração de época precisa ser executada, em que a alteração de época causa uma alteração de uma época atual com um nó primário atual para uma nova época com um novo nó primário;
    verificar, pelo nó de rede, se a mensagem EPOCH_CHANGE é válida;
    em resposta a verificar que a mensagem EPOCH_ CHANGE é válida, enviar, pelo nó de rede, uma mensagem NEW_EPOCH para os outros nós de rede, em que a mensagem NEW_EPOCH compreende um resumo da mensagem EPOCH_CHANGE;
    receber, pelo nó de rede, pelo menos uma mensagem NEW_EPOCH de pelo menos um dentre a pluralidade de nós de rede diferente do nó de rede;
    verificar, pelo nó de rede, se a pelo menos uma mensagem NEW_EPOCH é válida;
    determinar, pelo nó de cópia de segurança, se um número de mensagens NEW_EPOCH válidas de pelo menos uma mensagem NEW_EPOCH excede um limiar predeterminado; e em resposta a determinação de que o número de mensagens NEW_EPOCH válidas excede o limiar predeterminado, determinar, pelo nó de rede, o nó de cópia de segurança para ser o novo nó primário na nova época.
    Petição 870190097362, de 30/09/2019, pág. 115/134
    17/17
  40. 40. SISTEMA, de acordo com a reivindicação 39, caracterizado pela mensagem EPOCH_CHANGE compreender uma soma de peso associada ao nó de cópia de segurança e um conjunto de assinaturas associadas a um conjunto de nós de rede da pluralidade de nós de rede.
  41. 41. SISTEMA, de acordo com a reivindicação 40, caracterizado pela verificação se a mensagem EPOCH_CHANGE é válida compreende verificar se a soma de peso na mensagem EPOCH_CHANGE é válida, em que verificar se a soma de peso na mensagem EPOCH_CHANGE é válida compreende verificar se o conjunto de assinaturas são válidos.
  42. 42. SISTEMA, de acordo com a reivindicação 40, caracterizado pela verificação se a pelo menos uma mensagem NEW_EPOCH é válida, compreender verificar se o resumo da mensagem EPOCH_CHANGE na pelo menos uma mensagem NEW_EPOCH é válido, e em que verificar se o resumo da mensagem EPOCH_CHANGE em pelo menos uma mensagem NEW_EPOCH é válida e compreende verificar se o conjunto de assinaturas na mensagem EPOCH_CHANGE é válido.
BR112019016598-3A 2018-12-13 2018-12-13 Métodos implementado por computador, meios de armazenamento não transitório e sistemas BR112019016598A2 (pt)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2018/120873 WO2019072296A2 (en) 2018-12-13 2018-12-13 REALIZING A CHANGE OF A PRIMARY NODE IN A DISTRIBUTED SYSTEM

Publications (1)

Publication Number Publication Date
BR112019016598A2 true BR112019016598A2 (pt) 2020-03-31

Family

ID=66100008

Family Applications (1)

Application Number Title Priority Date Filing Date
BR112019016598-3A BR112019016598A2 (pt) 2018-12-13 2018-12-13 Métodos implementado por computador, meios de armazenamento não transitório e sistemas

Country Status (16)

Country Link
US (2) US10630672B2 (pt)
EP (1) EP3566397B1 (pt)
JP (1) JP6726367B2 (pt)
KR (1) KR102134549B1 (pt)
CN (1) CN111543026B (pt)
AU (1) AU2018348336B2 (pt)
BR (1) BR112019016598A2 (pt)
CA (1) CA3053208C (pt)
MX (1) MX2019009548A (pt)
MY (1) MY189985A (pt)
PH (1) PH12019501871A1 (pt)
RU (1) RU2716558C1 (pt)
SG (1) SG11201907346UA (pt)
TW (1) TWI705690B (pt)
WO (1) WO2019072296A2 (pt)
ZA (1) ZA201905274B (pt)

Families Citing this family (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10599835B2 (en) 2018-02-06 2020-03-24 Vmware, Inc. 32-bit address space containment to secure processes from speculative rogue cache loads
US10713133B2 (en) 2018-06-11 2020-07-14 Vmware, Inc. Linear view-change BFT
US10747629B2 (en) * 2018-06-11 2020-08-18 Vmware, Inc. Linear view-change BFT with optimistic responsiveness
SG11201907346UA (en) * 2018-12-13 2019-09-27 Alibaba Group Holding Ltd Performing a change of primary node in a distributed system
CN110169015B (zh) 2018-12-13 2022-03-01 创新先进技术有限公司 在分布式系统中的网络节点之间达成共识
PL3560142T3 (pl) 2018-12-13 2021-01-11 Alibaba Group Holding Limited Przeprowadzanie procesu przywracania węzła sieciowego w systemie rozproszonym
US11048596B2 (en) * 2018-12-14 2021-06-29 Nokia Technologies Oy Hierarchical weighted consensus for permissioned blockchains
US20210185091A1 (en) * 2018-12-28 2021-06-17 Mox-SpeedChain, LLC Advanced Security System for Implementation in an Internet of Things (IOT) Blockchain Network
AU2019203865B2 (en) 2019-03-18 2021-01-21 Advanced New Technologies Co., Ltd. Consensus system downtime recovery
ES2862428T3 (es) 2019-03-18 2021-10-07 Advanced New Technologies Co Ltd Recuperación de tiempo de inactividad de sistema de consenso
US10938750B2 (en) 2019-03-18 2021-03-02 Advanced New Technologies Co., Ltd. Consensus system downtime recovery
CN110049051B (zh) * 2019-04-22 2020-08-11 成都四方伟业软件股份有限公司 请求的验证方法、装置、存储介质及联盟链验证系统
EP3701701A4 (en) 2019-06-05 2020-12-30 Alibaba Group Holding Limited CONSENSUS SYSTEM AND PROCESS
US10896171B2 (en) * 2019-06-13 2021-01-19 Tyson York Winarski Big data blockchains with Merkle trees
SG11202010724PA (en) * 2019-11-06 2020-11-27 Alipay Hangzhou Inf Tech Co Ltd Consenus of shared blockchain data storage based on error correction code
JP7004423B2 (ja) * 2019-11-06 2022-01-21 アリペイ （ハンジョウ） インフォメーション テクノロジー カンパニー リミテッド 誤り訂正符号に基づく共有されたブロックチェーンデータの記憶のデータセキュリティ
US11914488B2 (en) 2019-11-06 2024-02-27 Visa International Service Association Blockchain enabled fault tolerance
WO2020035092A2 (en) 2019-11-13 2020-02-20 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain data storage based on error correction code for permissioned blockchain network
CN111369266A (zh) * 2020-03-03 2020-07-03 珠海市一堂科技有限公司 一种基于区块链的工艺作品的溯源方法
CN111507840B (zh) * 2020-04-15 2024-03-26 财付通支付科技有限公司 区块链共识方法、装置、计算机以及可读存储介质
CN111539726B (zh) * 2020-04-20 2024-03-19 中国工商银行股份有限公司 区块链共识系统及方法
US11431476B2 (en) * 2020-04-30 2022-08-30 Dell Products L.P. Install time creation of forward error correction data and integrity checksums
CN111711526B (zh) * 2020-06-16 2024-03-26 深圳前海微众银行股份有限公司 一种区块链节点的共识方法及系统
WO2022000482A1 (en) * 2020-07-03 2022-01-06 Alipay (Hangzhou) Information Technology Co., Ltd. System and method for providing privacy and security protection in blockchain-based private transactions
CN111522800B (zh) 2020-07-03 2020-10-30 支付宝(杭州)信息技术有限公司 蜜獾拜占庭容错共识机制的区块链共识方法、节点及系统
CN111526219B (zh) * 2020-07-03 2021-02-09 支付宝(杭州)信息技术有限公司 一种联盟链的共识方法及联盟链系统
CN111526216B (zh) * 2020-07-03 2020-09-22 支付宝(杭州)信息技术有限公司 联盟链中的共识方法和系统
CN111526217B (zh) 2020-07-03 2020-10-09 支付宝(杭州)信息技术有限公司 一种区块链中的共识方法和系统
KR102577432B1 (ko) * 2020-07-27 2023-09-12 한국전자통신연구원 블록체인 네트워크의 블록 합의 방법 및 장치
CN112068978B (zh) * 2020-08-27 2022-06-10 恒宝股份有限公司 View-change二次启动定时器的定时期限延长方法及装置
CN112511337B (zh) * 2020-11-09 2023-03-14 迅鳐成都科技有限公司 区块链共识网络自恢复方法、电子设备、系统及存储介质
CN112511338A (zh) * 2020-11-09 2021-03-16 迅鳐成都科技有限公司 区块链共识网络动态恢复方法、电子设备、系统及介质
CN112398692B (zh) * 2020-11-16 2022-07-19 网易（杭州）网络有限公司 共识流程处理方法、装置和电子设备
US11593210B2 (en) * 2020-12-29 2023-02-28 Hewlett Packard Enterprise Development Lp Leader election in a distributed system based on node weight and leadership priority based on network performance
US20240089089A1 (en) * 2020-12-31 2024-03-14 Oded Noam Using decentralized networks to ensure transparency in remote device operation
CN113079139B (zh) * 2021-03-23 2022-11-29 中国工商银行股份有限公司 基于区块链的共识组主节点确定方法、装置及系统
CN113297173B (zh) * 2021-05-24 2023-10-31 阿里巴巴新加坡控股有限公司 分布式数据库集群管理方法及装置、电子设备
CN113535942B (zh) * 2021-07-21 2022-08-19 北京海泰方圆科技股份有限公司 一种文本摘要生成方法、装置、设备及介质
CN114531722B (zh) * 2022-03-01 2024-05-03 杭州老板电器股份有限公司 本地网络中设备的联网方法、装置和电子设备
CN114760135B (zh) * 2022-04-19 2023-03-28 浙江大学 一种区块链容错共识方案的优化方法
CN115131022B (zh) * 2022-08-26 2022-11-29 中国工业互联网研究院 基于区块链的数字资产交易方法、装置、设备及介质

Family Cites Families (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4309569A (en) 1979-09-05 1982-01-05 The Board Of Trustees Of The Leland Stanford Junior University Method of providing digital signatures
US4569015A (en) 1983-02-09 1986-02-04 International Business Machines Corporation Method for achieving multiple processor agreement optimized for no faults
US7249259B1 (en) 1999-09-07 2007-07-24 Certicom Corp. Hybrid signature scheme
US6671821B1 (en) * 1999-11-22 2003-12-30 Massachusetts Institute Of Technology Byzantine fault tolerance
US6985956B2 (en) 2000-11-02 2006-01-10 Sun Microsystems, Inc. Switching system
US6931431B2 (en) 2001-01-13 2005-08-16 International Business Machines Corporation Agreement and atomic broadcast in asynchronous networks
US7502360B2 (en) * 2005-03-04 2009-03-10 Itt Manufacturing Enterprises, Inc. Method and apparatus for dynamic neighbor discovery within wireless networks using time division multiple access (TDMA)
US8819102B2 (en) 2007-07-03 2014-08-26 Cisco Technology, Inc. Method and system for managing message communications
US20100162036A1 (en) * 2008-12-19 2010-06-24 Watchguard Technologies, Inc. Self-Monitoring Cluster of Network Security Devices
JP5427574B2 (ja) 2009-12-02 2014-02-26 株式会社日立製作所 仮想計算機の移動管理方法、前記移動管理方法を用いた計算機、前記移動管理方法を用いた仮想化機構および前記移動管理方法を用いた計算機システム
KR101615691B1 (ko) * 2011-10-25 2016-05-11 니시라, 인크. 범용 흐름을 변환하는 섀시 제어기
US9471622B2 (en) 2012-04-30 2016-10-18 International Business Machines Corporation SCM-conscious transactional key-value store
JP2014178793A (ja) * 2013-03-14 2014-09-25 Hitachi Ltd 情報処理システム
CN104468163B (zh) * 2013-09-18 2018-11-09 腾讯科技（北京）有限公司 容灾网络组网的方法、装置及容灾网络
JP2015146165A (ja) * 2014-02-04 2015-08-13 日本電信電話株式会社 障害耐性信号処理装置および障害耐性信号処理方法
ES2705708T3 (es) * 2014-07-01 2019-03-26 Sas Inst Inc Sistemas y procedimientos para comunicaciones tolerantes a fallos
WO2016155002A1 (en) 2015-04-03 2016-10-06 Yahoo! Inc. Method and system for data recovery in a data system
WO2017036546A1 (en) 2015-09-04 2017-03-09 Nec Europe Ltd. Method for storing an object on a plurality of storage nodes
WO2017136527A1 (en) * 2016-02-05 2017-08-10 Manifold Technology, Inc. Blockchain-enhanced database
US10204341B2 (en) * 2016-05-24 2019-02-12 Mastercard International Incorporated Method and system for an efficient consensus mechanism for permissioned blockchains using bloom filters and audit guarantees
WO2017186317A1 (en) 2016-10-04 2017-11-02 Nec Europe Ltd. Method and system for byzantine fault-tolerance replicating of data on a plurality of servers
US10360191B2 (en) 2016-10-07 2019-07-23 International Business Machines Corporation Establishing overlay trust consensus for blockchain trust validation system
US10158527B2 (en) * 2016-10-28 2018-12-18 International Business Machines Corporation Changing an existing blockchain trust configuration
US10554746B2 (en) 2016-11-14 2020-02-04 International Business Machines Corporation Decentralized immutable storage blockchain configuration
US10311230B2 (en) 2016-12-24 2019-06-04 Cisco Technology, Inc. Anomaly detection in distributed ledger systems
CN106529951A (zh) 2016-12-30 2017-03-22 杭州云象网络技术有限公司 一种联盟链网络下采用异步方式的节点共识验证方法
CN107391320B (zh) * 2017-03-10 2020-07-10 创新先进技术有限公司 一种共识方法及装置
CN107360206B (zh) * 2017-03-29 2020-03-27 创新先进技术有限公司 一种区块链共识方法、设备及系统
US20180308091A1 (en) 2017-04-21 2018-10-25 Vmware, Inc. Fairness preserving byzantine agreements
CN107423152B (zh) 2017-04-24 2019-05-21 杭州趣链科技有限公司 一种区块链共识节点自动恢复方法
US11626993B2 (en) 2017-05-22 2023-04-11 Visa International Service Association Network for improved verification speed with tamper resistant data
CN107528882B (zh) * 2017-07-14 2020-12-25 创新先进技术有限公司 区块链共识网络中处理共识请求的方法、装置和电子设备
WO2019055507A1 (en) 2017-09-15 2019-03-21 Identify3D, Inc. SYSTEM AND METHOD FOR MANAGING AND SECURING DATA FOR DIGITAL MANUFACTURING
US11165862B2 (en) * 2017-10-24 2021-11-02 0Chain, LLC Systems and methods of blockchain platform for distributed applications
CN108306760A (zh) * 2017-12-28 2018-07-20 中国银联股份有限公司 用于在分布式系统中使管理能力自恢复的方法和装置
CN108365993B (zh) * 2018-03-09 2020-04-28 深圳前海微众银行股份有限公司 区块链节点动态变更方法、系统和计算机可读存储介质
CN108616596B (zh) * 2018-05-09 2020-12-25 南京邮电大学 基于动态授权和网络环境感知的区块链自适应共识方法
CN108768749B (zh) 2018-06-21 2021-03-30 佛山科学技术学院 一种基于区块链的节点隔离自恢复方法及装置
SG11201907346UA (en) * 2018-12-13 2019-09-27 Alibaba Group Holding Ltd Performing a change of primary node in a distributed system
CN110169015B (zh) 2018-12-13 2022-03-01 创新先进技术有限公司 在分布式系统中的网络节点之间达成共识
PL3560142T3 (pl) 2018-12-13 2021-01-11 Alibaba Group Holding Limited Przeprowadzanie procesu przywracania węzła sieciowego w systemie rozproszonym

Also Published As

Publication number Publication date
PH12019501871A1 (en) 2020-06-01
ZA201905274B (en) 2021-10-27
US20200195625A1 (en) 2020-06-18
TWI705690B (zh) 2020-09-21
MX2019009548A (es) 2019-09-26
EP3566397A4 (en) 2020-03-04
AU2018348336A1 (en) 2020-07-02
JP6726367B2 (ja) 2020-07-22
US10791107B2 (en) 2020-09-29
RU2716558C1 (ru) 2020-03-12
SG11201907346UA (en) 2019-09-27
JP2020513170A (ja) 2020-04-30
KR102134549B1 (ko) 2020-07-27
CN111543026B (zh) 2023-08-04
TW202023232A (zh) 2020-06-16
KR20200074912A (ko) 2020-06-25
US10630672B2 (en) 2020-04-21
EP3566397A2 (en) 2019-11-13
CN111543026A (zh) 2020-08-14
WO2019072296A3 (en) 2019-08-29
WO2019072296A2 (en) 2019-04-18
EP3566397B1 (en) 2021-07-28
AU2018348336B2 (en) 2020-07-23
MY189985A (en) 2022-03-22
CA3053208C (en) 2020-10-06
US20190288993A1 (en) 2019-09-19
CA3053208A1 (en) 2019-04-18

Similar Documents

Publication Publication Date Title
BR112019016598A2 (pt) Métodos implementado por computador, meios de armazenamento não transitório e sistemas
ES2818597T3 (es) Realizar un proceso de recuperación para un nodo de red en un sistema distribuido
RU2723072C1 (ru) Достижение консенуса между сетевывыми узлами в распределенной системе
TWI729880B (zh) 可信賴執行環境中基於錯誤校正編碼的共享區塊鏈資料儲存
TW202111586A (zh) 可信賴執行環境中基於錯誤校正編碼的共享區塊鏈資料儲存
TWI759791B (zh) 基於錯誤校正碼的共享區塊鏈資料儲存的方法、系統及裝置

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)

B350 Update of information on the portal [chapter 15.35 patent gazette]
B09A Decision: intention to grant [chapter 9.1 patent gazette]
B11D Dismissal acc. art. 38, par 2 of ipl - failure to pay fee after grant in time