ES2867423T3 - Facilitar el consenso práctico de cadena de bloques de tolerancia a fallas bizantinas y la sincronización de nodos - Google Patents

Facilitar el consenso práctico de cadena de bloques de tolerancia a fallas bizantinas y la sincronización de nodos Download PDF

Info

Publication number
ES2867423T3
ES2867423T3 ES18865827T ES18865827T ES2867423T3 ES 2867423 T3 ES2867423 T3 ES 2867423T3 ES 18865827 T ES18865827 T ES 18865827T ES 18865827 T ES18865827 T ES 18865827T ES 2867423 T3 ES2867423 T3 ES 2867423T3
Authority
ES
Spain
Prior art keywords
consensus
messages
node
consensus node
computer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES18865827T
Other languages
English (en)
Inventor
Dayi Yang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Advanced New Technologies Co Ltd
Original Assignee
Advanced New Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Advanced New Technologies Co Ltd filed Critical Advanced New Technologies Co Ltd
Application granted granted Critical
Publication of ES2867423T3 publication Critical patent/ES2867423T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2365—Ensuring data consistency and integrity
    • 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/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • 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/18—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits
    • G06F11/183—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits by voting, the voting not being performed by the redundant components
    • 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/18—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits
    • G06F11/187—Voting techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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/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/3297—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 time stamps, e.g. generation of time stamps
    • 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/18—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits
    • G06F11/182—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits based on mutual exchange of the output between redundant processing components
    • 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/82—Solving problems relating to consistency
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Databases & Information Systems (AREA)
  • Computer Hardware Design (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Retry When Errors Occur (AREA)
  • Computer And Data Communications (AREA)
  • Hardware Redundancy (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Debugging And Monitoring (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un método (500) implementado por computadora para facilitar un proceso de consenso en una red (102) de cadena de bloques basado en la tolerancia a fallas bizantinas práctica (PBFT), que comprende: establecer, mediante un primer nodo (310) de consenso, un temporizador de vista para iniciar, tras el tiempo de espera del temporizador de vista, un cambio de vista de una vista actual; establecer (502), mediante el primer nodo de consenso, un temporizador de recuperación que se agota antes del temporizador de vista; determinar, mediante el primer nodo de consenso y en respuesta a que se agote el temporizador de recuperación, si al primer nodo de consenso le faltan uno o más mensajes de consenso; y si el primer nodo de consenso determina que faltan uno o más mensajes de consenso: enviar (504), mediante el primer nodo de consenso y solo a un segundo nodo (308) de consenso, una solicitud para el uno o más mensajes de consenso que faltan en el primer nodo de consenso; recibir (506), mediante el primer nodo de consenso desde el segundo nodo de consenso, el uno o más mensajes de consenso cada uno firmado digitalmente por una clave privada de un nodo de consenso correspondiente que genera el uno o más mensajes de consenso respectivos; y determinar (508), mediante el primer nodo de consenso, que un bloque de transacciones es válido, si una cantidad de mensajes de confirmación incluidos en el uno o más mensajes de consenso recibidos es mayor o igual que 2f + 1, donde f es un número máximo de nodos defectuosos que es tolerable por la cadena de bloques basada en PBFT.

Description

DESCRIPCIÓN
Facilitar el consenso práctico de cadena de bloques de tolerancia a fallas bizantinas y la sincronización de nodos
ANTECEDENTES
Las redes de cadena de bloques, que también pueden denominarse sistemas de cadena de bloques, redes de consenso, redes de sistemas de contabilidad distribuida (DLS) o cadena de bloques, permiten a las entidades participantes almacenar datos de forma segura e inmutable. Una cadena de bloques se puede describir como un libro mayor de transacciones y se almacenan múltiples copias de la cadena de bloques en la red de cadenas de bloques. Los tipos de ejemplo de cadenas de bloques pueden incluir cadenas de bloques públicas, cadenas de bloques de consorcio y cadenas de bloques privadas. Una cadena de bloques pública está abierta para que todas las entidades la utilicen y participen en el proceso de consenso. Se proporciona un DLS privado para una entidad particular, que controla de forma centralizada los permisos de lectura y escritura.
Otro tipo de sistema de cadena de bloques incluye un sistema de cadena de bloques de consorcio. Se proporciona un sistema de cadena de bloques de consorcio para un grupo selecto de entidades, que controlan el proceso de consenso e incluye una capa de control de acceso. En consecuencia, una o más entidades que participan en el sistema de cadena de bloques de consorcio tienen control sobre quién puede acceder al sistema de cadena de bloques de consorcio y quién puede participar en el proceso de consenso del sistema de cadena de bloques de consorcio. Por ejemplo, un grupo de empresas (p. ej., empresas, instituciones académicas) puede participar en un sistema de cadena de bloques de consorcio para registrar datos de forma inmutable (p. ej., transacciones). En algunos ejemplos, una entidad puede acceder/ver datos dentro del sistema de cadena de bloques de consorcio, pero no contribuir con datos al sistema de cadena de bloques de consorcio.
Una cadena de bloques incluye una serie de bloques, cada uno de los cuales contiene una o más transacciones ejecutadas en la red. Cada uno de los bloques puede ser análogo a una página del libro mayor, mientras que la cadena de bloques en sí es una copia completa del libro mayor. Las transacciones individuales se confirman y se agregan a un bloque, que se agrega a la cadena de bloques. Las copias de la cadena de bloques se replican en los nodos de la red. De esta manera, existe un consenso en toda la red sobre el estado de la cadena de bloques.
La tolerancia a fallas es una preocupación en los sistemas red de cadena de bloques. La tolerancia a fallas generalmente se puede describir como la tolerancia de una red a los nodos que fallan o actúan de manera maliciosa. La tolerancia a fallas es de particular interés en los sistemas de cadena de bloques que tienen menos nodos participantes, tales como los sistemas de cadena de bloques de consorcio. La tolerancia a fallas bizantinas (BFT) se puede describir como la confiabilidad de un sistema informático distribuido tolerante a fallas, tal como un sistema de cadena de bloques. BFT describe la confiabilidad, en los casos en que los componentes pueden fallar y/o ser maliciosos, y hay información imperfecta sobre si un componente ha fallado o es malicioso. BFT se aprovecha de protocolos de consenso para permitir que los sistemas logren el consenso a pesar de que los nodos maliciosos del sistema propagan información incorrecta a otros pares. El objetivo de BFT es defenderse de las fallas del sistema mitigando la influencia que tienen los nodos maliciosos en el correcto funcionamiento del protocolo de consenso. BFT práctico (PBFT) es una optimización de BFT. PBFT funciona en sistemas asíncronos, tales como un sistema de cadena de bloques de consorcio, y asume que hay fallas de nodos independientes y mensajes manipulados propagados por nodos independientes específicos. En PBFT, todos los nodos en un sistema de consenso se ordenan en una secuencia con un nodo siendo un nodo principal (se designan diferentes nodos como el nodo principal a lo largo del tiempo) y los otros nodos son nodos de respaldo. Todos los nodos se comunican entre sí a través de mensajes de difusión y los llamados nodos honestos llegan a un consenso por mayoría.
En PBFT, la seguridad de consenso puede garantizar que dos nodos que no tienen problema alguno asociado con ellos no lleguen a un consenso con valores diferentes. La vigencia de consenso puede garantizar que los nodos no caigan en bucles infinitos mientras intercambian mensajes y que los nodos puedan llegar a su estado final.
En algunos casos, los nodos de consenso en una cadena de bloques de consorcio pueden estar muy alejados geográficamente y no se puede garantizar la calidad o conectividad de la red. En tales casos, los mensajes de difusión pueden no llegar a todos los nodos de consenso, lo que afecta la capacidad de los nodos de consenso para llegar al consenso PBFT. Como resultado, recopilar suficientes respuestas para llegar a un consenso puede llevar mucho tiempo y ser una carga computacional.
Castro, Liskov: "Proactive Recovery in a Byzantine-Fault-Tolerant System", USENIX, The Advanced Computing Systems Association, 8 de marzo de 2001) describe un sistema de replicación de máquina de estados asíncrona que tolera fallas bizantinas, que pueden ser provocadas por ataques maliciosos o errores de software. El sistema recupera réplicas defectuosas bizantinas de forma proactiva y utiliza criptografía simétrica en lugar de clave pública para la autenticación. El mecanismo de recuperación descrito permite la tolerancia de cualquier número de fallas durante la vida útil del sistema, siempre que menos de 1/3 de las réplicas se vuelvan defectuosas dentro de una pequeña ventana de vulnerabilidad, en condiciones normales. La ventana puede aumentar con un ataque de denegación de servicio, pero dichos ataques pueden detectarse y responderse. Se presentan los resultados de los experimentos que muestran el rendimiento general y que incluso una pequeña ventana de vulnerabilidad tiene poco impacto en la latencia del servicio.
Eleftherios Kokoris Kogias et al.: "Middleware 2013", incluido en las Actas del 25° Simposio de Seguridad de USENIX del 10 al 12 de agosto, 1 de enero de 2013) describe ByzCoin, un protocolo de consenso bizantino que aprovecha la firma colectiva escalable para comprometer transacciones de Bitcoin de forma irreversible en segundos. ByzCoin logra el consenso bizantino al tiempo que conserva la membresía abierta de Bitcoin al formar dinámicamente grupos de consenso de potencia proporcionales de resumen que representan a los mineros de bloques recientemente exitosos. Atul Singh et al.: "Zeno: Eventually Consistent ByzantineFault Tolerance", Usenix, The Advanced Computing Systems Association, 2 de abril de 2009) describe un protocolo de replicación de máquina de estados BFT llamado Zeno que intercambia consistencia por mayor disponibilidad. En particular, Zeno reemplaza la consistencia fuerte (linealización) con una garantía más débil (consistencia eventual): los clientes pueden perder temporalmente las actualizaciones de los demás, pero cuando la red es estable, los estados de las particiones individuales se fusionan haciendo que las réplicas acuerden un pedido total para todas las solicitudes.
Ethan Buchman et al.: "The latest gossip on BFT consenso", Arxiv.Org, Cornell University Library, 201 Olin Library Cornell University Ithaca, NY 14853, 13 de julio de 2018) describe Tendermint, un protocolo para ordenar eventos en una red distribuida bajo condiciones adversas. Más comúnmente conocido como consenso bizantino tolerante a fallas (BFT) o difusión atómica, el problema ha atraído una atención significativa en los últimos años debido al éxito generalizado de las divisas digitales basadas en red de cadena de bloques, tales como Bitcoin y Ethereum, que resolvieron con éxito el problema en un entorno público sin una autoridad central. Tendermint moderniza el trabajo académico clásico sobre el tema y simplifica el diseño del algoritmo BFT confiando en un protocolo de chismes de igual a igual entre los nodos.
RESUMEN
Las implementaciones de la presente divulgación están dirigidas a facilitar los procesos de sincronización y consenso de una red de cadena de bloques basada en la tolerancia a fallas bizantinas (PBFT) práctica. Más particularmente, las implementaciones de la presente divulgación están dirigidas a facilitar las transmisiones de mensajes de consenso y la sincronización de nodos en una red de cadena de bloques basada en PBFT utilizando un método de comunicaciones basado en chismes y añadiendo firmas digitales a los mensajes de consenso.
En algunas implementaciones, las acciones incluyen configurar, por un primer nodo de consenso, un temporizador que se agota antes de que se agote el tiempo de espera de un cambio de vista; enviar, a un segundo nodo de consenso, una solicitud de uno o más mensajes de consenso que faltan para el primer nodo de consenso en respuesta a que el temporizador se agota; recibir, desde el segundo nodo de consenso, el uno o más mensajes de consenso cada uno firmado digitalmente por una clave privada de un nodo de consenso correspondiente que genera el respectivo uno o más mensajes de consenso; y determinar que un bloque de transacciones es válido, si una cantidad de mensajes de confirmación incluidos en el uno o más mensajes de consenso recibidos es mayor o igual a 2 f 1, donde f es un número máximo de nodos defectuosos que es tolerable por el red de cadena de bloques basado en la tolerancia a fallas bizantinas práctica. Otras implementaciones incluyen sistemas, aparatos y programas informáticos correspondientes, configurados para realizar las acciones de los métodos, codificados en dispositivos de almacenamiento informáticos.
Cada una de estas y otras implementaciones puede incluir opcionalmente una o más de las siguientes características: la solicitud incluye un número de secuencia que indica un número de una ronda de consenso; el uno o más mensajes de consenso incluyen uno o más mensajes de preparación previa, mensajes de preparación y mensajes de confirmación de que faltan en el primer nodo de consenso; el uno o más mensajes de consenso se almacenan en uno o más nodos de consenso en los que se generan o almacenan, hasta que se alcanza un punto de control estable; recibir uno o más números de secuencia correspondientes a uno o más mensajes de consenso, en donde cada uno de los números de secuencia indica un número de una ronda de consenso asociada con un mensaje de consenso correspondiente; enviar el bloque de transacciones a una cadena de bloques y una base de datos de estados, si se determina que el bloque de transacciones es válido; enviar, a un tercer nodo de consenso, una solicitud de un uno o más segundos mensajes de consenso que faltan en el segundo nodo de consenso en respuesta a que el temporizador se está agotando y si se determina que el bloque de transacciones no es válido; recibir, desde el tercer nodo de consenso, el uno o más segundos mensajes de consenso, cada uno de los cuales está firmado digitalmente por una clave privada de un nodo de consenso correspondiente que genera el uno o más segundos mensajes de consenso respectivos; y determinar que el bloque de transacciones es válido, si una cantidad de los mensajes de confirmación incluidos en el uno o más mensajes de consenso y el uno o más segundos mensajes de consenso es mayor o igual que 2f 1.
La presente divulgación también proporciona uno o más medios de almacenamiento legibles por computadora no transitorios acoplados a uno o más procesadores y que tienen instrucciones almacenadas en los mismos que, cuando se ejecutan por el uno o más procesadores, hacen que el uno o más procesadores realicen operaciones de acuerdo con implementaciones de los métodos proporcionados en el presente documento.
La presente divulgación proporciona además un sistema para implementar los métodos proporcionados en el presente documento. El sistema incluye uno o más procesadores, y un medio de almacenamiento legible por computadora acoplado al uno o más procesadores que tienen instrucciones almacenadas en los mismos que, cuando se ejecutan por el uno o más procesadores, hacen que el uno o más procesadores realicen operaciones de acuerdo con las implementaciones de los métodos proporcionados en el presente documento.
Se aprecia que los métodos de acuerdo con la presente divulgación pueden incluir cualquier combinación de los aspectos y características descritos en el presente documento. Es decir, los métodos de acuerdo con la presente divulgación no se limitan a las combinaciones de aspectos y características descritos específicamente en el presente documento, sino que también incluyen cualquier combinación de los aspectos y características proporcionados.
Los detalles de una o más implementaciones de la presente divulgación se establecen en los dibujos adjuntos y la descripción a continuación. Otras características y ventajas de la presente divulgación resultarán evidentes a partir de la descripción y los dibujos, y de las reivindicaciones.
DESCRIPCIÓN DE LOS DIBUJOS
La FIG. 1 representa un entorno de ejemplo que puede utilizarse para ejecutar implementaciones de la presente divulgación.
La FIG. 2 representa una arquitectura conceptual de ejemplo de acuerdo con implementaciones de la presente divulgación.
La FIG. 3 representa un proceso de consenso de ejemplo basado en PBFT de acuerdo con implementaciones de la presente divulgación.
La FIG. 4 representa una estructura de ejemplo de un mensaje de consenso basado en PBFT de acuerdo con implementaciones de la presente divulgación.
La FIG. 5 representa un proceso de ejemplo que se puede ejecutar de acuerdo con implementaciones de la presente divulgación.
Los símbolos de referencia iguales en los diversos dibujos indican elementos iguales.
DESCRIPCIÓN DETALLADA
Las implementaciones de la presente divulgación están dirigidas a facilitar los procesos de sincronización y consenso de una red de cadena de bloques basada en la tolerancia a fallas bizantinas (PBFT) práctica. Más particularmente, las implementaciones de la presente divulgación están dirigidas a facilitar las transmisiones de mensajes de consenso y la sincronización de nodos en una red de cadena de bloques basada en PBFT utilizando un método de comunicaciones basado en chismes y añadiendo firmas digitales a los mensajes de consenso. De esta manera, y como se describe con más detalle en el presente documento, se puede reducir el consumo de ancho de banda de comunicaciones y se puede mejorar la confiabilidad del sistema. En algunas implementaciones, las acciones incluyen configurar, por un primer nodo de consenso, un temporizador que se agota antes de que se agote el tiempo de espera de un cambio de vista; enviar, a un segundo nodo de consenso, una solicitud de uno o más mensajes de consenso que faltan para el primer nodo de consenso en respuesta a que el temporizador se agota; recibir, desde el segundo nodo de consenso, el uno o más mensajes de consenso cada uno firmado digitalmente por una clave privada de un nodo de consenso correspondiente que genera el respectivo uno o más mensajes de consenso; y determinar que un bloque de transacciones es válido, si una cantidad de mensajes de compromiso incluidos en el uno o más mensajes de consenso recibidos es mayor o igual a 2f 1, donde f es un número máximo de nodos defectuosos que es tolerable por el red de cadena de bloques basado en la tolerancia a fallas bizantinas práctica.
Para proporcionar un contexto adicional para las implementaciones de la presente divulgación, y como se introdujo anteriormente, redes de cadena de bloques, que también pueden denominarse redes de consenso (p. ej., compuestas por nodos de igual a igual), sistemas de contabilidad distribuida o simplemente cadena de bloques, permitir que las entidades participantes realicen transacciones y almacenen datos de forma segura e inmutable. Una cadena de bloques se puede proporcionar como una cadena de bloques pública, una cadena de bloques privada o una cadena de bloques de consorcio. Las implementaciones de la presente divulgación se describen con más detalle en el presente documento con referencia a una cadena de bloques de consorcio, en la que el proceso de consenso está controlado por un conjunto de nodos preseleccionados. Sin embargo, se contempla que las implementaciones de la presente divulgación se puedan realizar en cualquier tipo apropiado de cadena de bloques.
En una cadena de bloques de consorcio, el proceso de consenso está controlado por un conjunto autorizado de nodos, siendo uno o más nodos operados por una entidad respectiva (p. ej., una empresa). Por ejemplo, un consorcio de diez (10) entidades (p. ej., empresas) puede operar un sistema de cadena de bloques de consorcio, cada una de las cuales opera al menos un nodo en el DLS de consorcio. En consecuencia, el sistema de cadena de bloques de consorcio puede considerarse una red privada con respecto a las entidades participantes. En algunos ejemplos, cada una de las entidades (nodo) debe firmar cada uno de los bloques para que el bloque sea válido y se agregue a la cadena de bloques. En algunos ejemplos, al menos un subconjunto de entidades (nodos) (p. ej., al menos 7 entidades) debe firmar cada uno de los bloques para que el bloque sea válido y se agregue a la cadena de bloques. Un ejemplo de sistema de cadena de bloques de consorcio incluye Quorum, desarrollado por JP Morgan Chase & Co. de Nueva York, Nueva York. Quorum se puede describir como una infraestructura de cadena de bloques autorizada y centrada en la empresa, diseñada específicamente para casos de uso financiero. Quorum se basa en Go Ethereum, el código base para la cadena de bloques Ethereum, que se proporciona por la Fundación Ethereum de Zug, Suiza.
En general, un sistema de cadena de bloques de consorcio admite transacciones entre entidades participantes, con permiso, en el sistema de cadena de bloques de consorcio. Una transacción se comparte con todos los nodos dentro del sistema de cadena de bloques de consorcio, porque la cadena de bloques se replica en todos los nodos. Es decir, todos los nodos están en perfecto estado de consenso con respecto a la cadena de bloques. Para lograr un consenso (p. ej., un acuerdo para agregar un bloque a una cadena de bloques), se implementa un protocolo de consenso dentro de la cadena de bloques de consorcio. Un ejemplo de protocolo de consenso incluye, sin limitación, prueba de trabajo (POW) implementada en la red Bitcoin.
Las implementaciones de la presente divulgación incluyen métodos implementados por computadora para facilitar los procesos de consenso de una red red de cadena de bloques basada en PBFT. Más particularmente, las implementaciones de la presente divulgación están dirigidas a facilitar la transmisión de mensajes de consenso y la sincronización de nodos en una red de cadena de bloques basada en PBFT utilizando un método de comunicaciones basado en chismes y añadiendo firma digital a los mensajes de consenso. De esta manera, y como se describe con más detalle en el presente documento, se puede reducir el consumo de ancho de banda de comunicaciones y se puede mejorar la confiabilidad del sistema.
De acuerdo con implementaciones de la presente divulgación, los nodos de consenso de un sistema de cadena de bloques de consorcio ejecutan un protocolo de consenso PBFT. En algunos ejemplos, los nodos pueden enviar mensajes de consenso. De acuerdo con implementaciones de la presente divulgación, los mensajes de consenso de ejemplo pueden incluir, sin limitación, preparar previamente, preparar y comprometer. En algunas implementaciones, se incluyen una firma digital y un número de secuencia con cada uno de los mensajes de consenso. La firma digital se puede utilizar para identificar el nodo que envió el mensaje de consenso respectivo, y el número de secuencia indica una ronda de consenso, dentro de la cual se envió el mensaje de consenso.
Cada uno de los nodos de consenso puede almacenar o registrar todos los mensajes de consenso recibidos. Si un nodo de consenso (p. ej., un nodo de respaldo) de la red de la cadena de bloques se recupera de una desconexión y ha perdido uno o más mensajes de consenso, puede sincronizarse con otros nodos obteniendo los mensajes perdidos desde uno o más otros nodos de consenso. De acuerdo con implementaciones de la presente divulgación, los mensajes de consenso se pueden recuperar utilizando un algoritmo de chismes, en lugar de, por ejemplo, difundir una solicitud de obtención a toda la red red de cadena de bloques. Debido a que los mensajes de consenso obtenidos desde otro nodo de consenso llevan la firma digital del nodo de consenso respectivo, la fuente del mensaje de consenso obtenido se puede confirmar (y confiar). En algunos ejemplos, el nodo de respaldo puede obtener todos los mensajes perdidos en una única sincronización. Como tal, la complejidad de la sincronización o el consenso se puede reducir a 0(1) en condiciones ideales, en comparación con O(n) basado en la multidifusión estándar de PBFT tradicional.
La FIG. 1 representa un entorno 100 de ejemplo que puede utilizarse para ejecutar implementaciones de la presente divulgación. En algunos ejemplos, el entorno 100 de ejemplo permite a las entidades participar en un sistema 102 de cadena de bloques de consorcio. El entorno 100 de ejemplo incluye los sistemas 106, 108 informáticos y una red 110. En algunos ejemplos, la red 110 incluye una red de área local (LAN) , red de área amplia (WAN), Internet o una combinación de las mismas, y conecta sitios web, dispositivos de usuario (p. ej., dispositivos informáticos) y sistemas de servidor. En algunos ejemplos, se puede acceder a la red 110 a través de un enlace de comunicaciones cableado y/o inalámbrico.
En el ejemplo representado, los sistemas 106, 108 informáticos pueden incluir cada uno cualquier sistema informático apropiado que permita la participación como un nodo en el sistema 102 de cadena de bloques de consorcio, para almacenar transacciones en una cadena 104 de bloques. Los dispositivos informáticos de ejemplo incluyen, sin limitación, un servidor, una computadora de escritorio, una computadora portátil, un dispositivo informático de tableta y un teléfono inteligente. En algunos ejemplos, los sistemas 106, 108 informáticos alojan uno o más servicios implementados por computadora para interactuar con el sistema 102 de cadena de bloques de consorcio. Por ejemplo, el sistema 106 informático puede alojar servicios implementados por computadora de una primera entidad (p. ej., el usuario A) , tal como un sistema de gestión de transacciones que utiliza la primera entidad para gestionar sus transacciones con una o más otras entidades (p. ej., otros usuarios). El sistema 108 informático puede alojar servicios implementados por computadora de una segunda entidad (p. ej., el usuario B), tal como un sistema de gestión de transacciones que utiliza la segunda entidad para gestionar sus transacciones con una o más de otras entidades (p. ej., otros usuarios). En el ejemplo de la FIG. 1, el sistema 102 de cadena de bloques de consorcio se representa como una red de nodos de igual a igual, y los sistemas 106, 108 informáticos proporcionan nodos de la primera entidad y la segunda entidad, respectivamente, que participan en el sistema 102 de cadena de bloques de consorcio.
La FIG. 2 representa una arquitectura 200 conceptual de ejemplo de acuerdo con implementaciones de la presente divulgación. La arquitectura 200 conceptual de ejemplo incluye una capa 202 de entidad, una capa 204 de servicios alojados y una capa 206 de cadena de bloques. En el ejemplo representado, la capa 202 de entidad incluye tres entidades, Entidad_1 (E1), Entidad_2 (E2) y Entidad_3 (E3), teniendo cada una de las entidades un respectivo sistema 208 de gestión de transacciones.
En el ejemplo representado, la capa 204 de servicios alojados incluye interfaces 210 de cadena de bloques para cada uno de los sistemas 208 de gestión de transacciones. En algunos ejemplos, un sistema 208 de gestión de transacciones respectivo se comunica con una interfaz 210 de cadena de bloques respectiva a través de una red (p. ej., la red 110 de la FIG. 1) utilizando un protocolo de comunicación (p. ej., protocolo de transferencia de hipertexto seguro (HTTPS)). En algunos ejemplos, cada una de las interfaces 210 de cadena de bloques proporciona una conexión de comunicación entre un sistema 208 de gestión de transacciones respectivo y la capa 206 de cadena de bloques. Más particularmente, cada una de las interfaces 210 de cadena de bloques permite que la entidad respectiva realice transacciones registradas en un sistema 212 de cadena de bloques de consorcio de la capa 206 de cadena de bloques. En algunos ejemplos, la comunicación entre una interfaz 210 de cadena de bloques y la capa 206 de cadena de bloques se realiza utilizando llamadas a procedimientos remotos (RPC). En algunos ejemplos, las interfaces 210 de cadena de bloques "alojan" nodos de cadena de bloques para los respectivos sistemas 208 de gestión de transacciones. Por ejemplo, las interfaces 210 de cadena de bloques proporcionan la interfaz de programación de aplicaciones (API) para acceder al sistema 212 de cadena de bloques de consorcio.
Como se describe en el presente documento, el sistema 212 de cadena de bloques de consorcio se proporciona como una red de igual a igual que incluye una pluralidad de nodos 214 que registran información de manera inmutable en una cadena 216 de bloques. Aunque se representa esquemáticamente una única cadena 216 de bloques de bloques, se proporcionan múltiples copias de la cadena 216 de bloques y se mantienen en todo el sistema 212 de cadena de bloques de consorcio. Por ejemplo, cada uno de los nodos 214 almacena una copia de la cadena 216 de bloques. En algunas implementaciones, la cadena 216 de bloques almacena información asociada con transacciones que se realizan entre dos o más entidades que participan en el sistema 212 de cadena de bloques de consorcio.
La FIG. 3 representa un proceso 300 de consenso de ejemplo basado en PBFT de acuerdo con implementaciones de la presente divulgación. A alto nivel, el proceso 300 de consenso de ejemplo se realiza por un nodo cliente (nodo 302 c ), un nodo líder (nodo 304 1) y una pluralidad de nodos de respaldo (nodo 306 2, nodo 308 3 y nodo 3104) de una red red de cadena de bloques. Se supone que el algoritmo de consenso utilizado por la red red de cadena de bloques es PBFT. Un sistema PBFt puede incluir tres fases. Las fases de ejemplo pueden incluir, sin limitación, preparación 312 previa, preparación 314 y confirmación 316. En el ejemplo representado, el nodo 3104 está desconectado o no está disponible de otra manera durante las tres fases de una ronda de consenso identificada por un número de secuencia representado mediante la variable sec. Una vez que se recupera el nodo 3104, puede solicitar sincronizar 318 con otros nodos para recuperar los mensajes de consenso que faltan para garantizar la seguridad y la vigencia del consenso de PBFT. Para lograr una sincronización más rápida, cada uno de los nodos de consenso puede utilizar su clave privada para firmar digitalmente el mensaje de consenso que envía. Como tal, cada uno de los mensajes de consenso lleva una firma digital de su nodo de envío. Incluso si el nodo de envío está desconectado o no está disponible de otra manera, un nodo de recepción puede reenviar de forma segura el mensaje de consenso para garantizar la vigencia de la red. Los detalles del proceso 300 de ejemplo se discuten adicionalmente en la siguiente descripción de la FIG. 3.
En algunas implementaciones, el nodo 302 cliente puede enviar una solicitud para agregar una o más transacciones a la cadena de bloques. En algunos casos, la solicitud también incluye una variable sec que indica la ronda de consenso actual. Por ejemplo, si la cadena de bloques está en una tercera ronda de consenso, la variable sec es igual a 3.
Después de recibir una o más solicitudes para agregar una o más transacciones a la cadena de bloques desde el nodo 302 cliente y/u otros nodos, el nodo 304 1 (nodo líder) puede generar un mensaje de preparación previa firmado digitalmente (pp1). Haciendo referencia brevemente a la FIG. 4, la FIG. 4 representa una estructura 400 de ejemplo de un mensaje de consenso basado en PBFT de acuerdo con implementaciones de la presente divulgación. Como se muestra en la FIG. 4, un mensaje 402 de preparación previa puede incluir vista, resumen, transacción, marca de tiempo y sec. La variable vista puede indicar el número v de cambio de vista. El cambio de vista en PBFT puede proporcionar vigencia al permitir que PBFT progrese cuando falla el nodo líder. Los cambios de vista se pueden activar por tiempos de espera que evitan que los nodos de respaldo esperen indefinidamente a que se ejecuten las solicitudes. Un nodo de respaldo puede iniciar un temporizador cuando recibe una solicitud y el temporizador aún no se está ejecutando. Puede detener el temporizador cuando ya no está esperando para ejecutar la solicitud. Sin embargo, el nodo de respaldo puede reiniciar el temporizador, si en ese momento está esperando para ejecutar otras solicitudes. Si el temporizador del nodo de respaldo expira en la vista, el nodo de respaldo puede iniciar un cambio de vista para mover el sistema a la vista v 1.
Transacción puede ser el mensaje de solicitud del nodo cliente para agregar transacciones a la cadena de bloques. Resumen puede ser el resumen del mensaje. Marca de tiempo se puede utilizar para garantizar que cada una de las solicitudes de cliente se ejecute una vez. Marcas de tiempo se pueden ordenar de manera que las solicitudes posteriores tengan marcas de tiempo más altas que las anteriores. Por ejemplo, la marca de tiempo podría ser el valor del reloj local del cliente cuando se emite la solicitud. Sec puede indicar la ronda de consenso del mensaje. En algunas implementaciones, se puede añadir una firma 404 digital al mensaje 402 de preparación previa utilizando una clave privada del nodo líder. En algunas implementaciones, el mensaje de consenso, tal como el mensaje 402 de preparación previa, puede almacenarse en un nodo que acepta el mensaje hasta que se alcanza un punto de control estable. Un punto de control puede ser el estado producido por la ejecución de una solicitud y un punto de control con una prueba puede denominarse punto de control estable.
Haciendo referencia de nuevo a la FIG. 3, después de generar el mensaje ppl de preparación previa firmado digitalmente, el nodo líder puede multidifundir el mensaje a los nodos de respaldo, el nodo 306 2, el nodo 308 3 y el nodo 3104.
Una vez que el nodo 306 2 y el nodo 308 3 aceptan el mensaje ppl de preparación previa, pueden entrar en la fase 314 de preparación. En este punto, el nodo 310 4 se desconecta de la red red de cadena de bloques o no está disponible de otra manera. Como tal, no puede recibir ppl, generar el mensaje de preparación o realizar la multidifusión. Las fases de preparación previa y preparación se pueden utilizar para ordenar las solicitudes enviadas en la misma vista, incluso cuando el nodo líder, que propone la ordenación de las solicitudes, sea defectuoso.
En la fase 314 de preparación, el nodo 306 2 puede multidifundir su mensaje p2 de preparación a otros nodos, y agregar tanto ppl como p2 a su registro. De manera similar, el nodo 308 3 puede multidifundir su mensaje p3 de preparación a otros nodos y agregar tanto ppl como p3 a su registro. Haciendo referencia de nuevo a la FIG. 4, el mensaje 406 de preparación puede incluir vista, resumen y sec. Se puede agregar una firma 408 digital al mensaje 406 de preparación.
Haciendo referencia de nuevo a la FIG. 3, el nodo 306 2 y el nodo 308 3 pueden firmar digitalmente p2 y p3, respectivamente, utilizando sus claves privadas. En algunas implementaciones, un nodo puede entrar en la fase 316 de confirmación si recibe 2 f mensajes de consenso que tienen un resumen igual que su propio resumen, donde f es un número máximo de nodos defectuosos que es tolerable por la cadena de bloques basada en PBFT. El valor f se puede calcular como el mayor entero menor o igual que (n - 1) / 3, donde n es el número total de nodos. En el proceso 300 de consenso de ejemplo, dado que el número total de nodos es 4, f = 1.
Suponiendo que todos los resúmenes recibidos son los mismos que los del propio resumen de un nodo, después de recibir p2 y p3, el nodo 304 1 tiene 2 f mensajes de resumen y puede generar y multidifundir una confirmación c1 y agregar p2, p3 y c1 a su registro. De manera similar, el nodo 3062 puede generar y multidifundir una confirmación c2 después de recibir ppl y p3 y agregar p3 y c2 a su registro. De manera similar, el nodo 308 3 puede generar y multidifundir una confirmación c3 después de recibir ppl y p2 y agregar p2 y c3 a su registro. Como tal, después de que un nodo de consenso recibe un mensaje de consenso firmado digitalmente desde otro nodo, el mensaje de consenso y la firma digital pueden almacenarse localmente en el nodo de recepción. Los mensajes de consenso firmados digitalmente se pueden clasificar en base a la correspondiente valor sec para asegurar el orden correcto de los mensajes.
Haciendo referencia de nuevo a la FIG. 4, el mensaje 410 de confirmación puede incluir vista, resumen y sec. Se puede agregar una firma 412 digital al mensaje 410 de confirmación.
Haciendo referencia de nuevo a la FIG. 3, suponiendo que el nodo 3104 se recupere y vuelva a conectarse a la red red de cadena de bloques, puede iniciar la fase 318 de sincronización para recuperar los mensajes que faltan durante su tiempo de inactividad. En algunas implementaciones, para evitar que un temporizador del nodo 3104 expire en la vista e inicie un cambio de vista, se puede configurar un temporizador de recuperación para que se agote antes del tiempo de espera del cambio de vista.
En respuesta a que se agote un temporizador de recuperación, el nodo 3104 puede determinar uno o más nodos de consenso que tienen mensajes de consenso que perdió el nodo 3104. El nodo 3104 puede seleccionar aleatoriamente entre uno o más nodos de consenso para enviar una solicitud de recuperación basada en un algoritmo de chismes. La solicitud de recuperación puede incluir el número de sec del nodo y los tipos de mensajes de consenso que faltan.
En el proceso 300 de consenso de ejemplo, los tipos de mensajes de consenso que faltan incluyen preparación previa, preparación y confirmación. Como tal, la solicitud de recuperación puede tener una forma de sec<pp, p, c>. En algunos ejemplos, el nodo 3104 selecciona aleatoriamente el nodo 3083 basándose en el algoritmo de chismes para recuperar los mensajes de consenso que faltan. El nodo 308 3 ha registrado p p l, p2, p3, c1, c2 y c3 en la ronda de consenso de la sec. Debido a que todos los mensajes registrados incluyen firmas digitales de los nodos emisores, su autenticidad puede verificarse utilizando las claves públicas correspondientes de los nodos emisores. Dado que el nodo 308 3 ha registrado tres mensajes c1, c2 y c3, de consenso que son mayores o iguales que 2f 1, puede proporcionar los mensajes pp1, p2, p3, c1, c2, c3 firmados digitalmente al nodo 310 4. En algunos casos, si el nodo que recibe la solicitud de recuperación ha registrado menos de 2f 1 mensajes de consenso, el nodo solicitante puede recuperar desde otros nodos en el sistema hasta que se obtengan al menos 2f 1 mensajes de consenso. En el proceso 300 de ejemplo, el nodo 3104 puede recuperar todos los mensajes de consenso siempre que cualquiera del nodo 304 1, el nodo 306 2 y el nodo 3083 esté conectado a la red red de cadena de bloques. Por lo tanto, es posible que el nodo recuperado solo necesite realizar la sincronización una vez para recuperar los mensajes que faltan. Como tal, se pueden ahorrar recursos de red y se puede mejorar la eficiencia del sistema.
La FIG. 5 representa un proceso 500 de ejemplo que puede ejecutarse de acuerdo con implementaciones de la presente divulgación. Para mayor claridad de presentación, la descripción que sigue describe generalmente el proceso 500 de ejemplo en el contexto de las otras figuras en esta descripción. Sin embargo, se entenderá que el proceso 500 de ejemplo puede realizarse, por ejemplo, mediante cualquier sistema, entorno, software y hardware, o una combinación de sistemas, entornos, software y hardware, según sea apropiado. En algunas implementaciones, diversos pasos del proceso 500 de ejemplo se pueden ejecutar en paralelo, en combinación, en bucles o en cualquier orden.
En 502, un nodo de respaldo de un sistema PBFT reconectado a una red red de cadena de bloques basada en PBFT establece un temporizador que se agota antes de que se agote un tiempo de espera de un cambio de vista.. En 504, el nodo de respaldo envía, a otro nodo de consenso, una solicitud para uno o más mensajes de consenso que faltan en el nodo de respaldo en respuesta a que el temporizador se agota. En algunas implementaciones, la solicitud incluye un número de secuencia que indica un número de rondas de consenso. En algunas implementaciones, el uno o más mensajes de consenso incluyen uno o más mensajes de preparación previa, mensajes de preparación y mensajes de confirmación que faltan en el primer nodo de consenso
En 506, el nodo de respaldo recibe, desde el nodo de consenso, el uno o más mensajes de consenso, cada uno firmado digitalmente por una clave privada de un nodo de consenso correspondiente que genera el respectivo uno o más mensajes de consenso. En algunas implementaciones, el uno o más mensajes de consenso incluyen uno o más mensajes de preparación previa, mensajes de preparación y mensajes de confirmación que faltan en el primer nodo de consenso En algunas implementaciones, el uno o más mensajes de consenso se almacenan en uno o más nodos de consenso en los que se generan o almacenan, hasta que se alcanza un punto de control estable.
En 508, el nodo de respaldo determina que un bloque de transacciones es válido, si una cantidad de mensajes de confirmación incluidos en el uno o más mensajes de consenso recibidos es mayor o igual que 2 f 1, donde f es un número máximo de nodos defectuosos que es tolerable por la cadena de bloques basada en PBFT. En algunas implementaciones, el nodo de respaldo recibe además uno o más números de secuencia correspondientes al uno o más mensajes de consenso. Cada número de secuencia indica una serie de rondas de consenso asociadas con un mensaje de consenso correspondiente.
En algunas implementaciones, el nodo de respaldo envía además el bloque de transacciones a una cadena de bloques y una base de datos de estado, si se determina que el bloque de transacciones es válido. En algunas implementaciones, el nodo de respaldo envía además a un tercer nodo de consenso diferente del nodo de consenso y el nodo de respaldo, una solicitud para uno o más segundos mensajes de consenso perdidos por el nodo de consenso en respuesta a que el temporizador se agota y si el bloque de transacciones se determina no válido. El nodo de respaldo recibe, desde el tercer nodo de consenso, el uno o más segundos mensajes de consenso, cada uno firmado digitalmente por una clave privada de un nodo de consenso correspondiente que genera el uno o más segundos mensajes de consenso respectivos. El nodo de respaldo determina entonces que el bloque de transacciones es válido, si una cantidad de los mensajes de confirmación incluidos en el uno o más mensajes de consenso y el uno o más segundos mensajes de consenso es mayor o igual que 2f 1.
Las implementaciones de la materia objeto descrita en esta memoria descriptiva se pueden implementar para realizar ventajas o efectos técnicos particulares. Por ejemplo, las implementaciones de la presente divulgación permiten a los nodos de consenso de una cadena de bloques de consorcio enviar mensajes de consenso firmados digitalmente con un número de secuencia que identifica la ronda de consenso del mensaje correspondiente. Un nodo de respaldo puede confiar en que los mensajes de consenso firmados digitalmente son seguros y se pueden verificar las fuentes de los mensajes. Como tal, se puede mejorar la seguridad y privacidad de datos de la cadena de bloques de consorcio. Además, si un nodo de respaldo se recupera de una desconexión, puede sincronizarse con otros nodos recuperando mensajes perdidos desde otro nodo de consenso aleatorio en lugar de difundir una solicitud de recuperación a toda la red. Debido a que los mensajes recuperados desde otro nodo de consenso llevan la firma digital del nodo emisor, se puede confiar en las fuentes de los mensajes y el nodo de respaldo puede recuperar todos los mensajes perdidos desde un nodo a través de una sincronización. Como tal, la complejidad de la sincronización o el consenso se puede reducir a 0(1) en condiciones ideales, en comparación con O(n) basado en el método de multidifusión estándar en PBFT. En consecuencia, se pueden ahorrar recursos computacionales y de red y se puede mejorar la eficiencia del sistema PBFT.
La metodología descrita puede garantizar el uso eficiente de los recursos informáticos (por ejemplo, ciclos de procesamiento, ancho de banda de red y uso de memoria), a través de la actualización eficiente de la cadena de bloques. Las operaciones de cuenta se pueden realizar de manera más rápida y segura a través de procesos de consenso más simples.
Las implementaciones y las operaciones descritas en esta memoria descriptiva se pueden implementar en circuitería electrónica digital, o en software, firmware o hardware de computadora, incluidas las estructuras dadas a conocer en esta memoria descriptiva o en combinaciones de una o más de ellas. Las operaciones pueden implementarse como operaciones realizadas por un aparato de procesamiento de datos sobre datos almacenados en uno o más dispositivos de almacenamiento legibles por computadora o recibidos desde otras fuentes. Un aparato de procesamiento de datos, computadora o dispositivo informático puede incluir aparatos, dispositivos y máquinas para procesar datos, incluidos, a modo de ejemplo, un procesador programable, una computadora, un sistema en chip, o múltiples o combinaciones de los anteriores. El aparato puede incluir circuitería lógica de propósito especial, por ejemplo, una unidad central de procesamiento (CPU), una matriz de puertas programables en campo (FPGA) o un circuito integrado de aplicación específica (ASIC). El aparato también puede incluir código que crea un entorno de ejecución para el programa informático en cuestión, por ejemplo, código que constituye el firmware del procesador, una pila de protocolo, un sistema de gestión de bases de datos, un sistema operativo (por ejemplo, un sistema operativo o una combinación de sistemas), un entorno de ejecución multiplataforma, una máquina virtual o una combinación de uno o más de ellos. El aparato y el entorno de ejecución pueden realizar diversas infraestructuras de modelos informáticos diferentes, tales como servicios web, informática distribuida e infraestructuras informáticas en malla.
Un programa informático (también conocido, por ejemplo, como programa, software, aplicación de software, módulo de software, unidad de software, secuencia de comandos o código) se puede escribir en cualquier forma de lenguaje de programación, incluidos los lenguajes compilados o interpretados, los lenguajes declarativos o procedimentales y se puede implementar en cualquier forma, incluso como un programa autónomo o como un módulo, componente, subrutina, objeto u otra unidad adecuada para su uso en un entorno informático. Un programa se puede almacenar en una porción de un archivo que contiene otros programas o datos (por ejemplo, una o más secuencias de comandos almacenadas en un documento de lenguaje de marcado), en un solo archivo dedicado al programa en cuestión, o en múltiples archivos coordinados (por ejemplo, archivos que almacenan uno o más módulos, subprogramas o porciones de código). Un programa informático se puede ejecutar en una computadora o en múltiples computadoras que están ubicadas en un sitio o distribuidas en múltiples sitios e interconectadas por una red de comunicaciones.
Los procesadores para la ejecución de un programa informático incluyen, a modo de ejemplo, microprocesadores tanto de uso general como especial, y uno o más procesadores de cualquier tipo de computadora digital. Generalmente, un procesador recibirá instrucciones y datos de una memoria de solo lectura o una memoria de acceso aleatorio o ambas. Los elementos esenciales de una computadora son un procesador para realizar acciones de acuerdo con instrucciones y uno o más dispositivos de memoria para almacenar instrucciones y datos. Generalmente, una computadora también incluirá, o estará acoplada operativamente para recibir datos o transferir datos a, o ambos, uno o más dispositivos de almacenamiento masivo para almacenar datos. Una computadora puede integrarse en otro dispositivo, por ejemplo, un dispositivo móvil, un asistente digital personal (PDA), una consola de juegos, un receptor del sistema de posicionamiento global (GPS) o un dispositivo de almacenamiento portátil. Los dispositivos adecuados para almacenar instrucciones y datos de programas informáticos incluyen memoria no volátil, dispositivos de medios y de memoria, que incluyen, a modo de ejemplo, dispositivos de memoria semiconductores, discos magnéticos y discos magneto-ópticos. El procesador y la memoria pueden complementarse o incorporarse en circuitería lógica de propósito especial.
Los dispositivos móviles pueden incluir teléfonos, equipos de usuario (UE), teléfonos móviles (por ejemplo, teléfonos inteligentes), tabletas, dispositivos ponibles (por ejemplo, relojes inteligentes y gafas inteligentes), dispositivos implantados dentro del cuerpo humano (por ejemplo, biosensores, implantes cocleares) u otros tipos de dispositivos móviles. Los dispositivos móviles pueden comunicarse de forma inalámbrica (por ejemplo, utilizando señales de radiofrecuencia (RF)) a diversas redes de comunicaciones (descritas a continuación). Los dispositivos móviles pueden incluir sensores para determinar características del entorno actual del dispositivo móvil. Los sensores pueden incluir cámaras, micrófonos, sensores de proximidad, sensores de GPS, sensores de movimiento, acelerómetros, sensores de luz ambiente, sensores de humedad, giroscopios, brújulas, barómetros, sensores de huellas dactilares, sistemas de reconocimiento facial, sensores de RF (por ejemplo, radios Wi-Fi y de telefonía móvil), sensores térmicos u otros tipos de sensores. Por ejemplo, las cámaras pueden incluir una cámara orientada hacia adelante o hacia atrás con lentes móviles o fijas, un flash, un sensor de imágenes y un procesador de imágenes. La cámara puede ser una cámara de megapíxeles capaz de capturar detalles para reconocimiento facial y/o de iris. La cámara junto con un procesador de datos y la información de autenticación almacenada en la memoria o al que se accede de forma remota pueden formar un sistema de reconocimiento facial. El sistema de reconocimiento facial o uno o más sensores, por ejemplo, micrófonos, sensores de movimiento, acelerómetros, sensores de GPS o sensores de RF, se pueden utilizar para la autenticación del usuario.
Para facilitar la interacción con un usuario, las realizaciones se pueden implementar en una computadora que tenga un dispositivo de visualización y un dispositivo de entrada, por ejemplo, una pantalla de cristal líquido (LCD) o diodo de emisión de luz orgánica (OLED)/de realidad virtual (VR)/de realidad aumentada (AR) para visualizar información al usuario y una pantalla táctil, un teclado y un dispositivo señalador mediante el cual el usuario puede proporcionar entrada a la computadora. También se pueden utilizar otros tipos de dispositivos para permitir la interacción con un usuario; por ejemplo, la retroalimentación proporcionada al usuario puede ser cualquier forma de retroalimentación sensorial, por ejemplo, retroalimentación visual, retroalimentación auditiva o retroalimentación táctil; y la entrada del usuario se puede recibir de cualquier forma, incluida la entrada acústica, de voz o táctil. Además, una computadora puede interactuar con un usuario enviando documentos y recibiendo documentos desde un dispositivo que se utiliza por el usuario; por ejemplo, enviando páginas web a un navegador web en el dispositivo cliente de un usuario en respuesta a las solicitudes recibidas desde el navegador web.
Las realizaciones se pueden implementar utilizando dispositivos informáticos interconectados por cualquier forma o medio de comunicación de datos digital cableada o inalámbrica (o una combinación de los mismos), por ejemplo, una red de comunicaciones. Ejemplos de dispositivos interconectados son un cliente y un servidor, generalmente, remotos entre sí que normalmente interactúan a través de una red de comunicaciones. Un cliente, por ejemplo, un dispositivo móvil, puede realizar transacciones por sí mismo, con un servidor, o a través de un servidor, por ejemplo, realizando transacciones de compra, venta, pago, entrega, envío o préstamo, o autorizando las mismas. Tales transacciones pueden ser en tiempo real, de manera que una acción y una respuesta sean próximas temporalmente; por ejemplo, un individuo percibe que la acción y la respuesta ocurren de manera sustancialmente simultánea, la diferencia de tiempo para una respuesta después de la acción del individuo es menos de 1 milisegundo (ms) o menos de 1 segundo (s), o la respuesta es sin demora intencional teniendo en cuenta limitaciones de procesamiento de cuentas del sistema.
Los ejemplos de redes de comunicaciones incluyen una red de área local (LAN), una red de acceso por radio (RAN), una red de área metropolitana (MAN) y una red de área amplia (WAN). La red de comunicaciones puede incluir todo o una parte de Internet, otra red de comunicaciones o una combinación de redes de comunicación. La información se puede transmitir en la red de comunicaciones de acuerdo con diversos protocolos y estándares, incluidos evolución a largo plazo (LTE), 5G, IEEE 802, Protocolo de Internet (IP) u otros protocolos o combinaciones de protocolos. La red de comunicaciones puede transmitir voz, vídeo, datos biométricos o de autenticación, u otra información entre los dispositivos informáticos conectados.
Las características descritas como implementaciones separadas pueden implementarse, en combinación, en una sola implementación, mientras que las características descritas como una sola implementación pueden implementarse en múltiples implementaciones, por separado o en cualquier subcombinación adecuada. Las operaciones descritas y reivindicadas en un orden particular no deben entenderse como que requieren que el orden particular, ni que todas las operaciones ilustradas deban realizarse (algunas operaciones pueden ser opcionales). Según corresponda, se puede realizar multitarea o procesamiento en paralelo (o una combinación de multitarea y procesamiento en paralelo).

Claims (12)

REIVINDICACIONES
1. Un método (500) implementado por computadora para facilitar un proceso de consenso en una red (102) de cadena de bloques basado en la tolerancia a fallas bizantinas práctica (PBFT), que comprende:
establecer, mediante un primer nodo (310) de consenso, un temporizador de vista para iniciar, tras el tiempo de espera del temporizador de vista, un cambio de vista de una vista actual;
establecer (502), mediante el primer nodo de consenso, un temporizador de recuperación que se agota antes del temporizador de vista;
determinar, mediante el primer nodo de consenso y en respuesta a que se agote el temporizador de recuperación, si al primer nodo de consenso le faltan uno o más mensajes de consenso; y
si el primer nodo de consenso determina que faltan uno o más mensajes de consenso:
enviar (504), mediante el primer nodo de consenso y solo a un segundo nodo (308) de consenso, una solicitud para el uno o más mensajes de consenso que faltan en el primer nodo de consenso;
recibir (506), mediante el primer nodo de consenso desde el segundo nodo de consenso, el uno o más mensajes de consenso cada uno firmado digitalmente por una clave privada de un nodo de consenso correspondiente que genera el uno o más mensajes de consenso respectivos; y
determinar (508), mediante el primer nodo de consenso, que un bloque de transacciones es válido, si una cantidad de mensajes de confirmación incluidos en el uno o más mensajes de consenso recibidos es mayor o igual que 2 f 1, donde f es un número máximo de nodos defectuosos que es tolerable por la cadena de bloques basada en PBFT.
2. El método (500) implementado por computadora de la reivindicación 1, en donde la solicitud incluye un número de secuencia que indica un número de una ronda de consenso.
3. El método (500) implementado por computadora de la reivindicación 1, en donde uno o más mensajes de consenso incluyen uno o más de mensajes de preparación previa, mensajes de preparación y mensajes de confirmación que faltan en el primer nodo (310) de consenso.
4. El método (500) implementado por computadora de la reivindicación 1, en donde uno o más mensajes de consenso se almacenan en uno o más nodos de consenso en los que se generan o almacenan, hasta que se alcanza un punto de control estable.
5. El método (500) implementado por computadora de la reivindicación 1, que comprende además recibir uno o más números de secuencia correspondientes al uno o más mensajes de consenso, en donde cada uno de los números de secuencia indica un número de una ronda de consenso asociada con un mensaje de consenso correspondiente.
6. El método (500) implementado por computadora de la reivindicación 1, que comprende además enviar el bloque de transacciones a una cadena de bloques y una base de datos de estado, si se determina que el bloque de transacciones es válido.
7. El método (500) implementado por computadora de la reivindicación 1, que además comprende:
determinar, mediante el primer nodo (310) de consenso y en respuesta a que se agote el temporizador de recuperación, si al primer nodo de consenso le faltan uno o más segundos mensajes de consenso;
determinar si el bloque de transacciones se determina no válido; y
si se determina que al primer nodo de consenso le faltan uno o más segundos mensajes de consenso o si se determina que el bloque de transacciones no es válido:
enviar, mediante el primer nodo de consenso a un tercer nodo de consenso, una solicitud para el uno o más segundos mensajes de consenso que faltan para el segundo nodo de consenso;
recibir, por el primer nodo de consenso desde el tercer nodo de consenso, el uno o más segundos mensajes de consenso, cada uno firmado digitalmente por una clave privada de un nodo de consenso correspondiente que genera el uno o más segundos mensajes de consenso respectivos; y
determinar, mediante el primer nodo de consenso, que el bloque de transacciones es válido, si una cantidad de los mensajes de confirmación incluidos en el uno o más mensajes de consenso y el uno o más segundos mensajes de consenso es mayor o igual que 2f 1.
8. El método (500) implementado por computadora de la reivindicación 7, en donde el tercer nodo de consenso es diferente del primer nodo (310) de consenso y del segundo nodo (308) de consenso.
9. El método (500) implementado por computadora de una cualquiera de las reivindicaciones 7 u 8, que comprende además seleccionar aleatoriamente, mediante el primer nodo (310) de consenso, el tercer nodo de consenso de una pluralidad de nodos de respaldo de la red (102) de cadena de bloques.
10. El método (500) implementado por computadora de una cualquiera de las reivindicaciones 1 a 9, que comprende además seleccionar aleatoriamente, mediante el primer nodo (310) de consenso, el segundo nodo (308) de consenso de una pluralidad de nodos de respaldo de la red (102) de cadena de bloques.
11. Un medio de almacenamiento legible por computadora no transitorio acoplado a uno o más procesadores y que tiene instrucciones almacenadas en el mismo que, cuando se ejecutan por el uno o más procesadores, hacen que el uno o más procesadores realicen operaciones de acuerdo con el método (500) de una o más de las reivindicaciones 1 a 10.
12. Un sistema que comprende:
un dispositivo informático; y
un dispositivo de almacenamiento legible por computadora acoplado al dispositivo informático y que tiene instrucciones almacenadas en el mismo que, cuando se ejecutan por el dispositivo informático, hacen que el dispositivo informático realice operaciones de acuerdo con el método (500) de una o más de las reivindicaciones 1 a 10.
ES18865827T 2018-11-07 2018-11-07 Facilitar el consenso práctico de cadena de bloques de tolerancia a fallas bizantinas y la sincronización de nodos Active ES2867423T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2018/114334 WO2019072263A2 (en) 2018-11-07 2018-11-07 FACILITATION OF BLOCK CHAIN CONSENSUS AND NODE SYNCHRONIZATION FOR PRACTICAL TOLERANCE TO ARBITRARY FAILURES

Publications (1)

Publication Number Publication Date
ES2867423T3 true ES2867423T3 (es) 2021-10-20

Family

ID=66100059

Family Applications (1)

Application Number Title Priority Date Filing Date
ES18865827T Active ES2867423T3 (es) 2018-11-07 2018-11-07 Facilitar el consenso práctico de cadena de bloques de tolerancia a fallas bizantinas y la sincronización de nodos

Country Status (16)

Country Link
US (3) US10803052B2 (es)
EP (2) EP3542514B1 (es)
JP (1) JP6727630B2 (es)
KR (1) KR102193549B1 (es)
CN (1) CN110115001B (es)
AU (1) AU2018347187B2 (es)
BR (1) BR112019008172B1 (es)
CA (1) CA3041463C (es)
ES (1) ES2867423T3 (es)
MX (1) MX2019004657A (es)
PH (1) PH12019500902B1 (es)
PL (1) PL3542514T3 (es)
RU (1) RU2724181C1 (es)
SG (1) SG11201903581WA (es)
WO (1) WO2019072263A2 (es)
ZA (1) ZA201902555B (es)

Families Citing this family (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106789095B (zh) * 2017-03-30 2020-12-08 腾讯科技（深圳）有限公司 分布式系统及消息处理方法
ES2867423T3 (es) 2018-11-07 2021-10-20 Advanced New Technologies Co Ltd Facilitar el consenso práctico de cadena de bloques de tolerancia a fallas bizantinas y la sincronización de nodos
ES2880108T3 (es) * 2019-03-18 2021-11-23 Advanced New Technologies Co Ltd Sistema y método para finalizar el protocolo de cambio de vista
SG11201908887XA (en) 2019-03-18 2019-10-30 Alibaba Group Holding Ltd System and method for ending view change protocol
ES2872101T3 (es) 2019-04-26 2021-11-02 Advanced New Technologies Co Ltd Gestión de claves distribuidas para entornos de ejecución confiables
CN110166295B (zh) * 2019-05-23 2021-07-30 杭州趣链科技有限公司 一种用于判断网络拓扑支持拜占庭容错与否的方法
US11050822B2 (en) * 2019-06-05 2021-06-29 International Business Machines Corporation Secure data dissemination
SE544149C2 (en) * 2019-06-25 2022-01-11 Coined Invest Pool Company Ab Method and system for performing electronic transactions
CN110458291A (zh) * 2019-08-09 2019-11-15 成都理工大学 一种基于遗传算法的最佳共识节点选择方法
CN110636113A (zh) * 2019-08-23 2019-12-31 上海电力大学 区块链的拜占庭容错共识方法、系统、设备和存储介质
CN110730204B (zh) * 2019-09-05 2022-09-02 创新先进技术有限公司 区块链网络中删除节点的方法和区块链系统
CN114401150B (zh) * 2019-09-05 2023-10-20 创新先进技术有限公司 区块链网络中加入节点的方法和区块链系统
WO2021050929A1 (en) * 2019-09-11 2021-03-18 Visa International Service Association Blockchain sharding with adjustable quorums
CN110661656B (zh) * 2019-09-20 2022-03-04 广东卓启投资有限责任公司 一种区块链快速共识方法及装置
US11368284B2 (en) * 2019-09-25 2022-06-21 Ford Global Technologies, Llc Vehicle blockchain transactions
CN110460484B (zh) * 2019-10-10 2020-02-18 杭州趣链科技有限公司 一种基于pbft算法改进的单节点异常主动恢复方法
US20220158892A1 (en) * 2019-10-14 2022-05-19 NEC Laboratories Europe GmbH Topology-driven byzantine fault-tolerant consensus protocol with vote aggregation
CN111131399B (zh) * 2019-12-03 2021-11-26 北京海益同展信息科技有限公司 一种区块链中共识节点动态增加方法及装置
CN111163148B (zh) * 2019-12-24 2021-09-28 腾讯科技（深圳）有限公司 一种区块链系统的共识状态的同步方法及相关设备
WO2020098840A2 (en) * 2020-02-24 2020-05-22 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain-based consensus process
CN111064813B (zh) * 2020-03-16 2020-06-30 支付宝(杭州)信息技术有限公司 在区块链共识处理时进行处理消息同步的方法及装置
CN111444211B (zh) * 2020-03-26 2021-07-13 腾讯科技（深圳）有限公司 区块链共识节点校验方法、装置、设备以及存储介质
US11250021B2 (en) 2020-04-17 2022-02-15 International Business Machines Corporation Faster view change for blockchain
CN111682942B (zh) * 2020-05-18 2022-06-10 哈尔滨工业大学 一种应用于许可链的二元加权拜占庭容错共识方法
CN111698315B (zh) * 2020-06-09 2021-10-15 腾讯科技（深圳）有限公司 针对区块的数据处理方法、数据处理装置及计算机设备
CN111756823A (zh) * 2020-06-12 2020-10-09 山西警察学院 基于简化拜占庭容错算法的应用于公安系统的开放许可链
CN112513914A (zh) * 2020-07-03 2021-03-16 支付宝(杭州)信息技术有限公司 基于区块链的隐私交易中提供隐私和安全保护的系统和方法
CN111523899B (zh) * 2020-07-03 2021-09-07 支付宝(杭州)信息技术有限公司 联盟链的共识方法、数据校验方法、装置及系统
CN112068978B (zh) * 2020-08-27 2022-06-10 恒宝股份有限公司 View-change二次启动定时器的定时期限延长方法及装置
CN112118321B (zh) * 2020-09-24 2023-06-06 北京工业大学 一种工业区块链的实用拜占庭容错共识机制优化系统
CN112565368B (zh) * 2020-11-26 2023-05-19 中国船舶集团有限公司系统工程研究院 基于区块链的海上装备自组网系统、方法和介质
CN112564960B (zh) * 2020-12-01 2022-05-13 浙商银行股份有限公司 基于区块链节点中心度弹性调整共识的方法及装置
CN112651830B (zh) * 2020-12-03 2023-01-24 齐鲁工业大学 应用于电力资源共享网络的区块链共识方法
CN112769917B (zh) * 2020-12-31 2022-08-02 山西特信环宇信息技术有限公司 一种锥体区块链的主权联盟链
CN112866399B (zh) * 2021-01-28 2023-01-31 深圳大学 一种改进的pbft共识方法、装置、智能终端及存储介质
CN113301149A (zh) * 2021-05-24 2021-08-24 山东大学 一种基于区块链的可信软件定义网络构建方法
CN113316177B (zh) * 2021-06-01 2022-03-25 山东大学 一种智能群体的决策通信系统及决策通信方法
CN113259456B (zh) * 2021-06-02 2021-10-15 支付宝(杭州)信息技术有限公司 跨链交互方法及装置
CN113259120B (zh) * 2021-06-02 2021-09-24 支付宝(杭州)信息技术有限公司 同步节点信息列表的方法
CN113448694B (zh) * 2021-06-11 2023-04-21 电子科技大学 一种提高事务处理能力的区块链共识方法
CN113542285B (zh) * 2021-07-19 2022-06-28 东南大学 一种针对Tendermint共识协议的多阶段自动化的形式化验证方法
CN113328920B (zh) * 2021-08-04 2021-10-29 成都飞机工业（集团）有限责任公司 一种对设备数据的采集与存储方法
WO2023035065A1 (en) * 2021-09-07 2023-03-16 Jalalzai Mohammad Methods and systems for fast consensus within distributed ledgers
CN113541968B (zh) * 2021-09-16 2021-11-26 中国信息通信研究院 共识方法、装置及区块链系统
CN113821569B (zh) * 2021-09-30 2024-02-06 广州智链未来科技有限公司 一种区块链的共识方法及区块链
CN113630257B (zh) * 2021-10-09 2022-01-04 支付宝(杭州)信息技术有限公司 一种共识方法、区块链系统和共识节点
CN113761071B (zh) * 2021-10-09 2023-07-11 支付宝(杭州)信息技术有限公司 一种共识方法、区块链系统和共识节点
CN114172659B (zh) * 2021-11-30 2024-04-26 中国建设银行股份有限公司 区块链系统中的消息传输方法、装置、设备及存储介质
CN114401064B (zh) * 2021-12-06 2023-10-31 西安电子科技大学 信任管理时间同步方法、系统、计算机设备、介质及终端
CN114258015B (zh) * 2021-12-23 2023-10-24 成都三零瑞通移动通信有限公司 一种基于全网共识的集群终端防失控方法及系统
CN114048517B (zh) * 2022-01-14 2022-05-20 北京大学深圳研究生院 区块链的双通道共识系统和方法、计算机可读存储介质
CN116633699B (zh) * 2023-07-25 2023-10-13 北京银联金卡科技有限公司 基于区块链的产品防伪溯源信息可信处理方法及系统
CN116915796B (zh) * 2023-09-14 2023-12-12 杭州趣链科技有限公司 集群视图分叉后的自主恢复方法、装置以及电子设备

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7392391B2 (en) 2001-11-01 2008-06-24 International Business Machines Corporation System and method for secure configuration of sensitive web services
US7720094B2 (en) * 2006-02-21 2010-05-18 Verso Backhaul Solutions, Inc. Methods and apparatus for low latency signal aggregation and bandwidth reduction
US9173168B2 (en) * 2010-08-23 2015-10-27 Nokia Technologies Oy Apparatus and method for power saving in an ad hoc network
US8745401B1 (en) 2010-11-12 2014-06-03 Google Inc. Authorizing actions performed by an online service provider
KR101757245B1 (ko) 2015-07-28 2017-07-13 한국과학기술원 피커링 에멀젼 및 그 제조 방법
JP6767007B2 (ja) * 2015-11-20 2020-10-14 株式会社写真化学 光造形装置
KR20170137388A (ko) * 2016-06-03 2017-12-13 (주) 블록체인오에스 블록체인 기술을 이용한 무결성 보장 방법
CN106447311B (zh) * 2016-09-26 2019-11-08 北京天德科技有限公司 一种四次通信的拜占庭容错算法的区块链建块方法
US10049017B2 (en) * 2016-10-04 2018-08-14 Nec Corporation Method and system for byzantine fault-tolerance replicating of data on a plurality of servers
WO2018095540A1 (en) * 2016-11-25 2018-05-31 NEC Laboratories Europe GmbH Method and system for byzantine fault - tolerance replicating of data
CN111327703B (zh) * 2017-03-28 2022-05-31 创新先进技术有限公司 一种基于区块链的共识方法及装置
CN107360206B (zh) * 2017-03-29 2020-03-27 创新先进技术有限公司 一种区块链共识方法、设备及系统
CN107124403A (zh) * 2017-04-14 2017-09-01 朱清明 区块链中共识区块的生成方法与计算设备
CN107301600B (zh) * 2017-06-23 2021-07-20 北京天德科技有限公司 一种跨链交易的区块链互联网模型的核心构建方法
CN107579848B (zh) * 2017-08-30 2020-08-25 上海保险交易所股份有限公司 实用拜占庭容错共识机制中动态更改共识节点的方法
RU181439U1 (ru) * 2018-04-06 2018-07-13 Оксана Валерьевна Кириченко Децентрализованная технологическая платформа хранения и обмена данными транзакций в распределенной вычислительной сети
ES2867423T3 (es) 2018-11-07 2021-10-20 Advanced New Technologies Co Ltd Facilitar el consenso práctico de cadena de bloques de tolerancia a fallas bizantinas y la sincronización de nodos

Also Published As

Publication number Publication date
PL3542514T3 (pl) 2021-08-30
EP3542514B1 (en) 2021-02-17
CN110115001B (zh) 2022-07-15
SG11201903581WA (en) 2019-05-30
CN110115001A (zh) 2019-08-09
US11397725B2 (en) 2022-07-26
BR112019008172B1 (pt) 2022-01-25
EP3542514A2 (en) 2019-09-25
PH12019500902A1 (en) 2019-12-02
RU2724181C1 (ru) 2020-06-22
EP3836512A1 (en) 2021-06-16
CA3041463A1 (en) 2019-04-18
US20210026839A1 (en) 2021-01-28
JP2020504351A (ja) 2020-02-06
US20210303550A1 (en) 2021-09-30
ZA201902555B (en) 2020-01-29
US11036721B2 (en) 2021-06-15
EP3836512B1 (en) 2022-07-13
JP6727630B2 (ja) 2020-07-22
EP3542514A4 (en) 2019-11-27
US10803052B2 (en) 2020-10-13
WO2019072263A3 (en) 2019-08-29
KR20200054127A (ko) 2020-05-19
WO2019072263A2 (en) 2019-04-18
CA3041463C (en) 2020-08-25
PH12019500902B1 (en) 2019-12-02
BR112019008172A2 (pt) 2019-09-10
KR102193549B1 (ko) 2020-12-23
MX2019004657A (es) 2019-08-12
US20190251077A1 (en) 2019-08-15
AU2018347187B2 (en) 2020-09-03
AU2018347187A1 (en) 2020-05-21

Similar Documents

Publication Publication Date Title
ES2867423T3 (es) Facilitar el consenso práctico de cadena de bloques de tolerancia a fallas bizantinas y la sincronización de nodos
KR102270518B1 (ko) 크로스 블록체인 인증 방법 및 장치
CA3083819C (en) Cross-blockchain authentication method, apparatus, and electronic device
CN110226318B (zh) 基于工作流管理区块链网络上的私有交易
US11108571B2 (en) Managing communications among consensus nodes and client nodes