ES2905932T3

ES2905932T3 - Método de gestión de cadena de bloques, programa de gestión de cadena de bloques, dispositivo de gestión de cadena de bloques y sistema de gestión de cadena de bloques

Info

Publication number: ES2905932T3
Application number: ES18742135T
Authority: ES
Inventors: Tsunekazu Shima; Jun Kogure
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2017-01-18
Filing date: 2018-01-05
Publication date: 2022-04-12
Anticipated expiration: 2038-01-05
Also published as: US20190340169A1; EP3572966B1; WO2018135328A1; JP2018116509A; JP6900680B2; EP3572966A4; EP3572966A1

Abstract

Un método de gestión de cadena de bloques en el que un proceso es ejecutado por un ordenador, el proceso comprende: generar (S302) un primer hash de datos incluidos en un bloque parcial obtenido al excluir una segunda área de un primer bloque de una cadena de bloques, el primer bloque incluye una primera área en la que se prohíbe un cambio de datos y la segunda área en la que se permite el cambio de datos; generar (S303) un segundo hash de datos incluidos en el primer bloque; y agregar (S304) el primer hash y el segundo hash a un segundo bloque de la cadena de bloques, el segundo bloque se agrega junto al primer bloque e incluye una primera área en la que se prohíbe un cambio de datos y una segunda área en la que se permite el cambio de datos.

Description

DESCRIPCIÓN

Método de gestión de cadena de bloques, programa de gestión de cadena de bloques, dispositivo de gestión de cadena de bloques y sistema de gestión de cadena de bloques

Campo técnico

La presente divulgación se refiere a un método de gestión de cadena de bloques, a un programa de gestión de cadena de bloques, a un dispositivo de gestión de cadena de bloques y a un sistema de gestión de cadena de bloques.

Técnica antecedente

Se conoce una tecnología llamada cadena de bloques (véase, por ejemplo, PTL 1). En la cadena de bloques, se dispone una pluralidad de bloques en series de tiempos. Cada uno de los bloques almacena un valor hash (en adelante, simplemente denominado hash) del bloque previo y datos relacionados con una relación comercial denominada transacción.

Lista de citas

Literatura de patentes

PTL 1: Patente japonesa núm. 5858506

PTL 2: Solicitud de patente estadounidense núm. 2016/358135

PTL 3: Solicitud de patente estadounidense núm. 2008/307230

Breve descripción de la invención

Problema técnico

Mientras tanto, en un caso donde los datos relacionados con privacidad, tal como información personal e información de la empresa, se incluyen en los datos anteriores en una cadena de bloques, a veces se desea cambiar una parte de los datos más tarde en vista de la protección de privacidad.

Por consiguiente, en un aspecto, es un objeto proporcionar un método de gestión de cadena de bloques, un programa de gestión de cadena de bloques, un dispositivo de gestión de cadena de bloques y un sistema de gestión de cadena de bloques capaces de determinar que, cuando se cambia una parte de los datos, una parte distinta de la parte cambiada no es manipulada.

Solución al problema

La invención está divulgada por las reivindicaciones independientes. Realizaciones adicionales están descritas por las reivindicaciones dependientes.

De acuerdo con una realización, un método de gestión de cadena de bloques es un método de gestión de cadena de bloques en el que un proceso es ejecutado por un ordenador, el proceso incluye: generar un primer hash de datos incluidos en un bloque parcial obtenido al excluir una segunda área de un primer bloque que incluye una primera área en la que se prohíbe un cambio de datos y la segunda área en la que se permite el cambio de datos; generar un segundo hash de datos incluidos en el primer bloque; y agregar el primer hash y el segundo hash a un segundo bloque que se agrega junto al primer bloque e incluye una primera área en la que se prohíbe un cambio de datos y una segunda área en la que se permite el cambio de datos.

Efectos ventajosos de la invención

Cuando se cambia una parte de los datos, es posible determinar que una parte distinta a la parte cambiada no ha sido manipulada.

Breve descripción de los dibujos

La figura 1 es un diagrama para explicar un ejemplo de un sistema de gestión de cadena de bloques.

La figura 2 es un ejemplo de una configuración de hardware de un nodo.

La figura 3 es un ejemplo de un diagrama de bloques funcional del nodo.

La figura 4 es un diagrama para explicar un ejemplo de una cadena de bloques de acuerdo con un ejemplo comparativo. La figura 5 es un diagrama para explicar un ejemplo de una cadena de bloques de acuerdo con la presente realización. ^{La figura}6 ^{es un diagrama de flujo que ilustra un ejemplo de una operación de un usuario.}

La figura 7 es un diagrama de flujo que ilustra un ejemplo de una operación relacionada con la generación de un bloque realizada por un extractor.

^{La figura}8 ^{es un diagrama de flujo que ilustra un ejemplo de un proceso de bloques.}

La figura 9 es un diagrama para explicar un ejemplo de generación de un nuevo bloque.

La figura 10 es un diagrama para explicar un ejemplo para cambiar datos incluidos en un bloque.

La figura 11 es un diagrama de flujo que ilustra un ejemplo de una operación relacionada con la verificación de bloques y actualización de bloques realizadas por el extractor.

La figura 12 es un diagrama de flujo que ilustra un ejemplo de un segundo proceso de verificación.

La figura 13 es un diagrama para explicar un ejemplo de verificación de un bloque.

La figura 14 es un diagrama que ilustra un ejemplo de estructura de datos de un n-ésimo bloque.

Descripción de las realizaciones

A continuación, se describirá una realización de la presente divulgación con referencia a los dibujos.

La figura 1 es un diagrama para explicar un ejemplo de un sistema de gestión de cadena de bloques S. El sistema de gestión de cadena de bloques S incluye una pluralidad de nodos 100, 150, 200 y 250, de los cuales todos sirven como dispositivos terminales. En la figura 1, se ilustra un teléfono inteligente como ejemplo del nodo 100. Se ilustra un ordenador personal (PC) tipo laptop como ejemplo del nodo 150. Nótese que los nodos 100 y 150 no se limitan al teléfono inteligente o al PC, y pueden ser, por ejemplo, una terminal de tableta o una terminal usable. La terminal portátil es, por ejemplo, un reloj inteligente o similar. Por otro lado, se ilustran un PC de escritorio y un servidor como ejemplos de los nodos 200 y 250.

Los nodos 100, 150, 200 y 250 están conectados entre sí mediante una red de comunicación NW. Específicamente los nodos 100, 150, 200 y 250 están acoplados entre sí utilizando una red denominada de igual a igual (P2P). La red de comunicación NW es, por ejemplo, una red alámbrica tal como una red de área local (LAN) o Internet. Además, la comunicación inalámbrica puede utilizarse para una parte de la comunicación entre los nodos 100, 150, 200 y 250. Por ^{ejemplo, como se ilustra en la figura}1^{, puede utilizarse comunicación inalámbrica para la comunicación entre el nodo}100 y los nodos 150, 200 y 250. En este caso, si el nodo 100 está incluido en un área de comunicación inalámbrica AR, el nodo 100 puede comunicarse con los nodos 150, 200 y 250 mediante una estación base móvil BS.

A continuación, se describirá una configuración de hardware del nodo 200 con referencia a la figura 2. Puesto que los nodos 100, 150 y 250 descritos anteriormente tienen básicamente la misma configuración de hardware que el nodo 200, se omitirá la descripción de la misma.

La figura 2 es un ejemplo de una configuración de hardware del nodo 200. Como se ilustra en la figura 2, el nodo 200 incluye al menos una unidad central de procesamiento (CPU) 200A, una memoria de acceso aleatorio (RAM) 200B, una memoria de sólo lectura (ROM) 200C, y una interfaz de red (I/F) 200D. El nodo 200 puede incluir al menos una de una unidad de disco duro (HDD) 200E, una I/F de entrada 200F, una I/F de salida 200G, una I/F de entrada y salida 200H, y un dispositivo de unidad 2001, según sea necesario. La CPU 200A y el dispositivo de unidad 2001 están acoplados entre sí por un bus interno 200J. Un ordenador se realiza por cooperación entre al menos la CPU 200A y la RAM 200B.

Un dispositivo de entrada 710 está acoplado a la I/F de entrada 200F. El dispositivo de entrada 710 es, por ejemplo, un teclado, un ratón o similares.

Un dispositivo de visualización 720 está acoplado a la I/F de salida 200G. El dispositivo de visualización 720 es, por ejemplo, una pantalla de cristal líquido.

Una memoria de semiconductor 730 está acoplada a la I/F de entrada y salida 200H. La memoria de semiconductor 730 es, por ejemplo, una memoria bus de serie universal (USB), una memoria flash o similar. La I/F de entrada y salida 200H lee un programa o datos almacenados en la memoria de semiconductor 730.

La I/F de entrada 200F y la I/F de entrada y salida 200H incluyen, por ejemplo, un puerto USB. La I/F de salida 200G incluye, por ejemplo, un puerto de pantalla.

Un medio de grabación portátil 740 se inserta en el dispositivo de unidad 2001. El medio de grabación portátil 740 es, por ejemplo, un disco extraíble tal como un disco compacto (CD)-ROM o un disco versátil digital (DVD). El dispositivo de unidad 2001 lee un programa o datos grabados en el medio de grabación portátil 740.

La I/F de red 200D incluye, por ejemplo, un puerto de LAN. La I/F de red 200D está acoplada a la red de comunicación NW.

La CPU 200A almacena un programa almacenado en la ROM 200C o la HDD 200E en la RAM 200B descrita anteriormente. La CPU 200A almacena el programa grabado en el medio de grabación portátil 740 en la RAM 200B. Como resultado de la ejecución del programa almacenado por la CPU 200A, se realizan varias funciones que se describirán más adelante y se ejecutan varios procesos que se describirán más adelante. Obsérvese que el programa puede ser de acuerdo con un diagrama de flujo que se describirá más adelante.

A continuación, se describirá cada una de las funciones de los nodos 100, 150, 200 y 250 con referencia a la figura 3.

La figura 3 es un ejemplo de un diagrama de bloques funcional de los nodos 100 y 200. Ya que el nodo 150 tiene básicamente la misma función que el nodo 100 y el nodo 250 tiene básicamente la misma función que el nodo 200, se omitirá su descripción.

Como se ilustra en la figura 3, el nodo 100 incluye una herramienta de cartera WT, y el nodo 200 incluye una herramienta de cartera WT y una herramienta de extracción MT. En este caso, la herramienta de cartera WT es una herramienta necesaria para realizar una transacción utilizando una cadena de bloques (específicamente, bitcoin (marca registrada) o similar). Por otro lado, la herramienta de extracción MT es una herramienta necesaria para verificar la integridad y consistencia de la transacción utilizando la cadena de bloques y para aprobar la transacción.

Aquí, el nodo 100 que incluye la herramienta de cartera WT sin la herramienta de extracción MT puede denominarse usuario. Así, en la siguiente descripción, los nodos 100 y 150 se describirán con otras palabras como usuarios 100 y 150. Por otro lado, el nodo 200 que incluye tanto la herramienta de cartera WT como la herramienta de extracción m T puede denominarse extractor (un excavador). Así, en la siguiente descripción, los nodos 200 y 250 se describirán con otras palabras como extractores 200 y 250.

Cada una de las herramientas de cartera WT del usuario 100 y del extractor 200 incluye una unidad de aceptación de solicitudes WT1 y una unidad de transmisión de solicitudes WT2. Por ejemplo, cuando se introduce una solicitud de registro de datos al usuario 100, la unidad de aceptación de solicitudes WT1 del usuario 100 acepta la solicitud de registro de datos de entrada. La solicitud de registro de datos es la información para realizar una solicitud de (solicitar) registro de datos de transacción , e incluye los datos que deben registrarse. Por ejemplo, cuando se introduce una solicitud de cambio de datos al usuario 100, la unidad de aceptación de solicitudes WT1 del usuario 100 acepta la solicitud de cambio de datos de entrada. La solicitud de cambio de datos es información para hacer una solicitud de (solicitar) un cambio de los datos de transacción, e incluye información que especifica los datos que deben cambiarse y la información después del cambio (por ejemplo, información para ocultar una parte relacionada con la privacidad). Además, cuando la unidad de aceptación de solicitudes WT 1 acepta una solicitud de registro de datos o una solicitud de cambio de datos, la unidad de transmisión de solicitudes WT2 transmite por P2P la solicitud de registro de datos o la solicitud de cambio de datos aceptada por la unidad de aceptación de solicitudes WT1. Es decir, puesto que la red P2P se utiliza en la presente realización, cuando la unidad de transmisión de solicitudes WT2 del usuario 100 transmite la solicitud de registro de datos o la solicitud de cambio de datos, la solicitud de registro de datos o la solicitud de cambio de datos se transmite al usuario 150, al extractor 200 y al extractor 250.

A continuación, la herramienta de extracción MT del extractor 200 incluye una unidad de generación de bloques MT1, una unidad de verificación de bloques MT2 y una unidad de actualización de bloques MT3. Por ejemplo, cuando la unidad de transmisión de solicitudes WT2 del usuario 100 transmite una solicitud de registro de datos, la unidad de generación de bloques MT1 del extractor 200 recibe la solicitud de registro de datos. Al recibir la solicitud de registro de datos, la unidad de generación de bloques MT1 genera un bloque y almacena los datos incluidos en la solicitud de registro de datos en el bloque. Por ejemplo, cuando la unidad de transmisión de solicitudes WT2 del usuario 100 transmite una solicitud de cambio de datos, la unidad de generación de bloques MT1 del extractor 200 recibe la solicitud de cambio de datos. Al recibir la solicitud de cambio de datos, la unidad de generación de bloques MT1 cambia una parte de los datos incluidos en un bloque específico entre los bloques gestionados por la cadena de bloques, por los datos incluidos en la solicitud de cambio de datos. Obsérvese que la generación de un bloque puede denominarse extracción de un bloque.

La unidad de verificación de bloques MT2 verifica la validez del bloque generado o cambiado por la unidad de generación de bloques MT 1. Más específicamente, la unidad de verificación de bloques MT2 verifica la validez de los datos incluidos en el bloque generado o cambiado por la unidad de generación de bloques MT1. Obsérvese que se describirán los detalles de un proceso de verificación realizado por la unidad de verificación de bloques MT2 a continuación.

En el caso donde la verificación por parte de la unidad de verificación de bloques MT2 es positiva, la unidad de actualización de bloques MT3 agrega el bloque al final de la cadena de bloques o cambia el bloque objetivo de cambio gestionado por la cadena de bloques al bloque cuyos datos han sido cambiados. Obsérvese que la cadena de bloques se distribuye a y se comparte entre los usuarios 100 y 150 y los extractores 200 y 250. Los usuarios 100 y 150 pueden almacenar una parte de la cadena de bloques que les interese, pero los extractores 200 y 250, deseablemente, almacenan toda la cadena de bloques. Obsérvese que, en lugar de distribuir y compartir, una base de datos (DB) puede gestionar la cadena de bloques de forma centralizada.

A continuación, se describirá una cadena de bloques de acuerdo con la presente realización en comparación con una cadena de bloques de acuerdo con un ejemplo comparativo con referencia a las figuras 4, 5 y 14.

La figura 4 es un diagrama para explicar un ejemplo de una cadena de bloques 10 de acuerdo con el ejemplo comparativo. La figura 5 es un diagrama para explicar un ejemplo de una cadena de bloques 20 de acuerdo con la presente realización. La figura 14 es un diagrama que ilustra un ejemplo de estructura de datos de un n-ésimo bloque.

En primer lugar, como se ilustra en la figura 4, la cadena de bloques 10 incluye un (n-1)-ésimo bloque 11, un n-ésimo bloque 12 y un (n+1)-ésimo bloque 13. El (n-l)-ésimo bloque 11 incluye un hash h(n-2) de un (n-2)-ésimo bloque (no ilustrado) dispuesto inmediatamente antes, un área que incluye datos do, y un área que incluye datos d1. Asimismo, el ^{n-ésimo bloque}12 ^{incluye un hash h(n-}1^{) del (n-}1^{)-ésimo bloque}11 ^{dispuesto inmediatamente antes, un área que incluye}datos d2, y un área que incluye datos d3. El (n+1)-ésimo bloque 13 incluye un hash h(n) del n-ésimo bloque 12 dispuesto inmediatamente antes, un área que incluye datos d4, y un área que incluye datos d5. En cada una de las áreas que incluyen los datos d0 a d5, se prohíbe un cambio de los datos.

Además, como se ilustra en el lado inferior del bloque 11, el hash h(n-1) se genera basándose en el hash h(n-2), los datos d0 y los datos d1 incluidos en el (n-1)-ésimo bloque 11, y una función H(). Asimismo, el hash h(n) se genera basándose en el hash h(n-1), los datos d2 y los datos d3 incluidos en el n-ésimo bloque 12, y la función H(). La función H() es una función hash que genera un hash a partir de elementos incluidos en un bloque. Por ejemplo, en el caso de un hash h(n), el hash h(n) se genera utilizando la función H() para el hash h(n-1), los datos d2 y los datos d3 los cuales son todos elementos del n-ésimo bloque 12. El hash h(n-1) se genera de la misma manera que el hash h(n).

Aquí, en la cadena de bloques 10 ilustrada en la figura 4, por ejemplo, supone que los datos d1 incluidos en el bloque 11 se eliminan y se genera de nuevo un hash h(n-1). A continuación, se genera el hash h(n-1) basándose en el hash h(n-2), los datos d0 y la función H() sin los datos d1. Por otro lado, el n-ésimo bloque 12 incluye el hash ya generado h(n-1). Cuando el hash h(n-1) que se genera después de borrar los datos d1 se compara con el hash h(n-1) que se incluye en el bloque 12 y se genera antes de borrar los datos d1, los hashes no coinciden entre sí. De este modo, puesto que los dos hashes h(n-1) son diferentes entre sí, es posible determinar que hay algunos cambios en el bloque 11. En ^{otras palabras, si los dos (n-}1^{) hashes no son diferentes entre sí, es posible determinar que no hay ningún cambio en el}bloque 11. Es decir, es posible verificar la validez del bloque 11.

De este modo, la cadena de bloques 10 de acuerdo con el ejemplo comparativo adopta un mecanismo en el que si se cambian los datos, se detecta el bloque 11 que incluye los datos cambiados. Por lo tanto, incluso si hay un cambio no autorizado, tal como manipulación de datos, el bloque 11 que incluye los datos se detecta fácilmente. Por esta razón, no hay casi ninguna ventaja en cambiar los datos de manera no autorizada, y el cambio de los datos se suprime. Sin embargo, en un caso donde se requiere un cambio válido en los datos, no se requiere detectar un bloque que incluya los datos cambiados, y este mecanismo del ejemplo comparativo no es adaptable.

Como se ilustra en la figura 5, la cadena de bloques 20 de acuerdo con la presente realización incluye un (n-1)-ésimo bloque 21, un n-ésimo bloque 22 y un (n+1)-ésimo bloque 23. El (n-1)-ésimo bloque 21 incluye un hash h(n-2) de todos ^{los elementos incluidos en un (n-}2^{)-ésimo bloque (no ilustrado) dispuesto inmediatamente antes, un hash h(n-}2^{)' de}algunos de los elementos incluidos en el (n-2)-ésimo bloque, un área de prohibición de cambios AR0, y un área de permiso de cambios AR1. Asimismo, el n-ésimo bloque 22 incluye un hash h(n-1) de todos los elementos incluidos en el ^(n-1^{)-ésimo bloque}21 ^{dispuesto inmediatamente antes, un hash h(n-}1^{)' de algunos de los elementos incluidos en el (n-}1)-ésimo bloque 21, un área de prohibición de cambios AR2, y un área de permiso de cambios AR3. El (n+1)-ésimo bloque 23 incluye un hash h(n) de todos los elementos incluidos en el n-ésimo bloque 22 dispuesto inmediatamente ^{antes, un hash h(n)' de algunos de los elementos incluidos en el n-ésimo bloque}22^{, un área de prohibición de cambios}AR4, y un área de permiso de cambios AR5.

Aquí, en un caso del n-ésimo bloque 22, por ejemplo, todos los elementos son el hash h(n-1), el hash h(n-1)', los datos almacenados en el área de prohibición de cambios AR2, y los datos almacenados en el área de permiso de cambios AR3. Algunos de los elementos son elementos que se obtienen al excluir los datos almacenados en el área de permiso de cambio AR3 de todos los elementos. El (n-1)-ésimo bloque 21 y el (n+1)-ésimo bloque 23 son iguales al n-ésimo bloque 22. Además, las áreas de prohibición de cambios AR0, AR2 y AR4 descritas anteriormente son áreas que almacenan datos, cuyo cambio está prohibido. Las áreas de permiso de cambios AR1, AR3 y AR5 son áreas que almacenan datos, cuyo cambio está permitido. Por ejemplo, los datos no confidenciales no relacionados con privacidad se almacenan en las áreas de prohibición de cambios AR0, AR2 y AR4, y los datos confidenciales relacionados con privacidad se almacenan en las áreas de permiso de cambios AR1, AR3 y AR5. Como ejemplo, el n-ésimo bloque 22 se describirá con referencia a la figura 14. Los datos no confidenciales se almacenan en un campo de prohibición de cambio que sirve como área de prohibición de cambios AR2, y los datos confidenciales se almacenan en un campo de permiso de cambios que sirve como área de permiso de cambios AR3. Por otro lado, los dos hashes descritos anteriormente, es decir, los hashes h(n-1) y h(n-1)', se almacenan en un campo hash. El (n-1)-ésimo bloque 21 y el (n+1)-ésimo bloque 23 son iguales al n-ésimo bloque 22. Tenga en cuenta que las áreas de permiso de cambios AR1, AR3 y a R5 se proporcionan respectivamente por adelantado en los bloques 21, 22 y 23.

El hash h(n-1) se genera basándose en un hash h(n-2) incluido en el (n-1)-ésimo bloque 21, un hash h(n-2)' incluido en el bloque 21, datos almacenados en el área de prohibición de cambios AR0, datos almacenados en el área de permiso de cambios AR1, y una función H(). Es decir, el hash h(n-1) se genera a partir de todos los elementos del (n-1)-ésimo bloque 21 y la función H(). Por otro lado, el hash h(n-1)' se genera a partir del hash h(n-2) incluido en el (n-1)-ésimo bloque 21, el hash h(n-2)' incluido en el bloque 21, los datos almacenados en el área de prohibición de cambios AR0, y la función H(). Es decir, el hash h(n-1)' se genera a partir de algunos de los elementos obtenidos al excluir los datos almacenados en el área de permiso de cambios AR1 de todos los elementos del (n-1)-ésimo bloque 21 y la función H(). Asimismo, el hash h(n) se genera a partir del hash h(n-1) incluido en el n-ésimo bloque 22, el hash h(n-1)' incluido en el bloque 22, los datos almacenados en el área de prohibición de cambios AR2, los datos almacenados en el área de permiso de cambios AR3 y una función H(). Es decir, el hash h(n) se genera a partir de todos los elementos del n-ésimo bloque 22 y la función H(). El hash h(n)' se genera a partir del hash h(n-1) incluido en el (n-1)-ésimo bloque 22, el hash h(n-1)' incluido en el bloque 22, los datos almacenados en el área de prohibición de cambios AR2 y la función H(). Es decir, el hash h(n)' se genera a partir de algunos de los elementos obtenidos al excluir los datos almacenados en el área de permiso de cambios AR3 de todos los elementos del n-ésimo bloque 22 y la función H().

De acuerdo con el mecanismo de la presente realización, en un caso donde los datos no se cambian, es posible verificar que los datos no se cambian por el mismo método que el ejemplo comparativo. Por otro lado, en el caso donde los datos ^{se cambian mediante un cambio válido, se genera un hash (por ejemplo, h(n-}1^{)' o h(n)') al utilizar algunos de los}elementos obtenidos al excluir los datos cambiados de todos los elementos de un bloque que incluye los datos cambiados. Por lo tanto, si el hash generado mediante el uso de algunos de los elementos coincide con el hash correspondiente incluido en el bloque dispuesto inmediatamente después del bloque que incluye los datos cambiados, es posible verificar que los datos distintos de los datos cambiados no han sido cambiados. Es decir, aunque se cambie una parte de los datos, es posible asegurar la validez del bloque, y se mantiene la cadena de bloques válida.

En lo sucesivo, se describirán los detalles de un proceso que utiliza la cadena de bloques 20 de acuerdo con la presente ^{realización con referencia a las figuras}6 ^a12^.

^{En primer lugar, se describirá una operación del usuario 100 con referencia a la figura}6^{. Puesto que la operación del usuario 150 es básicamente la misma que la operación del usuario 100, se omitirá su descripción. La figura}6 ^{es un}diagrama de flujo que ilustra un ejemplo de la operación del usuario 100. En primer lugar, la unidad de aceptación de solicitudes WT1 espera una solicitud (NO en la etapa S101). Más específicamente, la unidad de aceptación de solicitudes WT1 espera hasta que haya una solicitud de registro de datos o una solicitud de cambio de datos. Si hay una solicitud (SÍ en la etapa S101), la unidad de aceptación de solicitudes WT1 acepta la solicitud (etapa S102), y la unidad de transmisión de solicitudes WT2 transmite la solicitud aceptada por la unidad de aceptación de solicitudes WT1 a la red de comunicación NW (etapa S103). Después de que la unidad de transmisión de solicitudes WT2 transmita la solicitud, el proceso finaliza.

A continuación, se describirá una operación relacionada con la generación de un bloque realizada por el extractor 200 con referencia a la figura 7. Puesto que una operación del extractor 250 es básicamente la misma que la operación del extractor 200, se omitirá su descripción. La figura 7 es un diagrama de flujo que ilustra un ejemplo de una operación relacionada con la generación de un bloque realizada por el extractor 200. En primer lugar, la unidad de generación de bloques MT1 espera hasta que se reciba una solicitud (NO en la etapa S201). Al recibir una solicitud (SÍ en la etapa S201), la unidad de generación de bloques MT1 ejecuta un proceso de bloques (etapa S202). En este caso, el proceso de bloques es un proceso realizado en un bloque de acuerdo con un tipo de solicitud. Aunque los detalles se describirán más adelante, en un caso donde la unidad de generación de bloques MT1 recibe una solicitud de registro de datos, la unidad de generación de bloques MT1 genera un nuevo bloque y agrega datos al bloque. En un caso donde la unidad de generación de bloques MT1 recibe una solicitud de cambio de datos, la unidad de generación de bloques MT1 cambia los datos almacenados en un área de permiso de cambios de un bloque objetivo de cambio a los datos de la solicitud de cambio de datos.

Además, en paralelo con el procesamiento de la etapa S202, la unidad de generación de bloques MT1 supervisa si hay una notificación predeterminada de otro extractor 250 diferente del extractor 200 (etapa s 203). Aquí, la notificación predeterminada significa una notificación que indica que el otro extractor 250 ha generado un bloque o ha cambiado un bloque. En la presente realización, puesto que se utiliza la red P2P, la solicitud de registro de datos o la solicitud de cambio de datos transmitida por la unidad de transmisión de solicitudes WT2 alcanza no sólo al extractor 200 sino también al extractor 250. Por lo tanto, si el extractor 250 genera un bloque o cambia un bloque basándose en la solicitud de registro de datos o la solicitud de cambio de datos, el extractor 250 transmite la notificación predeterminada. De este ^{modo, la notificación predeterminada llega al extractor}200^.

Aquí, en el caso donde no hay una notificación predeterminada (NO en la etapa S203), la unidad de generación de bloques MT1 transmite el bloque generado o cambiado (etapa S204). Más específicamente, la unidad de generación de bloques MT1 difunde el bloque generado o cambiado. Por consiguiente, el bloque generado o cambiado por la unidad de generación de bloques MT1 llega a los usuarios 100 y 150 y al extractor 250.

Por otro lado, en el caso donde hay una notificación predeterminada (SÍ en la etapa S203), la unidad de generación de bloques MT1 recibe el bloque generado o cambiado por el extractor 250 (etapa S205). Una vez finalizado el procesamiento de la etapa S204 o la etapa S205, la unidad de generación de bloques MT1 finaliza el proceso.

^{A continuación, se describirá el proceso de bloques descrito anteriormente con referencia a las figuras}8 ^{a 10.}

^{La figura}8 ^{es un diagrama de flujo que ilustra un ejemplo del proceso de bloques. La figura 9 es un diagrama para}explicar un ejemplo de generación de un nuevo bloque. La figura 10 es un diagrama para explicar un ejemplo para cambiar datos incluidos en un bloque.

En primer lugar, al recibir una solicitud en el procesamiento de la etapa S201 descrito anteriormente, la unidad de generación de bloques MT1 determina si la solicitud es o no una solicitud de cambio de datos (etapa S301), como se ^{ilustra en la figura}8^{. En el caso donde la solicitud no es la solicitud de cambio de datos (NO en la etapa S301), la unidad}de generación de bloques MT1 genera un hash h(n)' (etapa S302). En otras palabras, en el caso donde la solicitud es una solicitud de registro de datos, la unidad de generación de bloques MT1 genera el hash h(n)'.

Específicamente, como se ilustra en la figura 9, primero, la unidad de generación de bloques MT1 especifica un n-ésimo bloque 32 dispuesto al final de una cadena de bloques. A continuación, la unidad de generación de bloques MT 1 extrae un hash h(n-1)', un hash h(n-1), y datos de "2016/3/6" que representan una fecha de envío y datos de "500" que representan un importe de envío almacenado en el área de prohibición de cambios AR2, del bloque 32 especificado. Además, la unidad de generación de bloques MT1 combina el hash h(n-1)', el hash h(n-1), y las dos piezas de datos de "2016/3/6" y "500" utilizando una función combine() que combina cadenas de caracteres, para generar una cadena de caracteres combinada. A continuación, la unidad de generación de bloques MT1 genera un hash h(n)' a partir de la cadena de caracteres combinada utilizando una función sha512 que es una de las funciones hash.

^{Con referencia nuevamente a la figura}8^{, una vez completado el procesamiento de la etapa S302, la unidad de}generación de bloques MT1 genera un hash h(n) a continuación (etapa S303). Específicamente como se ilustra en la figura 9, la unidad de generación de bloques MT1 extrae del bloque 32 el hash h(n-1)', el hash h(n-1), los datos de "2016/3/6" que representan la fecha de envío y los datos de "500" que representan el importe de envío almacenados en el área de prohibición de cambios AR2, y los datos de "A" que representan una cuenta de origen de envío y los datos de "C" que representan una cuenta de destino de envío almacenados en el área de permiso de cambios AR3. Además, la unidad de generación de bloques MT1 combina el hash h(n-1)', el hash h(n-1) y las cuatro piezas de datos de "A", "C", "2016/3/6" y "500" al utilizar la función combine() para generar una cadena de caracteres combinada. A continuación, la unidad de generación de bloques MT1 genera un hash h(n) a partir de la cadena de caracteres combinada al utilizar la función sha512. Obsérvese que el orden de procesamiento de las etapas S302 y S303 puede invertirse.

^{Con referencia nuevamente a la figura}8^{, una vez completado el procesamiento de la etapa S303, la unidad de}generación de bloques MT1 agrega el hash h(n)' y el hash h(n) a un (n+1)-ésimo bloque a continuación (etapa S304). Específicamente, como se ilustra en la figura 9, la unidad de generación de bloques MT1 genera un (n+1)-ésimo bloque 33 que se acopla al n-ésimo bloque 32 dispuesto al final de la cadena de bloques, y agrega el hash h(n)' y el hash h (n) al (n+1)-ésimo bloque 33. Aunque el (n+1)-ésimo bloque 33 generado incluye el área de prohibición de cambios AR4 y el área de permiso de cambios AR5 por adelantado, los datos de solicitud de registro de datos aún no se almacenan en el área de prohibición de cambios AR4 y el área de permiso de cambios AR5 inmediatamente después de que se genere el (n+1)-ésimo bloque 33. Además, el (n+1)-ésimo bloque 33 puede generarse, por ejemplo, entre la etapa S301 y la etapa S302.

^{Con referencia nuevamente a la figura}8^{, una vez completado el procesamiento de la etapa S304, la unidad de}generación de bloques MT 1 divide los datos a continuación (etapa S305). Más específicamente, la unidad de generación de bloques MT1 divide los datos incluidos en la solicitud de registro de datos en datos no confidenciales y datos confidenciales. Tenga en cuenta que la solicitud de registro de datos tiene información para dividir los datos en datos no confidenciales y datos confidenciales. La unidad de generación de bloques MT1 divide los datos basándose en la información.

Una vez completado el procesamiento de la etapa S305, la unidad de generación de bloques MT1 agrega los datos no confidenciales al área de prohibición de cambios AR4 a continuación (etapa S306). Por ejemplo, en un caso donde las partes relacionadas con una fecha de envío de datos y un importe de envío entre las piezas de datos de "A", "D", "2016/3/9" y "300" incluidas en la solicitud de registro de datos corresponden a los datos no confidenciales, la unidad de generación de bloques MT1 agrega los datos de "2016/3/9" de la fecha de envío y los datos de "300" del importe de envío al área de prohibición de cambios AR4, como se ilustra en la figura 9.

Una vez completado el procesamiento de la etapa S306, la unidad de generación de bloques MT1 agrega los datos confidenciales al área de permiso de cambios AR5 a continuación (etapa S307). Por ejemplo, en un caso donde las partes relacionadas con una cuenta de origen de envío y una cuenta de destino de envío entre las piezas de datos de "A", "D", "2016/3/9" y "300" incluidas en la solicitud de registro de datos corresponden a los datos confidenciales, la unidad de generación de bloques MT1 agrega los datos de "A" de la cuenta de origen de envío y los datos de "D" de la cuenta de destino de envío al área de permiso de cambios AR5 como se ilustra en la figura 9. Una vez completado el procesamiento de la etapa S307, la unidad de generación de bloques MT1 finaliza el proceso. Obsérvese que el orden de procesamiento de las etapas S306 y S307 puede invertirse.

Por otro lado, en el caso donde la solicitud es una solicitud de cambio de datos (SÍ en la etapa S301) en el procesamiento de la etapa S301, la unidad de generación de bloques MT1 obtiene un bloque objetivo de cambio (etapa S308). Puesto que la solicitud de cambio de datos incluye datos que deben cambiarse, la unidad de generación de bloques MT1 especifica un bloque que incluye los datos y obtiene el bloque especificado como bloque objetivo de cambio, basándose en los datos que deben cambiarse.

Una vez completado el procesamiento de la etapa S308, la unidad de generación de bloques MT1 cambia los datos del área de permiso de cambios AR5 a continuación (etapa S309). Puesto que la solicitud de cambio de datos incluye información para especificar los datos que debe cambiarse, la unidad de generación de bloques MT1 especifica los datos que deben cambiarse basándose en la información, y cambia una parte que corresponde a los datos confidenciales (específicamente, la cuenta de origen de envío y la cuenta de destino de envío) por un símbolo específico (por ejemplo, "*" o similar). Por lo tanto, en el caso donde la unidad de generación de bloques MT1 obtiene el n-ésimo bloque 32, los datos de la cuenta de origen de envío y los datos de la cuenta de destino de envío del área de permiso de cambios AR5 del bloque 32 se cambian por símbolos específicos, como se ilustra en la figura 10. Por consiguiente, se oculta la parte relacionada con la intimidad y se asegura la privacidad. Una vez completado el procesamiento de la etapa S309, la unidad de generación de bloques MT1 genera un hash de todos los elementos incluidos en el bloque 32 que incluye los datos cambiados. La unidad de generación de bloques MT1 agrega el hash de algunos elementos y el hash generado de todos los elementos al bloque 33, que se agrega junto al bloque 32 que incluye los datos cambiados. A continuación, la unidad de generación de bloques MT1 finaliza el proceso.

A continuación, se describirá una operación relacionada con la verificación de bloques y actualización de bloques realizadas por el extractor 200 con referencia a la figura 11. Puesto que una operación del extractor 250 es básicamente la misma que la operación del extractor 200, se omitirá su descripción. La figura 11 es un diagrama de flujo que ilustra un ejemplo de la operación relacionada con la verificación de bloques y actualización de bloques realizadas por el ^extractor200^.

Después de que la unidad de generación de bloques MT1 finalice el proceso, la unidad de verificación de bloques MT2 determina si un bloque que debe verificarse es un bloque relacionado con un cambio de datos (etapa S401). Como se describe con referencia a las etapas S204 y S205 de la figura 7, mientras la unidad de generación de bloques MT1 genera o cambia un bloque, la unidad de generación de bloques MT1 recibe un bloque generado por el extractor 250 o recibe un bloque cambiado por el extractor 250. La unidad de verificación de bloques MT2 especifica una etapa de ^{procesamiento de una entrada de bloque de la unidad de generación de bloques m T}1^{, y determina si el bloque que ha}de verificarse es o no un bloque relacionado con un cambio de datos.

En un caso donde el bloque que ha de verificarse no es un bloque relacionado con un cambio de datos (NO en la etapa S401), la unidad de verificación de bloques MT2 ejecuta un primer proceso de verificación (etapa S402). El primer proceso de verificación es un proceso para verificar la validez del bloque generado. Específicamente el primer proceso de verificación se realiza al comprobar si un hash calculado a partir de un bloque encadenado inmediatamente antes del bloque que ha de verificarse coincide o no con un hash, registrado en el bloque que ha de verificarse, del bloque encadenado inmediatamente antes del bloque que ha de verificarse.

Una vez completado el procesamiento de la etapa S402, la unidad de verificación de bloques MT2 determina si la verificación es OK o no a continuación (etapa S403). Es decir, la unidad de verificación de bloques MT2 determina si la verificación es positiva o no. Por ejemplo, la unidad de verificación de bloques MT2 compara el hash calculado del bloque encadenado inmediatamente antes del bloque que ha de verificarse con el hash, registrado en el bloque que ha de verificarse, del bloque encadenado inmediatamente antes del bloque que ha de verificarse. En un caso donde los hashes coincidan entre sí, la unidad de verificación de bloques MT2 determina que la verificación es OK. Por el contrario, en un caso donde la unidad de verificación de bloques MT2 compara el hash calculado del bloque encadenado inmediatamente antes del bloque que ha de verificarse con el hash, registrado en el bloque que ha de verificarse, del bloque encadenado inmediatamente antes del bloque que ha de verificarse y los hashes no coinciden entre sí, la unidad de verificación de bloques MT2 determina que la verificación es NG.

En un caso donde la verificación es OK (SÍ en la etapa S403), la unidad de actualización de bloques MT3 agrega el bloque a la cadena de bloques (etapa S404), vuelve al procesamiento de la etapa S401 y espera. Por otro lado, en un caso donde la verificación es NG (NO en la etapa S403), la unidad de actualización de bloques MT3 se salta el procesamiento de la etapa S404, vuelve al procesamiento de la etapa S401 y espera. Por consiguiente, un nuevo bloque que incluye los datos incluidos en la solicitud de registro de datos se agrega al final de la cadena de bloques existente y la cadena de bloques se actualiza a una nueva cadena de bloques.

Por otro lado, en un caso donde el bloque que ha de verificarse es un bloque relacionado con un cambio de datos (SÍ en la etapa S401), la unidad de verificación de bloques MT2 ejecuta un segundo proceso de verificación (etapa S405). Específicamente, en un caso donde un bloque que ha de verificarse es un bloque cambiado por la unidad de generación de bloques MT1 o un bloque cambiado por el extractor 250, la unidad de verificación de bloques MT2 ejecuta el segundo proceso de verificación. Es decir, el segundo proceso de verificación es un proceso para verificar la validez del bloque cambiado. Tenga en cuenta que los detalles del segundo proceso de verificación se describirán más adelante.

Una vez completado el procesamiento de la etapa S405, la unidad de verificación de bloques MT2 determina si la verificación es OK o no a continuación (etapa S406). Es decir, la unidad de verificación de bloques MT2 determina si la verificación es positiva o no. En un caso donde la verificación es OK (SÍ en la etapa S406), la unidad de actualización de bloques MT3 cambia un bloque de la cadena de bloques (etapa S407), vuelve al procesamiento de la etapa S401 y espera. Por consiguiente, el bloque que incluye los datos antes de un cambio se actualiza a un bloque que incluye los datos cambiados. Por otro lado, en un caso donde la verificación es NG (NO en la etapa S406), la unidad de actualización de bloques MT3 se salta el procesamiento de la etapa S407, vuelve al procesamiento de la etapa S401 y espera.

A continuación, se describirá el segundo proceso de verificación descrito anteriormente con referencia a las figuras 12 y 13.

La figura 12 es un diagrama de flujo que ilustra un ejemplo del segundo proceso de verificación. La figura 13 es un diagrama para explicar un ejemplo de verificación de un bloque.

En primer lugar, en un caso donde un bloque que ha de verificarse es un bloque relacionado con un cambio de datos en el procesamiento de la etapa S401 descrito anteriormente, la unidad de verificación de bloques MT2 genera un hash hA(n) como se ilustra en la figura 12 (etapa S501). Específicamente, como se ilustra en el lado inferior de la figura 13, en primer lugar, la unidad de verificación de bloques MT2 especifica un n-ésimo bloque 32 para ser cambiado. A continuación, la unidad de verificación de bloques MT2 extrae un hash h(n-1)', un hash h(n-1), datos de "2016/3/6" que representan una fecha de envío y datos de "500" que representan un importe de envío almacenados en el área de prohibición de cambios AR2, y dos piezas de datos cambiados de "****" y "****" almacenados en el área de permiso de cambios AR3, del bloque 32 especificado. Además, la unidad de verificación de bloques MT2 combina el hash h(n-1)', el hash h(n-1) y las cuatro piezas de datos de "2016/3/6", "500", "****" y "****" utilizando la función combine() para generar una cadena de caracteres combinada. A continuación, la unidad de verificación de bloques MT2 genera un hash hA(n) a partir de la cadena de caracteres combinada al utilizar la función sha512.

Una vez completado el procesamiento de la etapa S501, la unidad de verificación de bloques MT2 obtiene un hash h(n) de un (n+1)-ésimo bloque (etapa S502) y compara el hash hA(n) con el hash h(n) para determinar si los hashes coinciden o no entre sí (etapa S503). En la presente realización, puesto que el hash hA(n) se genera al utilizar los datos cambiados mientras que el hash h(n) se genera al utilizar los datos anteriores al cambio, el hash hA(n) y el hash h(n) difieren entre sí. Por ejemplo, en un caso donde los datos anteriores al cambio y los datos después del cambio coinciden entre sí, es decir, en un caso donde los datos se actualizan simplemente a los mismos datos, el hash hA(n) y el hash h(n) coinciden entre sí.

En un caso donde el hash hA(n) y el hash h(n) no coincidan entre sí (NO en la etapa S503), la unidad de verificación de bloques MT2 genera un hash hA(n)' (etapa S504). Específicamente, como se ilustra en el lado superior de la figura 13, la unidad de verificación de bloques MT2 primero especifica un n-ésimo bloque 32 para ser cambiado. A continuación, la unidad de verificación de bloques MT2 extrae un hash h(n-1)', un hash h(n-1), y datos de "2016/3/6" que representan una fecha de envío y datos de "500" que representan un importe de envío almacenado en el área de prohibición de cambios AR2, del bloque 32 especificado. Además, la unidad de verificación de bloques MT2 combina el hash h(n-1)', el hash h(n-1) y las dos piezas de datos de "2016/3/6" y "500" al utilizar la función combine() para generar una cadena de caracteres combinada. La unidad de verificación de bloques MT2 genera un hash hA(n) a partir de la cadena de caracteres combinada al utilizar la función sha512.

Una vez completado el procesamiento de la etapa S504, la unidad de verificación de bloques MT2 obtiene un hash h(n) del (n+1)-ésimo bloque (etapa S505) y compara el hash hA(n) con el hash h(n) para determinar si los hashes coinciden o no entre sí (etapa S506). En la presente realización, puesto que el hash hA(n)' se genera al utilizar datos no cambiados, el hash hA(n)' y el hash h(n)' coinciden entre sí. Por ejemplo, cuando los datos almacenados en el área de prohibición ^{de cambios a R}2 ^{se cambian por manipulación o similar, el hash hA(n)' y el hash h(n)' difieren entre sí.}

En un caso donde el hash hA(n)' coincide con el hash h(n)' (SÍ en la etapa S506), la unidad de verificación de bloques MT2 determina que los datos almacenados en el área de prohibición de cambios AR2 no se han cambiado y almacena la verificación OK en el resultado de verificación (etapa s 507). También en un caso donde el hash hA(n) y el hash h(n) coinciden entre sí (SÍ en la etapa S503) en el procesamiento de la etapa S503 descrito anteriormente, la unidad de verificación de bloques MT2 ejecuta el procesamiento de la etapa S507 de manera similar. Por otro lado, en un caso donde el hash hA(n)' y el hash h(n)' no coinciden entre sí (NO en la etapa S506), la unidad de verificación de bloques MT2 determina que los datos almacenados en el área de prohibición de cambios AR2 han cambiado y almacena la verificación NG en el resultado de verificación (etapa S508). Por consiguiente, la unidad de verificación de bloques MT2 puede determinar si la verificación es OK o no en el procesamiento de la etapa posterior S406 (véase figura 11).

Como se ha descrito anteriormente, de acuerdo con la presente realización, el extractor 200 que sirve como dispositivo de gestión de cadena de bloques incluye la unidad de generación de bloques MT1, la unidad de verificación de bloques MT2 y la unidad de actualización de bloques MT3. La unidad de generación de bloques MT1 genera un hash h(n)' de los datos incluidos en una parte obtenida al excluir el área de permiso de cambios AR3 del n-ésimo bloque 32 que incluye el área de prohibición de cambios AR2 y el área de permiso de cambios AR3 y un hash h(n) de los datos incluidos en el bloque 32. Además, la unidad de generación de bloques MT1 agrega el hash h(n)' y el hash h(n) al (n+1)-ésimo bloque 33, que se agrega junto al bloque 32 y que incluye el área de prohibición de cambios AR4 y el área de permiso de cambios AR5. Por ejemplo, la unidad de generación de bloques MT1 agrega el hash h(n)' y el hash h(n) al (n+1)-ésimo bloque 33, que se encadena inmediatamente después del bloque 32 e incluye el área de prohibición de cambios AR4 y el área de permiso de cambios AR5. El extractor 200 gestiona el bloque 33 al que se agregan el hash h(n)' y el hash h(n), de modo que una parte de los datos puede cambiarse por una razón válida.

Además, la unidad de verificación de bloques MT2 determina si un hash hA(n) de datos incluidos en el bloque 32 coincide o no con un hash h(n) de datos incluidos en el bloque 33 que se agrega junto al bloque 32 y que incluye el área de prohibición de cambios AR4 y el área de permiso de cambios AR5. Por ejemplo, la unidad de verificación de bloques MT2 determina si el hash hA(n) de los datos incluidos en el bloque 32 coincide o no con el hash h(n) de los datos incluidos en el bloque 33 que se encadena inmediatamente después del bloque 32 y que incluye el área de prohibición de cambios AR4 y el área de permiso de cambios AR5. Además, en un caso donde el hash hA(n) y el hash h(n) no coinciden entre sí, la unidad de verificación de bloques MT2 genera un hash hA(n)' de datos incluidos en una parte obtenida al excluir el área de permiso de cambios AR3 del bloque 32 y obtiene un hash h(n)' de los datos incluidos en una parte obtenida al excluir el área de permiso de cambios AR5 del bloque 33. En un caso donde el hash hA(n)' y el hash h(n)' coinciden entre sí, la unidad de verificación de bloques MT2 determina que los datos almacenados en el área de prohibición de cambios AR4 del bloque 32 no se han cambiado. En un caso donde se determina que los datos almacenados en el área de prohibición de cambios AR4 del bloque 32 no se cambian, la unidad de actualización de bloques MT3 cambia el bloque 32 por un bloque en el que se cambian los datos almacenados en el área de permiso de cambios AR3 del bloque 32. Por consiguiente, es posible verificar que los datos almacenados en el área de prohibición de cambios AR2 no se cambian.

Aunque la realización preferida de la presente invención se ha descrito en detalle anteriormente, las realizaciones no se limitan a la realización específica de acuerdo con la presente invención, y pueden realizarse diversas modificaciones y cambios dentro del alcance de la esencia de la presente invención descrita en las reivindicaciones.

Específicamente, aunque la realización en la que dos piezas de datos se almacenan en un área de prohibición de cambios y se han descrito en la presente realización dos piezas de datos que se almacenan en un área de permiso de cambios, las realizaciones no se limitan particularmente a dicha realización. Por ejemplo, un bloque puede incluir una pluralidad de áreas de prohibición de cambios y una pluralidad de áreas de permiso de cambios para las piezas de datos que han de almacenarse respectivas. En este caso, se genera un hash de todos los elementos del bloque y un hash de algunos de los elementos obtenidos al excluir los datos almacenados en cada una de la pluralidad de áreas de permiso de cambios de todos los elementos del bloque, de modo que es posible obtener el mismo efecto que el efecto de la presente realización. Por ejemplo, la importancia de privacidad puede estar asociada con la pluralidad de áreas de permiso de cambios.

Lista de signos de referencia

S sistema de gestión de cadena de bloques

100, 150 nodo (usuario)

WT herramienta de cartera

WT1 unidad de aceptación de solicitudes

WT2 unidad de transmisión de solicitudes

200, 250 nodo (extractor)

MT herramienta de extracción

MT1 unidad de generación de bloques

MT2 unidad de verificación de bloques

MT3 unidad de actualización de bloques

Claims

REIVINDICACIONES

1. Un método de gestión de cadena de bloques en el que un proceso es ejecutado por un ordenador, el proceso comprende:

generar (S302) un primer hash de datos incluidos en un bloque parcial obtenido al excluir una segunda área de un primer bloque de una cadena de bloques, el primer bloque incluye una primera área en la que se prohíbe un cambio de datos y la segunda área en la que se permite el cambio de datos;

generar (S303) un segundo hash de datos incluidos en el primer bloque; y

agregar (S304) el primer hash y el segundo hash a un segundo bloque de la cadena de bloques, el segundo bloque se agrega junto al primer bloque e incluye una primera área en la que se prohíbe un cambio de datos y una segunda área en la que se permite el cambio de datos.

2. El método de gestión de cadena de bloques de acuerdo con la reivindicación 1, además comprende:

un proceso de división (S305), en un caso donde una solicitud recibida es una solicitud de registro de datos, datos de la solicitud de registro en datos cuyo cambio está prohibido y datos cuyo cambio está permitido, y almacenamiento de los datos divididos en cada una de la primera área y la segunda área del segundo bloque.

3. El método de gestión de cadena de bloques de acuerdo con la reivindicación 1 o 2, además comprende: un proceso de cambio, en el caso donde una solicitud recibida es una solicitud de cambio de datos, datos almacenados en la segunda área del primer bloque a los datos de la solicitud de cambio.

4. El método de gestión de cadena de bloques de acuerdo con la reivindicación 1, además comprende:

generar (S501) un tercer hash de datos incluidos en el primer bloque de la cadena de bloques al verificar el primer bloque; determinar (S503) si el tercer hash coincide o no con el segundo hash incluido en el segundo bloque de la cadena de bloques;

generar (S504), en un caso donde el tercer hash y el segundo hash no coinciden entre sí, un cuarto hash de datos incluidos en un primer bloque parcial obtenido al excluir la segunda área del primer bloque;

determinar (S506) si el primer hash incluido en el segundo bloque de la cadena de bloques coincide o no con el cuarto hash; y determinar que los datos almacenados en la primera área del primer bloque no se cambian en el caso donde el primer hash y el cuarto hash coinciden entre sí.

5. El método de gestión de cadena de bloques de acuerdo con la reivindicación 1, además comprende:

un proceso de cambio, en un caso donde se determina que los datos almacenados en la primera área del primer bloque no se cambian, el primer bloque a un bloque en el que se cambian los datos almacenados en la segunda área del primer bloque.

6^{. Un dispositivo de gestión de cadena de bloques que comprende:}

una unidad de procesamiento configurada para ejecutar un proceso, el proceso incluye

generar (S302) un primer hash de datos incluidos en un bloque parcial obtenido al excluir una segunda área de un primer bloque de una cadena de bloques, el primer bloque incluye una primera área en la que se prohíbe un cambio de datos y la segunda área en la que se permite el cambio de datos, generando (S303) un segundo hash de datos incluidos en el primer bloque, y

agregar (S304) el primer hash y el segundo hash a un segundo bloque de la cadena de bloques, el segundo bloque se agrega junto al primer bloque e incluye una primera área en la que se prohíbe un cambio de datos y una segunda área en la que se permite el cambio de datos.

^{7. El dispositivo de gestión de cadena de bloques de acuerdo con la reivindicación}6^,

en donde la unidad de procesamiento divide (S305), en un caso donde una solicitud recibida es una solicitud de registro de datos, datos de la solicitud de registro en datos cuyo cambio está prohibido y datos cuyo cambio está permitido, y almacena los datos divididos en cada una de la primera área y la segunda área del segundo bloque.

8^{. El dispositivo de gestión de cadena de bloques de acuerdo con la reivindicación}6^,

en donde la unidad de procesamiento cambia, en un caso donde una solicitud recibida es una solicitud de cambio de datos, datos almacenados en la segunda área del primer bloque a los datos de la solicitud de cambio.

^{9. El dispositivo de gestión de cadena de bloques de acuerdo con la reivindicación}6^{, en donde:}

el proceso incluye

generar (S501) un tercer hash de datos incluidos en el primer bloque de la cadena de bloques al verificar el primer bloque; determinar (S503) si el tercer hash coincide o no con el segundo hash incluido en el segundo bloque de la cadena de bloques,

generar (S504), en un caso donde el tercer hash y el segundo hash no coinciden entre sí, un cuarto hash de datos incluidos en un primer bloque parcial obtenido al excluir la segunda área del primer bloque,

determinar (S506) si el primer hash incluido en el segundo bloque de la cadena de bloques coincide o no con el cuarto hash; y determinar que los datos almacenados en la primera área del primer bloque no se cambian en el caso donde el primer hash y el cuarto hash coinciden entre sí.

10. El dispositivo de gestión de cadena de bloques de acuerdo con la reivindicación 9,

en donde la unidad de procesamiento cambia, en un caso donde se determina que los datos almacenados en la primera área del primer bloque no se cambian, el primer bloque a un bloque en el que se cambian los datos almacenados en la segunda área del primer bloque.

11. Un sistema de gestión de cadena de bloques que incluye una pluralidad de nodos, el sistema comprende:

un primer nodo que transmite una solicitud de registro de datos; y

un segundo nodo que genera (S302), en un caso de recepción de la solicitud de registro, un primer hash de los datos incluidos en un bloque parcial obtenido al excluir una segunda área de un primer bloque de una cadena de bloques, el primer bloque incluye una primera área en la que se prohíbe un cambio de datos y la segunda área en la que se permite el cambio de datos, genera (S303) un segundo hash de datos incluidos en el primer bloque, agrega (S304) el primer hash y el segundo hash a un segundo bloque de la cadena de bloques, el segundo bloque se agrega junto al primer bloque e incluye una primera área en la que se prohíbe un cambio de datos y una segunda área en la que se permite el cambio de datos, y divide (S305) los datos de la solicitud de registro en datos cuyo cambio está prohibido y datos cuyo cambio está permitido y almacena los datos divididos en cada una de la primera área y la segunda área del segundo bloque.

12. El sistema de gestión de cadena de bloques de acuerdo con la reivindicación 11, en donde el

segundo nodo que genera (S501) un tercer hash de datos incluidos en el primer bloque de la cadena de bloques al verificar el primer bloque, determina (S503), si el tercer hash coincide o no con el segundo hash incluido en el segundo bloque de la cadena de bloques, genera (S504), en un caso donde el tercer hash y el segundo hash no coinciden entre sí, un cuarto hash de datos incluidos en un primer bloque parcial obtenido al excluir la segunda área del primer bloque, determina (S506) si el primer hash incluido en el segundo bloque de la cadena de bloques coincide o no con el cuarto hash, determina que los datos almacenados en la primera área del primer bloque no se cambian en un caso donde el primer hash y el cuarto hash coinciden entre sí, y cambia los datos almacenados en la segunda área del primer bloque por los datos de la solicitud de cambio.