KR102267560B1 - Method for Managing Modified Record of Data Which Can Reduce Size of Data Stored in Block Chain - Google Patents

Abstract

The present invention relates to a data management method executed in an environment including a user terminal, a data management module, a smart contract module, and a block chain. The method comprises: a first step of a data management module receiving data from the user terminal; a second step of designating the previous data address as a null value and transmitting the data to the smart contract module together with the data if the data received by the data management module is new data; a third step of the smart contract module storing the data as a transaction in the block chain; and a fourth step in which the smart contract module transmits the transaction address of the data to the data management module and the data management module stores the transaction address.

Description

{Method for Managing Modified Record of Data Which Can Reduce Size of Data Stored in Block Chain}

The present invention relates to a method of storing a data change history in a block chain, and more particularly, to a data change history management method capable of reducing the size of data stored in a block chain.

The blockchain functions as a distributed ledger that records transactions, all network participants can validate transactions, and can fundamentally block unauthorized persons from altering or forging stored data.

However, according to the conventional block chain, all nodes participating in the transaction hold all transaction data. If the transaction data is partially changed, the entire data from before and after the change is stored in the block chain, so the amount of stored data increases. there is a problem with For example, since the original data is stored in block 1, the data after the first change in which the first change is reflected in block 2, and the data after the second change in which the secondary change is reflected in block 3, especially As the number of changes increases, the amount of data stored in the blockchain increases significantly.

Korean Patent No. 10-2165272 (published on October 13, 2020)

An object of the present invention is to provide a data change history management method that can reduce the amount of data stored in the block chain when a change history occurs in data stored in the block chain.

The present invention relates to a data management method executed in an environment including a user terminal, a data management module, a smart contract module, and a block chain, the data management module comprising: a first step of receiving data from the user terminal; a second step of designating the previous data address as a null value and transmitting the data to the smart contract module together with the data if the data received by the data management module is new data; a third step of the smart contract module storing the data as a transaction in the block chain; and a fourth step in which the smart contract module transmits the transaction address of the data to the data management module and the data management module stores the transaction address.

According to the present invention, there is provided a method for managing a data change history, comprising: a fifth step of receiving, by a data management module, modified data in which the revision details are reflected from a user terminal; a sixth step of sending, by the data management module, the correction data to the smart contract module; a seventh step in which the smart contract module obtains transaction data of the corresponding address with reference to the address immediately preceding the modification data; an eighth step in which the smart contract module compares the transaction data obtained in the seventh step with the modified data to extract the change details; a ninth step in which the smart contract module generates post-change data by reflecting the change details extracted in the eighth step to previous data; The smart contract module includes a tenth step of storing the change details in the block chain when the hash value of the data after the change generated in the ninth step matches the hash value of the data received in the sixth step.

The tenth step may be a step of further storing the transaction address of the previous data.

The tenth step may be a step of further storing a hash value of the previous data.

The tenth step may be a step of further storing a hash value of the currently stored data.

The seventh step may be a step of recursively repeating until there is no previous address.

The data change history management method according to the present invention may further include a step 7-1 of acquiring transaction data without an immediately preceding address as original data.

The data change history management method according to the present invention may further include a step 7-2 of assembling by reflecting previous data to the original data.

Step 8 may be a step of extracting change details by comparing the transaction data assembled in step 7-2 with the correction data received in step 6 by the smart contract module.

The present invention can be implemented by a computer program recorded on a computer-readable recording medium.

According to the present invention, there is an effect of providing a data change history management method that can significantly reduce the amount of data stored in the block chain by storing only the changed part of the original document in the block chain.

1 shows an example of an environment in which the present invention is practiced;
2 is a flowchart of a data change history management method according to the present invention.
3 is a structure of data stored in a block chain according to the present invention.
4 is an example of a data structure for explaining the data change history management method of the present invention.

Hereinafter, the present invention will be described in detail with reference to the accompanying drawings.

Encryption/decryption may be applied as needed to the information (data) transmission/reception process performed in this specification, and the expressions describing the information (data) transmission process in the present specification and claims are all encrypted/decrypted even if not separately mentioned. It should be interpreted as including the case of decryption. In this specification, expressions such as "transmission (transmission) from A to B" or "A receives from B" include transmission (transmission) or reception by including another medium in the middle, and directly from A to B It does not represent only what is transmitted (delivered) or received. In the description of the present invention, the order of each step should be understood as non-limiting unless the preceding step must be logically and temporally performed before the subsequent step. That is, except for the above exceptional cases, even if the process described as a subsequent step is performed before the process described as the preceding step, the essence of the invention is not affected, and the scope of rights should be defined regardless of the order of the steps. And in the present specification, "A or B" is defined as meaning not only to selectively indicate any one of A and B, but also to include both A and B. In addition, in the present specification, the term "comprising" has a meaning to encompass the inclusion of other components in addition to the elements listed as including.

As used herein, the term “module” or “unit” refers to a logical combination of general-purpose hardware and software performing its function.

In this specification, only the minimum components necessary for the description of the present invention are described, and components not related to the essence of the present invention are not mentioned. And it should not be construed as an exclusive meaning including only the mentioned components, and it should be construed as a non-exclusive meaning that may also include other components not mentioned.

The method according to the present invention may be executed by an electronic computing device such as a computer, a tablet PC, a mobile phone, a portable computing device, or a stationary computing device. It should also be understood that one or more methods or aspects of the present invention may be executed by at least one processor. The processor may be installed in a computer, a tablet PC, a mobile device, a portable computing device, or the like. A memory adapted to store computer program instructions may be installed in such a device such that the program is specifically programmed to cause the processor to execute the stored program instructions to execute one or more processes as described herein. In addition, it should be understood that the information and methods described herein may be implemented by a computer, tablet PC, mobile device, portable computing device, etc. including one or more additional components and a processor. In addition, the control logic may be implemented in a non-volatile computer-readable medium including program instructions executable by a processor, a controller/control unit, or the like. Examples of computer-readable media include, but are not limited to, ROM, RAM, CD-ROM, magnetic tape, floppy disk, flash drive, smart card, optical data storage device, and the like. In addition, the computer-readable recording medium may be distributed in computers connected to a network, and the computer-readable medium may be stored and executed in a distributed manner, for example, by a remote server or a controller area network (CAN).

In the present specification, the meaning of obtaining a predetermined value by performing an operation such as encryption or hashing on a specific value means not only the specific value but also the transformation value of the specific value (eg, additionally calculating a predetermined value on the specific value, or It is defined as including an operation such as encryption or hashing for another value calculated through a process such as changing a specific value according to a predetermined rule.

1 shows an example of an environment in which the present invention is practiced. The environment in which the present invention is executed includes a user terminal 10, a data management module 20, a smart contract module 30, a block chain 40, and a communication network 50 as shown in FIG. do

The user terminal 10 may be, for example, an electronic computing device such as a computer, a tablet PC, a mobile phone, a portable computing device, or a stationary computing device. The data management module 20 is a module for transmitting data received from the user terminal 10 to the smart contract module 30, and may be provided to the user terminal 10 in the form of an application program that works together with hardware. , or as a separate system running in a cloud environment.

The smart contract module 30 performs some steps of the present invention between the data management module 20 and the block chain 40 as a module in which the algorithm of the data change history management method according to the present invention is set.

2 is a flowchart of a data change history management method of the present invention. First, a general description will be given with reference to FIG. 2 , and then a detailed description will be given with reference to FIG. 4 .

Data input by the user through the user terminal 10 is received by the smart contract module 30 through the data management module 20 (step 200).

In the case of new data, an example of the format of the received data is as follows. In the following data types, "***" refers to the original data, and "***$$$" refers to the data after the change in which the change history "$$$" is reflected in the original data "***".

{

previous_data_address: null

current_data: ***

}

Data previously stored on the blockchain can have the following format:

{

previous_data_address: aaa

current_data: ***$$$

}

In this specification, text consisting of three lowercase letters means a transaction address where data is stored in the block chain.

It is determined whether the data received in step 205 is new data, that is, original data to be stored for the first time. This determination is based on whether the received data has a previous data address (previous_data_address).

If it is determined as new data, the smart contract module 30 stores the new data as a transaction in the block chain (210), and transmits the stored transaction address to the data management module (20). The data management module 20 stores the received transaction address.

An example of the structure of data stored in a transaction is shown, and more specifically, it may be as follows.

{

previous_data_address: null

previous_data_hash: null

current_data_hash: HASH(***)

current_edit_data: ***

}

If the received data is not new data, the previous transaction data is obtained by referring to the previous data address (step 220).

With reference to FIG. 3 and the data structure of the acquired transaction data, it is determined whether there is a previous data address (step 225). If there is a previous data address in the acquired transaction data, since there is a more changed history before that, the process returns to step 220 to obtain the previous data by referring to the previous data address. This process is repeated until there is no previous address in the acquired previous transaction data, that is, until the original data is acquired.

If it is determined that there is no previous data address in the acquired previous transaction data, the acquired transaction data is acquired as original data (step 230). By assembling data by reflecting at least one previous data (changed part) acquired in step 220 in the original data thus obtained, final data up to just before the data received in step 200 is generated (step 235) .

In step 240 , the change details are extracted by comparing with the data received in step 200 , and data reflecting the change details in the data assembled in step 235 is generated (step 245 ).

A hash value of the data generated in step 245 is generated (step 250), and the hash value is compared with the hash value of the data received in step 200 (step 255). If the two hash values are the same, the change details extracted in step 240 are stored in the transaction (step 260). The format of the stored data may be as follows.

{

previous_data_address: aaa

previous_data_hash: HASH(***}

current_data_hash: HASH($$$)

current_edit_data: $$$

}

A specific example will be described with reference to FIG. 4 .

The data shown in FIG. 4 is changed data by sequentially applying the original data 410 , the primary change history 420 , the secondary change history 430 , and the third change history 430 .

The original data (410; ***) is transmitted to the smart contract module 30 in the following format.

{

previous_data_address: null

current_data: ***

}

Since the data of this structure does not have a previous transaction address (previous_data_address), the process proceeds to step 210 and the original data is stored in the transaction address (aaa). The data format to be saved may be as follows.

{

previous_data_address: null

previous_data_hash: null

current_data_hash: HASH(***)

current_edit_data: ***

}

The stored transaction address (aaa) is transmitted to the data management module 20 (step 215).

When the first change detail 420 ($$$) occurs, data in which the first change detail 420 is reflected in the original data 410 is received in step 200 . The format of the received data may be as follows.

{

previous_data_address: aaa

current_data: ***$$$

}

Since the previous transaction address exists as “aaa” in this data, the flow advances to step 220 to obtain the previous transaction data 410; *** with reference to the address.

At this time, since the previous transaction address does not exist in the acquired previous transaction data 410, the process proceeds to step 230 to acquire the acquired previous transaction data 410; *** as the original data.

And in step 240, by comparing the original data (410; ***) with the data received in step 200 to extract the change details, and to reflect the change details in the original data (410; ***) After the change, data is generated (step 245). It is determined whether the hash value of the data after the change so generated is the same as the hash value received in step 200 (step 255), and if it is the same, the change history extracted in step 240 is used as the current data (transaction address) : bbb) (step 260). The format of the stored data may be as follows.

{

previous_data_address: aaa

previous_data_hash: HASH(***)

current_data_hash: HASH($$$)

current_edit_data: $$$

}

The transaction address (bbb) is transmitted to and stored in the data management module 20 .

Thereafter, when the secondary change details 430 occur, data in which the primary change details 420 and the secondary change details 430 are reflected in the original data 410 are received in step 200 . The format of the received data may be as follows.

{

previous_data_address: bbb

current_data: ***$$$&&&

}

Since the previous transaction address exists as “bbb” in this data, the flow advances to step 220 to obtain the previous transaction data by referring to the address. The format of the previous transaction data obtained here may be as follows.

{

previous_data_address: aaa

previous_data_hash: HASH(***)

current_data_hash: HASH($$$)

current_edit_data: $$$

}

At this time, since the previous transaction address (aaa) exists in the acquired previous transaction data, the process returns to step 220 to obtain the previous transaction data by referring to the corresponding address. The format of the previous transaction data obtained here may be as follows.

{

previous_data_address: null

previous_data_hash: null

current_data_hash: HASH(***)

current_edit_data: ***

}

Since there is no previous transaction address in the previous transaction data obtained here, the process proceeds to step 230, and current_edit-data(410; ***) included in the previous transaction data obtained here is acquired as the original data.

And in step 240, the original data (410; ***) and the data ($$$ and &&&) received in step 200 are compared to extract the change details, and the original data 410; *** ) to reflect the change details to generate data after the change (step 245). It is determined whether the hash value of the data after the change so generated is the same as the hash value received in step 200 (step 255), and if it is the same, the change history extracted in step 240 is used as the current data (transaction address) : ccc) (step 260). The format of the stored data may be as follows.

{

previous_data_address: bbb

previous_data_hash: HASH($$$)

current_data_hash: HASH(&&&)

current_edit_data: &&&

}

Even if there is an additional data change thereafter, the data change history is stored in the block chain in the same way.

According to the present invention, even if a change history occurs in the data stored in the block chain, it is not necessary to store the entire changed data version in the block chain every time, only the changed details need to be stored. The size of the data stored in managing the data change history in the block chain There is provided an effect that can significantly reduce the

The present invention has been described above with reference to the accompanying drawings, but the scope of the present invention is determined by the following claims and should not be construed as being limited to the above-described embodiments and/or drawings. And it should be clearly understood that improvements, changes and modifications obvious to those skilled in the art of the invention described in the claims are also included in the scope of the present invention.

10: user terminal 20: data management module
30: smart contract module 40: block chain

Claims (13)

A method for managing change history of data executed in an environment including a user terminal, a data management module, a smart contract module, and a block chain,
A first step of the data management module receiving data from the user terminal;
If the data received by the data management module is new data, a second step of designating the old data address as a null value and transmitting the data to the smart contract module together with the data;
A third step of the smart contract module storing the data as a transaction in the block chain;
a fourth step in which the smart contract module transmits the transaction address of the data to the data management module and the data management module stores the transaction address;
A fifth step of receiving, by the data management module, the correction data in which the correction details are reflected from the user terminal;
A sixth step of the data management module transmitting the correction data to the smart contract module;
A seventh step in which the smart contract module obtains the transaction data of the address by referring to the address immediately preceding the modification data;
An eighth step in which the smart contract module compares the transaction data and the modified data obtained in the seventh step to extract the change details;
A ninth step in which the smart contract module generates post-change data by reflecting the change details extracted in the eighth step to previous data;
A smart contract module, including a tenth step of storing the change details in a block chain when the hash value of the data after the change generated in the ninth step and the hash value of the data received in the sixth step match,
How to manage data change history.
delete The method according to claim 1,
Step 10 is a step of further storing the transaction address of the previous data,
How to manage data change history.
4. The method according to claim 3,
Step 10 is a step of further storing the hash value of the previous data,
How to manage data change history.
5. The method according to claim 3 or 4,
The tenth step is a step of further storing the hash value of the currently stored data,
How to manage data change history.
4. The method according to claim 3,
Step 7 is a step that recursively repeats until there is no previous address,
How to manage data change history.
5. The method according to claim 4,
Further comprising the step 7-1 of obtaining the transaction data without the immediately preceding address as the original data,
How to manage data change history.
8. The method of claim 7,
Further comprising a step 7-2 of assembling by reflecting the previous data to the original data,
How to manage data change history.
9. The method of claim 8,
Step 8 is a step of extracting change details by comparing the transaction data assembled in step 7-2 with the correction data received in step 6 by the smart contract module,
How to manage data change history.
A computer-readable recording medium recording a program for executing each step of the method of any one of claims 1, 3, 4, and 6 to 9.
A computer-readable recording medium in which a program for executing each step of the method of claim 5 is recorded.
A computer program stored in a computer-readable recording medium for executing each step of the method of any one of claims 1, 3, 4, and 6 to 9.
A computer program stored in a computer-readable recording medium for executing each step of the method of claim 5 .

Images