ES2827301T3

ES2827301T3 - Sistema de cadena de bloques y método y aparato de almacenamiento de datos

Info

Publication number: ES2827301T3
Application number: ES18754500T
Authority: ES
Inventors: Ning Li
Original assignee: Advanced New Technologies Co Ltd
Current assignee: Advanced New Technologies Co Ltd
Priority date: 2017-02-17
Filing date: 2018-02-12
Publication date: 2021-05-20
Anticipated expiration: 2038-02-12
Also published as: SG10202005442PA; MX2019009435A; AU2019101605A4; EP3754941B1; US20200153612A1; US10749669B2; US10855449B2; PL3562120T3; TWI684105B; PH12019501702A1; US10505720B2; EP3562120A1; CA3051025C; CN107018125B; EP3562120B1; EP3754941A1; US20200336298A1; JP2020512617A; AU2018222076B2; RU2732535C1

Abstract

Un sistema de cadena de bloques, que comprende un centro de distribución (102), un subsistema sin consenso (101) y una pluralidad de subsistemas de consenso (103), en el que el subsistema sin consenso (101) comprende una pluralidad de nodos sin consenso y cada uno de los subsistemas de consenso comprende una pluralidad de nodos de consenso; un nodo sin consenso de la pluralidad de nodos sin consenso envía una solicitud de transacción al centro de distribución (102); el centro de distribución (102) recibe la solicitud de transacción del subsistema sin consenso, determina un subsistema de consenso (103) correspondiente a la solicitud de transacción según los datos de la transacción comprendidos en la solicitud de transacción y reenvía la solicitud de transacción al subsistema de consenso (103) determinado; y el subsistema de consenso (103) recibe la solicitud de transacción enviada por el centro de distribución (102) y envía la solicitud de transacción a todos los nodos de consenso en el subsistema de consenso para la validación de consenso; si la validación tiene éxito, genera un bloque correspondiente de acuerdo con la solicitud de transacción y almacena el bloque en una cadena de bloques de consorcio correspondiente al subsistema de consenso (103).

Description

DESCRIPCIÓN

Sistema de cadena de bloques y método y aparato de almacenamiento de datos

Campo técnico

La presente solicitud se refiere al campo de las tecnologías de software y, en particular, a un sistema de cadena de bloques (blockchain) y a un método y un aparato de almacenamiento de datos.

Antecedentes

La red cadena de bloques, también conocida como red de contabilidad distribuida, es una base de datos de Internet caracterizada por la descentralización, transparencia y sincronización de los registros de la base de datos (es decir, una contabilidad compartida) por todos los nodos.

En un ejemplo, una red cadena de bloques consiste en varios nodos, teniendo cada nodo una contabilidad compartida. Los datos asociados con los bloques se registran cronológicamente en la contabilidad compartida (los datos asociados con un bloque corresponden a un conjunto de transacciones para las cuales todos los nodos alcanzan un consenso sobre la legitimidad durante un período de tiempo). En otras palabras, la contabilidad compartida registra una cadena cronometrada de bloques de datos, por lo que se denomina "cadena de bloques". Cada nodo puede sincronizar la contabilidad compartida y validar la autenticidad de cada transacción.

Además, cualquier nodo tiene derecho a sugerir la adición de un bloque de datos a la contabilidad compartida. Todos los nodos pueden llegar a un consenso sobre si las transacciones correspondientes al bloque de datos que se sugiere añadir son legítimas y añadir el bloque de datos para el cual se alcanza un consenso con respecto a la legitimidad en la contabilidad compartida. En la actualidad, existen principalmente dos tipos de redes de cadena de bloques: redes públicas de cadena de bloques y redes de cadena de bloques de consorcio.

Una red cadena de bloques pública está completamente descentralizada y es transparente para el público. Cualquier entidad (individuo u organización) puede convertirse en un nodo en la red cadena de bloques pública, lo que significa que cualquier entidad puede mantener la contabilidad compartida al convertirse en un nodo y solicitar a todos los nodos que lleguen a un consenso sobre un bloque de datos y registren el bloque de dato en la contabilidad compartida.

Sin embargo, dado que cualquier entidad puede convertirse en un nodo en una red cadena de bloques pública, un pirata informático puede invadir fácilmente en la red cadena de bloques pública e intentar controlar la mayoría de los nodos, añadir bloques de datos ilegítimos a la cadena de bloques pública (es decir, la contabilidad compartida ) y representan una amenaza para la seguridad de la red cadena de bloques pública.

Una red cadena de bloques de consorcio está parcialmente descentralizada y no está abierta al público. Solo una entidad designada previamente puede convertirse en un nodo en la red cadena de bloques de consorcio, mientras que otras entidades no están cualificadas para convertirse en nodos, ni pueden mantener la contabilidad compartida ni participar en el consenso. La red cadena de bloques de consorcio puede proporcionar servicios a entidades fuera de la red cadena de bloques de consorcio (entidades que no son nodos). Una entidad que no es un nodo puede interaccionar con la red de la cadena de bloques de consorcio y solicitar a la red cadena de bloques de consorcio que llegue a un consenso con respecto a la legitimidad de una transacción generada por la entidad que no es un nodo.

Una red cadena de bloques de consorcio a menudo solo está relacionada con un campo de transacción. Los nodos en una red cadena de bloques de consorcio son a menudo instituciones autorizadas en el campo. Por ejemplo, los nodos en una red cadena de bloques de consorcio en el campo financiero suelen ser grandes bancos e instituciones reguladoras financieras. Además, los nodos en las redes de cadena de bloques de consorcio para muchos campos de transacciones, como facturas, logística, atención sanitaria, gobierno y administración, también son instituciones autorizadas en los campos correspondientes, respectivamente.

Una entidad que no es un nodo debe seleccionar una red cadena de bloques de consorcio correspondiente de acuerdo con un campo de transacción al que pertenece una transacción generada por la entidad que no es un nodo. Solo después de que la entidad que no es un nodo interaccione con una red cadena de bloques de consorcio, la entidad que no es un nodo podrá disfrutar de los servicios proporcionados por la red cadena de bloques de consorcio. Sin embargo, las redes de cadena de bloques de consorcio pueden tener diferentes protocolos de interfaz. Si una pluralidad de transacciones generadas por la entidad que no es un nodo pertenecen a diferentes campos de transacción, la entidad que no es un nodo tiene que interaccionar con una pluralidad de redes de cadena de bloques de consorcio de acuerdo con diferentes protocolos de interfaz, respectivamente, lo que no es conveniente para la entidad que no es un nodo.

El documento US 2016/224949 desvela un método para realizar una transacción de pago entre un pagador que tiene un ordenador de pago asociado con un almacenamiento de contabilidad para el pagador y un beneficiario que tiene un ordenador de beneficiario asociado con un almacenamiento de contabilidad para el beneficiario en una red de pago de consenso.

Sumario

Las realizaciones de la presente solicitud proporcionan un sistema de cadena de bloques y un método y aparato de almacenamiento de datos, para proporcionar seguridad y conveniencia a las redes de cadena de bloques.

Para resolver los problemas técnicos anteriores, las realizaciones de la presente solicitud se implementan de la siguiente manera:

según un primer aspecto de la invención, se proporciona un sistema de cadena de bloques, que comprende un centro de distribución, un subsistema sin consenso y una pluralidad de subsistemas de consenso;

el subsistema sin consenso comprende una pluralidad de nodos sin consenso y cada uno de los subsistemas de consenso comprende una pluralidad de nodos de consenso;

un nodo sin consenso de la pluralidad de nodos sin consenso envía una solicitud de transacción al centro de distribución;

el centro de distribución recibe la solicitud de transacción del subsistema sin consenso, determina un subsistema de consenso correspondiente a la solicitud de transacción según los datos de la transacción comprendidos en la solicitud de transacción y reenvía la solicitud de transacción al subsistema de consenso determinado; y el subsistema de consenso recibe la solicitud de transacción enviada por el centro de distribución y envía la solicitud de transacción a todos los nodos de consenso en el subsistema de consenso para la validación de consenso; si la validación tiene éxito, genera un bloque correspondiente de acuerdo con la solicitud de transacción y almacena el bloque en una cadena de bloques de consorcio correspondiente al subsistema de consenso.

Según un segundo aspecto de la invención, se proporciona un método de almacenamiento de datos, en el que un sistema de cadena de bloques comprende un centro de distribución, un subsistema sin consenso y una pluralidad de subsistemas de consenso, el subsistema sin consenso comprende una pluralidad de nodos sin consenso, y cada uno de los subsistemas de consenso comprende una pluralidad de nodos de consenso, comprendiendo el método:

recibir, por un subsistema de consenso correspondiente a una solicitud de transacción, la solicitud de transacción reenviada por el centro de distribución, la solicitud de transacción que comprende los datos de la transacción, en la que la solicitud de transacción es enviada por la pluralidad de nodos sin consenso al centro de distribución, en el que el consenso el subsistema correspondiente a la solicitud de transacción es determinado, por el centro de distribución, en base a los datos de la transacción comprendidos en la solicitud de transacción;

enviar la solicitud de transacción a todos los nodos de consenso en el subsistema de consenso para la validación de consenso;

si la validación tiene éxito, generar un bloque correspondiente de acuerdo con la solicitud de transacción y almacenar el bloque en una cadena de bloques de consorcio correspondiente al subsistema de consenso.

Según un tercer aspecto de la invención, se proporciona un método de almacenamiento de datos, en el que un sistema de cadena de bloques comprende un centro de distribución, un subsistema sin consenso y una pluralidad de subsistemas de consenso, el subsistema sin consenso comprende una pluralidad de nodos sin consenso, y cada uno de los subsistemas de consenso comprende una pluralidad de nodos de consenso, comprendiendo el método:

recibir, por parte del centro de distribución, una solicitud de transacción enviada por el subsistema sin consenso, comprendiendo la solicitud de transacción los datos de la transacción;

determinar un subsistema de consenso correspondiente a la solicitud de transacción según los datos de transacción comprendidos en la solicitud de transacción; y

reenviar la solicitud de transacción al subsistema de consenso determinado, haciendo que el subsistema de consenso realice una validación de consenso en la solicitud de transacción y almacene un bloque correspondiente a la solicitud de transacción validada en una cadena de bloques de consorcio correspondiente al subsistema de consenso.

Según el cuarto aspecto de la invención, se proporciona un método de almacenamiento de datos, en el que un sistema de cadena de bloques comprende un centro de distribución, un subsistema sin consenso y una pluralidad de subsistemas de consenso, el subsistema sin consenso comprende una pluralidad de nodos sin consenso y cada uno de los subsistemas de consenso comprende una pluralidad de nodos de consenso, comprendiendo el método: enviar, por el subsistema sin consenso, una solicitud de transacción al centro de distribución, comprendiendo la solicitud de transacción los datos de la transacción, haciendo que el centro de distribución reenvíe, en base a los datos de la transacción, la solicitud de la transacción a un subsistema de consenso correspondiente a los datos de la transacción.

Según un quinto aspecto, se proporciona un aparato de almacenamiento de datos configurado para llevar a cabo el método según el segundo, tercer o cuarto aspecto.

A partir de las soluciones técnicas descritas anteriormente de acuerdo con aspectos de la invención, se puede ver que en las realizaciones de la presente solicitud se crea un sistema de cadena de bloques que comprende un centro de distribución, un subsistema sin consenso y una pluralidad de subsistemas de consenso, en el que el subsistema sin consenso comprende una pluralidad de nodos sin consenso, cada uno de los subsistemas de consenso comprende una pluralidad de nodos de consenso y cada uno de los subsistemas de consenso es equivalente a una red cadena de bloques de consorcio que contiene la pluralidad de nodos de consenso. Esto también significa que los subsistemas de consenso pueden realizar validaciones de consenso por separado para diferentes campos de transacciones. De esta manera, los nodos de consenso en los subsistemas de consenso son responsables de la validación de consenso y los nodos sin consenso en el subsistema sin consenso pueden enviar una solicitud de transacción al centro de distribución. El centro de distribución determina un subsistema de consenso en un campo de transacción particular basado en los datos de transacción incluidos en la solicitud de transacción. A continuación, el subsistema de consenso realiza la validación de consenso en la solicitud de transacción. De acuerdo con las realizaciones de la presente solicitud, por un lado, solo los nodos de consenso son responsables de la validación de consenso, y los nodos sin consenso fuera de los subsistemas de consenso no pueden participar en la validación de consenso de una red cadena de bloques de consorcio. Esto mejora la seguridad de la red cadena de bloques. Por otro lado, el centro de distribución puede interactuar con las redes cadena de bloques de consorcio y las entidades sin consenso (nodos sin consenso) fuera de la red cadena de bloques de consorcio solo necesitan interactuar con el centro de distribución y no necesitan interactuar con una pluralidad. de redes cadena de bloques de consorcio de acuerdo con diferentes protocolos de interfaz. Esto mejora la conveniencia de la red cadena de bloques.

Breve descripción de los dibujos

Para describir más claramente las soluciones técnicas en las realizaciones de la presente solicitud o las tecnologías actuales, los dibujos adjuntos que se utilizarán en las realizaciones o las tecnologías actuales se describirán brevemente a continuación. Es obvio que los dibujos adjuntos en la descripción siguiente son simplemente algunas realizaciones de la presente solicitud. Sobre la base de estos dibujos adjuntos, un experto en la técnica puede obtener otros dibujos relevantes sin esfuerzo creativo.

Las figuras 1a-b son diagramas esquemáticos de un sistema de cadena de bloques según algunas realizaciones de la presente solicitud;

la figura 2 es un diagrama de flujo de un método de almacenamiento de datos según algunas realizaciones de la presente solicitud;

las figuras 3-5 son diagramas esquemáticos de tres aparatos de almacenamiento de datos de acuerdo con algunas realizaciones de la presente solicitud.

Descripción detallada

Las realizaciones de la presente solicitud proporcionan una red cadena de bloques y un método y aparato de almacenamiento de datos.

Para permitir que un experto en la técnica comprenda mejor las soluciones técnicas de la presente solicitud, las soluciones técnicas en las realizaciones de la presente solicitud se describirán clara y completamente a continuación con referencia a los dibujos adjuntos en las realizaciones de la presente solicitud. Es obvio que las realizaciones descritas son simplemente algunas, pero no todas, las realizaciones de la presente solicitud. Sobre la base de las realizaciones de la presente solicitud, todas las demás formas de realización que pueda obtener un experto en la técnica sin esfuerzo creativo estarán dentro del alcance de la presente solicitud.

Como se ha descrito anteriormente, en aplicaciones de ejemplo, existen principalmente dos tipos de aplicaciones de redes cadena de bloques, es decir, red cadena de bloques pública y red cadena de bloques de consorcio. No hay restricción de identidad para los nodos en una red cadena de bloques pública y cualquier entidad (individuo u organización) puede convertirse en un nodo en la red cadena de bloques pública para participar en la validación de consenso en una solicitud de transacción. Dado que la red cadena de bloques pública está verdaderamente descentralizada y completamente abierta, un pirata informático puede tener la oportunidad de controlar la mayoría de los nodos y realizar una solicitud de transacción ilegítima para aprobar la validación. Además, cualquier entidad puede ver todos los datos de transacciones almacenados en la cadena pública, mientras que los datos de transacciones a menudo implican la privacidad del nodo y de las entidades que no lo son. Incluso si los datos de la transacción están cifrados, todavía existe el riesgo de que se descifre el cifrado.

Cabe señalar que una "contabilidad compartida" es una cadena de bloques administrada por una red cadena de bloques y, en consecuencia, una red cadena de bloques de consorcio administra una cadena de bloques de consorcio y una red cadena de bloques pública administra una cadena de bloques pública.

Todos los nodos de una red cadena de bloques de consorcio son instituciones autorizadas previamente designadas. Por ejemplo, todos los nodos en una red cadena de bloques de consorcio en el campo financiero pueden ser el Banco Industrial y Comercial de China, el Banco de Construcción de China, el Banco Popular de China, la Comisión Reguladora de Valores de China, la Comisión Reguladora Bancaria de China, etc. Esta característica de la red cadena de bloques de consorcio no da a los piratas informáticos la oportunidad de participar en la validación de consenso o de ver los datos de transacción almacenados en la cadena de bloques de consorcio. De esta manera, la seguridad de la red cadena de bloques se mejora enormemente. Sin embargo, dado que los nodos en una red cadena de bloques de consorcio son a menudo instituciones autorizadas en un campo de transacción, la red cadena de bloques de consorcio solo puede proporcionar servicios de validación pública en el campo de transacción en particular. Una entidad que no es un nodo a menudo necesita gastar un coste muy alto para interactuar con las redes cadena de bloques de consorcio en diferentes campos de transacciones, lo cual es muy inconveniente.

Con este fin, la solución técnica de la presente aplicación proporciona un sistema de cadena de bloques y se establece un centro de distribución en el sistema. El centro de distribución proporciona protocolos estándar de interfaz para, por un lado, interactuar con entidades que no son nodos para aceptar solicitudes de transacciones de las entidades que no son nodos y, por otro lado, interactuar con varias redes cadena de bloques de consorcio para reenviar las solicitudes de transacciones recibidas. a las redes cadena de bloques de consorcio correspondientes para su validación de acuerdo con los campos de transacción correspondientes a las solicitudes de transacción.

El sistema de cadena de bloques en la solución técnica de la presente solicitud puede incorporar redes de cadena de bloques de consorcio existentes que operan de forma independiente y entidades que no son nodos que necesitan varios servicios de validación de consenso en una arquitectura de sistema unificada, proporcionan protocolos estándar de interfaz para las redes cadena de bloques de consorcio y entidades que no son nodos, e incluso incluyen varios servicios de validación en toda la sociedad en el sistema de cadena de bloques. Todos los miembros de la sociedad pueden convertirse en nodos del sistema de cadena de bloques (no es necesario ser responsable de la validación de consenso) y las solicitudes de transacciones generadas en todos los aspectos de la vida y el trabajo de cada miembro pueden validarse en el sistema de cadena de bloques.

La figura 1a es un diagrama esquemático de un sistema de cadena de bloques según algunas realizaciones de la presente solicitud. Como se muestra en la figura 2, el sistema de cadena de bloques comprende un centro de distribución, un subsistema sin consenso y una pluralidad de subsistemas de consenso, en el que el subsistema sin consenso puede corresponder a las entidades que no son nodos, y las entidades que no son nodos pueden servir como nodos sin consenso en el subsistema sin consenso. Como alternativa, el subsistema sin consenso también puede corresponder a una red cadena de bloques pública, y los nodos sin consenso en el subsistema sin consenso son prácticamente nodos en la red cadena de bloques pública, pero los nodos sin consenso no tienen la función de participar en validación el consenso y solo puede enviar solicitudes de transacción. Por otro lado, cada uno de los subsistemas de consenso equivale a una red cadena de bloques de consorcio, y los nodos de consenso en cada uno de los subsistemas de consenso son prácticamente nodos de la red cadena de bloques de consorcio correspondiente al subsistema de consenso; las solicitudes de transacción iniciadas por los nodos sin consenso son asignadas por el centro de distribución de manera uniforme y el centro de distribución reenvía las solicitudes de transacción correspondientes a diferentes campos de transacción a los subsistemas de consenso correspondientes (es decir, equivalente a reenviar las solicitudes de transacción a las redes de cadena de bloques de consorcio correspondientes).

De hecho, cuando un sistema de validación de consenso de toda la sociedad se basa en el sistema de cadena de bloques, las redes cadena de bloques de consorcio pueden considerarse como estaciones de servicio para brindar servicios a cada miembro de la sociedad. Para cada miembro de la sociedad, hay muchas solicitudes de transacción generadas por el miembro de la sociedad en actividades sociales debido a la vida o el trabajo, que abarca una pluralidad de campos de transacción, y el sistema de cadena de bloques puede proporcionar servicios de ventanilla única al miembro de la sociedad. Además, los datos de transacciones almacenados en el sistema de cadena de bloques también abarcan todos los aspectos de las actividades sociales de cada miembro de la sociedad, incluidas las finanzas, la atención sanitaria, la educación, los seguros, las compras y la liquidación de activos del miembro de la sociedad, así como campos como la administración y el poder judicial., ejecución, etc. Los datos de la transacción pueden servir como macrodatos con una precisión muy alta para una mayor construcción de un sistema de crédito para toda la sociedad.

Las soluciones técnicas de las realizaciones de la presente solicitud se describirán con detalle con referencia a los dibujos adjuntos.

La figura 1a es un diagrama esquemático de un sistema de cadena de bloques según algunas realizaciones de la presente solicitud, que comprende:

un subsistema sin consenso 101, un centro de distribución 102 y una pluralidad de subsistemas de consenso 103; el subsistema sin consenso 101 comprende una pluralidad de nodos sin consenso y cada uno de los subsistemas de consenso comprende una pluralidad de nodos de consenso;

un nodo sin consenso envía una solicitud de transacción al centro de distribución 102;

el centro de distribución 102 recibe la solicitud de transacción del subsistema sin consenso, determina un subsistema de consenso correspondiente a la solicitud de transacción en base a los datos de transacción comprendidos en la solicitud de transacción y reenvía la solicitud de transacción al subsistema de consenso 103 determinado; y

el subsistema de consenso 103 recibe la solicitud de transacción enviada por el centro de distribución, y envía la solicitud de transacción a todos los nodos de consenso en el subsistema de consenso 103 para la validación de consenso; si la validación tiene éxito, genera un bloque correspondiente de acuerdo con la solicitud de transacción y almacena el bloque en una cadena de bloques de consorcio correspondiente al subsistema de consenso 103.

El subsistema de consenso 103 está configurado además para enviar el bloque correspondiente a la solicitud de transacción al subsistema sin consenso 101; y

el subsistema sin consenso 101 recibe el bloque y almacena el bloque en una cadena de bloques pública correspondiente al subsistema sin consenso 101.

El subsistema de consenso 103 está configurado además para generar un resumen de la transacción correspondiente al bloque según los datos de transacción correspondientes al bloque, y enviar el resumen de la transacción al subsistema sin consenso 101; y

el subsistema sin consenso 101 almacena el resumen de la transacción en la cadena de bloques pública, de modo que el resumen de la transacción está disponible para su búsqueda por parte de los nodos sin consenso.

El subsistema sin consenso 101 comprende, además:

un navegador 1011 de datos configurado para recibir una solicitud de búsqueda de datos de transacciones desde un nodo sin consenso, determinar el permiso de búsqueda del nodo sin consenso de acuerdo con la solicitud de búsqueda; y devolver, según el permiso de búsqueda, los datos de transacción correspondientes al permiso de búsqueda al nodo sin consenso.

El navegador 1011 de datos obtiene, de acuerdo con el permiso de búsqueda, los datos de la transacción correspondientes al permiso de búsqueda del subsistema de consenso 103 correspondiente a la solicitud de búsqueda y devuelve los datos de transacción obtenidos al nodo sin consenso.

En una red cadena de bloques existente, los nodos son miembros de la red cadena de bloques. Los nodos pueden participar en la validación de consenso en una solicitud de transacción, también pueden buscar bloques almacenados en la red cadena de bloques (es decir, la contabilidad compartida), y pueden además buscar datos de transacciones respectivamente correspondientes a los bloques. La solicitud de transacción comprende datos de transacción y una entidad de nodo o no nodo puede enviar una solicitud de transacción para solicitar a la red cadena de bloques que realice una validación de consenso sobre la solicitud de transacción y para verificar si los datos de transacción de la solicitud de transacción son legítimos.

En este caso, los datos de la transacción son datos de la transacción generados por un nodo o una entidad que no es un nodo y comprenden la firma digital, el identificador, la dirección de la cuenta, etc. del nodo o la entidad que no es un nodo, y además comprende asuntos que se deben verificar según lo solicite la entidad nodo o que no es un nodo. Estos asuntos a verificar varían según los diferentes campos de transacción. Por ejemplo, un nodo A transfiere 500 yuanes a un nodo B. Para que el nodo B crea que se ha realizado la transferencia, el nodo A enviará una solicitud de transacción y la solicitud de transacción comprende los siguientes datos de la transacción: dirección de la cuenta del nodo A, dirección de la cuenta del nodo B y "A transfiere 500 yuanes a B". Luego, los nodos de la red cadena de bloques deben verificar si se deducen 500 yuanes de la cuenta del nodo A y si se añaden 500 yuanes de la cuenta del nodo A a la cuenta de B.

Cabe señalar que, en el campo de las tecnologías cadena de bloques, la validación de consenso se realiza en una solicitud de transacción por parte de todos los nodos de acuerdo con un algoritmo de consenso y la red cadena de bloques tiene derecho a acceder a información privada de todos los nodos, tales como cuentas, registros de transacciones., etc., para su validación. El flujo de validación de consenso en las realizaciones de la presente solicitud no es diferente de un flujo existente de validación de consenso y, por lo tanto, el flujo de validación de consenso en las realizaciones de la presente solicitud no se desarrollará en la memoria descriptiva siguiente.

En una red cadena de bloques existente, hay una gran cantidad de solicitudes de transacciones que necesitan validación de consenso. Por lo tanto, la validación de consenso se realiza normalmente una vez en un lote de solicitudes de transacción dentro de un período de tiempo o cuando el número de solicitudes de transacción como lote alcanza un umbral, para mejorar la eficiencia. A continuación, si la validación en este lote de solicitudes de transacción tiene éxito, se genera un bloque correspondiente a este lote de solicitudes de transacción y se almacena en la cadena de bloques (es decir, se almacena en la contabilidad compartida). Los nodos pueden buscar datos de transacciones correspondientes a un bloque para comprobar si el bloque se ha atemperado.

En las realizaciones de la presente solicitud, los nodos de consenso no son diferentes de los nodos en una red cadena de bloques de consorcio en términos de funciones. Un subsistema de consenso corresponde a una red cadena de bloques de consorcio (que comprende una cadena de bloques de consorcio) y cada nodo de consenso corresponde a una institución autorizada para participar en la validación de consenso. Los nodos sin consenso pueden ser las entidades que no son nodos descritas en la sección de "Antecedentes" y las entidades que no son nodos pueden tener asignada una identidad de nodo en el presente sistema, pero los nodos sin consenso pueden no participar en la validación de consenso. Los nodos sin consenso también pueden ser nodos en una red cadena de bloques pública, lo que significa que el subsistema sin consenso corresponde a una red cadena de bloques pública. En los escenarios de aplicación de la presente solicitud, estos nodos sin consenso tampoco pueden participar en la validación de consenso. En los escenarios de aplicación de la presente solicitud, todos los nodos de consenso en los subsistemas de consenso realizan la validación de consenso.

Sin embargo, en escenarios distintos de los escenarios de aplicación de la presente solicitud, los nodos sin consenso pueden realizar una validación de consenso. Por ejemplo, los nodos sin consenso pueden ser nodos en un escenario de aplicación de bitcoin que realizan una validación de consenso para la circulación de bitcoins de acuerdo con un algoritmo de prueba de trabajo. Como se ha descrito anteriormente, toda la sociedad puede incorporarse a un sistema de crédito unificado sobre la base del sistema actual. Cuando el subsistema sin consenso corresponde a una red cadena de bloques pública, la red cadena de bloques pública solo necesita interactuar con el sistema actual, mientras que las operaciones originales de la red cadena de bloques pública no se verán afectadas.

Además, el subsistema sin consenso en el presente sistema puede corresponder además a una pluralidad de redes cadena de bloques públicas. Sin embargo, en el sistema actual, todos los nodos comprendidos en la pluralidad de redes cadena de bloques públicas son nodos sin consenso y al subsistema sin consenso no le importa a qué red cadena de bloques pública pertenecen originalmente estos nodos sin consenso.

En las realizaciones de la presente solicitud, el centro de distribución proporciona al público protocolos estándar de interfaz. En un ejemplo, cada red cadena de bloques de consorcio puede desarrollar un cliente que tenga los protocolos estándar integrados de acuerdo con una interfaz de programa de aplicación (API) proporcionada por el centro de distribución para interactuar con el centro de distribución y, por lo tanto, convertirse en un subsistema de consenso. Además, cualquier entidad puede interactuar con el centro de distribución y convertirse en un nodo sin consenso. En un ejemplo, una persona o individuo puede instalar un cliente que tenga el protocolo estándar de interfaz incorporado en un terminal y, a continuación, las solicitudes de transacción pueden enviarse en cualquier momento a través del cliente. Una empresa, en particular una empresa que proporciona servicios a los usuarios, puede conectar la aplicación de la empresa con el centro de distribución. Cuando la empresa proporciona un servicio a un usuario, se puede enviar una solicitud de transacción correspondiente al servicio para que un subsistema de consenso correspondiente realice la validación de consenso.

Por ejemplo, el Sr. Zhang es un filántropo que a menudo brinda asistencia financiera a estudiantes sin medios económicos. El Sr. Zhang está muy preocupado por el destino de cada donación que hizo y si los estudiantes realmente han recibido las donaciones. Entonces, el Sr. Zhang puede solicitar convertirse en un nodo sin consenso e instalar una aplicación de pago con un protocolo estándar de interfaz incorporado. Cada vez que el Sr. Zhang hace una donación, un subsistema de consenso correspondiente en el campo de la caridad realizará la validación de consenso sobre la donación para garantizar que la donación realizada por el Sr. Zhang se transfiera a la cuenta de un estudiante sin medios económicos designado. Además, el Sr. Zhang puede confirmar más tarde que la transacción no se ha inactivado consultando el bloque almacenado en la cadena de bloques de consorcio.

Por ejemplo, un cliente de una plataforma de comercio electrónico puede tener un protocolo estándar de interfaz incorporado para interactuar con el centro de distribución. Cuando un usuario compra en la plataforma de comercio electrónico, la plataforma de comercio electrónico solicita un subsistema de consenso para realizar la validación de consenso sobre si los bienes adquiridos por el usuario son auténticos, si el pago realizado por el usuario ha tenido éxito, etc., y proporciona retroalimentación al usuario.

Por ejemplo, un individuo común puede convertirse en un nodo sin consenso. Cuando dos nodos sin consenso realizan una transferencia, uno de los nodos sin consenso puede iniciar una solicitud de transacción para solicitar una red cadena de bloques de consorcio correspondiente al campo de pago para realizar la validación de consenso de la transferencia y registrar un bloque correspondiente a la transferencia en una cadena de bloques de consorcio.

En resumen, existen abundantes escenarios de aplicación bajo la arquitectura del sistema actual. Un individuo puede convertirse en un nodo sin consenso para solicitar la validación de varios eventos generados por el individuo. Una empresa puede convertirse en un nodo sin consenso para mejorar la confianza que los usuarios tienen en la empresa.

En las realizaciones de la presente solicitud, cuando el subsistema sin consenso corresponde a una red cadena de bloques pública, el bloque generado correspondiente a la solicitud de transacción puede enviarse además al subsistema sin consenso, lo que hace que el subsistema sin consenso almacene el bloque recibido en la cadena de bloques pública. De esta manera, todos los nodos sin consenso pueden ver convenientemente las cadenas de tiempo de las transacciones y no necesitan solicitar un subsistema de consenso para buscar los bloques.

Además, para facilitar aún más que los nodos sin consenso busquen solicitudes de transacciones que hayan sido objeto de validación de consenso, los datos de la transacción correspondientes a un bloque generado se pueden resumir para generar un resumen de la transacción y el resumen de la transacción se puede enviar al subsistema sin consenso. El subsistema sin consenso puede almacenar el resumen de la transacción en la cadena de bloques pública. De esta forma, los nodos sin consenso pueden buscar el resumen de la transacción para satisfacer las demandas de búsqueda en el sentido general. Mientras tanto, los nodos sin consenso no pueden ver los datos de la transacción completados, lo que impide que los usuarios con intenciones ilegales utilicen determinados datos privados. Al enviar el resumen de bloque y transacción al subsistema sin consenso para su almacenamiento, se garantiza que el subsistema sin consenso no corre el riesgo de ser invadido, al tiempo que se logra la apertura de la red cadena de bloques.

En las realizaciones de la presente solicitud, el subsistema sin consenso puede comprender además un navegador de datos. El navegador de datos tiene una función para proporcionar funciones de búsqueda de datos y gestión de permisos para los nodos sin consenso. Como se ha descrito anteriormente, el resumen de bloque y la transacción se envía al subsistema sin consenso para su almacenamiento. En circunstancias normales, los nodos sin consenso pueden conocer información tal como si la validación de consenso ha tenido éxito, qué asuntos se han verificado, etc., mediante la búsqueda del resumen de bloque y transacción almacenado en la cadena pública. En algunos casos, si un nodo sin consenso sospecha que un bloque está inactivado, la sospecha solo se puede confirmar buscando los datos de transacción correspondientes al bloque. En otros casos, si un nodo sin consenso necesita demostrar el crédito del nodo a otros nodos sin consenso, el nodo sin consenso también debe presentar algunos datos de transacción detallados a otros nodos sin consenso. Sin embargo, conduciría a un alto riesgo en la seguridad si los nodos sin consenso pueden ver directamente todos los datos de transacciones almacenados en una cadena de bloques de consorcio. Por lo tanto, el navegador de datos puede realizar la gestión de permisos de búsqueda en los nodos sin consenso.

La arquitectura del sistema de cadena de bloques en las soluciones técnicas según la presente aplicación es flexible. El administrador de datos puede implementarse no en el subsistema sin consenso, sino en el centro de distribución o en paralelo al centro de distribución, el subsistema sin consenso y los subsistemas de consenso. En resumen, el navegador de datos puede proporcionar servicios de búsqueda de datos y gestionar el permiso de búsqueda para nodos sin consenso independientemente de la ubicación del navegador de datos en el sistema.

En un ejemplo, el permiso de búsqueda de un nodo sin consenso puede determinarse de la siguiente manera: para cada nodo sin consenso, determinando un tipo de nodo sin consenso; y según el tipo de nodo sin consenso, asignar permiso de búsqueda al nodo sin consenso.

En este caso, el tipo de nodo sin consenso puede ser individual, empresarial, agencia reguladora, etc., o puede ser diferentes niveles de crédito, tal como crédito alto, crédito medio, crédito bajo, etc. En resumen, el tipo de nodos sin consenso puede decidirse de acuerdo con situaciones reales, lo que no está limitado en la presente solicitud.

Por ejemplo, el permiso de búsqueda para un nodo sin consenso de tipo empresarial pueden ser datos de transacciones generados por todos los usuarios atendidos por la empresa; el permiso de búsqueda para una persona normal puede ser datos de transacciones solo relacionados con la persona; y el permiso de búsqueda para una agencia reguladora pueden ser todos los datos de transacciones.

En las realizaciones de la presente solicitud, una solicitud de búsqueda de datos de transacción enviada por un nodo sin consenso puede llevar un bloque, lo que indica que el nodo sin consenso desea buscar datos de transacción correspondientes al bloque; como alternativa, la solicitud de búsqueda también puede llevar un identificador del nodo sin consenso, lo que indica que el nodo sin consenso desea buscar datos de transacciones dentro del permiso de búsqueda del nodo sin consenso.

Cuando el navegador de datos recibe la solicitud de búsqueda de datos de transacciones enviada por el nodo sin consenso, el navegador de datos verifica el permiso de búsqueda del nodo sin consenso. Cuando el nodo sin consenso no tiene el permiso de búsqueda correspondiente (por ejemplo, el nodo sin consenso no tiene permiso para buscar datos de transacciones correspondientes a un bloque), el navegador de datos rechaza la solicitud de búsqueda. Si el nodo sin consenso tiene el permiso de búsqueda correspondiente, el navegador de datos puede obtener los datos de transacción correspondientes al permiso de búsqueda del subsistema de consenso correspondiente a la solicitud de búsqueda de acuerdo con el permiso de búsqueda y devolver los datos de transacción obtenidos al nodo sin consenso.

Además, el navegador de datos puede determinar qué datos de transacciones pueden ser buscados por el nodo sin consenso de acuerdo con el permiso de búsqueda determinado y luego obtener los datos de transacción de un subsistema de consenso correspondiente; o puede enviar directamente el permiso de búsqueda determinado al subsistema de consenso correspondiente para que el subsistema de consenso devuelva los datos de transacción correspondientes de acuerdo con el permiso de búsqueda.

En el sistema de cadena de bloques mostrado en la figura 1a, se crea un sistema de cadena de bloques que comprende un centro de distribución, un subsistema sin consenso y una pluralidad de subsistemas de consenso, en el que el subsistema sin consenso comprende una pluralidad de nodos sin consenso, cada uno de los subsistemas de consenso comprende una pluralidad de nodos de consenso y cada uno de los subsistemas de consenso corresponde a una red cadena de bloques de consorcio que contiene la pluralidad de nodos de consenso. Como resultado, los subsistemas de consenso pueden realizar validaciones de consenso en diferentes campos de transacciones. De esta manera, los nodos de consenso en los subsistemas de consenso son responsables de la validación de consenso y los nodos sin consenso en el subsistema sin consenso pueden enviar una solicitud de transacción al centro de distribución. El centro de distribución determina un subsistema de consenso en un campo de transacción particular basado en los datos de transacción incluidos en la solicitud de transacción. A continuación, el subsistema de consenso realiza la validación de consenso en la solicitud de transacción. De acuerdo con las realizaciones de la presente solicitud, por un lado, solo los nodos de consenso son responsables de la validación de consenso, y los nodos sin consenso fuera de los subsistemas de consenso no pueden participar en la validación del consenso por una red cadena de bloques de consorcio, mejorando de este modo la seguridad de la red cadena de bloques; por otro lado, el centro de distribución puede interactuar con las redes cadena de bloques de consorcio y las entidades sin consenso (nodos sin consenso) fuera de la red de cadena de bloques de consorcio solo necesitan interactuar con el centro de distribución y no necesitan interactuar con una pluralidad. de redes cadena de bloques de consorcio de acuerdo con diferentes protocolos de interfaz, mejorando de este modo la conveniencia de la red cadena de bloques.

Además, se debe enfatizar que las funciones del centro de distribución pueden limitarse solo a determinar un subsistema de consenso correspondiente de acuerdo con una solicitud de transacción o puede servir como agente de interacción de datos entre el subsistema de consenso y el subsistema sin consenso. En otras palabras, el subsistema de consenso y el subsistema sin consenso pueden realizar una interacción de datos (por ejemplo, enviar un bloque, un resumen de transacción, datos de transacción, etc.) sin pasar por el centro de distribución pero basándose en un protocolo de enrutamiento particular, como se muestra. en la figura 1b.

La figura 2 es un diagrama de flujo de un método de almacenamiento de datos según algunas realizaciones de la presente solicitud, que comprende las etapas siguientes:

S201: envío, por parte del subsistema sin consenso, de una solicitud de transacción al centro de distribución.

Estas realizaciones de la presente solicitud se basan en el mismo concepto de invención que el sistema de cadena de bloques mostrado en la figura 1a. Se puede hacer referencia a las explicaciones del sistema de cadena de bloques mostrado en la figura 1a para explicar conceptos relevantes.

En las realizaciones de la presente solicitud, puede ser un nodo sin consenso en el subsistema sin consenso el que envía la solicitud de transacción al centro de distribución.

S202: determinación, por parte del centro de distribución, de un subsistema de consenso correspondiente a la solicitud de transacción.

S203: reenvío, por parte del centro de distribución, de la solicitud de transacción al subsistema de consenso determinado.

El centro de distribución puede recibir transacciones enviadas por una pluralidad de nodos sin consenso varias veces, y para cada solicitud de transacción, reenviar la solicitud de transacción a un subsistema de consenso correspondiente para la validación de consenso.

El centro de distribución puede servir como agente de interacción de datos entre el subsistema de consenso y el subsistema sin consenso (por ejemplo, enviar un bloque, un resumen de transacción, datos de transacción, etc. en etapas posteriores), o puede no servir como agente, pero dejar que el subsistema de consenso y el subsistema sin consenso realicen la interacción de datos directamente.

S204: realización, por parte del subsistema de consenso, de la validación de consenso en la solicitud de transacción.

El subsistema de consenso realiza la validación de consenso en la solicitud de transacción, que es prácticamente enviar la solicitud de transacción a todos los nodos de consenso comprendidos en el subsistema de consenso para realizar la validación de consenso. Un algoritmo de consenso basado en el cual los nodos de consenso realizan la validación de consenso puede ser el algoritmo de Tolerancia a Fallos Bizantinos u otros algoritmos de consenso, que no están limitados.

S205: después de que la validación haya tenido éxito, el subsistema de consenso genera un bloque correspondiente según la solicitud de transacción, almacena el bloque en una cadena de bloques de consorcio correspondiente al subsistema de consenso y genera un resumen de la transacción correspondiente al bloque.

Una vez que la validación tiene éxito, el subsistema de consenso genera un bloque correspondiente de acuerdo con la solicitud de transacción. En la práctica, el bloque correspondiente se genera según un lote de solicitudes de transacción que comprenden la solicitud de transacción, que se ha explicado anteriormente y no se elaborará.

S206: envío, por parte del subsistema de consenso, del bloque correspondiente a la solicitud de transacción y el resumen de la transacción al subsistema sin consenso.

S207: almacenamiento, por parte del subsistema sin consenso, del bloque en una cadena de bloques pública correspondiente.

S208: envío, por parte del subsistema sin consenso, de una solicitud de obtención de los datos de la transacción al subsistema de consenso.

En las realizaciones de la presente solicitud, puede ser el subsistema sin consenso el que envía la solicitud de obtención al subsistema de consenso y, en un ejemplo, puede ser el navegador de datos comprendido en el subsistema sin consenso el que envía la solicitud de obtención al subsistema de consenso.

Cuando la solicitud de obtención comprende el permiso de búsqueda de un nodo sin consenso, el subsistema de consenso puede determinar, de acuerdo con el permiso de búsqueda, los datos de transacción correspondientes al permiso de búsqueda de los datos de transacción almacenados en el subsistema sin consenso, donde se determina el permiso de búsqueda por parte del subsistema sin consenso de acuerdo con una solicitud de búsqueda de los datos de transacción enviados por el nodo sin consenso.

Cuando la solicitud de obtención comprende una lista de identificadores de datos de transacción, el subsistema de consenso puede devolver los datos de transacción correspondientes al subsistema sin consenso según la lista de identificadores.

S209: devolución de datos de transacciones correspondientes a la solicitud de obtención al subsistema sin consenso.

Con el método de almacenamiento de datos mostrado en la figura 2, se puede evitar que los nodos sin consenso fuera del subsistema de consenso busquen libremente datos de transacciones, mientras que las solicitudes de transacción enviadas por los nodos sin consenso se pueden asignar de manera unificada, mejorando así la conveniencia de la red cadena de bloques.

Según el método de almacenamiento de datos mostrado en la figura 2, las realizaciones de la presente solicitud proporcionan además un aparato de almacenamiento de datos correspondiente. Como se muestra en la figura 3, un sistema de cadena de bloques comprende un centro de distribución, un subsistema sin consenso y una pluralidad de piezas del aparato, en el que el subsistema sin consenso comprende una pluralidad de nodos sin consenso y cada pieza del aparato comprende una pluralidad de nodos de consenso, comprendiendo el aparato:

un módulo de recepción 301 configurado para recibir una solicitud de transacción enviada por el centro de distribución, comprendiendo la solicitud de transacción datos de la transacción;

un módulo de validación 302 configurado para enviar la solicitud de transacción a todos los nodos de consenso en el subsistema de consenso para la validación de consenso; y

un módulo de almacenamiento 303 configurado para, si la validación tiene éxito, generar un bloque correspondiente de acuerdo con la solicitud de transacción y almacenar el bloque en una cadena de bloques de consorcio correspondiente al subsistema de consenso.

El aparato comprende además: un módulo de envío 304 configurado para, si la validación tiene éxito, enviar el bloque correspondiente a la solicitud de transacción al subsistema sin consenso, haciendo que el subsistema sin consenso almacene el bloque en una cadena de bloques pública correspondiente al subsistema sin consenso.

El aparato comprende además: un módulo de generación 305 configurado para, si los nodos de consenso llegan a un consenso de que la solicitud de transacción es legítima, generar un resumen de transacción correspondiente al bloque según los datos de transacción correspondientes al bloque, y enviar el resumen de transacción al subsistema sin consenso, lo que hace que el subsistema sin consenso almacene el resumen de la transacción en la cadena de bloques pública de modo que el resumen de la transacción esté disponible para su búsqueda por los nodos sin consenso.

El aparato comprende además: un módulo de gestión de datos de transacción 306 configurado para recibir una solicitud de obtención de datos de transacción del subsistema sin consenso, y devolver, según la solicitud de obtención, los datos de transacción correspondientes a la solicitud de obtención al subsistema sin consenso.

La solicitud de obtención comprende el permiso de búsqueda de un nodo sin consenso, y el subsistema sin consenso determina el permiso de búsqueda según una solicitud de búsqueda de los datos de transacción enviados por el nodo sin consenso; y

el módulo de gestión de datos de transacción 306 determina, según el permiso de búsqueda, los datos de transacción correspondientes al permiso de búsqueda de los datos de transacción almacenados en el subsistema sin consenso.

Según el método de almacenamiento de datos mostrado en la figura 2, las realizaciones de la presente solicitud proporcionan además un aparato de almacenamiento de datos correspondiente. Como se muestra en la figura 4, un sistema de cadena de bloques comprende el aparato, un subsistema sin consenso y una pluralidad de subsistemas de consenso, el subsistema sin consenso comprende una pluralidad de nodos sin consenso y cada uno de los subsistemas de consenso comprende un pluralidad de nodos de consenso, comprendiendo el aparato:

un módulo de recepción 401 configurado para recibir una solicitud de transacción enviada por el subsistema sin consenso, comprendiendo la solicitud de transacción datos de transacción;

un módulo de determinación 402 configurado para determinar un subsistema de consenso correspondiente a la solicitud de transacción en base a los datos de transacción comprendidos en la solicitud de transacción; y un módulo de reenvío 403 configurado para reenviar la solicitud de transacción al subsistema de consenso determinado, haciendo que el subsistema de consenso realice la validación de consenso en la solicitud de transacción, y almacene un bloque correspondiente a la solicitud de transacción validada en una cadena de bloques de consorcio correspondiente al subsistema de consenso.

Según el método de almacenamiento de datos mostrado en la figura 2, las realizaciones de la presente solicitud proporcionan además un aparato de almacenamiento de datos correspondiente. Como se muestra en la figura 5, un sistema de cadena de bloques comprende un centro de distribución, el aparato y una pluralidad de subsistemas de consenso, el aparato comprende una pluralidad de nodos sin consenso y cada uno de los subsistemas de consenso comprende un pluralidad de nodos de consenso, comprendiendo el aparato:

un módulo de envío 501 configurado para enviar una solicitud de transacción al centro de distribución, comprendiendo la solicitud de transacción datos de transacción, haciendo que el centro de distribución reenvíe, en base a los datos de transacción, la solicitud de transacción a un subsistema de consenso correspondiente a los datos de transacción.

El aparato comprende además: un primer módulo de almacenamiento 502 configurado para recibir un bloque del subsistema de consenso y almacenar el bloque en una cadena de bloques pública correspondiente al subsistema sin consenso.

El aparato comprende además: un segundo módulo de almacenamiento 503 configurado para recibir un resumen de transacciones correspondiente al bloque del subsistema de consenso y almacenar el resumen de transacciones en la cadena de bloques pública de manera que el resumen de transacciones esté disponible para su búsqueda por los nodos sin consenso.

El aparato comprende además: un módulo de búsqueda 504 configurado para recibir una solicitud de búsqueda de datos de transacción desde un nodo sin consenso, determinar el permiso de búsqueda del nodo sin consenso de acuerdo con la solicitud de búsqueda y devolver, de acuerdo con el permiso de búsqueda, los datos de la transacción correspondientes al permiso de búsqueda del nodo sin consenso.

El permiso de búsqueda de un nodo sin consenso puede determinarse de la siguiente manera:

para cada nodo sin consenso, determinar un tipo de nodo sin consenso; y

según el tipo de nodo sin consenso, asignar permiso de búsqueda al nodo sin consenso.

El módulo de búsqueda 504 obtiene, según el permiso de búsqueda, los datos de transacción correspondientes al permiso de búsqueda del subsistema de consenso correspondiente a la solicitud de búsqueda y devuelve los datos de transacción obtenidos al nodo sin consenso.

En la década de 1990, una mejora de una tecnología se puede diferenciar obviamente en una mejora de hardware (por ejemplo, una mejora de la estructura de un circuito, tal como un diodo, un transistor, un interruptor, etc.) o una mejora de software (una mejora de un flujo de un método). Sin embargo, con el desarrollo tecnológico, muchas de las mejoras actuales de los flujos de métodos pueden considerarse mejoras directas de las estructuras de los circuitos de hardware. Los diseñadores casi siempre obtienen una estructura de circuito de hardware correspondiente programando un flujo de método mejorado en un circuito de hardware. Por lo tanto, no se puede concluir que no se pueda realizar una mejora en el flujo de un método con un módulo de hardware. Por ejemplo, el dispositivo lógico programable (PLD) (por ejemplo, la matriz de puerta programable en campo (FP-GA)) es un circuito integrado tal que las funciones lógicas del circuito integrado las determina un usuario mediante la programación del dispositivo. Un diseñador programa por sí mismo para "integrar" un sistema digital en una pieza de PLD, sin necesidad de pedirle a un fabricante de chips que diseñe y fabrique un chip IC exclusivo. En la actualidad, además, este tipo de programación se ha implementado principalmente a través de software de "compilador lógico", en lugar de fabricar manualmente los chips IC. El software del compilador lógico es similar a un compilador de software utilizado para el desarrollo y la escritura de programas, mientras que se debe utilizar un lenguaje de programación particular para escribir códigos fuente antes de la compilación, que se conoce como lenguaje de descripción de hardware (HDL). No hay solo uno, sino muchos tipos de HDL, tales como ABEL (lenguaje de expresiones booleanas avanzadas), AHDL (lenguaje de descripción de hardware Altera), Confluence, CUPL (lenguaje de programación de la Universidad de Cornell), HDCal, JHDL (lenguaje de descripción de hardware Java), Lava, Lola, MyHDL, PALASM, RHDL (lenguaje de descripción de hardware Ruby), etc. El más utilizado en este momento incluye VHDL (lenguaje de descripción de hardware de circuito integrado de muy alta velocidad) y Verilog. Un experto en la técnica también debería saber que sería muy fácil obtener un circuito de hardware para implementar un flujo de método lógico utilizando los HDL anteriores para llevar a cabo una ligera programación lógica en el flujo de método y programar el flujo de método en un IC.

Un controlador puede implementarse de cualquier manera adecuada. Por ejemplo, un controlador puede estar en, por ejemplo, una forma de microprocesador o procesador, así como un medio legible por ordenador que almacena códigos de programa legibles por ordenador (por ejemplo, software o firmware) capaces de ser ejecutados por el (micro)procesador, una puerta lógica, un interruptor, un circuito integrado de aplicación específica (ASIC), un controlador lógico programable y un microcontrolador integrado. Los ejemplos del controlador incluyen, pero sin limitaciones, los siguientes microcontroladores: ARC 625D, Atmel AT91sA m , Microchip PIC18F26K20 y Silicone Labs C8051F320. Un controlador de memoria puede implementarse además como parte de una lógica de control de una memoria. Un experto en la técnica también debería ser consciente de que, además de que un controlador se implementa en una forma de códigos de programa legibles por ordenador, es totalmente factible realizar la programación lógica en las etapas de un método para permitir que un controlador implemente las mismas funciones en forma de puerta lógica, interruptor, ASIC, controlador lógico programable y microcontrolador integrado. Por lo tanto, dicho controlador puede considerarse como una parte de hardware, mientras que los dispositivos incluidos en el controlador y configurados para lograr diversas funciones también pueden considerarse como una estructura dentro de la parte de hardware. Como alternativa, los dispositivos configurados para lograr diversas funciones pueden incluso considerarse como módulos de software para implementar un método y una estructura dentro de una parte de hardware.

Los operadores técnicos involucrados en el pago en las realizaciones de la presente solicitud pueden comprender, por ejemplo, Comunicación de campo cercano (NFC), WIFI, 3G/4G/5G, tecnologías de deslizamiento de tarjetas de terminales POS, tecnologías de escaneo de códigos QR, tecnologías de escaneo de códigos de barras, Bluetooth, IR, servicio de mensajes cortos (SMS), servicio de mensajes multimedia (MMS), etc.

El sistema, aparato, módulo o unidad descrito en las realizaciones anteriores puede implementarse mediante un chip o entidad de ordenador, o implementarse mediante un producto que tiene una función. Un dispositivo de implementación típico es un ordenador. En un ejemplo, un ordenador puede ser, por ejemplo, un ordenador personal, un ordenador portátil, un teléfono móvil, 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, un consola de juegos, una tableta, un dispositivo portátil o una combinación de cualquier dispositivo en estos dispositivos.

Por conveniencia de la descripción, el dispositivo anterior se divide en varias unidades de acuerdo con las funciones para la descripción. Las funciones de las unidades pueden implementarse en una o más piezas de software y/o hardware cuando se implementa la presente solicitud.

Un experto en la técnica debería comprender que las realizaciones de la presente invención pueden proporcionarse como un método, un sistema o un producto de programa informático. Por lo tanto, la presente invención puede implementarse como una realización completa de hardware, una realización completa de software o una realización que combine software y hardware. Además, la presente invención puede tener la forma de un producto de programa informático implementado en uno o más medios de almacenamiento utilizables por ordenador (que incluyen, entre otros, una memoria de disco magnético, CD-ROM, una memoria óptica, etc.) que comprende códigos de programa utilizables por un ordenador.

La presente invención se describe con referencia a diagramas de flujo y/o diagramas de bloques del método, dispositivo (sistema) y producto de programa informático según las realizaciones de la presente invención. Debe entenderse que se puede utilizar una instrucción de programa informático para implementar cada proceso y/o bloque en los diagramas de flujo y/o diagramas de bloques y una combinación de procesos y/o bloques en los diagramas de flujo y/o diagramas de bloques. Estas instrucciones del programa informático pueden proporcionarse para un ordenador de uso general, un ordenador de uso especial, un procesador integrado o un procesador de otros dispositivos de procesamiento de datos programables para generar una máquina, lo que hace que las instrucciones sean ejecutadas por un ordenador o un procesador de otros dispositivos de procesamiento de datos programables para generar un aparato para implementar una función especificada en uno o más procesos en los diagramas de flujo y/o en uno o más bloques en los diagramas de bloques.

Estas instrucciones del programa informático también pueden almacenarse en una memoria legible por ordenador que puede instruir a un ordenador u otros dispositivos de procesamiento de datos programables para que funcionen de una manera particular, haciendo que las instrucciones almacenadas en la memoria legible por ordenador generen un artículo fabricado que incluye un aparato de instrucciones. El aparato de instrucciones implementa una función especificada en uno o más procesos en los diagramas de flujo y/o en uno o más bloques en los diagramas de bloques.

Estas instrucciones del programa informático también pueden cargarse en un ordenador u otros dispositivos de procesamiento de datos programables, provocando que se realicen una serie de etapas operativas en el ordenador u otros dispositivos programables, generando así un procesamiento implementado por ordenador. Por tanto, las instrucciones ejecutadas en el ordenador u otros dispositivos programables proporcionan etapas para implementar una función especificada en uno o más procesos en los diagramas de flujo y/o en uno o más bloques en los diagramas de bloques.

En una configuración típica, el dispositivo de cálculo incluye uno o más procesadores (CPU), interfaces de entrada/salida, interfaces de red y una memoria.

La memoria puede incluir medios legibles por ordenador, tal como una memoria volátil, una memoria de acceso aleatorio (RAM) y/o una memoria no volátil, por ejemplo, una memoria de solo lectura (ROM) o una memoria RAM flash. La memoria es un ejemplo de un medio legible por ordenador.

Los medios legibles por ordenador incluyen medios no volátiles, volátiles, móviles e inmóviles, que pueden implementar el almacenamiento de información a través de cualquier método o tecnología. La información puede ser instrucciones legibles por ordenador, estructuras de datos, módulos de programa u otros datos. Los ejemplos de medios de almacenamiento de ordenadores incluyen, entre otros, memorias de acceso aleatorio de cambio de fase (PRAM), memorias de acceso aleatorio estáticas (SRAM), memorias de acceso aleatorio dinámico (DRAM), otros tipos de memorias de acceso aleatorio (RAM), memorias de solo lectura (ROM), memorias de solo lectura programables y borrables eléctricamente (EEPROM), memorias flash u otras tecnologías de memoria, memorias de disco compacto de solo lectura (CD-ROM), discos versátiles digitales (DVD) u otras memorias ópticas, casetes, memorias de casete y disco u otros dispositivos de memoria magnética, o cualquier otro medio que no sea de transmisión que pueda usarse para almacenar información accesible a un dispositivo de computación. De acuerdo con las definiciones de la memoria descriptiva, los medios legibles por ordenador no incluyen medios transitorios, tales como señales y portadoras de datos modulados.

Cabe señalar además que los términos "que incluye", "que comprende" o cualquier otra variante de los términos pretenden abarcar una inclusión no exclusiva, lo que provoca que un proceso, método, producto básico o dispositivo que comprenda una serie de elementos no solo comprendan estos elementos, sino que también comprendan otros elementos que no están claramente enumerados, o comprendan además elementos que son inherentes al proceso, método, producto básico o dispositivo. Cuando no hay ninguna restricción adicional, los elementos definidos por la declaración "que comprende uno ..." no excluyen que un proceso, método, producto básico o dispositivo que comprende los elementos anteriores comprenda además elementos idénticos adicionales.

Un experto en la técnica debería comprender que las realizaciones de la presente solicitud pueden proporcionarse como un método, un sistema o un producto de programa informático. Por lo tanto, la presente solicitud puede implementarse como una realización de hardware completa, una realización de software completa o una realización que combina software y hardware. Además, la presente solicitud puede tener la forma de un producto de programa informático implementado en uno o más medios de almacenamiento utilizables por ordenador (que incluyen, pero sin limitación, una memoria de disco magnético, CD-ROM, una memoria óptica, etc.) que comprende códigos de programa utilizables por ordenador.

La presente solicitud puede describirse en un contexto regular de una instrucción ejecutable por ordenador que es ejecutada por un ordenador, tal como un módulo de programa. Generalmente, el módulo de programa comprende una rutina, un programa, un objeto, un componente, una estructura de datos, etc. para ejecutar una tarea particular o implementar un tipo de datos abstracto particular. La presente aplicación también se puede poner en práctica en entornos informáticos distribuidos. En estos entornos informáticos distribuidos, los dispositivos de procesamiento remoto conectados a través de redes de comunicación realizan tareas. En los entornos informáticos distribuidos, un módulo de programa puede estar ubicado en un medio de almacenamiento informático local y remoto, incluidos los dispositivos de almacenamiento.

Las realizaciones en esta memoria descriptiva se describen de una manera progresiva con cada realización enfocada en las diferencias de otras realizaciones y las realizaciones pueden ser referenciadas mutuamente para partes idénticas o similares. En particular, la realización del sistema se describe de una manera relativamente simple, ya que la realización del sistema es sustancialmente similar a la realización del método. La descripción de la realización del método puede hacer referencia a las partes relacionadas.

Claims

REIVINDICACIONES

1. Un sistema de cadena de bloques, que comprende un centro de distribución (102), un subsistema sin consenso (101) y una pluralidad de subsistemas de consenso (103), en el que el subsistema sin consenso (101) comprende una pluralidad de nodos sin consenso y cada uno de los subsistemas de consenso comprende una pluralidad de nodos de consenso;

un nodo sin consenso de la pluralidad de nodos sin consenso envía una solicitud de transacción al centro de distribución (102);

el centro de distribución (102) recibe la solicitud de transacción del subsistema sin consenso, determina un subsistema de consenso (103) correspondiente a la solicitud de transacción según los datos de la transacción comprendidos en la solicitud de transacción y reenvía la solicitud de transacción al subsistema de consenso (103) determinado; y el subsistema de consenso (103) recibe la solicitud de transacción enviada por el centro de distribución (102) y envía la solicitud de transacción a todos los nodos de consenso en el subsistema de consenso para la validación de consenso; si la validación tiene éxito, genera un bloque correspondiente de acuerdo con la solicitud de transacción y almacena el bloque en una cadena de bloques de consorcio correspondiente al subsistema de consenso (103).

2. El sistema de cadena de bloques de acuerdo con la reivindicación 1, en el que el subsistema de consenso (103) está configurado además para: si la validación tiene éxito, enviar el bloque correspondiente a la solicitud de transacción al subsistema sin consenso (101);

en donde el subsistema sin consenso (101) recibe el bloque y almacena el bloque en una cadena de bloques pública correspondiente al subsistema sin consenso,

en donde, opcionalmente, el subsistema de consenso (103) está configurado además para: generar un resumen de la transacción correspondiente al bloque basado en los datos de transacción correspondientes al bloque y enviar el resumen de la transacción al subsistema sin consenso; en donde el subsistema sin consenso (101) almacena el resumen de la transacción en la cadena de bloques pública de manera que el resumen de la transacción está disponible para su búsqueda por los nodos sin consenso.

3. El sistema de cadena de bloques de acuerdo con la reivindicación 1, en el que el subsistema sin consenso (101) comprende además:

un navegador de datos configurado para recibir una solicitud de búsqueda de datos de transacciones desde el nodo sin consenso (101), determinar el permiso de búsqueda del nodo sin consenso de acuerdo con la solicitud de búsqueda; y devolver, según el permiso de búsqueda, los datos de transacción correspondientes al permiso de búsqueda al nodo sin consenso.

4. El sistema de cadena de bloques de acuerdo con la reivindicación 3, en el que el permiso de búsqueda del nodo sin consenso (101) se determina de la siguiente manera:

para cada nodo sin consenso (101), determinar un tipo de nodo sin consenso; y

5. El sistema de cadena de bloques de acuerdo con la reivindicación 3, en el que el navegador de datos obtiene, según el permiso de búsqueda, los datos de transacción correspondientes al permiso de búsqueda de un subsistema de consenso (103) correspondiente a la solicitud de búsqueda y devuelve los datos de transacción obtenidos al nodo sin consenso.

6. Un método de almacenamiento de datos, en el que un sistema de cadena de bloques comprende un centro de distribución (102), un subsistema sin consenso (101) y una pluralidad de subsistemas de consenso (103), el subsistema sin consenso (101) comprende una pluralidad de nodos sin consenso y cada uno de los subsistemas de consenso comprende una pluralidad de nodos de consenso, comprendiendo el método:

recibir, por parte de un subsistema de consenso (103) correspondiente a una solicitud de transacción, la solicitud de transacción reenviada (203) por el centro de distribución, comprendiendo la solicitud de transacción los datos de la transacción, en donde la solicitud de transacción es enviada (201) por la pluralidad de nodos sin consenso al centro de distribución, en donde el subsistema de consenso correspondiente a la solicitud de transacción es determinado (202), por el centro de distribución, según los datos de la transacción comprendidos en la solicitud de transacción;

enviar la solicitud de transacción a todos los nodos de consenso en el subsistema de consenso para la validación de consenso (204);

si la validación tiene éxito, generar (205) un bloque correspondiente de acuerdo con la solicitud de transacción y almacenar el bloque en una cadena de bloques de consorcio correspondiente al subsistema de consenso.

7. El método de acuerdo con la reivindicación 6, que además comprende: si la validación tiene éxito, enviar (206) el bloque correspondiente a la solicitud de transacción al subsistema sin consenso, haciendo que el subsistema sin consenso almacene (207) el bloque en una cadena de bloques pública correspondiente al subsistema sin consenso.

8. El método de acuerdo con la reivindicación 7, en el que, si los nodos de consenso llegan a un consenso de que la solicitud de transacción es legítima, el método comprende además:

generar un resumen de la transacción correspondiente al bloque según los datos de transacción correspondientes al bloque; y

enviar el resumen de la transacción al subsistema sin consenso (101), haciendo que el subsistema sin consenso almacene el resumen de la transacción en la cadena de bloques pública de modo que el resumen de la transacción esté disponible para su búsqueda por los nodos sin consenso.

9. El método de acuerdo con la reivindicación 6, que además comprende:

recibir una solicitud de obtención (208) de datos de transacciones del subsistema sin consenso; y

devolver (209), de acuerdo con la solicitud de obtención, los datos de transacción correspondientes a la solicitud de obtención al subsistema sin consenso,

en donde, opcionalmente, la solicitud de obtención comprende el permiso de búsqueda de un nodo sin consenso y el permiso de búsqueda lo determina el subsistema sin consenso según una solicitud de búsqueda de los datos de transacción enviados por el nodo sin consenso; y

la devolución, según la solicitud de obtención, de los datos de transacción correspondientes a la solicitud de obtención al subsistema sin consenso (101) comprende:

determinar, de acuerdo con el permiso de búsqueda, datos de transacción correspondientes al permiso de búsqueda a partir de datos de transacción almacenados en el subsistema sin consenso.

10. Un método de almacenamiento de datos, en el que un sistema de cadena de bloques comprende un centro de distribución (102), un subsistema sin consenso (101) y una pluralidad de subsistemas de consenso (103), el subsistema sin consenso comprende una pluralidad de nodos sin consenso y cada uno de los subsistemas de consenso comprende una pluralidad de nodos de consenso, comprendiendo el método:

recibir, por parte del centro de distribución (102), una solicitud de transacción enviada (201) por el subsistema sin consenso, comprendiendo la solicitud de transacción datos de transacción;

determinar (202) un subsistema de consenso correspondiente a la solicitud de transacción según los datos de transacción incluidos en la solicitud de transacción; y

reenviar (203) la solicitud de transacción al subsistema de consenso determinado, haciendo que el subsistema de consenso realice una validación de consenso sobre la solicitud de transacción y almacene un bloque correspondiente a la solicitud de transacción validada en una cadena de bloques de consorcio correspondiente al subsistema de consenso.

11. Un método de almacenamiento de datos, en el que un sistema de cadena de bloques comprende un centro de distribución (102), un subsistema sin consenso (101) y una pluralidad de subsistemas de consenso (103), el subsistema sin consenso comprende una pluralidad de nodos sin consenso y cada uno de los subsistemas de consenso comprende una pluralidad de nodos de consenso, comprendiendo el método:

enviar (201), por el subsistema sin consenso, una solicitud de transacción al centro de distribución, comprendiendo la solicitud de transacción datos de la transacción, haciendo que el centro de distribución reenvíe (203), según los datos de la transacción, la solicitud de transacción a un subsistema de consenso correspondiente a los datos de la transacción, en donde la solicitud de transacción es para la validación de consenso.

12. El método de acuerdo con la reivindicación 11, que además comprende:

recibir un bloque del subsistema de consenso; y

almacenar (207) el bloque en una cadena de bloques pública correspondiente al subsistema sin consenso, que opcionalmente comprende además:

recibir un resumen de transacciones correspondiente al bloque desde el subsistema de consenso (103); y

almacenar el resumen de la transacción en la cadena de bloques pública de modo que el resumen de la transacción esté disponible para que lo busquen los nodos sin consenso.

13. El método de acuerdo con la reivindicación 11, que además comprende:

recibir una solicitud de búsqueda de datos de transacción desde un nodo sin consenso de la pluralidad de nodos sin consenso, determinar el permiso de búsqueda del nodo sin consenso de acuerdo con la solicitud de búsqueda y devolver (209), de acuerdo con el permiso de búsqueda, los datos de transacción correspondientes al permiso de búsqueda al nodo sin consenso.

14. El método de acuerdo con la reivindicación 13, en el que el permiso de búsqueda del nodo sin consenso se determina de la siguiente manera:

para cada nodo sin consenso, determinar un tipo de nodo sin consenso; y

según el tipo de nodo sin consenso, asignar permiso de búsqueda al nodo sin consenso, y/o

en donde la devolución, de acuerdo con el permiso de búsqueda, de los datos de transacción correspondientes al permiso de búsqueda al nodo sin consenso comprende:

obtener, de acuerdo con el permiso de búsqueda, datos de la transacción correspondientes al permiso de búsqueda de un subsistema de consenso (103) correspondiente a la solicitud de búsqueda y devolver los datos de la transacción obtenidos al nodo sin consenso.

15. Un aparato de almacenamiento de datos configurado para llevar a cabo el método de una cualquiera de las reivindicaciones 6 a 14.