ES2818597T3

ES2818597T3 - Realizar un proceso de recuperación para un nodo de red en un sistema distribuido

Info

Publication number: ES2818597T3
Application number: ES18866176T
Authority: ES
Inventors: Peng Lin
Original assignee: Advanced New Technologies Co Ltd
Current assignee: Advanced New Technologies Co Ltd
Priority date: 2018-12-13
Filing date: 2018-12-13
Publication date: 2021-04-13
Anticipated expiration: 2038-12-13
Also published as: US10649859B2; WO2019072295A2; PL3560142T3; CN110178340A; EP3560142B1; PH12019501710A1; KR20200074911A; JP2020516105A; JP6732321B2; CA3050560C; AU2018348335B2; EP3748906B1; AU2018348335A1; PH12019501710B1; SG11201906535WA; EP3560142A2; EP3560142A4; BR112019014815A2; EP3748906A1; CA3050560A1

Abstract

Un método que se implementa mediante ordenador (1100) para realizar un proceso de recuperación de un nodo de red (1102) de una red de cadena de bloques (102, 212), el método que comprende: difundir (1106), mediante el nodo de red de la red de cadena de bloques, un mensaje de solicitud de estado a una pluralidad de otros nodos de red (1104) de la red de cadena de bloques, en donde el nodo de red debe recuperar una transacción objetivo de un número de secuencia objetivo, el mensaje de solicitud comprende el número de secuencia objetivo, y el número de secuencia objetivo representa un número de secuencia mayor o un número de secuencia más reciente para el nodo de red; recibir (1108), mediante el nodo de red, una pluralidad de mensajes de respuesta de estado de la pluralidad de otros nodos de red, en donde cada uno de la pluralidad de mensajes de respuesta de estado comprende un número de secuencia; determinar (1110) si un número de mensajes de respuesta de estado excede un primer umbral predeterminado, en donde cada uno de los mensajes de estado comprende un mismo número de secuencia; si el número de mensajes de respuesta de estado excede el primer umbral predeterminado, identificar (1112), mediante el nodo de red, el número de secuencia objetivo en base al mismo número de secuencia; enviar (1114), mediante el nodo de red, un mensaje de solicitud a la pluralidad de otros nodos de red, en donde el mensaje de solicitud solicita un mensaje ECHO de cada uno de la pluralidad de otros nodos de red, el mensaje ECHO es un mensaje que se transmite mediante cada uno de la pluralidad de otros nodos de red para lograr un consenso entre la pluralidad de otros nodos de red sobre la transacción objetivo que tiene el número de secuencia objetivo, y el mensaje ECHO comprende una parte de la transacción objetivo y una firma de cada uno de la pluralidad de otros nodos de red; recibir (1116), mediante el nodo de red, una pluralidad de mensajes ECHO de la pluralidad de otros nodos de red; determinar, mediante el nodo de red, un número de mensajes ECHO válidos de la pluralidad de mensajes ECHO, en donde cada uno del número de mensajes ECHO válidos comprende el número de secuencia objetivo; determinar (1120) si el número de mensajes ECHO válidos excede un segundo umbral predeterminado; si el número de mensajes ECHO válidos excede el segundo umbral predeterminado, recuperar (1122), mediante el nodo de red, la transacción objetivo que tiene el mismo número de secuencia en el nodo de red basándose en el número de mensajes ECHO válidos; y enviar (1124), mediante el nodo de red, un mensaje a la pluralidad de otros nodos de red indicando que el nodo de red se ha recuperado.

Description

DESCRIPCIÓN

Realizar un proceso de recuperación para un nodo de red en un sistema distribuido

Antecedentes

Los sistemas de registro distribuido (DLS), que también pueden denominarse redes de consenso y/o redes de cadena de bloques, permiten que las entidades participantes almacenen datos de forma segura e inmutable. Los DLS se conocen comúnmente como redes de cadena de bloques sin hacer referencia a ningún caso de usuario en particular. Los ejemplos de redes de cadena de bloques pueden incluir: redes de cadena de bloques públicas, redes de cadena de bloques privadas y redes de cadena de bloques de consorcios. Una red de cadena de bloques pública está abierta para que todas las entidades usen el DLS y participen en el proceso de consenso. Se proporciona una red de cadena de bloques privada para una entidad en particular, que controla de forma centralizada los permisos de lectura y escritura. Se proporciona una red 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.

Los mecanismos de consenso son un componente principal de los sistemas de cadena de bloques distribuidos. Un mecanismo de consenso es un proceso en informática que se usa para lograr un acuerdo sobre un valor de datos único entre procesos o sistemas distribuidos. Los mecanismos de consenso se diseñan para lograr confiabilidad en una red que involucra múltiples nodos no confiables. Resolver ese problema, que se conoce como problema de consenso, es importante en la computación distribuida y los sistemas de múltiples agentes.

La cadena de bloques se basa en mecanismos de consenso para llegar a un acuerdo entre los nodos. Una cadena de bloques es una base de datos descentralizada que se administra mediante ordenadores distribuidos en una red de igual a igual (P2P). Cada par mantiene una copia del registro para impedir un solo punto de falla (SPOF). Las actualizaciones y validaciones se reflejan en todas las copias simultáneamente.

Aunque pueden usarse varias técnicas existentes para realizar el consenso entre los nodos de red de un sistema de cadena de bloques, una solución más eficiente para realizar el consenso sería ventajosa.

El documento US 6,671,821 describe un enfoque para la replicación de máquina de estado asíncrona en un sistema tolerante a fallas que ofrece integridad y alta disponibilidad en presencia de fallas bizantinas. El enfoque descrito también mejora la seguridad de los sistemas anteriores al recuperar réplicas de forma proactiva sin identificar necesariamente que han fallado o han sido atacadas. Esta recuperación proactiva limita la extensión de tiempo de una falla en particular al recuperar réplicas regularmente. De esta manera, el sistema funciona correctamente incluso cuando todas las réplicas fallan varias veces durante la vida útil del sistema, siempre que menos de 1/3 de las réplicas sean todas defectuosas dentro de una ventana de vulnerabilidad. El enfoque también presenta una implementación eficiente de la autenticación de mensajes que impide que un atacante se haga pasar por un nodo replicado que estaba defectuoso después de que ese nodo se recupera.

Resumen

Los objetos de la presente invención se consiguen mediante el conjunto de reivindicaciones adjuntas. Las implementaciones de la presente especificación incluyen un método que se implementa mediante ordenador para abordar problemas de consenso en un sistema distribuido (por ejemplo, una red de cadena de bloques). Más particularmente, las implementaciones de la presente especificación se dirigen a realizar un proceso de recuperación para un nodo de red en un sistema distribuido.

En algunas implementaciones, las acciones incluyen: difundir un mensaje de solicitud de estado a un número de nodos de red de la red de cadena de bloques mediante un nodo de la red de cadena de bloques, en donde el nodo de la red debe recuperar una transacción objetivo de un número de secuencia objetivo; recibir un número de mensajes de respuesta de estado por parte del nodo de red desde el número de nodos de red, en donde cada uno de los mensajes de respuesta de estado incluye un número de secuencia; identificar el número de secuencia objetivo mediante el nodo de red basándose en el mismo número de secuencia en respuesta a la determinación de que un número de mensajes de respuesta de estado excede un umbral predeterminado, en donde cada uno de los números de mensajes de estado incluye un mismo número de secuencia; enviar un mensaje de solicitud a la pluralidad de nodos de red mediante el nodo de red, en donde el mensaje de solicitud solicita un mensaje ECHO de cada uno de los nodos de red, en donde el mensaje ECHO es un mensaje que transmite cada uno de los nodos de red para lograr un consenso entre el número de nodos de red en la transacción objetivo que tiene el número de secuencia objetivo, y el mensaje ECHO incluye una parte de la transacción objetivo y una firma de cada uno de la pluralidad de nodos de red; recibir un número de mensajes ECHO mediante el nodo de red desde la pluralidad de nodos de red; determinar un número de mensajes ECHO válidos de la pluralidad de mensajes ECHO mediante el nodo de red, en donde cada uno del número de mensajes ECHO válidos incluye el número de secuencia objetivo; recuperar la transacción objetivo que tiene el mismo número de secuencia en el nodo de red basándose en el número de mensajes ECHO válidos en respuesta a la determinación de que el número de mensajes ECHO válidos excede un umbral predeterminado; enviar un mensaje a la pluralidad de nodos de red mediante el nodo de red indicando que el nodo de red se ha recuperado.

Otras implementaciones incluyen un sistema correspondiente y un programa informático que se configura para realizar las acciones de los métodos, codificados en un dispositivo de almacenamiento informático.

Cada una de estas y otras implementaciones puede incluir opcionalmente una o más de las siguientes características:

Una primera característica, que puede combinarse con cualquiera de las siguientes características, en donde el número de nodos de red incluye un nodo primario y uno o más nodos de respaldo.

Una segunda característica, que puede combinarse con cualquiera de las siguientes características, en donde el nodo de red es un nodo primario o un nodo de respaldo.

Una tercera característica, que puede combinarse con cualquiera de las siguientes características, en donde el mensaje de solicitud incluye el número de secuencia objetivo.

Una cuarta característica, que puede combinarse con cualquiera de las siguientes características, en donde cada uno de los nodos de red distintos del nodo de red verifica el mensaje de solicitud antes de enviar los mensajes ECHO al nodo de red.

Una quinta característica, que puede combinarse con cualquiera de las siguientes características, en donde el nodo de red verifica si cada uno de los mensajes ECHO es válido mediante el uso de un árbol Merkel.

Una sexta característica, que puede combinarse con cualquiera de las siguientes características, en donde el nodo de red verifica además si la firma en el mensaje ECHO es válida

Una séptima característica, que puede combinarse con cualquiera de las siguientes características, en donde cada uno de los mensajes ECHO incluye además al menos uno de una serie de bloques de código de borrado (EC) que se asocian con la transacción objetivo, en donde la cantidad de bloques EC se generan de acuerdo con un código EC mediante el uso de la transacción objetivo.

Una octava característica, que puede combinarse con cualquiera de las siguientes características, en donde el nodo de red reconstruye la transacción objetivo mediante el uso de un subconjunto del número de bloques EC que están en el número de mensajes ECHO válidos.

Una novena característica, que puede combinarse con cualquiera de las siguientes características, en donde el mensaje al número de nodos de red que indica que el nodo de red se ha recuperado incluye un conjunto de firmas en el número de mensajes ECHO válidos y el número de secuencia objetivo.

La presente especificación también proporciona uno o más medios de almacenamiento no transitorios legibles mediante ordenador que se acoplan a uno o más procesadores y que tienen instrucciones almacenadas en el mismo que, cuando se ejecutan mediante uno o más procesadores, hacen que uno o más procesadores realicen operaciones de acuerdo con implementaciones de los métodos que se proporcionan en la presente descripción.

La presente especificación proporciona además un sistema para implementar los métodos que se proporcionan en la presente descripción. El sistema incluye uno o más procesadores, y un medio de almacenamiento legible mediante ordenador que se acopla a uno o más procesadores que tienen instrucciones almacenadas en el mismo que, cuando se ejecutan mediante uno o más procesadores, hacen que uno o más procesadores realicen operaciones de acuerdo con las implementaciones de los métodos que se proporcionan en la presente descripción.

La presente especificación describe mecanismos de consenso mejorados que incluyen técnicas para lograr consenso entre los nodos de red en un sistema distribuido, realizar un cambio de nodo primario en un sistema distribuido y realizar un proceso de recuperación para un nodo de red en un sistema distribuido. Los mecanismos de consenso descritos pueden lograr diferentes ventajas en diferentes aplicaciones.

Por ejemplo, el proceso de consenso que se analiza a continuación incluye muchas características que mejoran las operaciones del sistema de cadena de bloques y ayudan a aliviar el cuello de botella de la red. Por ejemplo, el proceso de consenso descrito incluye convertir una solicitud de transacción en un número de bloques de código de borrado (EC) de acuerdo con un código EC y enviar uno de los bloques EC a cada uno de los nodos de red. El bloque EC es más pequeño que la solicitud de transacción original. En consecuencia, enviar el bloque EC en lugar de la solicitud de transacción completa a los nodos de red reduce el tamaño de los bloques de datos que se transmiten entre los nodos de red de la red de cadena de bloques, conservando así el ancho de banda de la red y reduciendo la carga de la red. Esto reduce aún más el tamaño de los datos que se escriben y leen en el espacio de memoria de los nodos de red, lo que reduce la carga en el espacio de memoria de los nodos de red y mejora la eficiencia del sistema de cadena de bloques en general.

Además, la presente especificación describe un proceso de cambio de época que incluye asignar pesos respectivos a múltiples fases del proceso de consenso, determinar una suma de pesos en base a los pesos respectivos de las múltiples fases y determinar un nuevo nodo primario en base a la suma de pesos. El proceso de cambio de época que se basa en la suma de pesos en lugar de un método de turno rotativo puede facilitar la elección de un nuevo nodo primario que no tenga fallas de manera oportuna. A diferencia del método de turno rotativo, el proceso de cambio de época en la presente especificación se basa en la suma de pesos para seleccionar el nuevo nodo primario, lo que puede reducir la latencia o la demora en la búsqueda del nuevo nodo primario que no esté defectuoso. Esto puede mejorar aún más la eficiencia del sistema de cadena de bloques en general al proporcionar los servicios de cadena de bloques.

Además, la presente especificación analiza un proceso de recuperación que incluye operaciones tales como enviar un mensaje de solicitud de estado mediante un nodo de red que solicita ser un nuevo nodo primario y recibir mensajes de respuesta de estado de los otros nodos de red. Estas operaciones se realizan de manera que el proceso de recuperación del nodo de red defectuoso no interfiera con el funcionamiento normal del proceso de consenso entre los otros nodos de red no defectuosos. Esto facilita la conservación de los recursos informáticos y de red para recuperar el nodo de red defectuoso al reducir la complejidad del proceso de recuperación.

Se reconoce que los métodos de acuerdo con la presente especificación pueden incluir cualquier combinación de los aspectos y características descritos en la presente descripción. Es decir, los métodos de acuerdo con la presente especificación no se limitan a las combinaciones de aspectos y características descritas específicamente en la presente descripción, sino que también incluyen cualquier combinación de los aspectos y características que se proporcionan.

Los detalles de una o más implementaciones de la presente especificación se exponen en los dibujos adjuntos y la descripción a continuación. Otras características y ventajas de la presente especificación descriptiva resultarán evidentes a partir de la descripción y los dibujos y de las reivindicaciones.

Breve descripción de los dibujos

La Figura 1 representa un ejemplo de un entorno que puede usarse para ejecutar implementaciones de la presente especificación.

La Figura 2 representa un ejemplo de una arquitectura conceptual de acuerdo con implementaciones de la presente especificación.

La Figura 3 representa un ejemplo de un proceso de consenso que puede ejecutarse de acuerdo con implementaciones de la presente especificación.

La Figura 4 representa un ejemplo de un proceso de consenso que puede ejecutarse de acuerdo con implementaciones de la presente especificación.

La Figura 5 representa un ejemplo de un árbol hash de acuerdo con implementaciones de la presente especificación.

La Figura 6 representa un ejemplo de mensajes que se comunican entre los nodos de red de un sistema distribuido de acuerdo con implementaciones de la presente especificación.

La Figura 7 representa un ejemplo de un proceso para realizar un cambio de un nodo primario en un sistema distribuido de acuerdo con implementaciones de la presente especificación.

La Figura 8 representa un ejemplo de un proceso para realizar un cambio de un nodo primario en un sistema distribuido de acuerdo con implementaciones de la presente especificación.

La Figura 9 representa un ejemplo de mensajes que se comunican entre los nodos de red de un sistema distribuido de acuerdo con implementaciones de la presente especificación.

La Figura 10 representa un ejemplo de un proceso para realizar un proceso de recuperación de un nodo de red en un sistema distribuido de acuerdo con implementaciones de la presente especificación.

La Figura 11 representa un ejemplo de un proceso de realización de un proceso de recuperación de un nodo de red en un sistema distribuido de acuerdo con implementaciones de la presente especificación.

La Figura 12 representa un ejemplo de mensajes que se comunican entre nodos de red de un sistema distribuido de acuerdo con implementaciones de la presente especificación.

La Figura 13 representa un ejemplo de un diagrama que ilustra módulos de un aparato de consenso, de acuerdo con una implementación de la presente especificación.

La Figura 14 representa un ejemplo de un diagrama que ilustra módulos de un aparato de consenso, de acuerdo con una implementación de la presente especificación.

La Figura 15 representa un ejemplo de un diagrama que ilustra módulos de un aparato de cambio de nodo primario, de acuerdo con una implementación de la presente especificación.

La Figura 16 representa un ejemplo de un diagrama que ilustra módulos de un aparato de cambio de nodo primario, de acuerdo con una implementación de la presente especificación.

La Figura 17 representa un ejemplo de un diagrama que ilustra módulos de un aparato de recuperación, de acuerdo con una implementación de la presente especificación.

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

Descripción detallada

Las implementaciones de la presente especificación incluyen métodos que se implementan mediante ordenador para abordar problemas de consenso en un sistema distribuido (por ejemplo, una red de cadena de bloques). Más particularmente, las implementaciones de la presente especificación se dirigen a realizar un proceso de recuperación para un nodo de red en un sistema distribuido.

Para proporcionar un contexto adicional para las implementaciones de la presente especificación, y como se introdujo anteriormente, los sistemas de registro distribuido (DLS), que también pueden denominarse redes de consenso (por ejemplo, compuestas por nodos de igual a igual) o redes de cadena de bloques, habilitan entidades participantes para realizar transacciones de forma segura e inmutable y almacenar datos. El término cadena de bloques se usa en la presente descripción para referirse generalmente a un DLS sin referencia a ningún caso de uso particular. Como se presentó anteriormente, una red de cadena de bloques puede proporcionarse como una red de cadena de bloques pública, una red de cadena de bloques privada o una red de cadena de bloques de consorcio.

Una cadena de bloques es una estructura de datos que almacena transacciones de una manera que permite verificar la coherencia de las transacciones futuras con todas las transacciones anteriores almacenadas en la cadena. Una cadena de bloques incluye uno o más bloques. Cada bloque de la cadena se vincula a un bloque anterior inmediatamente antes de él en la cadena mediante la inclusión de un hash criptográfico del bloque anterior. Cada bloque también incluye una marca de tiempo, su propio hash criptográfico y una o más transacciones. Las transacciones, que ya se han verificado por los nodos de red de cadena de bloques, se procesan con un hash y se codifican en un árbol Merkle. Un árbol Merkle es una estructura de datos en la que los datos en los nodos hojas del árbol se procesan con un hash y todos los hashes de cada rama del árbol se concatenan en la raíz de la rama. Este proceso continúa subiendo por el árbol hasta la raíz de todo el árbol, que almacena un hash que es representativo de todos los datos del árbol. Un hash que pretende ser de una transacción almacenada en el árbol puede verificarse rápidamente determinando si es consistente con la estructura del árbol.

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

En una red de cadena de bloques pública, el proceso de consenso se controla mediante nodos de red de consenso. Por ejemplo, cientos, miles, incluso millones de entidades pueden cooperar en una red de cadena de bloques pública, cada una de las cuales opera al menos un nodo en la red de cadena de bloques pública. En consecuencia, la red de cadena de bloques pública puede considerarse una red pública con respecto a las entidades participantes. En algunos ejemplos, la mayoría de las entidades (nodos) deben firmar cada bloque para que el bloque sea válido y se agregue a la cadena de bloques (registro distribuido) de la red de cadena de bloques. Las redes públicas de cadena de bloques de ejemplo incluyen redes de pago particulares de igual a igual que aprovechan un registro distribuido, que se denomina cadena de bloques. Como se señaló anteriormente, el término cadena de bloques, sin embargo, se usa para referirse generalmente a registros distribuidos sin una referencia particular a ninguna red de cadena de bloques en particular.

En general, una red de cadena de bloques pública admite transacciones públicas. Una transacción pública se comparte con todos los nodos dentro de la red de cadena de bloques pública y se almacena en una cadena de bloques global. Una cadena de bloques global es una cadena de bloques que 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 global. Para lograr un consenso (por ejemplo, un acuerdo para la adición de un bloque a una cadena de bloques), se implementa un protocolo de consenso dentro de la red pública de la cadena de bloques. Los ejemplos de protocolos de consenso incluyen, sin limitación, prueba de trabajo (POW), prueba de participación (POS) y prueba de autoridad (POA). En la presente descripción se hace referencia a POW como un ejemplo no limitativo.

En general, se proporciona una red de cadena de bloques privada para una entidad en particular, que controla de forma centralizada los permisos de lectura y escritura. La entidad controla qué nodos pueden participar en la red de cadena de bloques, por lo tanto, las redes de cadena de bloques privadas generalmente se denominan redes autorizadas que imponen restricciones sobre quién puede participar en la red y sobre su nivel de participación (por ejemplo, solo en ciertas transacciones). Pueden usarse diferentes tipos de mecanismos de control de acceso (por ejemplo, los participantes existentes votan sobre la adición de nuevas entidades, una autoridad reguladora puede controlar la admisión).

En general, una red de cadena de bloques de consorcio es privada entre las entidades participantes. En una red de cadena de bloques de consorcio, el proceso de consenso se controla mediante un conjunto autorizado de nodos, uno o más nodos se operan mediante una entidad respectiva (por ejemplo, una institución financiera, una compañía de seguros). Por ejemplo, un consorcio de diez (10) entidades (por ejemplo, instituciones financieras, compañías de seguros) puede operar una red de cadena de bloques de consorcio, cada una de las cuales opera al menos un nodo en la red de cadena de bloques del consorcio. En consecuencia, la red de cadena de bloques del consorcio puede considerarse una red privada con respecto a las entidades participantes. En algunos ejemplos, cada entidad (nodo) debe firmar cada bloque 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) (por ejemplo, al menos 7 entidades) debe firmar cada bloque para que el bloque sea válido y se agregue a la cadena de bloques.

Las implementaciones de la presente especificación se describen con más detalle en la presente descripción con referencia a una red de cadena de bloques de consorcio. Sin embargo, se contempla que las implementaciones de la presente especificación puedan realizarse en cualquier tipo apropiado de red de cadena de bloques.

Las implementaciones de la presente especificación se describen con más detalle en la presente descripción en vista del contexto anterior. Más particularmente, y como se introdujo anteriormente, las implementaciones de la presente especificación se dirigen a realizar un proceso de recuperación para un nodo de red en un sistema distribuido.

Una cadena de bloques es un registro digital compartido a prueba de manipulaciones que registra transacciones en una red pública o privada de igual a igual. El registro se distribuye a todos los nodos miembros de la red y el historial de transacciones de activos que ocurren en la red se registra permanentemente en el bloque.

Los mecanismos de consenso garantizan que todos los nodos de red en una red de cadena de bloques distribuida ejecuten transacciones en el mismo orden y luego escriban en los mismos registros. Un problema que los modelos de consenso pretenden abordar es superar las fallas bizantinas. En una falla bizantina, un componente como un servidor o un nodo de red de una red de cadena de bloques distribuida puede aparecer de manera inconsistente como fallado y funcionando para los sistemas de detección de fallas, al presentar diferentes síntomas para diferentes observadores. Es difícil para los otros nodos de red declarar que falló y sacarlo de la red, porque primero necesitan llegar a un consenso sobre qué nodo de red ha fallado en primer lugar.

En el contexto de los sistemas distribuidos, la tolerancia a fallas bizantinas (BFT) es la capacidad de una red informática distribuida para funcionar como se desea y alcanzar correctamente un consenso suficiente a pesar de que los componentes maliciosos (es decir, los nodos de red de una red de cadena de bloques) del sistema fallan o propagan información incorrecta a otros pares. El objetivo es defenderse contra fallas catastróficas del sistema al mitigar la influencia que estos nodos maliciosos tienen en el correcto funcionamiento de la red y el consenso correcto que alcanzan los nodos honestos en el sistema.

Sin embargo, los mecanismos existentes de BFT han demostrado ser ineficaces en muchos aspectos. Por ejemplo, los mecanismos BFT existentes han agregado complejidad de implementación a la red de cadena de bloques distribuida cuando se intenta superar las fallas bizantinas, de manera que se incrementa la latencia para la comunicación entre los nodos de red de la red de cadena de bloques distribuida. La tolerancia práctica a fallos bizantinos (PBFT) es una de las optimizaciones que tiene como objetivo mejorar los mecanismos de consenso BFT existentes. El modelo PBFT se enfoca en proporcionar una replicación práctica de la máquina de estado bizantina que tolera fallas bizantinas (nodos maliciosos) mediante la suposición de que hay fallas de nodos independientes y mensajes manipulados que se propagan por nodos específicos e independientes.

En el modelo PBFT, todos los nodos se ordenan en una secuencia, siendo un nodo el nodo primario (líder) y los otros se denominan nodos de respaldo. Todos los nodos dentro del sistema se comunican entre sí y el objetivo es que la mayoría de los nodos honestos lleguen a un acuerdo sobre el estado del sistema. Los nodos se comunican entre sí y no solo tienen que demostrar que los mensajes provienen de un nodo par específico, sino que también deben verificar que el mensaje no se modificó durante la transmisión.

Para que el modelo PBFT funcione, se asume que la cantidad de nodos maliciosos en la red no puede igualar o exceder simultáneamente 1/3 del total de nodos del sistema en una ventana de vulnerabilidad dada. Cuantos más nodos haya en el sistema, más improbable matemáticamente es que un número cercano a 1/3 del total de nodos sea malicioso. El algoritmo proporciona de manera efectiva tanto vitalidad como seguridad siempre que como máximo (n-1)/3 nodos sean maliciosos o defectuosos al mismo tiempo, donde n representa el total de nodos.

Cada ronda de consenso PBFT (llamadas vistas) incluye 4 fases:

(1) Un cliente envía una solicitud al nodo líder para invocar una operación de servicio;

(2) El nodo líder transmite la solicitud a los nodos de respaldo;

(3) Los nodos ejecutan la solicitud y luego envían una respuesta al cliente; y

(4) El cliente espera f+1 (f representa el número máximo de nodos que pueden estar defectuosos) respuestas de diferentes nodos con el mismo resultado.

El resultado final es que todos los nodos honestos llegan a un acuerdo sobre el orden del registro y lo aceptan o lo rechazan. El nodo líder se cambia en un esquema de turno rotativo durante cada vista e incluso puede reemplazarse con un protocolo que se llama cambio de vista si ha pasado una cantidad de tiempo específica sin que el nodo líder transmita la solicitud. La mayoría de los nodos honestos también pueden decidir si un líder es defectuoso y eliminarlo con el siguiente líder en la fila como reemplazo.

Sin embargo, existen algunas limitaciones para el mecanismo de consenso PBFT. Por ejemplo, el modelo PBFT puede funcionar bien en su forma clásica con tamaños de grupo de consenso relativamente pequeños debido a la gran cantidad de comunicación que se requiere entre los nodos. Los grandes bloques de datos que se transmiten entre los nodos de red provocan un problema de carga de la red y provocan un cuello de botella en la red. Además, el uso de códigos de autenticación de método (MAC) como formato para los mensajes de autenticación en el modelo PBFT puede ser ineficaz con la cantidad de comunicación necesaria entre los nodos en grandes grupos de consenso, tales como las redes de criptomonedas y con MAC. Podría haber una incapacidad inherente para demostrar la autenticidad de los mensajes a un tercero.

Además, encontrar nodos maliciosos consecutivos al cambiar el nodo líder mediante el uso de un método de turno rotativo que usa PBFT afecta el servicio de cadena de bloques al introducir latencia o retraso en la búsqueda de un nodo líder que sea honesto. Por ejemplo, cuando se selecciona un primer nodo de red como nuevo nodo líder, el primer nodo de red puede ser un nodo malicioso, por lo que no puede seleccionarse como el nuevo nodo líder. En un método de turno rotativo, puede seleccionarse un segundo nodo de red en línea como el nuevo nodo líder. Sin embargo, si el segundo nodo de red también es un nodo malicioso, se verificará si otro nodo de red en línea es adecuado para ser el nodo líder. Este proceso continúa hasta que se identifique un nuevo nodo líder que sea honesto. Un cambio tan frecuente del nodo líder introduce una latencia significativa en los servicios de cadena de bloques.

Además, los nodos de red en una red de cadena de bloques pueden experimentar fallas bizantinas o fallas por colisión en cualquier momento. Por ejemplo, un nodo de red puede verse comprometido por un atacante cibernético malintencionado y comportarse de manera incorrecta. Si los nodos de red que se comprometen no se recuperan rápidamente, el atacante cibernético malintencionado puede poner en peligro la red y los servicios de la cadena de bloques al corromper más de 1/3 de los nodos de red sin ser detectado.

Para abordar los problemas y preocupaciones descritos anteriormente que se asocian con los mecanismos de consenso de BFT existentes y el mecanismo de consenso de PBFT, la presente especificación describe mecanismos de consenso mejorados que incluyen técnicas para lograr el consenso entre los nodos de red en un sistema distribuido, realizar un cambio de nodo primario en un sistema distribuido y realizar un proceso de recuperación para un nodo de red en un sistema distribuido. Los mecanismos de consenso descritos pueden lograr diferentes ventajas en diferentes aplicaciones.

Además, la presente especificación describe un proceso de cambio de época que incluye asignar pesos respectivos a múltiples fases del proceso de consenso, determinar una suma de pesos en base a los pesos respectivos de las múltiples fases y determinar un nuevo nodo primario en base a la suma de pesos. El proceso de cambio de época que se basa en la suma de pesos en lugar de un método de turno rotativo puede facilitar la elección de un nuevo nodo primario que no tenga fallas de manera oportuna. Un nodo primario puede ser un nodo líder que tiene la autoridad para iniciar una ronda de proceso de consenso entre un número de nodos de red, que incluye al nodo primario. Los otros nodos de red de la red de cadena de bloques pueden denominarse nodos de respaldo. El proceso de cambio de época puede ayudar a abordar el problema del método de turno rotativo que causa un cambio frecuente de nodo primario cuando múltiples nodos de red en línea para el nuevo nodo primario tienen fallas. A diferencia del método de turno rotativo, el proceso de cambio de época en la presente especificación se basa en la suma de pesos para seleccionar el nuevo nodo primario, lo que puede reducir la latencia o la demora en la búsqueda del nuevo nodo primario que no esté defectuoso. Esto puede mejorar aún más la eficiencia del sistema de cadena de bloques en general al proporcionar los servicios de cadena de bloques.

La Figura 1 representa un ejemplo de un entorno 100 que puede usarse para ejecutar implementaciones de la presente especificación. En algunos ejemplos, el entorno 100 permite a las entidades participar en una red de cadena de bloques 102 de consorcio. El entorno 100 incluye dispositivos o sistemas informáticos 106, 108 y una red 110. En algunos ejemplos, la red 110 incluye una red de área local (LAN), una red de área amplia (WAN), Internet o una combinación de las mismas, y conecta sitios web, dispositivos de usuario (por ejemplo, dispositivos informáticos) y sistemas back-end. En algunos ejemplos, puede accederse a la red 110 a través de un enlace de comunicaciones por cable y/o inalámbrico. En algunos ejemplos, la red 110 permite la comunicación con y dentro de la red de cadena de bloques 102 de consorcio. En general, la red 110 representa una o más redes de comunicación. En algunos casos, los dispositivos informáticos 106, 108 pueden ser nodos de un sistema informático en la nube (no se muestra), o cada dispositivo informático 106, 108 puede ser un sistema informático en la nube independiente que incluye una pluralidad de ordenadores interconectados mediante una red y que funciona como un sistema de procesamiento distribuido.

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

La Figura 2 representa un ejemplo de una arquitectura conceptual 200 de acuerdo con implementaciones de la presente especificación. El ejemplo de una arquitectura conceptual 200 incluye los sistemas participantes 202, 204, 206 que corresponden al Participante A, Participante B y Participante C, respectivamente. Cada participante (por ejemplo, usuario, empresa) participa en una red de cadena de bloques 212 que se proporciona como una red de igual a igual que incluye una pluralidad de nodos 214, al menos algunos de los cuales registran información de manera inmutable en una cadena de bloques 216. Aunque una única cadena de bloques 216 se representa esquemáticamente dentro de la red de cadena de bloques 212, se proporcionan múltiples copias de la cadena de bloques 216 y se mantienen a través de la red de cadenas de bloques 212, como se describe con más detalle en la presente descripción.

En el ejemplo representado, cada sistema participante 202, 204, 206 se proporciona mediante, o en nombre del Participante A, Participante B y Participante C, respectivamente, y funciona como un nodo 214 respectivo dentro de la red de cadena de bloques. Como se usa en la presente descripción, un nodo generalmente se refiere a un sistema individual (por ejemplo, un ordenador, un servidor) que se conecta a la red de cadena de bloques 212 y permite que un participante respectivo participe en la red de cadena de bloques. En el ejemplo de la Figura 2, un participante corresponde a cada nodo 214. Sin embargo, se contempla que un participante pueda operar múltiples nodos 214 dentro de la red de cadena de bloques 212, y/o múltiples participantes puedan compartir un nodo 214. En algunos ejemplos, los sistemas participantes 202, 204, 206 se comunican con, o a través de, la red de cadena de bloques 212 mediante el uso de un protocolo (por ejemplo, protocolo de transferencia de hipertexto seguro (HTTPS)) y/o mediante el uso de llamadas de procedimiento remoto (RPC).

Los nodos 214 pueden tener diversos grados de participación dentro de la red de cadena de bloques 212. Por ejemplo, algunos nodos 214 pueden participar en el proceso de consenso (por ejemplo, como nodos cuidadores que agregan bloques a la cadena de bloques 216), mientras que otros nodos 214 no participan en el proceso de consenso. Como otro ejemplo, algunos nodos 214 almacenan una copia completa de la cadena de bloques 216, mientras que otros nodos 214 solo almacenan copias de porciones de la cadena de bloques 216. Por ejemplo, los privilegios de acceso a datos pueden limitar los datos de la cadena de bloques que un participante respectivo almacena dentro de su sistema respectivo. En el ejemplo de la Figura 2, los sistemas participantes 202, 204, 206 almacenan copias completas 216', 216”, 216'” respectivas de la cadena de bloques 216.

Una cadena de bloques (por ejemplo, la cadena de bloques 216 de la Figura 2) se forma por una cadena de bloques, cada bloque almacena datos. Los ejemplos de datos incluyen datos de transacciones representativos de una transacción entre dos o más participantes. Si bien las transacciones se usan en la presente descripción a modo de ejemplo no limitativo, se contempla que cualquier dato apropiado pueda almacenarse en una cadena de bloques (por ejemplo, documentos, imágenes, videos, audio). Los ejemplos de transacciones pueden incluir, sin limitación, intercambios de algo de valor (por ejemplo, activos, productos, servicios y moneda). Los datos de la transacción se almacenan de forma inmutable dentro de la cadena de bloques. Es decir, los datos de la transacción no pueden cambiarse.

Antes de almacenar en un bloque, los datos de la transacción se procesan con un hash. El hashing es un proceso de transformación de los datos de la transacción (que se proporcionan como datos de cadena) en un valor hash de longitud fija (que también se proporciona como datos de cadena). No es posible eliminar el hash del valor hash para obtener los datos de la transacción. El hashing asegura que incluso un pequeño cambio en los datos de la transacción da como resultado un valor hash completamente diferente. Además, y como se indicó anteriormente, el valor hash es de longitud fija. Es decir, no importa el tamaño de los datos de la transacción, la longitud del valor hash es fija. El hashing incluye procesar los datos de la transacción a través de una función hash para generar el valor hash. Un ejemplo de función hash incluye, sin limitación, el algoritmo hash seguro (SHA)-256, que genera valores hash de 256 bits.

Los datos de transacciones de múltiples transacciones se procesan con un hash y se almacenan en un bloque. Por ejemplo, se proporcionan valores hash de dos transacciones y ellos mismos se procesan con un hash para proporcionar otro hash. Este proceso se repite hasta que se proporciona un único valor hash, para que todas las transacciones se almacenen en un bloque. Este valor hash se conoce como hash raíz de Merkle y se almacena en un encabezado del bloque. Un cambio en cualquiera de las transacciones dará como resultado un cambio en su valor hash y, en última instancia, un cambio en el hash raíz de Merkle.

Los bloques se agregan a la cadena de bloques a través de un protocolo de consenso. Múltiples nodos dentro de la red de cadena de bloques participan en el protocolo de consenso y compiten para que se agregue un bloque a la cadena de bloques. Dichos nodos se conocen como mineros (o nodos cuidadores). La POW, presentado anteriormente, se usa como ejemplo no limitativo.

Los nodos mineros ejecutan el proceso de consenso para agregar transacciones a la cadena de bloques. Aunque múltiples nodos mineros participan en el proceso de consenso, solo un nodo minero puede escribir el bloque en la cadena de bloques. Es decir, los nodos mineros compiten en el proceso de consenso para que su bloque se agregue a la cadena de bloques. Más detalladamente, un nodo minero recopila periódicamente transacciones pendientes de un grupo de transacciones (por ejemplo, hasta un límite predefinido en el número de transacciones que pueden incluirse en un bloque, si las hay). El grupo de transacciones incluye mensajes de transacciones de los participantes en la red de cadena de bloques. El nodo minero construye un bloque y agrega las transacciones al bloque. Antes de agregar las transacciones al bloque, el nodo minero verifica si alguna de las transacciones ya se incluyó en un bloque de la cadena de bloques. Si una transacción ya se incluyó en otro bloque, la transacción se descarta.

El nodo minero genera un encabezado de bloque, aplica un hash a todas las transacciones en el bloque y combina el valor hash en pares para generar más valores hash hasta que se proporciona un solo valor hash para todas las transacciones en el bloque (el hash raíz de Merkle). Este hash se agrega al encabezado del bloque. El minero también determina el valor hash del bloque más reciente en la cadena de bloques (es decir, el último bloque que se agrega a la cadena de bloques). El nodo minero también agrega un valor nonce y una marca de tiempo al encabezado del bloque. En un proceso de minería, el nodo minero intenta encontrar un valor hash que cumpla con los parámetros requeridos. El nodo minero sigue cambiando el valor nonce hasta encontrar un valor hash que cumpla con los parámetros requeridos.

Cada minero en la red de cadena de bloques intenta encontrar un valor hash que cumpla con los parámetros requeridos y, de esta manera, compiten entre sí. Finalmente, uno de los nodos mineros encuentra un valor hash que cumple con los parámetros requeridos y lo anuncia a todos los demás nodos mineros en la red de cadena de bloques. Los otros nodos mineros verifican el valor hash y, si se determina que es correcto, verifican cada transacción en el bloque, aceptan el bloque y agregan el bloque a su copia de la cadena de bloques. De esta manera, un estado global de la cadena de bloques es consistente en todos los nodos mineros dentro de la red de cadena de bloques. El proceso descrito anteriormente es el protocolo de consenso de POW.

Se proporciona un ejemplo no limitativo con referencia a la Figura 2. En este ejemplo, el participante A desea enviar una cantidad de fondos al participante B. El participante A genera un mensaje de transacción (por ejemplo, que incluye los campos De, Para y Valor) y envía el mensaje de transacción a la red de cadena de bloques, que agrega el mensaje de transacción a un grupo de transacciones. Cada nodo minero en la red de cadena de bloques crea un bloque y toma todas las transacciones del grupo de transacciones (por ejemplo, hasta un límite predefinido en el número de transacciones que pueden agregarse a un bloque, si las hay), y agrega las transacciones al bloque. De esta manera, la transacción que publica el Participante A se agrega a los bloques de los nodos mineros.

En algunas redes de cadena de bloques, la criptografía se implementa para mantener la privacidad de las transacciones. Por ejemplo, si dos nodos quieren mantener una transacción privada, de manera que otros nodos de red de cadena de bloques no puedan discernir los detalles de la transacción, los nodos pueden cifrar los datos de la transacción. Los ejemplos de métodos criptográficos incluyen, sin limitación, cifrado simétrico y cifrado asimétrico. El cifrado simétrico se refiere a un proceso de cifrado que usa una única clave tanto para el cifrado (generar texto cifrado a partir del texto llano) como para el descifrado (generar texto llano a partir del texto cifrado). En el cifrado simétrico, la misma clave se dispone para múltiples nodos, por lo que cada nodo puede cifrar/descifrar datos de transacciones.

El cifrado asimétrico usa pares de claves que cada uno incluye una clave privada y una clave pública, la clave privada la conoce solo un nodo respectivo y la clave pública la conoce cualquiera o todos los demás nodos de red de cadena de bloques. Un nodo puede usar la clave pública de otro nodo para cifrar datos, y los datos cifrados pueden descifrarse mediante el uso de la clave privada de otro nodo. Por ejemplo, y refiriéndonos de nuevo a la Figura 2, el participante A puede usar la clave pública del participante B para cifrar los datos y enviar los datos cifrados al participante B. El participante B puede usar su clave privada para descifrar los datos cifrados (texto cifrado) y extraer los datos originales (texto llano). Los mensajes cifrados con la clave pública de un nodo solo se pueden descifrar mediante el uso de la clave privada del nodo.

El cifrado asimétrico se usa para proporcionar firmas digitales, lo que permite a los participantes de una transacción confirmar a otros participantes en la transacción, así como la validez de la transacción. Por ejemplo, un nodo puede firmar digitalmente un mensaje y otro nodo puede confirmar que el mensaje fue enviado por el nodo basándose en la firma digital del Participante A. Las firmas digitales también pueden usarse para garantizar que los mensajes no sean manipulados en el tránsito. Por ejemplo, y nuevamente haciendo referencia a la Figura 2, el participante A debe enviar un mensaje al participante B. El participante A genera un hash del mensaje y luego, mediante el uso de su clave privada, cifra el hash para proporcionar una firma digital como el hash cifrado. El participante A agrega la firma digital al mensaje y envía el mensaje con firma digital al participante B. El participante B descifra la firma digital mediante el uso de la clave pública del participante A y extrae el hash. El participante B procesa el mensaje y compara los valores hash. Si los valores hash son los mismos, el participante B puede confirmar que el mensaje fue realmente del participante A y que no se manipuló.

La Figura 3 representa un ejemplo de un proceso 300 para lograr consenso entre los nodos de red (por ejemplo, el nodo 214) de un sistema distribuido (por ejemplo, la red de cadena de bloques 102 y 212) que puede ejecutarse de acuerdo con las implementaciones de la presente especificación. Específicamente, la Figura 3 ilustra un diagrama que presenta una modalidad ejemplar de un método 300 para lograr consenso en un caso normal, de acuerdo con la presente especificación. Como se ilustra en la Figura 3, el proceso de consenso 300 incluye tres fases o etapas 310, 320 y 330 como se describe a continuación.

En una primera fase 310 del proceso de consenso 300, un nodo primario (o un nodo líder) de la red de cadena de bloques envía un primer mensaje a los otros nodos de red (es decir, los nodos de respaldo). El primer mensaje indica que el nodo primario está iniciando un proceso de consenso. Por ejemplo, como se ilustra en la Figura 3, el nodo primario Ro envía un mensaje INITIAL a otros nodos de red Rb, R2 y R3 en la red de cadena de bloques. Obsérvese que el proceso 300 se ilustra incluyendo cuatro nodos de red Ro, Ri, R2 y R3 sólo con fines ilustrativos, el proceso 300 puede incluir cualquier número adecuado de nodos de red. La primera fase y un formato del mensaje INITIAL se discutirán a continuación en mayor detalle con referencia a las Figuras 4-6.

En una segunda fase 320 del proceso de consenso 300, cada uno de los nodos de respaldo recibe el primer mensaje que envía el nodo primario, prepara un segundo mensaje en respuesta al primer mensaje y transmite el segundo mensaje al otro nodo de red. El segundo mensaje indica que el nodo de respaldo ha recibido el primer mensaje del nodo primario y está enviando una respuesta en respuesta al primer mensaje. Por ejemplo, como se ilustra en la Figura 3, el nodo de respaldo Ri recibe el mensaje INITIAL que envía el nodo primario Ro, y responde al nodo primario Ro con un mensaje ECHO como ejemplo del segundo mensaje. Mientras tanto, el nodo de respaldo Ri también transmite el mensaje ECHO a los otros nodos de respaldo, como los nodos de respaldo R2 y R3. De manera similar, el nodo de respaldo R2 y R3 difunden cada uno un mensaje ECHO a los otros nodos de red, que incluye el nodo primario Ro.

Cuando un nodo de red, por ejemplo, como un nodo primario o un nodo de respaldo, recibe los mensajes ECHO de los otros nodos de red, el nodo de red puede verificar la información en los mensajes ECHO. La segunda fase y un formato del mensaje ECHO se discutirán a continuación en mayor detalle con referencia a las Figuras 4-6.

En una tercera fase 330 del proceso de consenso 300, cada uno de los nodos de red transmite un tercer mensaje a los otros nodos de red. El tercer mensaje indica que un nodo de red ha aceptado un número predeterminado de segundos mensajes. En algunas implementaciones, el tercer mensaje puede indicar que el nodo de red está listo para ejecutar la transacción. En algunas implementaciones, el tercer mensaje puede indicar que la transacción se ha reconstruido con éxito en el nodo de red. Por ejemplo, como se ilustra en la Figura 3, el nodo primario Ro transmite un mensaje ACCEPT a los nodos de respaldo Ri, R2 y R3. De manera similar, los nodos de respaldo Ri, R2 y R2 transmiten un mensaje ACCEPT a los demás nodos de red. En algunas implementaciones de la presente especificación, antes de transmitir el mensaje ACCEPT, un nodo de red determina si ACCEPT se envía de acuerdo con un código de borrado (EC) y la información en los mensajes ECHO es la que se recibe en la segunda fase. La tercera fase, el código EC y un formato del mensaje ACCEPT se discutirán a continuación en mayor detalle con referencia a las Figuras 4-6.

Cuando un nodo de red recibe suficientes mensajes ACCEPT de los otros nodos de red, el nodo de red determina que se ha logrado un consenso. Por ejemplo, si el nodo primario Ro o los nodos de respaldo Rb, R2 o R3 reciben un número de quórum (por ejemplo, 2f+l, donde f representa un número de nodos de red defectuosos) de mensajes ACCEPT, se logra un consenso automáticamente entre los nodos de red.

La Figura 4 representa un ejemplo de un proceso 400 para lograr consenso entre los nodos de red (por ejemplo, el nodo 214 o los nodos Ro, Ri, R2 y R3) de un sistema de distribución (por ejemplo, la red de cadena de bloques 102 o 212) que puede ejecutarse de acuerdo con implementaciones de la presente especificación. En algunas implementaciones, el proceso 400 puede realizarse mediante el uso de uno o más programas ejecutables por ordenador que se ejecutan mediante el uso de uno o más dispositivos informáticos. Para claridad de la presentación, la descripción que sigue generalmente describe el método 400 en el contexto de las otras figuras en esta descripción. Se entenderá que el método 400 puede llevarse a cabo, por ejemplo, mediante cualquier sistema, entorno, software y hardware adecuado, o una combinación de sistemas, entornos, software y hardware, según sea apropiado. En algunas implementaciones, pueden ejecutarse diferentes etapas del método 400 en paralelo, en combinación, en bucles o en cualquier orden.

Al principio, el proceso 400 puede implementarse junto con el sistema 100-300 como se ilustra en las Figuras 1-3. En algunas implementaciones de la presente especificación, la red de cadena de bloques 102 y/o 212 incluye un nodo primario 404 y uno o más nodos de respaldo 406. La red de cadena de bloques 102 y/o 212 se comunica con el sistema informático 106 y/o 108, tal como los nodos de cliente 402 a través de la red 110 para proporcionar servicios de cadena de bloques. Cada uno del nodo cliente 402, el nodo primario 404 y el nodo de respaldo 406 puede ser un ordenador de propósito especial u otro aparato de procesamiento de datos que se configura para realizar los procesos descritos en la presente descripción. Por ejemplo, el nodo cliente 402 también puede denominarse terminal cliente o dispositivo cliente que interactúa con una red de cadena de bloques. El nodo cliente 402 puede instalar, por ejemplo, una aplicación cliente o un kit de desarrollo de software cliente (SDK) en conexión con la red de cadena de bloques para acceder y comunicarse con la red de cadena de bloques. El nodo primario 404 y uno o más nodos de respaldo 406 también pueden denominarse nodos de consenso o nodos de red que logran consenso y registran información de manera inmutable en la red de cadena de bloques.

El proceso 400 comienza en 408 donde el nodo cliente 402 genera una solicitud de transacción. En algunas implementaciones de la presente especificación, la solicitud de transacción puede incluir una solicitud que solicita un servicio de cadena de bloques de la red de cadena de bloques 102 y/o 212.

En 410, el nodo cliente 402 transmite la solicitud de transacción al nodo primario 404 de la red de cadena de bloques 102 y/o 212. En algunas implementaciones de la presente especificación, el nodo primario 404 asigna un número de secuencia a la solicitud de transacción para realizar un seguimiento de las solicitudes de transacción después de recibir la solicitud de transacción del nodo cliente 402.

En 412, el nodo primario 402 genera un número de bloques EC después de recibir la solicitud de transacción del nodo cliente 402. En algunas implementaciones de la presente especificación, el nodo primario 404 genera el número de bloques EC de acuerdo con un código EC mediante el uso de la solicitud de transacción. Por ejemplo, haciendo referencia a la Figura 5, el nodo primario 404 aplica un código EC 504 en una solicitud de transacción 502 y transforma la solicitud de transacción 502 en un mensaje EC 506 mediante el uso del código EC 504. El código EC 504 es un código de corrección de errores en recepción (FEC) bajo el supuesto de borrado de bits. El código EC 504 transforma la solicitud de transacción original 502 en un mensaje EC más largo 506 de manera que la solicitud de transacción original 502 puede recuperarse de una porción o un fragmento del mensaje EC 506.

En algunas implementaciones de la presente especificación, el código EC 504 es un código de borrado casi óptimo, tal como un código Tornado o un código de verificación de paridad de baja densidad. En implementaciones alternativas de la presente especificación, el código EC 504 es un código fuente casi óptimo, tal como un código fuente, un código en línea, un código de transformación Luby (LT) o un código raptor. En implementaciones alternativas de la presente especificación, el código EC 504 es un código de borrado óptimo, tal como un código de paridad, un código Parchive, un código Reed-Solomon o un código regenerativo. En algunas implementaciones de la presente especificación, el código EC 504 puede ser cualquier tipo adecuado de código de borrado.

Después de transformar la solicitud de transacción 502 en el mensaje EC 506, el nodo primario 404 genera un número de bloques EC 508 mediante el uso del mensaje EC 506. Por ejemplo, como se ilustra en la Figura 5, el nodo primario 404 genera cuatro bloques EC 508, bloque EC A, bloque EC B, bloque EC C y bloque EC D al dividir el mensaje EC 506. Nótese que los bloques EC 508 se ilustran en la Figura 5 como que incluyen cuatro bloques con fines ilustrativos, los bloques EC 508 pueden generarse incluyendo cualquier número adecuado de bloques EC 508. Los bloques EC 508 se enviarán a los respectivos nodos de respaldo 406 dentro de los mensajes INITIAl .

En algunas implementaciones de la presente especificación, los bloques EC 508 tienen el mismo tamaño. Sin embargo, en implementaciones alternativas, los bloques EC 508 pueden tener tamaños que son diferentes entre sí.

En algunas implementaciones de la presente especificación, el nodo primario 404 genera un árbol hash 500 (por ejemplo, un árbol Merkle) mediante el uso de los bloques EC 508. El árbol hash 500 incluye un número de nodos hoja que se etiquetan con el hash de los bloques de datos y un número de nodos que no son hojas que se etiquetan con el hash criptográfico de las etiquetas de sus nodos hijos. Por ejemplo, como se ilustra en la Figura 5, el árbol hash 500 se configura para incluir cuatro nodos hoja 510, hash A, hash B, hash C y hash D que se generan como un hash criptográfico de sus respectivos bloques EC 508, cuatro nodos no hoja 512 que se generan como un hash de la concatenación de sus respectivos nodos hijos 510, y un nodo no hoja 514 que se genera como un hash de sus nodos hijos 512 y es un hash raíz del árbol hash 500.

El árbol hash 500 permite una verificación eficiente y segura del contenido de grandes estructuras de datos. El árbol hash 500 puede usarse para verificar cualquier tipo de datos que se almacena, maneja y transfiere dentro y entre ordenadores. Pueden ayudar a garantizar que los bloques de datos que se reciben de otros pares en una red P2P se reciban sin daños ni alteraciones, e incluso para verificar que los otros pares no envíen bloques falsos. La verificación de bloques de datos mediante el uso del árbol hash 500 se discutirá a continuación en mayor detalle con referencia a las siguientes etapas del proceso de consenso 400.

Volviendo a la Figura 4, el nodo primario 404 genera un primer mensaje (por ejemplo, un mensaje INITIAL) después de generar los bloques EC 508 y el árbol hash 500. El primer mensaje indica que el nodo primario está iniciando un proceso de consenso. En algunas implementaciones, el mensaje INITIAL, como un ejemplo del primer mensaje, se genera mediante el uso de la información en los bloques EC 508 y el árbol hash 500. En algunas implementaciones de la presente especificación, con referencia a la Figura 6, el mensaje INITIAL tiene un formato de <época, tx_root_hash, ec_block_hash, ec_block, seq, j>, donde "época" representa una ronda de consenso en la que se envía el mensaje, "tx root hash" representa el hash raíz 514 en el árbol hash 500, "ec block hash" representa los hash 510 y/o 512 en el árbol hash 500, "ec block" representa los bloques EC 508 en el árbol hash 500, "seq" representa el número de secuencia que se asocia con la solicitud de transacción 502, y "j" representa el nodo de red que genera y envía el mensaje INITIAL. En algunas implementaciones, el mensaje INITIAL puede tener un formato diferente, por ejemplo, al incluir campos adicionales o diferentes.

Volviendo a la Figura 4, en 416, en la primera fase del proceso de consenso, el nodo primario 404 transmite el mensaje INITIAL a los otros nodos de red (por ejemplo, nodos de respaldo 406). En algunas implementaciones, los mensajes INITIAL que se envían a los nodos de respaldo 406 tienen un formato de <época, tx_root_hash, ec_block_hash, ec_block, seq, j>. Por ejemplo, el nodo primario 404 puede enviar un primer mensaje INITIAL <época 1, Hash ABCD, {Hash B, Hash C, Hash D}, bloque EC A, 1, 0> a un primer nodo de respaldo 406 y un segundo mensaje INITIAL <época 1, Hash ABCD, {Hash A, Hash C, Hash D}, bloque EC B, 1, 0> a un segundo nodo de respaldo 406, y así sucesivamente. Tenga en cuenta que la información del mensaje INITIAL, tal como "ec block" puede usarse con "ec block hash" para reconstruir el árbol hash 500. Por ejemplo, en el primer mensaje INITIAL <época 1, Hash ABCD, {Hash B, Hash C, Hash D}, bloque EC A, 1, 0>, el bloque EC 508 "bloque EC A" puede procesarse con un hash para generar un hash criptográfico 510 "Hash A", que se usa además con los otros hash 510 "{Hash B, Hash C, Hash D}" para reconstruir el árbol hash 500. El árbol hash 500 reconstruido se usará para verificar los mensajes ECHO como se describe a continuación en mayor detalle con referencia a las siguientes etapas del proceso de consenso.

En 418, cada uno de los nodos de respaldo 406 genera un segundo mensaje (por ejemplo, un mensaje ECHO) en la segunda fase del proceso de consenso después de recibir el mensaje INITIAL del nodo primario 404. El segundo mensaje indica que el nodo de respaldo ha recibido el primer mensaje del nodo primario. El segundo mensaje se envía como respuesta al primer mensaje. En algunas implementaciones de la presente especificación, el mensaje ECHO se genera mediante un nodo de respaldo 406 que incluye el mensaje INITIAL o una parte del mensaje INITIAL y una firma del nodo de respaldo 406 que se asocia con el mensaje INITIAL. Por ejemplo, el nodo de respaldo 406 puede generar la firma al firmar el mensaje INITIAL o un resumen del mensaje INITIAL mediante el uso de una clave privada. La firma de clave privada puede usarse por otros nodos de red mediante el uso de una clave pública emparejada con la clave privada para autenticar el mensaje ECHO que incluye la firma de clave privada.

En algunas implementaciones de la presente especificación, con referencia a la Figura 6, el mensaje ECHO tiene un formato de <época, tx_root_hash, ec_block_hash, ec_block, seq, sign_proof, j>, donde "época" representa una ronda de consenso en la que se envía el mensaje, "tx root hash" representa la raíz hash 514 en el árbol hash 500, "ec_block_hash" representa los hash 510 y/o 512 en el árbol hash 500, "ec_block" representa los bloques EC 508 en el árbol hash 500 que reciben los respectivos nodos de respaldo 406, "seq" representa el número de secuencia que se asocia con la solicitud de transacción 502,"sign-proof' representa la firma de los nodos de respaldo 406 que se asocian con los mensajes INITIAL, y "j" representa el nodo de red que genera y envía el mensaje ECHO. En algunas implementaciones, el mensaje ECHO puede tener un formato diferente, por ejemplo, al incluir campos adicionales o diferentes.

Volviendo a la Figura 4, en 420, los nodos de respaldo 406 envían los mensajes ECHO al nodo primario 404. En 421, cada uno de los nodos de respaldo 406 envía los mensajes ECHO a los otros nodos de respaldo 406. En 423, cada uno de los nodos de respaldo 406 puede recibir los mensajes ECHO de los otros nodos de respaldo 406.

En 422, el nodo primario 404 verifica los mensajes ECHO que envían los nodos de respaldo 406. En algunas implementaciones de la presente especificación, el nodo primario 404 verifica si los mensajes ECHO son válidos de acuerdo con el árbol hash 500. Por ejemplo, el nodo primario 404 puede recibir un primer mensaje ECHO <época 1, Hash ABCD, [Hash B, Hash C, Hash D], bloque EC A, 1, 1> desde un primer nodo de respaldo 406. El nodo primario 404 puede recuperar el bloque EC 508 "bloque EC A" del mensaje y aplicar un hash para generar un hash criptográfico 510 "Hash A". El nodo primario 404 usa además el hash 510 que se genera "Hash A" con los otros hash 510 "{Hash B, Hash C, Hash D}" en el mensaje para reconstruir el árbol hash 500. Luego, el nodo primario 404 determina el hash raíz 514 del árbol hash 500 reconstruido y lo compara con el hash raíz 514 en el mensaje ECHO, tal como, "Hash ABCD". Si los dos hashes raíz 514 coinciden, el nodo primario 404 determina que el mensaje ECHO es válido. El nodo primario 404 puede almacenar los mensajes ECHO válidos y descartar los mensajes ECHO que se determina que no son válidos.

En 424, el nodo primario 404 determina si un número de mensajes ECHO válidos excede un umbral predeterminado. En algunas implementaciones de la presente especificación, el nodo primario 404 determina si el número de mensajes ECHO válidos alcanza un número de quórum n-f o 2f+l, donde n es el número total de nodos de red y f es el número máximo de nodos defectuosos que la red puede tolerar.

En 426, el nodo primario 404 reconstruye la solicitud de transacción 502 en respuesta a la determinación de que el número de mensajes ECHO válidos alcanza el número de quórum. En algunas implementaciones de la presente especificación, el nodo primario 404 reconstruye la solicitud de transacción 502 en base al menos a un subconjunto de mensajes ECHO válidos de acuerdo con el código EC. Por ejemplo, el nodo primario 404 puede recuperar un número de n-2f o f+1 de los bloques EC 508 que están en el número de quórum (por ejemplo, n-f o 2f+l) de mensajes ECHO válidos, y usar los bloques EC recuperados 508 para reconstruir la solicitud de transacción 502 de acuerdo con el código EC 504.

En 428, en la tercera fase del proceso de consenso, el nodo primario 404 genera un tercer mensaje (por ejemplo, un mensaje ACCEPT) en respuesta a la determinación de que la solicitud de transacción 502 se ha reconstruido con éxito. El tercer mensaje indica que un nodo de red ha aceptado un número predeterminado de segundos mensajes. En algunas implementaciones, el tercer mensaje puede indicar que el nodo de red está listo para ejecutar la transacción. En algunas implementaciones, el tercer mensaje puede indicar que la transacción se ha reconstruido con éxito en el nodo de red. Por ejemplo, el mensaje ACCEPT puede usarse para indicar a otros nodos de red que la solicitud de transacción 502 se ha reconstruido con éxito. Si el nodo primario 404 no logra reconstruir la solicitud de transacción 502, el nodo primario 404 puede no generar el mensaje ACCEPT.

En algunas implementaciones de la presente especificación, con referencia a la Figura 6, el mensaje ACCEPT tiene un formato de <época, tx_root_hash, seq, sign_proofs, j>, donde “época" representa una ronda de consenso en la que se envía el mensaje, "tx root hash" representa el hash raíz 514 en el árbol hash 500, "seq" representa el número de secuencia que se asocia con la solicitud de transacción 502, "sign-proofs" representa un conjunto de firmas en los mensajes ECHO válidos y "j" representa el nodo de red que genera y envía el mensaje ACCEPT. En algunas implementaciones, el mensaje ACCEPT puede tener un formato diferente, por ejemplo, al incluir campos adicionales o diferentes.

Volviendo a la Figura 4, en 430, el nodo primario 404 envía el mensaje ACCEPT a los nodos de respaldo 406.

De manera similar al nodo primario 404, cada uno de los nodos de respaldo 406 puede reconstruir la solicitud de transacción, por ejemplo, al realizar etapas similares a las etapas 422-428 como el nodo primario 404. En 432, cada uno de los nodos de respaldo 406 genera un mensaje ACCEPT en respuesta a la determinación de que la solicitud de transacción 502 ha sido reconstruida con éxito por el nodo de respaldo 406. En algunas implementaciones, el nodo primario 404 y el nodo de respaldo 406 pueden realizar las etapas 422-428 de manera paralela, por ejemplo, como se indica en la Figura 3.

En 434, los nodos de respaldo 406 envían los mensajes ACCEPT al nodo primario 404. Mientras tanto, cada uno de los nodos de respaldo 406 puede enviar los mensajes ACCEPT a los otros nodos de respaldo 406.

En 436, el nodo primario 404 ejecuta la solicitud de transacción 502 en respuesta a la determinación de que un número de mensajes ACCEPT excede un umbral predeterminado. En algunas implementaciones de la presente especificación, el nodo primario 404 determina si los mensajes ACCEPT que se reciben son idénticos y si un número de mensajes ACCEPT que son idénticos alcanza un número de quórum (por ejemplo, 2f+1). Si el número de mensajes ACCEPT idénticos alcanza el número de quórum, el nodo primario 404 determina que se ha logrado un consenso entre todos los nodos de red y luego ejecuta la solicitud de transacción 502 localmente. En algunas implementaciones de la presente especificación, si el nodo primario 404 determina que el número de mensajes ACCEPT que son idénticos no alcanza el número de quórum, el nodo primario 404 determina que no se ha logrado un consenso entre todos los nodos de red, y luego se abstiene de ejecutar la solicitud de transacción 502.

En algunas implementaciones de la presente especificación, cada uno de los nodos de respaldo 406 puede realizar las mismas operaciones que realiza el nodo primario 404 como se describe anteriormente en 436 antes de ejecutar la solicitud de transacción 502. Si un nodo de respaldo 406 determina que los mensajes ACCEPT que recibe exceden un umbral predeterminado, el nodo de respaldo 406 determina que se ha logrado un consenso entre los nodos de red y ejecuta la solicitud de transacción 502 localmente. En algunas implementaciones de la presente especificación, si el nodo de respaldo 406 determina que el número de mensajes ACCEPT que son idénticos no alcanza el número de quórum, el nodo de respaldo 406 determina que no se ha logrado un consenso entre todos los nodos de red, y luego se abstiene de ejecutar la solicitud de transacción 502.

En 438, el nodo primario 404 envía un resultado de transacción al nodo cliente 402 después de ejecutar la solicitud de transacción 502. Los nodos de respaldo 406 que han ejecutado con éxito la solicitud de transacción 502 localmente también pueden enviar sus respectivos resultados de transacción al nodo cliente 402.

El proceso de consenso como se discutió anteriormente incluye muchas características que mejoran el funcionamiento de todo el sistema de cadena de bloques y ayudan a aliviar el cuello de botella de la red. Por ejemplo, el proceso de consenso en la presente especificación incluye generar un número de bloques EC de acuerdo con un código EC mediante el uso de una solicitud de transacción y enviar uno de los bloques EC a cada uno de los nodos de red. El bloque EC es más pequeño que la solicitud de transacción original. Por lo tanto, enviar el bloque EC en lugar de la solicitud de transacción a los nodos de red reduce el tamaño de los bloques de datos que se transmiten entre los nodos de red de cadena de bloques, conservando así el ancho de banda de la red y reduciendo la carga de la red. Esto reduce aún más el tamaño de los datos que se escriben y leen en el espacio de memoria de los nodos de red, lo que reduce la carga en el espacio de memoria de los nodos de red y mejora la eficiencia del sistema de cadena de bloques en general.

Durante el proceso de consenso, los nodos de respaldo están esperando una solicitud del nodo primario. Sin embargo, el nodo primario puede encontrar una falla bizantina o una falla por colisión de modo que el nodo primario no pueda difundir la solicitud dentro de una ventana de tiempo predeterminada. Cuando ha pasado una cantidad de tiempo específica sin que el nodo primario transmita la solicitud, es posible que sea necesario elegir un nuevo nodo primario para impedir que los nodos de respaldo esperen indefinidamente la ejecución de las solicitudes.

La Figura 7 representa un ejemplo de un proceso 700 para realizar un cambio de un nodo primario (por ejemplo, el nodo 214 o 404) de un sistema distribuido (por ejemplo, la red de cadena de bloques 102 y 212) que puede ejecutarse de acuerdo con las implementaciones de la presente especificación. Específicamente, la Figura 7 ilustra un diagrama que presenta una modalidad ejemplar de un método 700 para realizar un cambio de un nodo primario, de acuerdo con la presente especificación. En algunas implementaciones, un nodo primario se asocia con una época que incluye un proceso de consenso en el que el nodo primario es el líder. Un cambio de un nodo primario puede resultar en un cambio de época.

En algunas implementaciones, en respuesta a la determinación de que un nodo primario de una época actual necesita cambiarse, un nodo de respaldo de la red de cadena de bloques envía un primer mensaje a los otros nodos de red. El primer mensaje indica que al nodo de respaldo le gustaría ser un nuevo nodo primario en una nueva época. Por ejemplo, como se ilustra en la Figura 7, el nodo de respaldo Ro envía un mensaje EPOCH_CHANGE a los otros nodos de redes Rb, R2 y R3 en la red de cadena de bloques en respuesta a que el nodo de respaldo Ro determina que un nodo primario actual está defectuoso y que debe realizarse un cambio de época. El mensaje EPOCH_CHANGE es un ejemplo del primer mensaje que indica que el nodo de respaldo Ro aplica para ser el nuevo nodo primario. El cambio de época puede provocar un cambio de una época actual con un nodo primario actual a una nueva época con un nuevo nodo primario. Tenga en cuenta que el proceso 700 se ilustra como implementado junto con cuatro nodos de red solo con fines ilustrativos. El proceso 700 puede implementarse junto con cualquier número adecuado de nodos de red.

Luego, cada uno de los nodos de red recibe el primer mensaje que envía el nodo de respaldo, prepara un segundo mensaje en respuesta al primer mensaje y difunde el segundo mensaje a los otros nodos de red. Por ejemplo, como se ilustra en la Figura 7, el nodo de red Ri recibe el mensaje EPOCH_CHANGE que envía el nodo de respaldo Ro, y responde al nodo de respaldo Ro con un mensaje NEW_EPOCH que indica un reconocimiento de que el nodo de respaldo Ro puede convertirse en el nuevo nodo primario. Mientras tanto, el nodo de red Ri también difunde el mensaje NEW_EPOCH a los otros nodos de red, tal como los nodos de red R2 y R3. De manera similar, el nodo de red R2 y R3 difunden cada uno un mensaje NEW_EPOCH a los otros nodos de red.

El proceso de cambio de época como se discutió anteriormente, un formato del mensaje EPOCH_CHANGE y un formato del mensaje NEW_EPOCH se discutirán a continuación en mayor detalle con referencia a las Figuras 8-9.

La Figura 8 representa un ejemplo de un proceso 800 para realizar un cambio de un nodo primario en un sistema de distribución (por ejemplo, la red de cadena de bloques 102 o 212) que puede ejecutarse de acuerdo con implementaciones de la presente especificación. En algunas implementaciones, el proceso de ejemplo 800 puede realizarse mediante el uso de uno o más programas ejecutables por ordenador que se ejecutan mediante el uso de uno o más dispositivos informáticos. Para claridad de la presentación, la descripción que sigue generalmente describe el método 800 en el contexto de las otras figuras en esta descripción. Se entenderá que el método 800 se puede llevar a cabo, por ejemplo, mediante cualquier sistema, entorno, software y hardware adecuado, o una combinación de sistemas, entornos, software y hardware, según sea apropiado. En algunas implementaciones, pueden ejecutarse ^{diferentes etapas del método}800 ^{en paralelo, en combinación, en bucles o en cualquier orden.}

El proceso 800 comienza en 806, donde un nodo de respaldo 802 determina que es necesario realizar un cambio de época. El cambio de época que se discute en la presente descripción causa un cambio de una época actual con un nodo primario actual a una nueva época con un nuevo nodo primario. Una época de ejemplo puede incluir un proceso de consenso (por ejemplo, el proceso de consenso 300 o 400) para lograr el consenso entre un número de nodos de red mediante el uso de un nodo primario como se discutió anteriormente con referencia a las Figuras 3-6.

En algunas implementaciones de la presente especificación, el nodo de respaldo 802 determina que debe realizarse un cambio de época en respuesta a la determinación de que el nodo de respaldo 802 todavía está esperando una solicitud del nodo primario actual después de que haya pasado una cantidad específica de tiempo sin recibir la solicitud del nodo primario actual. Por ejemplo, el nodo primario actual puede encontrar una falla bizantina o una falla por colisión, de modo que el nodo primario actual no puede transmitir la solicitud dentro de una ventana de tiempo predeterminada. Por lo tanto, el cambio de época se desencadena por tiempos de espera que impiden que los nodos de respaldo esperen indefinidamente a que se ejecuten las solicitudes. El proceso de cambio de época que se analiza en la presente descripción proporciona vitalidad y reduce la latencia de la red al permitir que el sistema avance cuando falla el nodo primario.

En 808, el nodo de respaldo 802 determina un peso respectivo del nodo de respaldo 802 que se asocia con cada una de las fases del proceso de consenso en la época actual. En algunas implementaciones, el proceso de consenso incluye tres fases como se describió anteriormente con referencia a las Figuras 3-6. El peso es una métrica de una calificación del nodo de respaldo 802 para ser el nuevo nodo primario en una nueva época.

En algunas implementaciones de la presente especificación, el nodo de respaldo 802 determina un peso del nodo de respaldo 802 para que una primera fase del proceso de consenso en la época actual sea un primer valor. Por ejemplo, al nodo de respaldo 802 se le puede asignar un peso inicial del 10 % si el nodo de respaldo 802 ha entrado en una primera fase del proceso de consenso (por ejemplo, la primera fase 310 del proceso de consenso 300). En implementaciones alternativas de la presente especificación, el nodo de respaldo 802 puede asignar cualquier valor de peso adecuado al nodo de respaldo 802 para la primera fase del proceso de consenso actual.

En algunas implementaciones de la presente especificación, el nodo de respaldo 802 determina un peso del nodo de respaldo 802 para una segunda fase del proceso de consenso (por ejemplo, la primera fase 320 del proceso de consenso 300) en la época actual en base a un proceso de verificación de quórum. El proceso de verificación de quórum se realiza mediante la determinación de si el nodo de respaldo 802 recibe un número predeterminado (por ejemplo, 2f+1) de mensajes ECHO de los otros nodos de red en la segunda fase del proceso de consenso.

En algunas implementaciones de la presente especificación, si el nodo de respaldo 802 falla en la verificación de quórum (por ejemplo, el nodo de respaldo 802 recibe una cantidad de mensajes ECHO que es menor que un umbral predeterminado), el nodo de respaldo 802 puede determinar que el peso del nodo de respaldo 802 para la segunda fase del proceso de consenso sea un primer valor. Si el nodo de respaldo 802 pasa la verificación de quórum (por ejemplo, el nodo de respaldo 802 recibe una cantidad de mensajes ECHO que iguala o excede un umbral predeterminado), el nodo de respaldo 802 puede determinar que el peso del nodo de respaldo 802 para la segunda fase del proceso de consenso sea un segundo valor. En algunas implementaciones de la presente especificación, el segundo valor se determina como mayor que el primer valor. Por ejemplo, si el nodo de respaldo 802 falla en la ^{verificación de quórum, al nodo de respaldo}802 ^{se le puede asignar un valor de peso de cero para la segunda fase del}proceso de consenso. Si el nodo de respaldo 802 pasa la verificación de quórum, al nodo de respaldo 802 se le puede asignar un valor de peso del 45 % al nodo de respaldo 802 para la segunda fase del proceso de consenso. Sin embargo, en implementaciones alternativas de la presente especificación, el nodo de respaldo 802 puede asignar cualquier valor adecuado al nodo de respaldo 802 para la segunda fase del proceso de consenso en la época actual.

En algunas implementaciones de la presente especificación, la verificación de quórum incluye además verificar si los mensajes ECHO que el nodo de respaldo 802 recibe de los otros nodos de red durante la segunda fase del proceso de consenso son válidos. Por ejemplo, el nodo de respaldo 802 puede autenticar las firmas de clave privada en los mensajes ECHO mediante el uso de una clave pública para determinar si los mensajes ECHO son válidos.

Similar a determinar el peso para la segunda fase, en algunas implementaciones, el nodo de respaldo 802 determina un peso del nodo de respaldo 802 para una tercera fase del proceso de consenso (por ejemplo, la tercera fase 330 del proceso de consenso 300) en la época actual en base a un proceso de verificación de quórum. El proceso de ^{verificación de quórum se realiza mediante la determinación de si el nodo de respaldo}802 ^{recibe un número}predeterminado (por ejemplo, 2f+1) de mensajes de aceptación de los otros nodos de red en la tercera fase del proceso de consenso en la época actual. Cada uno de los mensajes de aceptación de otros nodos de red indica que cada uno de los otros nodos de red ha aceptado un número predeterminado de mensajes ECHO. El mensaje de aceptación puede ser, por ejemplo, los mensajes ACCEPT descritos anteriormente con referencia a la tercera fase 330 del proceso de consenso 300.

En algunas implementaciones de la presente especificación, si el nodo de respaldo 802 falla la verificación de quórum (por ejemplo, el nodo de respaldo 802 recibe una cantidad de mensajes ACCEPT que es menor que un umbral predeterminado), el nodo de respaldo 802 puede determinar el que peso del nodo de respaldo 802 para que la tercera fase del proceso de consenso sea un primer valor. Si el nodo de respaldo 802 pasa la verificación de quórum (por ejemplo, el nodo de respaldo 802 recibe un número de mensajes ACCEPT que iguala o excede un umbral predeterminado), el nodo de respaldo 802 puede determinar que el peso del nodo de respaldo 802 para la tercera fase del proceso de consenso sea un segundo valor. En algunas implementaciones, el segundo valor se determina como mayor que el primer valor. Por ejemplo, si el nodo de respaldo 802 falla en la verificación de quórum, al nodo de respaldo 802 se le puede asignar un valor de peso de cero al nodo de respaldo 802 para la segunda fase del proceso de consenso. Si el nodo de respaldo 802 pasa la verificación de quórum, al nodo de respaldo 802 se le puede asignar un valor de peso del 45 % al nodo de respaldo 802 para la segunda fase del proceso de consenso. Sin embargo, en implementaciones alternativas de la presente especificación, el nodo de respaldo 802 puede asignar cualquier valor adecuado al nodo de respaldo 802 para la tercera fase del proceso de consenso en la época actual.

En 810, después de determinar los pesos respectivos del nodo de respaldo 802 para las fases del proceso de consenso en la época actual, el nodo de respaldo 802 determina una suma de pesos del nodo de respaldo 802 para el proceso de consenso en base a los respectivos pesos. En algunas implementaciones de la presente especificación, la suma de pesos es una suma de las respectivas sumas de los nodos de respaldo que se asocian con cada una de las fases del proceso de consenso en la época actual. Por ejemplo, si el nodo de respaldo 802 ha determinado que un primer valor de peso del nodo de respaldo 802 para la primera fase es del 10 %, un segundo valor de peso del nodo de respaldo 802 para la segunda fase es del 45 % y un tercer valor de peso del nodo de respaldo 802 para la tercera fase es del 45 %, el nodo de respaldo 802 determina que la suma de pesos es del 100 %. Como otro ejemplo, si el nodo de respaldo 802 ha determinado que un primer valor de peso del nodo de respaldo 802 para la primera fase es del 10 %, un segundo valor de peso del nodo de respaldo 802 para la segunda fase es del 45 %, y un tercer valor de peso del nodo de respaldo 802 para la tercera fase es 0, el nodo de respaldo 802 determina que la suma de pesos es del 55 %.

En 812, el nodo de respaldo 802 envía un mensaje EPOCH_CHANGE a los otros nodos de red 804 si el nodo de respaldo 802 determina que la suma de pesos que se determinó en 810 alcanza o excede un umbral predeterminado. Por ejemplo, el nodo de respaldo 802 puede enviar un mensaje EPOCH_CHANGE a los otros nodos de red 804 si la suma de pesos determinada en 810 alcanza el 100 %. El mensaje EPOCH_CHANGE indica una solicitud para un cambio de la época actual con el nodo primario actual a la nueva época con el nodo de respaldo como el nuevo nodo primario.

En algunas implementaciones de la presente especificación, con referencia a la Figura 9, el mensaje EPOCH_CHANGE tiene un formato de <peso, epoch+1, ECHO {], ACCEPT {], j>, donde "peso" representa la suma de pesos del nodo de respaldo 802 como se determinó previamente en 810 para el proceso de consenso, "epoch+1" representa una ronda de nuevo consenso (es decir, una nueva época) que se asocia con un nuevo nodo primario, "ECHO]}" representa un conjunto de mensajes ECHO que el nodo de respaldo 802 recibe durante la segunda fase del proceso de consenso, "ACCEPT}}" representa un conjunto de mensajes ACCEPT que recibe el nodo de respaldo 802 durante la tercera fase del proceso de consenso, y "j" representa el nodo de red (por ejemplo, nodo de respaldo 802) que genera y envía el mensaje EPOCH_CHANGe . En algunas implementaciones, el mensaje EPOCH_CHANGE puede tener un formato diferente, por ejemplo, al incluir campos adicionales o diferentes.

Volviendo a la Figura 8, en 814, los nodos de red 804 distintos del nodo de respaldo 802 verifican el mensaje EPOCH_CHANGE que envía el nodo de respaldo 802. En algunas implementaciones, cada uno de los nodos de red 804 verifica si el mensaje EPOCH_CHANGE es válido al verificar si la suma de pesos en el mensaje EPOCH_CHANGE es válida. En algunas implementaciones, verificar si la suma de pesos en el mensaje EPOCH_CHANGE es válida incluye verificar si el conjunto de firmas en los mensajes ECHO que se incluyen en el mensaje EPOCH_CHANGE es válido. Por ejemplo, cada uno de los nodos de red 804 puede autenticar el conjunto de firmas de clave privada en los mensajes ECHO que se incluyen en el mensaje EPOCH_CHANGE mediante el uso de una clave pública.

En 816, cada uno de los nodos de red 804 envía un mensaje NEW_EP0CH al nodo de respaldo 802 en respuesta a verificar que el mensaje EPOCH_CHANGE que envía el nodo de respaldo 802 es válido. El mensaje NEW_EPOCH indica un reconocimiento del nodo de respaldo como el nuevo nodo primario. Por ejemplo, el mensaje NEW_EPOCH que envía un nodo de red 804 incluye una indicación de que el nodo de red 804 reconoce que el nodo de respaldo 802 se convertirá en el nuevo nodo primario en la nueva época. Mientras tanto, cada uno de los nodos de red 804 también envía el mensaje NEW_EPOCH a los otros nodos de red 804.

Refiriéndose a la Figura 9, el mensaje NEW_EPOCH se genera con un formato de <epoch+1, i, j, seq, ec_digest>, donde " epoch+1" representa una ronda de consenso nuevo (es decir, una nueva época) que se asocia con un nuevo nodo primario, "i" representa el nuevo nodo primario en la nueva época, "j" representa un nodo de red 804 que envía el mensaje NEW EPOCH, y "ec digest" representa un resumen del mensaje EPOCH_CHANGE. En algunas implementaciones, el resumen del mensaje EPOCH_CHANGE incluye un valor hash del mensaje EPOCH_CHANGE. En algunas implementaciones, el mensaje NEW_EPOCH puede tener un formato diferente, por ejemplo, al incluir campos adicionales o diferentes.

Volviendo a la Figura 8, en 818, el nodo de respaldo 802 verifica si los mensajes NEW_EPOCH que envían los nodos de red 804 son válidos. En algunas implementaciones, el nodo de respaldo 802 verifica los mensajes NEW_EPOCH al verificar si el resumen del mensaje EPOCH_CHANGE en los mensajes NEW_EPOCH es válido. Debido a que el resumen incluye información del mensaje EPOCH_CHANGE, el resumen también incluye las firmas en el mensaje EPOCH_CHANGE. El nodo de respaldo 802 puede verificar el resumen del mensaje Ep Oc H_CHANGE al verificar si el conjunto de firmas en el mensaje EPOCH_CHANGE es válido.

En 820, el nodo de respaldo 802 determina si un número de mensajes NEW_EPOCH válidos según se determina en 818 excede un umbral predeterminado. En algunas implementaciones, el umbral predeterminado es un número de quórum (por ejemplo, 2f+1).

En 822, el nodo de respaldo 802 determina que el nodo de respaldo 802 es el nuevo nodo primario en la nueva época en respuesta a la determinación de que el número de mensajes NEW_EPOCH válidos según se determina excede el umbral predeterminado. Nótese que cada uno de los nodos de red 804 realiza las mismas etapas 818-822 que hace el nodo de respaldo 802, y que los nodos de red 804 y el nodo de respaldo 802 pueden realizar las etapas 818-822 de manera paralela. Por ejemplo, cada uno de los nodos de red 804 puede verificar un conjunto de mensajes NEW_EPOCH que se envían desde los otros nodos de red 804, determinar si un número de mensajes NEW_EPOCH válidos excede un umbral predeterminado y determinar un nuevo nodo primario.

El proceso de cambio de época (por ejemplo, el proceso 700 u 800) como se discutió anteriormente incluye muchas características que mejoran el funcionamiento de todo el sistema de cadena de bloques y ayudan a aliviar el cuello de botella de la red. Por ejemplo, el proceso de cambio de época en la presente especificación incluye asignar pesos respectivos a las tres fases del proceso de consenso, determinar una suma de pesos en base a los pesos respectivos de las tres fases y determinar un nuevo nodo primario en base a la suma de pesos. El proceso de cambio de época que se basa en la suma de pesos en lugar de un método de turno rotativo puede facilitar la elección de un nuevo nodo primario que no tenga fallas de manera oportuna. Un método de turno rotativo puede causar un cambio frecuente de nodo primario cuando múltiples nodos de red en línea para el nuevo nodo primario tienen fallas. Esto afecta significativamente el servicio de cadena de bloques al introducir latencia o demora en la búsqueda de un nodo primario que no esté defectuoso. A diferencia del método de turno rotativo, el proceso de cambio de época en la presente especificación se basa en la suma de pesos para seleccionar el nuevo nodo primario, lo que puede reducir el tiempo para encontrar el nuevo nodo primario que no está defectuoso. Esto puede mejorar aún más la eficiencia del sistema de cadena de bloques en general al proporcionar los servicios de cadena de bloques.

Durante la operación de una red de cadena de bloques, la velocidad de ejecución de algunos nodos de red puede retrasarse con respecto a la de la mayoría de los nodos de red debido a la inestabilidad de la red, una falla repentina de energía, una falla del disco y similares. En este escenario, más de 1/3 de los nodos de red del sistema pueden fallar. BFT proporciona seguridad y vitalidad si menos de 1/3 de los nodos de red fallan durante la vida útil del sistema. Sin embargo, estas garantías son insuficientes para los sistemas de larga duración porque es probable que se supere el límite superior en el escenario descrito anteriormente. Por lo tanto, es deseable un proceso de recuperación que haga que los nodos de red defectuosos se comporten correctamente de nuevo y continúen participando en procesos de consenso posteriores para permitir que el sistema tolere más de f fallas durante su vida útil. Además, el proceso de recuperación descrito puede recuperar uno o más nodos de red que todavía están realizando un proceso de consenso (por ejemplo, el proceso de consenso 300 o 400), y no es necesario esperar hasta que se alcance el consenso entre todos los nodos de red. Como tal, el proceso de recuperación descrito puede reducir aún más la latencia del sistema y mejorar la eficiencia de la red de cadena de bloques.

La Figura 10 representa un ejemplo de un proceso 1000 para realizar un proceso de recuperación de un nodo de red (por ejemplo, el nodo 214 o 404) de un sistema distribuido (por ejemplo, la red de cadena de bloques 102 y 212) que puede ejecutarse de acuerdo con las implementaciones de la presente especificación. Específicamente, la Figura 10 ilustra un diagrama que presenta una modalidad ejemplar de un método 1000 para realizar un proceso de recuperación de un nodo de red, de acuerdo con la presente especificación. Como se ilustra en la Figura 10, el proceso 1000 incluye algunas fases y etapas.

En una primera fase 1010, un nodo de red (por ejemplo, el nodo de red Ro) que quisiera recuperar una transacción objetivo con un número de secuencia objetivo Ro transmite un mensaje de solicitud de estado (por ejemplo, el mensaje QUERY_STATE) a los otros nodos de red indicando que la red nodo se va a recuperar. El mensaje de solicitud de estado puede incluir el número de secuencia objetivo que el nodo de red Ro le gustaría recuperar. En una segunda fase 1020, los otros nodos de red reciben el mensaje de solicitud de estado y envían un mensaje de respuesta de estado (por ejemplo, el mensaje REPLY_STATE) al nodo de red Ro. En una tercera fase 1030, el nodo de red Ro envía un mensaje de solicitud (por ejemplo, el mensaje FETCH_ECHO) a los otros nodos de red solicitando un mensaje ECHO de cada uno de los otros nodos de red. El mensaje ECHO puede ser el mismo mensaje ECHO que envían los otros nodos de red respectivos en la segunda fase 320 del proceso de consenso 300 como se describió anteriormente con referencia a las Figuras 3-6. En una cuarta fase 1040, cada uno de los otros nodos de red envía un mensaje ECHO al nodo de red Ro en respuesta al mensaje FETCH_ECHO. En una quinta fase 1050, el nodo de red Ro verifica los mensajes ECHO y recupera la transacción objetivo de acuerdo con un código EC, por ejemplo, de acuerdo con las técnicas de reconstrucción de ejemplo descritas anteriormente con referencia a la Figura 4. En una sexta fase 1060, el nodo de red Ro envía un mensaje ACCEPT a los otros nodos de red indicando que el nodo de red se ha recuperado.

Tenga en cuenta que el proceso 1000 se ilustra como implementado junto con cuatro nodos de red sólo con fines ilustrativos. El proceso 1000 puede implementarse junto con cualquier número adecuado de nodos de red. El proceso 1000, un formato del mensaje QUERY_STATE y un formato del mensaje REPLY_STATE se discutirán a continuación en mayor detalle con referencia a las Figuras 11-12.

La Figura 11 representa un ejemplo de un proceso 1100 para realizar un proceso de recuperación de un nodo de red en un sistema de distribución (por ejemplo, la red de cadena de bloques 102 o 212) que puede ejecutarse de acuerdo con implementaciones de la presente especificación. En algunas implementaciones, el proceso 1100 puede realizarse mediante el uso de uno o más programas ejecutables por ordenador que se ejecutan mediante el uso de uno o más dispositivos informáticos. Para claridad de la presentación, la descripción que sigue generalmente describe el método 1100 en el contexto de las otras figuras en esta descripción. Se entenderá que el método 1100 se puede llevar a cabo, por ejemplo, mediante cualquier sistema, entorno, software y hardware adecuado, o una combinación de sistemas, entornos, software y hardware, según sea apropiado. En algunas implementaciones, pueden ejecutarse diferentes etapas del método 1100 en paralelo, en combinación, en bucles o en cualquier orden.

El proceso 1100 comienza en 1106 donde un nodo de red 1102 transmite un mensaje de solicitud de estado a los otros nodos de red 1104. El mensaje de solicitud de estado incluye una indicación de que el nodo de red 1102 va a recuperar una transacción objetivo con un número de secuencia objetivo. El nodo de red 1102 puede ser un nodo primario o un nodo de respaldo.

En algunas implementaciones de la presente especificación, con referencia a la Figura 12, el mensaje QUERY_STATE, como ejemplo del mensaje de solicitud de estado, tiene un formato de <j, seq>, donde "j" representa un nodo de red 1102 que envía el mensaje QUERY STATE, y "seq" representa un número de secuencia más grande o un número de secuencia más reciente para el nodo de red 1102 en el proceso de consenso actual. En algunas implementaciones, el mensaje QUERY_STATE puede tener un formato diferente, por ejemplo, al incluir campos adicionales o diferentes.

Al difundir el mensaje QUERY_STATE a los otros nodos de red 1104, el nodo de red 1102 está solicitando a los otros nodos de red 1104 que envíen su número de secuencia más reciente al nodo de red 1102, obteniendo así la última información de bloque del sistema de cadena de bloques. Y al obtener la información de bloque más reciente de todo el sistema de cadena de bloques, el nodo de red 1102 puede sincronizarse con el último estado de todo el sistema, recuperándose así y continuando con su participación en el proceso de consenso.

Volviendo a la Figura 11, en 1108, cada uno de los otros nodos de red 1104 envía un mensaje de respuesta de estado (por ejemplo, el mensaje REPLY_STATE) al nodo de red 1102 en respuesta a la recepción del mensaje de solicitud de estado. En algunas implementaciones, el mensaje de respuesta de estado incluye un número de secuencia anterior que se asocia con los nodos de red 1104.

En algunas implementaciones, con referencia a la Figura 12, el mensaje REPLY_STATE, como ejemplo del mensaje de respuesta de estado, tiene un formato de <j, last_seq>, donde "j" representa un nodo de red 1104 que envía el mensaje REPLY STATE, y "last seq" representa un número de secuencia anterior para el nodo de red 1104 en el proceso de consenso actual. En algunas implementaciones, el mensaje REPLY_STATE puede tener un formato diferente, por ejemplo, al incluir campos adicionales o diferentes.

Volviendo a la Figura 11, en 1110, el nodo de red 1102 determina si un número de mensajes de respuesta de estado que se reciben excede un umbral predeterminado. Por ejemplo, el nodo de red 1102 puede determinar si un número de mensajes REPLY_STATE que se reciben excede un número de quórum (por ejemplo, 2f+l o nf). En algunas implementaciones, el nodo de red 1102 determina además si el número de quórum de los mensajes REPLY_STATE que se reciben incluye un número de secuencia idéntico. El número de quórum de los mensajes REPLY_STATE que se reciben incluye un número de secuencia idéntico, lo que significa que la mayoría de los nodos de red 1104 están de acuerdo en un estado común de todo el sistema.

En 1112, el nodo de red 1102 determina el número de secuencia objetivo basándose en el número de secuencia idéntico si el nodo de red 1102 determina que el número de mensajes de respuesta de estado que incluyen el número de secuencia idéntico recibido de los nodos de red 1104 excede el umbral predeterminado. Por ejemplo, el nodo de red 1102 puede determinar que el número de secuencia objetivo sea un incremento (por ejemplo, "last_seq+1") del número de secuencia idéntico (por ejemplo, "last_seq").

En 1114, el nodo de red 1102 envía un mensaje de solicitud (por ejemplo, el mensaje FETCH_ECHO) a los otros nodos de red 1104. El mensaje FETCH_ECHO se envía mediante el nodo de red 1102 para solicitar un mensaje ECHO de cada uno de los otros nodos de red 1104. Como se discutió anteriormente con referencia a las Figuras 3-6, el mensaje ECHO es un mensaje que se transmite mediante los nodos de red 1104 para lograr un consenso entre los nodos de red 1104 sobre una transacción objetivo. El mensaje ECHO incluye una parte de la transacción objetivo (por ejemplo, un bloque EC) y una firma del nodo de red 1104 que envía el mensaje ECHO.

En algunas implementaciones, con referencia a la Figura 12, el mensaje FETCH_ECHO, como ejemplo del mensaje de solicitud, tiene un formato de <j, last_seq+l>, donde "j" representa un nodo de red 1102 que envía el mensaje FETCH ECHO, y "last_seq+l" representa un número de secuencia de destino que se asocia con los mensajes ECHO que el nodo de red 1102 está solicitando a los otros nodos de red 1104. En algunas implementaciones, el mensaje FETCH_ECHO puede tener un formato diferente, por ejemplo, al incluir campos adicionales o diferentes.

El mensaje FETCH_ECHO como se describe en la presente descripción se envía mediante el nodo de red 1102 para solicitar los mensajes ECHO que incluyen un número de secuencia más reciente o un número de secuencia más grande de los otros nodos de red 1104. Al recopilar los mensajes ECHO que incluyen un número de secuencia más reciente o un número de secuencia más grande de los otros nodos de red 1104, el nodo de red 1102 puede ser capaz de recuperarse al estado más reciente que se asocia con el número de secuencia más reciente.

Volviendo a la Figura 11, en 1116, cada uno de los nodos de red 1104 envía un mensaje ECHO al nodo de red 1102 en respuesta a la recepción del mensaje FETCH_ECHO. En algunas implementaciones, cada uno de los nodos de red 1104 verifica el mensaje FETCH_ECHO antes de enviar el mensaje ECHO al nodo de red 1102. En algunas implementaciones, cada uno de los nodos de red 1104 verifica el mensaje FETCH_ECHO mediante determinar si el número de secuencia que se incluye en los mensajes FETCH_ECHO excede el número de secuencia más reciente que se asocia con el nodo de red 1104. Si el número de secuencia que se incluye en los mensajes FETCH_ECHO es igual al número de secuencia más reciente que se asocia con el nodo de red 1104, el nodo de red 1104 determina que el mensaje FETCH_ECHO es válido y que se enviará un mensaje ECHO al nodo de red 1102. Si el número de secuencia que se incluye en los mensajes FETCH_ECHO excede el número de secuencia más reciente que se asocia con el nodo de red 1104, el nodo de red 1104 determina que el mensaje FETCH_ECHO no es válido y que no se enviará un mensaje ECHO al nodo de red 1102.

En 1118, el nodo de red 1102 verifica si los mensajes ECHO que envían los nodos de red 1104 son válidos. En algunas implementaciones, el nodo de red 1102 verifica los mensajes ECHO mediante el uso de un árbol Merkel. Por ejemplo, el nodo de red 1102 puede usar los datos que se incluyen en el mensaje ECHO para reconstruir un árbol Merkel y determinar un valor de hash raíz reconstruido del árbol Merkel reconstruido. El nodo de red 1102 puede entonces comparar el valor de hash raíz reconstruido con un valor de hash raíz que se incluye en el mensaje ECHO. Si el valor de hash raíz reconstruido coincide con el valor de hash raíz que se incluye en el mensaje ECHO, el nodo de red 1102 determina que el mensaje ECHO es válido. Si el valor de hash raíz reconstruido no coincide con el valor de hash raíz que se incluye en el mensaje ECHO, el nodo de red 1102 determina que el mensaje ECHO no es válido y puede descartar el mensaje ECHO no válido.

En algunas implementaciones, el nodo de red 1102 verifica si el mensaje ECHO es válido al verificar además si la firma en el mensaje ECHO es válida. Por ejemplo, el nodo de red 1102 puede autenticar la firma de clave privada en el mensaje ECHO mediante el uso de una clave pública emparejada con la clave privada para verificar la firma.

En 1120, el nodo de red 1102 determina si un número de mensajes ECHO válidos que se reciben de los otros nodos de red 1104 excede un umbral predeterminado. Por ejemplo, el nodo de red 1102 puede determinar si un número de mensajes ECHO válidos que se reciben de los otros nodos de red 1104 excede un número de quórum (por ejemplo, 2f+1).

En 1122, el nodo de red 1102 recupera la transacción objetivo con el número de secuencia objetivo en respuesta a determinar que el número de mensajes ECHO válidos excede el umbral predeterminado. En algunas implementaciones, el nodo de red 1102 recupera la transacción objetivo mediante el uso de los datos que se incluyen en el número de mensajes ECHO válidos. Por ejemplo, el nodo de red 1102 puede recuperar un subconjunto de bloques EC que se incluyen en los mensajes ECHO para reconstruir la transacción objetivo de acuerdo con un código EC.

En 1124, el nodo de red 1102 transmite un mensaje ACCEPT a los otros nodos de red 1104 después de recuperar la transacción objetivo. Por ejemplo, el nodo de red 1102 puede transmitir un mensaje ACCEPT a los otros nodos de red 1104 después de reconstruir con éxito la transacción objetivo. En algunas implementaciones, el mensaje ACCEPT incluye un conjunto de firmas en los mensajes ECHO y el número de secuencia objetivo. Al enviar el mensaje ACCEPT que incluye las firmas y el número de secuencia objetivo a los otros nodos de red 1104, el nodo de red 1102 indica a los otros nodos de red 1104 que el nodo de red 1102 se ha recuperado y sincronizado con el último estado del sistema.

El proceso de recuperación como se discutió anteriormente en la presente especificación incluye muchas características que mejoran el funcionamiento de los ordenadores que implementan el proceso de recuperación y ayudan a aliviar el cuello de botella de la red. Por ejemplo, el proceso de recuperación en la presente especificación incluye operaciones que incluyen enviar un mensaje de solicitud de estado mediante un nodo de red que aplica para ser un nuevo nodo primario, recibir mensajes de respuesta de estado de los otros nodos de red y enviar un mensaje FETCH_ECHO mediante el nodo de red para solicitar mensajes ECHO de los otros nodos de red. Estas operaciones se realizan de manera que el proceso de recuperación del nodo de red defectuoso no interfiera con el funcionamiento normal del proceso de consenso entre los otros nodos de red no defectuosos. Esto facilita la conservación de los recursos informáticos y de red para recuperar el nodo de red defectuoso al reducir la complejidad del proceso de recuperación.

Refiriéndose a la Figura 13, la Figura 13 es un diagrama que ilustra módulos de un aparato de consenso 1300, de acuerdo con una implementación de la presente especificación. El aparato 1300 para lograr consenso puede aplicarse a un sistema de consenso que se basa en una tecnología de cadena de bloques. Por ejemplo, el aparato 1300 puede corresponder a las implementaciones que se muestran en las Figuras 1-6. El aparato 1300 puede implementarse en un nodo primario en la red de cadena de bloques. El aparato 1300 incluye lo siguiente: un receptor o unidad receptora 1302, que se configura para recibir una solicitud de transacción; una unidad generadora 1304, que se configura para generar un número de bloques de código de borrado (EC) de acuerdo con un código EC mediante el uso de la solicitud de transacción; un transmisor o unidad transmisora 1306, que se configura para enviar un número de primeros mensajes a uno o más nodos de respaldo, respectivamente, en donde cada uno del número de primeros mensajes incluye un valor hash compuesto que se asocia con el número de bloques EC; el receptor o unidad receptora 1302, que se configura además para recibir al menos un segundo mensaje de al menos uno de los nodos de respaldo, en donde al menos un segundo mensaje incluye uno del número de primeros mensajes y una firma de al menos uno de los nodos de respaldo que se asocian con uno del número de primeros mensajes; una unidad de verificación 1306, que se configura para verificar si al menos un segundo mensaje es válido en respuesta a la recepción de al menos un segundo mensaje de al menos uno de los nodos de respaldo; una unidad de determinación 1310, que se configura para determinar si un número de segundos mensajes válidos excede un umbral predeterminado; una unidad de reconstrucción 1312, que se configura para reconstruir la solicitud de transacción basándose en un subconjunto del número de segundos mensajes válidos de acuerdo con el código EC en respuesta a la determinación de que el número de segundos mensajes válidos excede el umbral predeterminado; el transmisor o la unidad transmisora 1306, que se configura además para enviar un tercer mensaje, a los otros nodos de red en respuesta a determinar que la solicitud de transacción se ha reconstruido con éxito, en donde el tercer mensaje incluye un conjunto de firmas que están en los segundos mensajes válidos; el receptor o la unidad receptora 1302, que se configuran además para recibir al menos un tercer mensaje de al menos uno de los nodos de respaldo; y una unidad de ejecución 1314, que se configura para ejecutar la solicitud de transacción en respuesta a recibir un número predeterminado de terceros mensajes que son idénticos.

En una implementación opcional, la solicitud de transacción se asocia con un número de secuencia.

En una implementación opcional, generar la pluralidad de bloques EC de acuerdo con un código EC incluye lo siguiente: transformar la solicitud de transacción en un mensaje EC mediante el uso del código EC y dividir el mensaje EC en el número de bloque EC.

En una implementación opcional, el valor hash compuesto del número de bloque EC se genera mediante el uso de un árbol hash.

En una implementación opcional, el árbol hash incluye un árbol Merkle, y en donde el valor hash compuesto es un valor hash raíz del árbol Merkle.

En una implementación opcional, la firma de al menos uno de los nodos de respaldo que se asocian con uno del número de primeros mensajes incluye una firma de clave privada de al menos uno de los nodos de respaldo que se asocian con uno del número de primeros mensajes.

En una implementación opcional, al menos un segundo mensaje incluye además al menos uno del número de bloques EC.

En una implementación opcional, la verificación de si al menos un segundo mensaje es válido incluye lo siguiente: generar un árbol hash reconstruido mediante el uso de al menos uno del número de bloques EC en al menos un segundo mensaje; determinar un valor hash compuesto reconstruido del árbol hash reconstruido; y determinar si el valor hash compuesto reconstruido coincide con los valores hash compuestos en al menos un segundo mensaje.

En una implementación opcional, la unidad de determinación 1310 se configura además para determinar que al menos un segundo mensaje es válido en respuesta a la determinación de que el valor de hash compuesto reconstruido coincide con los valores de hash compuesto en los segundos mensajes.

En una implementación opcional, el número predeterminado de terceros mensajes que son idénticos incluye el número predeterminado de terceros mensajes que tienen un conjunto idéntico de firmas.

La Figura 13 es un diagrama esquemático que ilustra un módulo funcional interno y una estructura de un aparato de consenso 1300. En esencia, un organismo de ejecución puede ser un dispositivo electrónico, y el dispositivo electrónico incluye lo siguiente: al menos un procesador; y una memoria que se configura para almacenar una instrucción ejecutable de al menos un procesador.

Al menos un procesador se configura para recibir una solicitud de transacción; generar un número de bloques de códigos de borrado (EC) de acuerdo con un código EC mediante el uso de la solicitud de transacción; enviar un número de primeros mensajes a uno o más nodos de respaldo, respectivamente, en donde cada uno de los primeros mensajes incluye un valor hash compuesto que se asocia con el número de bloques EC; recibir al menos un segundo mensaje de al menos uno de los nodos de respaldo, en donde al menos un segundo mensaje incluye uno del número de primeros mensajes y una firma de al menos uno de los nodos de respaldo que se asocian con el del número de primeros mensajes; verificar si al menos un segundo mensaje es válido en respuesta a la recepción de al menos un segundo mensaje de al menos uno de los nodos de respaldo; determinar si un número de segundos mensajes válidos excede un umbral predeterminado; reconstruir la solicitud de transacción en base a un subconjunto del número de segundos mensajes válidos de acuerdo con el código EC en respuesta a la determinación de que el número de segundos mensajes válidos excede el umbral predeterminado; enviar un tercer mensaje a los otros nodos de red en respuesta a la determinación de que la solicitud de transacción se ha reconstruido con éxito, en donde el tercer mensaje incluye un conjunto de firmas que están en los segundos mensajes válidos; recibir al menos un tercer mensaje de al menos uno de los nodos de respaldo; y ejecutar la solicitud de transacción en respuesta a la recepción de un número predeterminado de terceros mensajes que son idénticos.

Opcionalmente, la solicitud de transacción se asocia con un número de secuencia.

Opcionalmente, generar la pluralidad de bloques EC de acuerdo con un código EC incluye lo siguiente: transformar la solicitud de transacción en un mensaje EC mediante el uso del código EC y dividir el mensaje EC en el número de bloque EC.

Opcionalmente, el valor hash compuesto del número de bloque EC se genera mediante el uso de un árbol hash.

Opcionalmente, el árbol hash incluye un árbol Merkle, y en donde el valor hash compuesto es un valor hash raíz del árbol Merkle.

Opcionalmente, la firma de al menos uno de los nodos de respaldo que se asocian con uno del número de primeros mensajes incluye una firma de clave privada de al menos uno de los nodos de respaldo que se asocian con uno del número de primeros mensajes.

Opcionalmente, al menos un segundo mensaje incluye además al menos uno del número de bloques EC.

Opcionalmente, la verificación de si al menos un segundo mensaje es válido incluye lo siguiente: generar un árbol hash reconstruido mediante el uso de al menos uno del número de bloques EC en al menos un segundo mensaje; determinar un valor hash compuesto reconstruido del árbol hash reconstruido; y determinar si el valor hash compuesto reconstruido coincide con los valores hash compuestos en al menos un segundo mensaje.

Opcionalmente, al menos un procesador se configura además para determinar que al menos un segundo mensaje es válido en respuesta a la determinación de que el valor de hash compuesto reconstruido coincide con los valores de hash compuesto en los segundos mensajes.

Opcionalmente, el número predeterminado de terceros mensajes que son idénticos incluye el número predeterminado de terceros mensajes que tienen un conjunto idéntico de firmas.

Refiriéndose a la Figura 14, la Figura 14 es un diagrama que ilustra módulos de un aparato de consenso 1400, de acuerdo con una implementación de la presente especificación. El aparato 1400 para lograr consenso puede aplicarse a un sistema de consenso en base a una tecnología de cadena de bloques. El aparato 1400 puede corresponder a las implementaciones que se muestran en las Figuras 1-6. Por ejemplo, el aparato 1400 puede implementarse en un nodo de respaldo de una red de cadena de bloques. El aparato 1400 incluye lo siguiente: un receptor o unidad receptora 1402, que se configura para recibir un primer mensaje del nodo primario, en donde el primer mensaje incluye un valor de hash compuesto que se asocia con un número de bloques EC, en donde se genera el número de bloques EC por el nodo primario de acuerdo con un código EC mediante el uso de una solicitud de transacción; un transmisor o unidad transmisora 1404, que se configura para enviar, mediante el nodo de respaldo, un segundo mensaje a los otros nodos de red en respuesta a la recepción del primer mensaje, en donde el segundo mensaje incluye el primer mensaje y una firma del nodo de respaldo que se asocia con el primer mensaje; el receptor o la unidad receptora 1402, que se configura además para recibir al menos un segundo mensaje de al menos un nodo de respaldo distinto del nodo de respaldo; una unidad de verificación 1406, que se configura para verificar si al menos un segundo mensaje es válido en respuesta a la recepción de al menos un segundo mensaje de al menos un nodo de respaldo; una unidad de determinación 1408, que se configura para determinar si un número de segundos mensajes válidos excede un umbral predeterminado; una unidad de reconstrucción 1410, que se configura para reconstruir la solicitud de transacción en base a un subconjunto del número de segundos mensajes válidos de acuerdo con el código EC en respuesta a la determinación de que el número de segundos mensajes válidos excede el umbral predeterminado; el transmisor o unidad transmisora 1404, que se configura para enviar un tercer mensaje a los otros nodos de red en respuesta a la determinación de que la solicitud de transacción se ha reconstruido con éxito, en donde el tercer mensaje incluye un conjunto de firmas que están en los segundos mensajes válidos; el receptor o unidad receptora 1402, que se configura además para recibir al menos un tercer mensaje de al menos uno de los nodos de respaldo; y una unidad de ejecución 1412, que se configura para ejecutar la solicitud de transacción en respuesta a recibir un número predeterminado de terceros mensajes que son idénticos.

En una implementación opcional, generar la pluralidad de bloques EC de acuerdo con un código EC incluye lo siguiente: transformar la solicitud de transacción en un mensaje EC mediante el uso del código EC; y dividir el mensaje EC en el número de bloque EC.

En una implementación opcional, el valor hash compuesto de la pluralidad de bloques EC se genera mediante el uso de un árbol hash.

En una implementación opcional, el árbol hash incluye un árbol Merkle y el valor hash compuesto es un valor hash raíz del árbol Merkle.

En una implementación opcional, la firma del nodo de respaldo que se asocia con el primer mensaje incluye una firma de clave privada del nodo de respaldo que se asocia con el primer mensaje.

En una implementación opcional, la verificación de si al menos un segundo mensaje es válido incluye lo siguiente: generar un árbol hash reconstruido mediante el uso de al menos uno del número de bloques EC en al menos un segundo mensaje; determinar un valor hash compuesto reconstruido del árbol hash reconstruido; comparar el valor hash compuesto reconstruido con un valor hash compuesto en al menos un segundo mensaje; y determinar si el valor hash compuesto reconstruido coincide con los valores hash compuestos en al menos un segundo mensaje.

En una implementación opcional, la unidad de determinación 1408 se configura además para determinar que al menos un segundo mensaje es válido en respuesta a la determinación de que el valor hash compuesto reconstruido coincide con los valores hash compuestos en los segundos mensajes.

La Figura 14 es un diagrama esquemático que ilustra un módulo funcional interno y una estructura de un aparato de consenso 1400. En esencia, un organismo de ejecución puede ser un dispositivo electrónico, y el dispositivo electrónico incluye lo siguiente: al menos un procesador; y una memoria que se configura para almacenar una instrucción ejecutable de al menos un procesador.

Al menos un procesador se configura para recibir un primer mensaje del nodo primario, en donde el primer mensaje incluye un valor de hash compuesto que se asocia con un número de bloques EC, en donde el número de bloques EC se generan mediante el nodo primario de acuerdo con un EC código mediante el uso de una solicitud de transacción; enviar, mediante el nodo de respaldo, un segundo mensaje a los otros nodos de red en respuesta a la recepción del primer mensaje, en donde el segundo mensaje incluye el primer mensaje y una firma del nodo de respaldo que se asocia con el primer mensaje; recibir al menos un segundo mensaje de al menos un nodo de respaldo distinto del nodo de respaldo; verificar si al menos un segundo mensaje es válido en respuesta a la recepción de al menos un segundo mensaje de al menos un nodo de respaldo; determinar si un número de segundos mensajes válidos excede un umbral predeterminado; reconstruir la solicitud de transacción en base a un subconjunto del número de segundos mensajes válidos de acuerdo con el código EC en respuesta a la determinación de que el número de segundos mensajes válidos excede el umbral predeterminado; enviar un tercer mensaje a los otros nodos de red en respuesta a la determinación de que la solicitud de transacción se ha reconstruido con éxito, en donde el tercer mensaje incluye un conjunto de firmas que están en los segundos mensajes válidos; recibir al menos un tercer mensaje de al menos uno de los nodos de respaldo; y ejecutar la solicitud de transacción en respuesta a la recepción de un número predeterminado de terceros mensajes que son idénticos.

Opcionalmente, generar la pluralidad de bloques EC de acuerdo con un código EC incluye lo siguiente: transformar la solicitud de transacción en un mensaje EC mediante el uso del código EC; y dividir el mensaje EC en el número de bloque EC.

Opcionalmente, el valor hash compuesto de la pluralidad de bloques EC se genera mediante el uso de un árbol hash.

Opcionalmente, el árbol hash incluye un árbol Merkle y el valor hash compuesto es un valor hash raíz del árbol Merkle.

Opcionalmente, la firma del nodo de respaldo que se asocia con el primer mensaje incluye una firma de clave privada del nodo de respaldo que se asocia con el primer mensaje.

Opcionalmente, la verificación de si al menos un segundo mensaje es válido incluye lo siguiente: generar un árbol hash reconstruido mediante el uso de al menos uno del número de bloques EC en al menos un segundo mensaje; determinar un valor hash compuesto reconstruido del árbol hash reconstruido; comparar el valor hash compuesto reconstruido con un valor hash compuesto en al menos un segundo mensaje; y determinar si el valor hash compuesto reconstruido coincide con los valores hash compuestos en al menos un segundo mensaje.

Refiriéndose a la Figura 15, la Figura 15 es un diagrama que ilustra módulos de un aparato 1500 de cambio de nodo primario, de acuerdo con una implementación de la presente especificación. El aparato 1500 para cambiar un nodo primario puede aplicarse a un sistema de consenso en base a una tecnología de cadena de bloques. El aparato 1500 puede corresponder a las implementaciones que se muestran en las Figuras 7-9. Por ejemplo, el aparato 1500 puede implementarse en un nodo de respaldo de una red de cadena de bloques. El aparato 1500 incluye lo siguiente: una unidad de determinación 1502, que se configura para determinar que es necesario realizar un cambio de época, en donde el cambio de época provoca un cambio de una época actual con un nodo primario actual a una nueva época con un nuevo nodo primario, en donde la época actual comprende un proceso de consenso para lograr un consenso entre el número de nodos de red que usan el nodo primario, el proceso de consenso que incluye tres fases; la unidad de determinación 1502, que se configura además para determinar un peso respectivo del nodo de respaldo que se asocia con cada una de las tres fases del proceso de consenso en la época actual, en donde el peso es una métrica de una calificación del nodo de respaldo para ser el nuevo nodo primario; la unidad de determinación 1502, que se configura además para determinar una suma de pesos para el nodo de respaldo en base al peso respectivo del nodo de respaldo que se asocia con cada una de las tres fases en la época actual; un transmisor o unidad transmisora 1504, que se configura para enviar un mensaje EPOCH_CHANGE al número de nodos de red distintos al nodo de red en respuesta a la determinación de que la suma de pesos alcanza un primer umbral predeterminado, en donde el mensaje EPOCH_CHANGE indica una solicitud de cambio del época actual con el nodo primario actual a la nueva época con el nodo de respaldo siendo el nuevo nodo primario, y el mensaje EPOCH_CHANGE incluye la suma de pesos del nodo de respaldo; un receptor o unidad receptora 1506, que se configura para recibir al menos un mensaje NEW_EP0CH de al menos uno del número de nodos de red distintos del nodo de respaldo, en donde el mensaje NEW_EP0CH indica un reconocimiento del nodo de respaldo como el nuevo nodo primario; una unidad de verificación 1508, que se configura para verificar si al menos un mensaje NEW_EP0CH es válido; la unidad de determinación 1502, que se configura además para determinar si un número de mensajes NEW_EP0CH válidos de al menos un mensaje NEW_EP0CH excede un segundo umbral predeterminado; y la unidad de determinación 1502, que se configura además para determinar que el nodo de respaldo sea el nuevo nodo primario en la nueva época en respuesta a la determinación de que el número de mensajes NEW_EP0CH válidos excede el segundo umbral predeterminado.

En una implementación opcional, determinar un peso respectivo del nodo de respaldo que se asocia con cada una de las tres fases del proceso de consenso en la época actual incluye determinar un peso del nodo de respaldo para que una primera fase del proceso de consenso sea un primer valor.

En una implementación opcional, determinar un peso respectivo del nodo de respaldo que se asocia con cada una de las tres fases del proceso de consenso en la época actual incluye lo siguiente: en respuesta a la determinación de un fallo de una verificación de quórum en una segunda fase del proceso de consenso en la época actual, determinar que un peso del nodo de respaldo para la segunda fase del proceso de consenso sea un primer valor; y en respuesta a determinar el éxito de una verificación de quórum en la segunda fase del proceso de consenso en la época actual, determinar que el peso del nodo de respaldo para la segunda fase del proceso de consenso sea un segundo valor, en donde el primer valor es menor que el segundo valor.

En una implementación opcional, la verificación de quórum en la segunda fase para el nodo de red incluye recibir un número predeterminado de mensajes ECHO de otros nodos de red.

En una implementación opcional, determinar un peso respectivo del nodo de respaldo que se asocia con cada una de las tres fases del proceso de consenso en la época actual incluye lo siguiente: en respuesta a la determinación de un fallo de una verificación de quórum en una tercera fase del consenso proceso en la época actual, determinar que un peso del nodo de respaldo para la tercera fase del proceso de consenso sea un tercer valor; y en respuesta a determinar el éxito de una verificación de quórum en la tercera fase del proceso de consenso en la época actual, determinar que el peso del nodo de respaldo para la tercera fase del proceso de consenso es un cuarto valor, en donde el tercer valor es menor que el cuarto valor.

En una implementación opcional, la verificación de quórum en la tercera fase para el nodo de red incluye recibir un número predeterminado de mensajes de aceptación de otros nodos de red, en donde cada uno de los mensajes de aceptación de otros nodos de red indica que cada uno de los otros nodos de red ha aceptado un número predeterminado de mensajes ECHO.

En una implementación opcional, el mensaje EPOCH_CHANGE incluye además un conjunto de firmas que se asocian con un conjunto de nodos de red del número de nodos de red, y en donde el mensaje NEW_EPOCH comprende un resumen del mensaje EPOCH_CHANGE.

En una implementación opcional, la verificación de si al menos un mensaje NEW_EPOCH válido es válido incluye verificar si el resumen del mensaje EPOCH_CHANGE en al menos un mensaje NEW_EPOCH es válido, y verificar si el resumen del mensaje EPOCH_CHANGE en al menos un mensaje NEW_EPOCH es válido incluye verificar si el conjunto de firmas en el mensaje EPOCH_CHANGE es válido.

En una implementación opcional, la determinación de que es necesario realizar un cambio de época incluye determinar que es necesario realizar un cambio de época en respuesta a la determinación de que no se ha logrado el consenso en la época antigua dentro de un período de tiempo predeterminado.

En una implementación opcional, el aparato 1500 de cambio de nodo primario incluye además lo siguiente: una unidad de operación 1510, que se configura para operar en la nueva época con el nuevo nodo primario, en donde la nueva época comprende un proceso de consenso para lograr consenso entre la pluralidad de nodos de red que usan el nuevo nodo primario.

La Figura 15 es un diagrama esquemático que ilustra un módulo funcional interno y una estructura de un aparato 1500 de cambio de nodo primario. En esencia, un organismo de ejecución puede ser un dispositivo electrónico, y el dispositivo electrónico incluye lo siguiente: al menos un procesador; y una memoria que se configura para almacenar una instrucción ejecutable de al menos un procesador.

Al menos un procesador se configura para determinar que debe realizarse un cambio de época, en donde el cambio de época provoca un cambio de una época actual con un nodo primario actual a una nueva época con un nuevo nodo primario, en donde la época actual comprende un proceso de consenso para lograr consenso entre el número de nodos de red que usan el nodo primario, el proceso de consenso que incluye tres fases; determinar un peso respectivo del nodo de respaldo que se asocia con cada una de las tres fases del proceso de consenso en la época actual, en donde el peso es una métrica de una calificación del nodo de respaldo para ser el nuevo nodo primario; determinar una suma de pesos para el nodo de respaldo basándose en el peso respectivo del nodo de respaldo que se asocia con cada una de las tres fases en la época actual; enviar un mensaje EPOCH_CHANGE al número de nodos de red que no sean el nodo de red en respuesta a la determinación de que la suma de pesos alcanza un primer umbral predeterminado, en donde el mensaje EPOCH_CHANGE indica una solicitud de cambio de la época actual con el nodo primario actual a la nueva época en la que el nodo de respaldo es el nuevo nodo primario, y el mensaje EPOCH_CHANGE incluye la suma de pesos del nodo de respaldo; recibir al menos un mensaje NEW_EPOCH de al menos uno del número de nodos de red distintos del nodo de respaldo, en donde el mensaje NEW_EPOCH indica un reconocimiento del nodo de respaldo como el nuevo nodo primario; verificar si al menos un mensaje NEW_EPOCH es válido; determinar si un número de mensajes NEW_EPOCh válidos de al menos un mensaje NEW_EPOCH excede un segundo umbral predeterminado; y determinar que el nodo de respaldo sea el nuevo nodo primario en la nueva época en respuesta a la determinación de que el número de mensajes NEW_EPOCH válidos excede el segundo umbral predeterminado.

Opcionalmente, determinar un peso respectivo del nodo de respaldo que se asocia con cada una de las tres fases del proceso de consenso en la época actual incluye determinar un peso del nodo de respaldo para que una primera fase del proceso de consenso sea un primer valor.

Opcionalmente, determinar un peso respectivo del nodo de respaldo que se asocia con cada una de las tres fases del proceso de consenso en la época actual incluye lo siguiente: en respuesta a la determinación de un fallo de una verificación de quórum en una segunda fase del proceso de consenso en la época actual, determinar que un peso del nodo de respaldo para la segunda fase del proceso de consenso sea un primer valor; y en respuesta a determinar el éxito de una verificación de quórum en la segunda fase del proceso de consenso en la época actual, determinar que el peso del nodo de respaldo para la segunda fase del proceso de consenso sea un segundo valor, en donde el primer valor es menor que el segundo valor.

Opcionalmente, la verificación de quórum en la segunda fase para el nodo de red incluye recibir un número predeterminado de mensajes ECHO de otros nodos de red.

Opcionalmente, determinar un peso respectivo del nodo de respaldo que se asocia con cada una de las tres fases del proceso de consenso en la época actual incluye lo siguiente: en respuesta a la determinación de un fallo de una verificación de quórum en una tercera fase del consenso proceso en la época actual, determinar que un peso del nodo de respaldo para la tercera fase del proceso de consenso sea un tercer valor; y en respuesta a determinar el éxito de una verificación de quórum en la tercera fase del proceso de consenso en la época actual, determinar que el peso del nodo de respaldo para la tercera fase del proceso de consenso es un cuarto valor, en donde el tercer valor es menor que el cuarto valor.

Opcionalmente, la verificación de quórum en la tercera fase para el nodo de red incluye recibir un número predeterminado de mensajes de aceptación de otros nodos de red, en donde cada uno de los mensajes de aceptación de otros nodos de red indica que cada uno de los otros nodos de red ha aceptado un número predeterminado de mensajes ECHO.

Opcionalmente, el mensaje EPOCH_CHANGE incluye además un conjunto de firmas que se asocian con un conjunto de nodos de red del número de nodos de red, y en donde el mensaje NEW_EP0CH comprende un resumen del mensaje EPOCH_CHANGE.

Opcionalmente, la verificación de si al menos un mensaje NEW_EPOCH válido es válido incluye verificar si el resumen del mensaje EPOCH_CHANGE en al menos un mensaje NEW_EPOCH es válido, y verificar si el resumen del mensaje EPOCH_CHANGE en al menos un mensaje NEW_EPOCH es válido incluye verificar si el conjunto de firmas en el mensaje EPOCH_CHANGE es válido.

Opcionalmente, la determinación de que es necesario realizar un cambio de época incluye determinar que es necesario realizar un cambio de época en respuesta a la determinación de que no se ha logrado el consenso en la época antigua dentro de un período de tiempo predeterminado.

Opcionalmente, al menos un procesador se configura además para operar en la nueva época con el nuevo nodo primario, en donde la nueva época comprende un proceso de consenso para lograr consenso entre la pluralidad de nodos de red que usan el nuevo nodo primario.

Refiriéndose a la Figura 16, la Figura 16 es un diagrama que ilustra módulos de un aparato 1600 de cambio de nodo primario, de acuerdo con una implementación de la presente especificación. El aparato 1600 para cambiar un nodo primario puede aplicarse a un sistema de consenso en base a una tecnología de cadena de bloques. El aparato 1600 corresponde a las implementaciones que se muestran en las Figuras 7-9. Por ejemplo, el aparato 1400 puede implementarse en un nodo de red de una red de cadena de bloques. El aparato 1600 incluye lo siguiente: un receptor o unidad receptora 1602, que se configura para recibir un mensaje EPCOH_CHANGE desde un nodo de respaldo que no sea el nodo de red, en donde el mensaje EPOCH_CHANGE incluye una indicación de que debe realizarse un cambio de época, en donde el cambio de época provoca un cambio de una época actual con un nodo primario actual a una nueva época con un nuevo nodo primario; una unidad de verificación 1604, que se configura para verificar si el mensaje EPOCH_CHANGE es válido; un transmisor o unidad transmisora 1606, que se configura para enviar un mensaje NEW_EPOCH a los otros nodos de red en respuesta a verificar que el mensaje EPOCH_CHANGE es válido, en donde el mensaje NEW_EPOCH comprende un resumen del mensaje EPOCH_CHANGE; el receptor o unidad receptora 1602, que se configura además para recibir al menos un mensaje NEW_EP0CH de al menos uno del número de nodos de red distintos del nodo de red; la unidad de verificación 1604, que se configura además para verificar si al menos un mensaje NEW_EPOCH es válido; una unidad de determinación 1608, que se configura para determinar si un número de mensajes NEW_EP0CH válidos de al menos un mensaje NEW_EP0Ch excede un umbral predeterminado; y la unidad de determinación 1608, que se configura además para determinar que el nodo de respaldo sea el nuevo nodo primario en la nueva época en respuesta a la determinación de que el número de mensajes NEW_EP0CH válidos excede el umbral predeterminado.

En una implementación opcional, el mensaje EPOCH_CHANGE incluye una suma de pesos que se asocia con el nodo de respaldo y un conjunto de firmas que se asocian con un conjunto de nodos de red del número de nodos de red.

En una implementación opcional, la verificación de si el mensaje EPOCH_CHANGE es válido incluye verificar si la suma de pesos en el mensaje EPOCH_CHANGE es válida, y la verificación de si la suma de pesos en el mensaje EPOCH_CHANGE es válida incluye verificar si el conjunto de firmas es válido.

En una implementación opcional, la verificación de si al menos un mensaje NEW_EP0CH es válido incluye verificar si el resumen del mensaje EPOCH_CHANGE en al menos un mensaje NEW_EP0CH es válido, y la verificación de si el resumen del mensaje EPOCH_CHANGE en al menos un mensaje NEW_EP0CH es válido incluye verificar si el conjunto de firmas en el mensaje EPOCH_CHANGE es válido.

La Figura 16 es un diagrama esquemático que ilustra un módulo funcional interno y una estructura de un aparato 1600 de cambio de nodo primario. En esencia, un cuerpo de ejecución puede ser un dispositivo electrónico, y el dispositivo electrónico incluye lo siguiente: al menos un procesador; y una memoria que se configura para almacenar una instrucción ejecutable de al menos un procesador.

Al menos un procesador se configura para recibir un mensaje EPOCH_CHANGE de un nodo de respaldo que no sea el nodo de red, en donde el mensaje EPOCH_CHANGE incluye una indicación de que es necesario realizar un cambio de época, en donde el cambio de época provoca un cambio de una época actual con un nodo primario actual a una nueva época con un nuevo nodo primario; verificar si el mensaje EPOCH_CHANGE es válido; enviar un mensaje NEW_EPOCH a los otros nodos de red en respuesta a la verificación de que el mensaje EPOCH_CHANGE es válido, en donde el mensaje NEW_EPOCH comprende un resumen del mensaje EPOCH_CHANGE; recibir al menos un mensaje NEW_EPOCH de al menos uno del número de nodos de red distintos del nodo de red; verificar si al menos un mensaje NEW_EPOCH es válido; determinar si un número de mensajes NEW_EPOCH válidos de al menos un mensaje NEW_EPOCH excede un umbral predeterminado; y determinar que el nodo de respaldo sea el nuevo nodo primario en la nueva época en respuesta a la determinación de que el número de mensajes NEW_EPOCH válidos excede el umbral predeterminado.

Opcionalmente, el mensaje EPOCH_CHANGE incluye una suma de pesos que se asocia con el nodo de respaldo y un conjunto de firmas que se asocian con un conjunto de nodos de red del número de nodos de red.

Opcionalmente, la verificación de si el mensaje EPOCH_CHANGE es válido incluye verificar si la suma de pesos en el mensaje EPOCH_CHANGE es válida, y la verificación de si la suma de pesos en el mensaje EPOCH_CHANGE es válida incluye verificar si el conjunto de firmas es válido.

Opcionalmente, la verificación de si al menos un mensaje NEW_EPOCH es válido incluye verificar si el resumen del mensaje EPOCH_CHANGE en al menos un mensaje NEW_EPOCH es válido, y la verificación de si el resumen del mensaje EPOCH_CHANGE en al menos un mensaje NEW_EP0CH es válido incluye verificar si el conjunto de firmas en el mensaje EPOCH_CHANGE es válido.

Refiriéndose a la Figura 17, la Figura 17 es un diagrama que ilustra módulos de un aparato de recuperación 1700, de acuerdo con una implementación de la presente especificación. El aparato 1700 para la recuperación puede aplicarse a un sistema de consenso en base a una tecnología de cadena de bloques. El aparato 1700 puede corresponder a las implementaciones que se muestran en las Figuras 10-12. Por ejemplo, el aparato 1700 puede implementarse en un nodo de red de una red de cadena de bloques. El aparato 1700 incluye lo siguiente: una unidad de difusión 1702, que se configura para difundir, mediante un nodo de red de una red de cadena de bloques, un mensaje de solicitud de estado a un número de otros nodos de red de la red de cadena de bloques, en donde el nodo de red debe recuperar una transacción objetivo de un número de secuencia objetivo; un receptor 1704 o una unidad receptora 1704, que se configura para recibir un número de mensajes de respuesta de estado del número de otros nodos de red, en donde cada uno de los mensajes de respuesta de estado incluye un número de secuencia; una unidad de identificación 1706, que se configura para identificar el número de secuencia objetivo en base al mismo número de secuencia en respuesta a la determinación de que un número de mensajes de respuesta de estado excede un umbral predeterminado, en donde cada uno del número de mensajes de estado comprende un mismo número de secuencia; un transmisor 1708 o una unidad transmisora 1708, que se configura para enviar un mensaje de solicitud al número de otros nodos de red, en donde el mensaje de solicitud solicita un mensaje ECHO de cada uno de los otros nodos de red, en donde el mensaje ECHO es un mensaje que se transmite mediante cada uno del número de otros nodos de red para lograr un consenso entre el número de otros nodos de red sobre la transacción objetivo que tiene el número de secuencia objetivo, y el mensaje ECHO incluye una parte de la transacción objetivo y una firma de cada uno de los números de otros nodos de red; el receptor 1704 o la unidad receptora 1704, que se configuran además para recibir un número de mensajes ECHO del número de otros nodos de red; una unidad de determinación 1710, que se configura para determinar un número de mensajes ECHO válidos entre el número de mensajes ECHO, en donde cada uno del número de mensajes ECHO válidos incluye el número de secuencia objetivo; una unidad de recuperación 1712, que se configura para recuperar la transacción objetivo que tiene el mismo número de secuencia en el nodo de red basándose en el número de mensajes ECHO válidos en respuesta a la determinación de que el número de mensajes ECHO válidos excede un umbral predeterminado; y el transmisor 1708, que se configura además para enviar un mensaje al número de otros nodos de red indicando que el nodo de la red se ha recuperado.

En una implementación opcional, el número de nodos de red incluye un nodo primario y uno o más nodos de respaldo.

En una implementación opcional, el nodo de red es un nodo primario o un nodo de respaldo.

En una implementación opcional, el mensaje de solicitud incluye el número de secuencia objetivo.

En una implementación opcional, el aparato de recuperación 1700 incluye además lo siguiente: una unidad de verificación 1714, que se configura para verificar, mediante cada uno de los otros nodos de red distintos del nodo de red, el mensaje de solicitud antes de enviar los mensajes ECHO al nodo de red.

En una implementación opcional, la unidad de verificación 1714 se configura además para verificar si cada uno de los mensajes ECHO es válido, en donde la verificación de si cada uno de los mensajes ECHO es válido incluye verificar si cada uno de los mensajes ECHO es válido mediante el uso de un árbol Merkel.

En una implementación opcional, la verificación de si cada uno de los mensajes ECHO es válido incluye además verificar si la firma en el mensaje ECHO es válida.

En una implementación opcional, cada uno de los mensajes ECHO incluye además al menos uno de un número de bloques de código de borrado (EC) que se asocian con la transacción objetivo, en donde el número de bloques EC se genera de acuerdo con un código EC mediante el uso de la transacción objetivo.

En una implementación opcional, la recuperación de la transacción objetivo que tiene el mismo número de secuencia en el nodo de la red en base al número de mensajes ECHO válidos comprende reconstruir la transacción objetivo mediante el uso de un subconjunto de la pluralidad de bloques EC que están en el número de mensajes ECHO válidos.

En una implementación opcional, el mensaje al número de otros nodos de red que indica que el nodo de red se ha recuperado incluye un conjunto de firmas en el número de mensajes ECHO válidos y el número de secuencia objetivo.

El sistema, el aparato, el módulo o la unidad que se ilustran en las implementaciones anteriores pueden implementarse mediante el uso de un chip de ordenador o una entidad, o pueden implementarse mediante el uso de un producto con una determinada función. Un dispositivo de implementación normal es un ordenador, y el ordenador puede ser un ordenador personal, un ordenador portátil, un teléfono celular, un teléfono con cámara, un teléfono inteligente, un asistente digital personal, un reproductor multimedia, un dispositivo de navegación, un dispositivo de correo electrónico, una consola de juegos, una tableta, dispositivo portátil o una combinación de cualquiera de estos dispositivos.

Para un proceso de implementación de funciones y roles de cada unidad en el aparato, pueden hacerse referencias a un proceso de implementación de etapas correspondientes en el método anterior. Los detalles se omiten aquí por simplicidad.

Debido a que la implementación de un aparato corresponde básicamente a la implementación de un método, para las partes relacionadas, pueden hacerse referencias a las descripciones relacionadas en la implementación del método. La implementación del aparato descrita anteriormente es simplemente un ejemplo. Las unidades descritas como partes separadas pueden o no estar físicamente separadas, y las partes que se muestran como unidades pueden o no ser unidades físicas, pueden ubicarse en una posición o pueden distribuirse en una pluralidad de unidades de red. Algunos o todos los módulos pueden seleccionarse basándose en las demandas reales para lograr los objetivos de las soluciones de la presente especificación. Un experto en la técnica puede comprender e implementar las implementaciones de la presente solicitud sin tener que realizar esfuerzos creativos.

La Figura 17 es un diagrama esquemático que ilustra un módulo funcional interno y una estructura de un aparato de recuperación 1700. En esencia, un organismo de ejecución puede ser un dispositivo electrónico, y el dispositivo electrónico incluye lo siguiente: al menos un procesador; y una memoria que se configura para almacenar una instrucción ejecutable de al menos un procesador.

Al menos un procesador se configura para transmitir, mediante un nodo de red de una red de cadena de bloques, un mensaje de solicitud de estado a una serie de otros nodos de red de la red de cadena de bloques, en donde el nodo de red debe recuperar una transacción objetivo de un número de secuencia objetivo; recibir un número de mensajes de respuesta de estado del número de otros nodos de red, en donde cada uno de los mensajes de respuesta de estado incluye un número de secuencia; identificar el número de secuencia objetivo basándose en el mismo número de secuencia en respuesta a la determinación de que un número de mensajes de respuesta de estado excede un umbral predeterminado, en donde cada uno del número de mensajes de estado comprende un mismo número de secuencia; enviar un mensaje de solicitud al número de otros nodos de red, en donde el mensaje de solicitud solicita un mensaje ECHO de cada uno de los otros nodos de red, en donde el mensaje ECHO es un mensaje que se transmite mediante cada uno de los otros nodos de red para lograr un consenso entre el número de otros nodos de red sobre la transacción objetivo que tiene el número de secuencia objetivo, y el mensaje ECHO incluye una parte de la transacción objetivo y una firma de cada uno de los otros nodos de red; recibir un número de mensajes ECHO de la pluralidad de otros nodos de red; determinar un número de mensajes ECHO válidos a partir del número de mensajes ECHO, en donde cada uno de los mensajes ECHO válidos incluye el número de secuencia objetivo; recuperar la transacción objetivo que tiene el mismo número de secuencia en el nodo de red basándose en el número de mensajes ECHO válidos en respuesta a la determinación de que el número de mensajes ECHO válidos excede un umbral predeterminado; y enviar un mensaje al número de otros nodos de red indicando que se ha recuperado el nodo de la red.

Opcionalmente, el número de nodos de red incluye un nodo primario y uno o más nodos de respaldo.

Opcionalmente, el nodo de red es un nodo primario o un nodo de respaldo.

Opcionalmente, el mensaje de solicitud incluye el número de secuencia objetivo.

Opcionalmente, al menos un procesador se configura además para verificar, mediante cada uno de los otros nodos de red distintos del nodo de red, el mensaje de solicitud antes de enviar los mensajes ECHO al nodo de red.

Opcionalmente, al menos un procesador se configura además para verificar si cada uno de los mensajes ECHO es válido, en donde la verificación de si cada uno de los mensajes ECHO es válido incluye verificar si cada uno de los mensajes ECHO es válido mediante el uso de un árbol Merkel.

Opcionalmente, la verificación de si cada uno de los mensajes ECHO es válido incluye además verificar si la firma en el mensaje ECHO es válida.

Opcionalmente, cada uno de los mensajes ECHO incluye además al menos uno de un número de bloques de código de borrado (EC) que se asocian con la transacción objetivo, en donde el número de bloques EC se genera de acuerdo con un código EC mediante el uso de la transacción objetivo.

Opcionalmente, recuperar la transacción objetivo que tiene el mismo número de secuencia en el nodo de red en base al número de mensajes ECHO válidos incluye reconstruir la transacción objetivo mediante el uso de un subconjunto del número de bloques EC que están en el número de mensajes ECHO válidos.

Opcionalmente, el mensaje al número de otros nodos de red que indica que el nodo de red se ha recuperado incluye un conjunto de firmas en el número de mensajes ECHO válidos y el número de secuencia objetivo.

Las implementaciones del tema en cuestión y las acciones y operaciones descritas en esta especificación pueden implementarse en circuitos electrónicos digitales, en software o firmware de ordenador que se incorporan de manera tangible, en hardware de ordenador, que incluye las estructuras descritas en esta especificación y sus equivalentes estructurales, o en combinaciones de uno o más de ellos. Las implementaciones del tema descrito en esta especificación se pueden implementar como uno o más programas informáticos, por ejemplo, uno o más módulos de instrucciones de programa informático, codificados en un soporte de programa informático, para su ejecución o para controlar la operación de procesamiento del aparato de procesamiento de datos. El portador puede ser un medio de almacenamiento informático tangible no transitorio. Alternativamente, o, además, el portador puede ser una señal propagada que se genera artificialmente, por ejemplo, una señal eléctrica, óptica o electromagnética generada por una máquina que se genera para codificar información para su transmisión a un aparato receptor adecuado para su ejecución por un aparato de procesamiento de datos. El medio de almacenamiento informático puede ser o ser parte de un dispositivo de almacenamiento legible por máquina, un sustrato de almacenamiento legible por máquina, un dispositivo de memoria de acceso aleatorio o en serie, o una combinación de uno o más de ellos. Un medio de almacenamiento informático no es una señal propagada.

El término "aparato de procesamiento de datos" abarca todo tipo de aparatos, dispositivos y máquinas para procesar datos, que incluyen, a modo de ejemplo, un procesador programable, un ordenador o múltiples procesadores u ordenadores. Los aparatos de procesamiento de datos pueden incluir circuitos lógicos de propósito especial, por ejemplo, una FPGA (matriz de puertas programables en campo), un ASIC (circuito integrado de aplicación específica) o una GPU (unidad de procesamiento de gráficos). El aparato también puede incluir, además del hardware, el código que crea un entorno de ejecución para programas informáticos, por ejemplo, el código que constituye el firmware del procesador, una pila de protocolos, un sistema de gestión de bases de datos, un sistema operativo o una combinación de uno o más de ellos.

Un programa informático, que también puede denominarse o describirse como un programa, software, una aplicación de software, una aplicación, un módulo, un módulo de software, un motor, una secuencia de comandos o un código, puede escribirse en cualquier forma de lenguaje de programación, que incluyen los lenguajes compilados o interpretados, o los lenguajes declarativos o de procedimiento; y puede implementarse en cualquier forma, incluso como un programa independiente o como un módulo, componente, motor, subrutina u otra unidad adecuada para ejecutarse en un entorno informático, cuyo entorno puede incluir uno o más ordenadores interconectados por una red de comunicación de datos en una o más ubicaciones.

Un programa informático puede, pero no necesariamente, corresponder a un archivo en un sistema de archivos. Un programa informático puede almacenarse en una parte de un archivo que contiene otros programas o datos, por ejemplo, uno o más scripts almacenados en un documento de lenguaje de marcado, en un único 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.

Los procesos y flujos lógicos descritos en esta especificación pueden realizarse mediante uno o más ordenadores que ejecutan uno o más programas informáticos para realizar operaciones al operar con datos de entrada y generar salida. Los procesos y flujos lógicos también pueden realizarse mediante circuitos lógicos de propósito especial, por ejemplo, un FPGA, un ASIC o una GPU, o mediante una combinación de circuitos lógicos de propósito especial y uno o más ordenadores programados.

Los ordenadores adecuados para la ejecución de un programa informático pueden basarse en microprocesadores de propósito general o especial o ambos, o cualquier otro tipo de unidad central de procesamiento. Generalmente, una unidad central de procesamiento recibirá instrucciones y datos desde una memoria de solo lectura o una memoria de acceso aleatorio o ambas. Los elementos de un ordenador pueden incluir una unidad central de procesamiento para ejecutar instrucciones y uno o más dispositivos de memoria para almacenar instrucciones y datos. La unidad central de procesamiento y la memoria pueden complementarse o incorporarse en un circuito lógico de propósito especial.

Generalmente, un ordenador se acoplará al menos a un medio de almacenamiento legible por ordenador no transitorio (también denominado memoria legible por ordenador). El medio de almacenamiento que se acopla al ordenador puede ser un componente interno del ordenador (por ejemplo, un disco duro integrado) o un componente externo (por ejemplo, un disco duro de bus serie universal (USB) o un sistema de almacenamiento al que se accede a través de una red). Los ejemplos de medios de almacenamiento pueden incluir, por ejemplo, discos magnéticos, magnetoópticos u ópticos, unidades de estado sólido, recursos de almacenamiento en red tales como sistemas de almacenamiento en la nube u otros tipos de medios de almacenamiento. Sin embargo, un ordenador no necesita tener tales dispositivos. Además, un ordenador puede integrarse en otro dispositivo, por ejemplo, un teléfono móvil, un asistente digital personal (PDA), un reproductor de audio o video móvil, una consola de juegos, un receptor del Sistema de Posicionamiento Global (GPS) o un dispositivo de almacenamiento portátil, por ejemplo, una unidad flash de bus serie universal (USB), por nombrar solo algunos.

Para permitir la interacción con un usuario, las implementaciones del tema descrito en esta especificación pueden implementarse o configurarse para comunicarse con un ordenador que tenga un dispositivo de visualización, por ejemplo, un monitor LCD (pantalla de cristal líquido), para mostrar información a el usuario, y un dispositivo de entrada mediante el cual el usuario puede proporcionar entrada al ordenador, por ejemplo, un teclado y un dispositivo señalador, por ejemplo, un ratón, una bola de seguimiento o un panel táctil. También pueden usarse otros tipos de dispositivos para proporcionar 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 puede recibirse en cualquier forma, que incluyen la entrada acústica, de voz o táctil. Además, un ordenador puede interactuar con un usuario al enviar y recibir documentos de un dispositivo que usa el usuario; por ejemplo, al enviar páginas web a un navegador web en un dispositivo del usuario en respuesta a solicitudes recibidas del navegador web, o al interactuar con una aplicación que se ejecuta en un dispositivo del usuario, por ejemplo, un teléfono inteligente o una tableta. Además, un ordenador puede interactuar con un usuario enviando mensajes de texto u otras formas de mensaje a un dispositivo personal, por ejemplo, un teléfono inteligente que ejecuta una aplicación de mensajería y, a cambio, recibe mensajes de respuesta del usuario.

Esta especificación usa el término "se configura para" en relación con sistemas, aparatos y componentes de programas informáticos. Para que un sistema de uno o más ordenadores se configure para realizar operaciones o acciones particulares significa que el sistema tiene instalado software, firmware, hardware o una combinación de ellos que, en funcionamiento, hacen que el sistema realice las operaciones o acciones. Para que uno o más programas de ordenador se configuren para realizar operaciones o acciones particulares significa que uno o más programas incluyen instrucciones que, cuando se ejecutan mediante un aparato de procesamiento de datos, hacen que el aparato realice las operaciones o acciones. Para que un circuito lógico de propósito especial se configure para realizar operaciones o acciones particulares, significa que el circuito tiene lógica electrónica que realiza las operaciones o acciones.

Si bien esta especificación contiene muchos detalles de implementación específicos, estos no deben interpretarse como limitaciones en el alcance de lo que se está reclamando, que está definido por las propias declaraciones, sino más bien como descripciones de características que pueden ser especificaciones en el contexto de implementaciones separadas también puede realizarse en combinación en una sola implementación. A la inversa, diferentes características que se describen en el contexto de una sola implementación también pueden realizarse en múltiples implementaciones por separado o en cualquier subcombinación adecuada. Además, aunque las características pueden describirse anteriormente como que actúan en ciertas combinaciones e incluso inicialmente reivindicarse como tales, una o más características de una combinación reivindicada pueden en algunos casos eliminarse de la combinación, y la reivindicación puede dirigirse a una subcombinación o variación de una subcombinación.

De manera similar, aunque las operaciones se describen en los dibujos y se enumeran en las reivindicaciones en un orden particular, esto no debe entenderse como que requiere que dichas operaciones se realicen en el orden particular que se muestra o en orden secuencial, o que todas las operaciones ilustradas se realicen, para lograr resultados deseables. En determinadas circunstancias, la multitarea y el procesamiento en paralelo pueden resultar ventajosos. Además, la separación de diferentes módulos y componentes del sistema en las implementaciones descritas anteriormente no debe entenderse que requiera dicha separación en todas las implementaciones, y debe entenderse que los componentes y sistemas del programa descritos generalmente pueden integrarse juntos en un solo producto de software o empaquetado en múltiples productos de software.

Se han descrito implementaciones particulares del tema. Por ejemplo, las acciones enumeradas en las reivindicaciones pueden realizarse en un orden diferente y aun así lograr resultados deseables. Como ejemplo, los procesos descritos en las figuras adjuntas no requieren necesariamente el orden particular que se muestra, o el orden secuencial, para lograr resultados deseables. En algunos casos, la multitarea y el procesamiento en paralelo pueden resultar ventajosos.

Claims

REIVINDICACIONES

1. Un método que se implementa mediante ordenador (1100) para realizar un proceso de recuperación de un nodo de red (1102) de una red de cadena de bloques (102, 212), el método que comprende:

difundir (1106), mediante el nodo de red de la red de cadena de bloques, un mensaje de solicitud de estado a una pluralidad de otros nodos de red (1104) de la red de cadena de bloques, en donde el nodo de red debe recuperar una transacción objetivo de un número de secuencia objetivo, el mensaje de solicitud comprende el número de secuencia objetivo, y el número de secuencia objetivo representa un número de secuencia mayor o un número de secuencia más reciente para el nodo de red;

recibir (1108), mediante el nodo de red, una pluralidad de mensajes de respuesta de estado de la pluralidad de otros nodos de red, en donde cada uno de la pluralidad de mensajes de respuesta de estado comprende un número de secuencia;

determinar (1110) si un número de mensajes de respuesta de estado excede un primer umbral predeterminado, en donde cada uno de los mensajes de estado comprende un mismo número de secuencia;

si el número de mensajes de respuesta de estado excede el primer umbral predeterminado, identificar (1112), mediante el nodo de red, el número de secuencia objetivo en base al mismo número de secuencia;

enviar (1114), mediante el nodo de red, un mensaje de solicitud a la pluralidad de otros nodos de red, en donde el mensaje de solicitud solicita un mensaje ECHO de cada uno de la pluralidad de otros nodos de red, el mensaje ECHO es un mensaje que se transmite mediante cada uno de la pluralidad de otros nodos de red para lograr un consenso entre la pluralidad de otros nodos de red sobre la transacción objetivo que tiene el número de secuencia objetivo, y el mensaje ECHO comprende una parte de la transacción objetivo y una firma de cada uno de la pluralidad de otros nodos de red;

recibir (1116), mediante el nodo de red, una pluralidad de mensajes ECHO de la pluralidad de otros nodos de red;

determinar, mediante el nodo de red, un número de mensajes ECHO válidos de la pluralidad de mensajes ECHO, en donde cada uno del número de mensajes ECHO válidos comprende el número de secuencia objetivo;

determinar (1120) si el número de mensajes ECHO válidos excede un segundo umbral predeterminado;

si el número de mensajes ECHO válidos excede el segundo umbral predeterminado, recuperar (1122), mediante el nodo de red, la transacción objetivo que tiene el mismo número de secuencia en el nodo de red basándose en el número de mensajes ECHO válidos; y enviar (1124), mediante el nodo de red, un mensaje a la pluralidad de otros nodos de red indicando que el nodo de red se ha recuperado.

2. El método (1100) de la reivindicación 1, en donde la pluralidad de nodos de red (1104) comprende un nodo primario y uno o más nodos de respaldo.

3. El método (1100) de la reivindicación 1, en donde el nodo de red (1102) es un nodo primario o un nodo de respaldo.

4. El método (1100) de cualquiera de las reivindicaciones 1 a 3, en donde el método comprende, además:

verificar, mediante cada uno de la pluralidad de otros nodos de red (1104) distintos del nodo de red (1102), el mensaje de solicitud antes de enviar los mensajes ECHO al nodo de red.

5. El método (1100) de la reivindicación 1, en donde el método comprende, además:

verificar (1118), mediante el nodo de red (1102), si cada uno de los mensajes ECHO es válido, en donde la verificación de si cada uno de los mensajes ECHO es válido comprende verificar si cada uno de los mensajes ECHO es válido mediante el uso de un árbol Merkel.

6. El método (1100) de la reivindicación 5, en donde verificar (1118) si cada uno de los mensajes ECHO es válido comprende además verificar si la firma en el mensaje ECHO es válida.

7. El método (1100) de la reivindicación 1, en donde cada uno de los mensajes ECHO comprende además al menos uno de una pluralidad de bloques de código de borrado (EC) que se asocian con la transacción objetivo, en donde la pluralidad de bloques EC se generan de acuerdo con un código EC mediante el uso de la transacción objetivo.

8 El método (1100) de la reivindicación 1, en donde recuperar la transacción objetivo que tiene el mismo número de secuencia en el nodo de red en base al número de mensajes ECHO válidos comprende reconstruir la transacción objetivo mediante el uso de un subconjunto de la pluralidad de bloques EC que están en el número de mensajes ECHO válidos.

9 El método (1100) de la reivindicación 1, en donde el mensaje a la pluralidad de otros nodos de red que indica que el nodo de red se ha recuperado comprende un conjunto de firmas en el número de mensajes ECHO válidos y el número de secuencia objetivo.

10. Un medio de almacenamiento legible por ordenador no transitorio que se acopla a uno o más ordenadores y se configura con instrucciones ejecutables mediante uno o más ordenadores para realizar el método (1100) de cualquiera de las reivindicaciones 1 a 9.

11. Un sistema que comprende:

uno o más ordenadores; y

una o más memorias legibles por ordenador que se acoplan a uno o más ordenadores y se configuran con instrucciones ejecutables por uno o más ordenadores para realizar el método (1100) de cualquiera de las reivindicaciones 1 a 9.