RU2790181C1 - Verifiable registry truncation system - Google Patents

Abstract

FIELD: data processing.

SUBSTANCE: invention relates to data processing field. According to the linked list scheme, the R_n-1 root hash value of the previous subtree is included in the T_n data block. The T_n data block, in which the R_n-1 root hash value is included, is hashed, which results in yielding h(T_n). The resulting h(T_n) and the R_n-1 root hash value of the previous subtree are combined and then hashed yielding h(h(T_n)|R_n-1). The yielding h(h(T_n)|R_n-1) is sequentially added to the corresponding nodes of the Merkle binary tree structure, which allows configuring the skewed Merkle tree creation module to unfold/create a skewed Merkle tree.

EFFECT: invention provides a verifiable registry truncation system, in which the registry structure is configured as a skewed Merkle tree.

5 cl, 10 dwg

Description

The field of technology to which the invention belongs

The present invention relates to a registry pruning system, and in particular to a verifiable registry pruning system.

State of the art

With respect to a distributed ledger, such as an existing block chain (blockchain) or a directed acyclic graph (DAG), the size of the ledger increases over time, and as a result, storage overflow becomes a significant problem.

With the development of technology to increase the data transfer rate, the phenomenon of shortage of storage capacity becomes a greater problem.

Currently, Ethereum has a processing speed of 20 transactions (Tx)/sec and Bitcoin has a processing speed of 7 Tx/sec. In the case of Ethereum, 250 GB of data is accumulated annually.

In the future, Ethereum may have a higher transaction processing speed. For example, in a ledger mechanism for account-level transaction chains (AWTC) using a directed acyclic graph (DAG), which has an even higher transaction processing speed than a block chain, it is also possible to set a target of 4 kTx/sec in the future.

With a transaction processing rate of 4 kTx/sec, the size of the distributed ledger produced daily as 0.5 kB/Tx * 4 kTx/sec * 60 sec/min * 60 min/hour * 24 hours/day becomes 172.8 GB /day.

When 172.8 GB of data is accumulated every day across all nodes, the problem is that very large storage capacity must be provided over time.

In a ledger structure with high transaction processing speed, the problem of storage efficiency with the cumulative increase in ledger size cannot but become a bigger problem.

Ethereum, which has a low processing speed, performs a pruning that removes data up to a few past years, and each node only has data after a few past years. With respect to pruned data, a mechanism is used in which old data, which is separately managed by a fund, is distributed each time a request is received.

Therefore, there may be a limit to efficiently managing registries with only an existing pruning.

The essence of the invention

Technical task

The purpose of the present invention is to provide a verifiable registry pruning system.

Technical solution

According to the first embodiment, the verifiable registry pruning system may be configured to include a skew Merkle tree generation module in which, according to the linked list scheme, the root hash value R _n-1 of the previous subtree is included in a block T _n of data, block T _n data, which includes the root hash value R _n-1 , is hashed, thereby obtaining h(T _n ), the resulting h(T _n ) and the root hash value R _n-1 of the previous subtree are combined and then hashed, due to thereby obtaining h(h(T _n )|R _n-1 ), and the resulting h(h(T _n )|R _n-1 ) is sequentially added to the corresponding nodes of the binary Merkle tree structure to unfold and create a skewed Merkle tree.

Here, the verifiable registry pruning system may be configured further including a node integrity verification module in which the last root hash value of the skewed Merkle tree is computed by successively performing a hash value operation by using T _k and a predetermined root hash value h( T _i ) (here, k<i<=n) of the skewed Merkle tree to verify whether or not the previous predefined data block T _k is included in the skewed Merkle tree, and compare whether or not the computed last root hash value and a previously known last root hash value in order to check the integrity of the block T _k .

According to the second embodiment, the verifiable registry pruning system can be implemented including a module for creating hierarchical (h-)skewed Merkle trees, in which, according to the linked list scheme, the root hash value R _n-1 of the previous subtree is included in the block T _n of data, the block T _n of data, which includes the root hash value R _n-1 , is hashed, thereby obtaining h(T _n ), the resulting h(T _n ) and the root hash value R _n-1 of the previous subtree and reference R _{n -(base^offset)} transitions are combined and then hashed, thereby obtaining h(h(T _n )|R _n-1 |R _{n-(base^offset)} , and the resulting h(h(T _n )|R _{n -1} |R _{n-(base^offset)} ) is sequentially added to the corresponding nodes of the binary Merkle tree to unroll and create an h-skewed Merkle tree.

Here, the hop reference R _{n-(base^offset)} may be the root hash value for the node at the predetermined previous time on the h-skewed Merkle tree, the base base may be the shortest distance of the predefined hop reference to highlight the hop reference with by a predetermined interval, and offset may be the location n of the current node % base.

In addition, the jump link distance can be adapted to be obtained by means of a base ^offset value.

Meanwhile, the h-skew Merkle tree generation module may be configured to extract the transition reference of each node offset+(base ^offset )*k.

In this case, k may be configured by a positive integer.

On the other hand, the verifiable registry pruning system can be configured to further include a node integrity verification module in which the last root hash value of the h-skew Merkle tree is computed by sequentially performing an operation on the hash values by using T _k and a predetermined root hash -values h(T _i ) (here, k<i<=n) of the h-skew Merkle tree to verify whether or not the previous predefined data block T _k is included in the h-skew Merkle tree, and compare whether or not no computed last root hash value and a priori known last root hash value in order to check the integrity of the block T _k .

Here, the node integrity verification module may be configured to verify whether or not the hash value R _y or the data block T _y exists in the h-skewed Merkle tree according to the following procedure, and 1) searching for a transition link or link (node), which exists in the near previous time, from the number of links (nodes) that are at the same time or further in the future than R _y , based on the link (node) within a predetermined distance in the direction of the previous time from the last root hash value of R _head , 2) search for a transition link or a link (node) that exists in the nearest previous time, from among links (nodes) that are at the same time or further in the future than R _y , based on the link (node) within the previously a certain distance in the direction of the previous time from the hash value of the transition link or the link that exists at the desired nearest previous time, 3) repeating the process 2) until R _y is reached , 4) calculating the root hashes directed in the future direction sequentially for a set of jump or link (node) links sought multiple times in processes 2) and 3) by using T _y , and 5) comparing whether the resulting resulting root hash is equal or not the value R _head , and verifying that the hash value R _y or the data block T _y exists in the h-skewed Merkle tree when the resulting final root hash value equals R _head as the result of the comparison.

Here, a predetermined distance may constitute a base.

Benefits of the Invention

According to the verifiable registry pruning system, the registry structure is configured by a skewed Merkle tree to store and manage only the latest data, and the integrity of a transaction sent by another node can be proven, and as a result, it has the advantage that the increase in the size of the registry can be minimized and be supported.

In particular, it is advantageous that the skewed Merkle tree is capable of being transformed into an upgraded h-skewed Merkle tree to drive the registry to significantly reduce the size of evidence data that grows over time. As the size of the evidence data is reduced, checking the integrity of old data from several past years is provided through fewer work steps to further increase the speed of verification.

In addition, in the h-skewed Merkle tree, the hash values computed by two or more work routes can be compared with each other to verify whether the hash values are equal or not to each other, to verify whether or not the newly added reference is forged. transition.

Brief description of the drawings

Fig. 1 is a block diagram of a verifiable registry pruning system according to an embodiment of the present invention.

Fig. 2 is a block diagram of an existing Merkle tree.

Fig. 3 and 4 are conceptual diagrams of an algorithm for generating skewed Merkle trees according to an embodiment of the present invention.

Fig. 5 and 10 are conceptual diagrams of an algorithm for generating h-skew Merkle trees according to an embodiment of the present invention.

Optimal Mode for Carrying Out the Invention

The present invention may have various modifications and various embodiments, and specific embodiments are illustrated in the drawings and described in detail in the specific content for carrying out the present invention. However, this does not limit the present invention to specific embodiments, and it is to be understood that the present disclosure covers all modifications, equivalents, and substitutions included within the spirit and scope of the present invention. In the description of each drawing, like reference numerals denote like elements.

Terms including "first", "second", "A", "B", and the like are used to describe various constituent elements, but the constituent elements are not limited by terms. The terms are only used to distinguish one component from another component. For example, the first component may be referred to as the "second component", and similarly, the second component may be referred to as the "first component" without departing from the scope of the present invention. The term "and/or" includes a combination of a plurality of associated disclosed claims, or any one of a plurality of associated disclosed claims.

It should be understood that when a component is described as "connecting" or "accessing" another component, the component may directly connect to or access the other component, or a third component may be present in between. On the contrary, when it is described that a component "directly connects" or "directly accesses" another component, it should be understood that no elements are present between said element and said other element.

The terms used in this application are used only to describe specific embodiments, and are not intended to limit the present disclosure. The singular form includes the plural form if there is no clear opposite semantic meaning in the context. In this application, it should be understood that the term "comprise" or "have" indicates that the feature, number, step, operation, component, part, or combination of the foregoing described in the description of the invention is present, but does not exclude the possibility of the presence or adding one or more other features, numbers, steps, operations, components, parts or combinations of the foregoing, in advance.

Unless otherwise indicated, all terms used in this document, including technical or scientific terms, have the same meanings as those commonly understood by those skilled in the art. Terms that are defined in a common vocabulary should be interpreted as having a meaning identical to the meaning in the context of the prior art, and are not interpreted as an ideal meaning or overly formal meanings, unless otherwise expressly stated in this application.

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

Fig. 1 is a block diagram of a verifiable registry pruning system according to an embodiment of the present invention, FIG. 2 is a block diagram of an existing Merkle tree, FIG. 3 and 4 are conceptual diagrams of an algorithm for generating skewed Merkle trees according to an embodiment of the present invention, and FIG. 5 and 10 are conceptual diagrams of an algorithm for generating h-skew Merkle trees according to an embodiment of the present invention.

First, referring to FIG. 1, a verifiable registry pruning system according to an embodiment of the present invention may be configured to include a skewed Merkle tree generating module 110, a hierarchical (h-)skewed Merkle tree generating module 120, and a node integrity verification module 130.

In general, a Merkle tree is also called a "hash tree" and has a tree-like data structure configured by a cryptographic hash value.

As illustrated in FIG. 2, a merkle tree is used to verify that a hash value (e.g. H ₆ , H ₇ , H ₈ , root) for any data (e.g. H ₁ , H ₂ , H ₃ , H ₄ , H ₅ ) is included in merkle tree. In other words, verification is carried out by calculating the hash value along the route up to the root node. Verification occurs when the final computed value matches the root hash value. For example, to verify H ₁ , verification is done when the result of calculating and verifying the hash value along the route by using H ₂ and H ₈ matches the root hash value.

However, when using the Merkle tree verification mechanism, the data size of the hash value (H ₆ , H ₇ , H ₈ , root) is small, but the original data (H ₁ , H ₂ , H ₃ , H ₄ , H ₅ ) can have a relatively very large data size.

The verifiable registry pruning system performs pruning that removes old data by using a skewed Merkle tree structure upgraded from such an existing common Merkle tree structure different from such an existing common h-skewed Merkle tree structure and a Merkle tree structure further upgraded from the skewed tree structure Merkle, and is made with the ability to perfectly verify the integrity of old data only with an upgraded Merkle tree structure.

In a skewed Merkle tree structure, each node can check the integrity of all data when in possession of recent data, such as only one day's data.

When it is assumed that the distributed ledger system has a transaction processing rate of 4 kTx/sec per day, only 172.8 GB data, which is the data collected in one day, is stored, and all the remaining previous data is truncated, and the data in truncated are ideally suited for checking integrity through the use of stored data, i.e. the root hash value of the skewed Merkle tree.

In addition, in an h-skewed Merkle tree structure, very old data of several years or more have even shorter evidence lengths than in a skewed Merkle tree structure. The size of this evidence increases over time, but in the present invention, the size of the evidence itself is reduced in order to reduce the workload assigned to verification and even reduce the time required for verification.

Returning to FIG. 1 and 3, the skew Merkle tree generation module 110 may be configured to generate a skew Merkle tree of a binary Merkle tree structure by using blocks of data.

The skew Merkle tree generating module 110 may be configured to generate a skew Merkle tree in the form of a binary Merkle tree structure in which the data block T _n and the root hash value R _n-1 of the previous subtree are paired.

The initial data block T1 and the root hash value R _n-1 are stored at each node of the skewed Merkle tree.

The skewed Merkle tree generation module 110 may be configured to calculate the root hash value of each node by h(h(T _n )|R _n-1 ) and sequentially store the root hash value at each node to expand and generate a skewed Merkle tree. .

The skew Merkle tree generation module 110 may be configured to first set the root hash value R _n-1 of the previous subtree in the new data block T _n produced according to the linked list mechanism.

In addition, h(T _n ) is computed by hashing T _n , the computed h(T _n ) and the root hash value R _n-1 of the previous subtree are added and then hashed again to compute h(h(T _n )|R _{n- 1} ); h(h(T _n )|R _n-1 ) is sequentially stored in the skewed Merkle tree.

In other words, a skewed Merkle tree can be thought of as a combination of a linked list and a binary Merkle tree.

In FIG. 3, the hash value R ₁ is a hash value by adding T ₁ , which is the first block of data, and the initial root hash value R ₀ . In addition, the hash value R ₂ is a value obtained by hashing T ₂ , which is the second block of data, and the oldest root hash value R ₁ . Since the oldest root hash value R ₁ is included in T ₂ via a linked list mechanism, T ₂ and R ₁ are hashed to calculate R ₂ . R ₂ is added to data block T ₃ by such a mechanism to expand and form a skewed Merkle tree by repeating such a process.

Meanwhile, the node integrity verification module 130 of FIG. 1 may be configured to verify integrity for a previous particular node on the skewed Merkle tree.

In FIG. 4, in order to verify whether or not T ₂ is included in the skewed Merkle tree, R ₄ included in T ₄ is obtained from T ₄ , which is the last data block of the skewed Merkle tree. In addition, for verification, R ₁ included in T ₂ is obtained from the given T ₂ . In addition, h(T ₂ ) is calculated by hashing T ₂ , and when R ₁ and h(T ₂ ) are added and hashed, R ₂ can be calculated.

Here, if the hash value h(T ₃ ) T ₃ is known in advance, R ₃ can be calculated by the same mechanism, and if h(T ₄ ) is also known in advance, R ₄ can be calculated by using R ₃ . If the calculated R ₄ is equal to the R ₄ obtained above, it can be verified that the corresponding node, which is the T ₂ node to be verified, is included in the skewed Merkle tree.

In other words, verification of T ₂ is provided if only h(T ₃ ) and h(T ₄ ) are known in the skewed Merkle tree.

When this is generalized and applied, the node integrity verification module 130 can verify the integrity of T _k if only the last root hash value R _n and the hash value h(T _i ) (here, k<i<=n) of the data block in an intermediate step are known in advance in order to verify the data block T _k of a particular node in the skewed Merkle tree.

In this case, the other data block in the intermediate step need not be known in advance, and the data block or hash value up to T _k need not necessarily be known.

In a skewed Merkle tree structure, even if each node does not directly own all blocks of data, it is possible to verify data integrity with only a few small hash values. This mainly contributes to even reducing the load on the network.

However, the skewed Merkle tree also has a disadvantage. Since each node of the skewed Merkle tree only has the hash value of the immediately preceding subtree according to the linked list mechanism, each of them must be computed and computed for all nodes, as illustrated in FIG. 4 in the process of verification. A skewed Merkle tree is advantageous in verifying recent data, but the number of work steps increases for hundreds of billions of transactions in units of several years, and as a result, the computational load increases. To complement this, an h-skewed Merkle tree can be used.

As illustrated in FIG. 5, h-skew Merkle tree generation module 120 of FIG. 1 is configured to additionally have information about the root hash value of the node a long time before, and also each node has the root hash value immediately before. The root hash value of a node a long time before as a link that refers to the previous tree is set as a transition link. In other words, the jump reference is the previous root hash value.

As illustrated in FIG. 5, the jump link has a spacing between exponential nodes, and the lengthy work step required for verification is omitted to ensure that the data block of the previous jump link is verified immediately. In other words, the size of evidence is reduced and the number of work steps is greatly reduced in order to quickly verify even a node over the past few years.

Each h-skew Merkle tree node value R _n that further possesses the jump reference of FIG. 5 may be organized as h(h(T _n )|R _n-1 |R _{n-(base^offset)} ).

Here, R _{n-(base^offset)} represents a transition reference, which is the hash value of the node at any previous time.

The base base in the jump link is the shortest distance of the predefined jump link in order to highlight the jump link at a predefined interval. If the base is 3, the jump link is allocated at intervals of three nodes.

In addition, the offset offset is the value of the remainder of the value obtained by dividing the location n of the current node by the base, i.e. n % base.

In addition, the distance dist from the location n of the current node to the transition link can be calculated as a base ^offset value.

Fig. 5 illustrates a jump link in which the base is 3 and the offset is 1.

Referring to FIG. 5, the jump link distance as base ^offset , i. e. 3 ¹ is equal to 3.

With respect to the R ₄ node, it can be seen that the R ₄ value can be obtained by adding and hashing the T ₄ hash value and the immediately preceding R ₃ hash value and the transition reference R ₁ .

Fig. 6 illustrates a jump link in which the base is 3 and the offset is 2.

In FIG. 6, it can be seen that the jump reference distance as 3 ² becomes 9.

However, the jump link need not necessarily be allocated to all nodes where the offset is 2. As illustrated in FIG. 7, the jump reference can only be allocated to the offset+(base ^offset )*k node at node location n. In this document, k represents a positive integer. The navigation link may not be allocated to a node other than the above node.

As illustrated in FIG. 7, if the base is 1 and the offset is 1, 1+3 ¹ *k, and the jump reference is allocated to R ₁₉ , R ₁₃ , R ₁₀ , R ₇ , R ₄ , R ₁ . In addition, if the base is 3 and the offset is 2, 2+3 ² *k, and the transition reference is allocated to R ₂₀ , R ₁₁ , R ₂ . If the base is 3 and the offset is 3, then the jump reference should be allocated for R ₅₇ , R ₃₀ , R ₃ .

Fig. 8 illustrates a state in which highlighting the jump link of FIG. 7 ends. The selection of the transition link is repeated repeatedly until each offset reaches the base.

Meanwhile, block verification can be performed as follows.

In a situation where the root hash value has R _x and any intermediate hash value can be accessed in an h-skewed Merkle tree, the following procedure is performed to verify whether the data block T _y or the top node R _y in h is included or not. - skewed Merkle tree.

1) Based on the link (node), provided that the corresponding distance (e.g., base) in the direction of the previous time from the last root hash value, is the nearest previous transition link or a common link that is equal to R _y or is in the future.

2) Based on the link (node), provided that the corresponding distance (e.g., base) in the direction of the previous time again from the hash value of the searched jump link or common link, finds the nearest previous jump link or common link, which is equal to R _y or is located in future. This process is repeated until R _y is reached.

3) The root hash is calculated, which is directed in the future direction sequentially for the set of searched links by using T _y . If the final result of the computation is R _head , the verification ends and R _head is verified to exist in the h-skewed Merkle tree.

Fig. 9 illustrates that R ₈ is detected in order to check T ₈ starting with R ₅₉ .

Referring to FIG. 9, R _head is R ₅₉ , links (nodes) R ₅₈ and R ₅₇ up to the corresponding distance in R ₅₉ , i.e. base distances of 3 refer to the values, and the nearest previous reference R ₃₀ that is farther in the future than R ₈ is found and interrogated from among jump references with an offset distance of 3 of R ₅₇ , i.e. 3 ³ .

Here, the link (node) R ₂₉ , up to the corresponding distance, i.e. base distance 3 is interrogated again. Transition link with offset distance of 2, i.e. 3 ² , and the jump link R ₁₁ of the jump link R ₂₀ is located and interrogated from R ₂₉ again. The jump link R ₁₁ becomes the closest previous link that is farther in the future than R ₈ from among the offset jump links in 2 based on R ₂₉ .

In addition, each of the links R ₁₀ , R ₉ and R ₈ within the appropriate distance is from R ₁₁ again, so as to eventually reach R ₈ .

In addition, the root hash value is sequentially computed in the future direction again by using T ₈ to be checked. If the final computed root hash value matches R ₅₉ on the h-skewed Merkle tree, then T ₈ is verified to exist in the h-skewed Merkle tree.

In this process, a total of 9 work steps are required from R ₈ to R ₉ , R ₁₀ , R ₁₁ , R ₂₀ , R ₂₉ , R ₃₀ , R ₅₇ , R ₅₈ and R ₅₉ . However, when the transition link is not used, all nodes R ₈ -R ₅₉ must be calculated and, as a result, only 51 work steps are required. It can be seen that the work steps are greatly reduced, and as the registry size increases, a significant amount of computation and significant computation time can be reduced.

Fig. 10 illustrates an h-skew Merkle tree in which the base is 10 as an example of an actual implementation. Since the transition reference is 10offset ^t , the distance of the transition reference increases to 10, 10 ² and 10 ³ , and when the distance is 1999, reaching is only possible by 28 stages.

In this regard, since the verifiable registry pruning system can ideally verify data with only a hash value, despite the direct possession of all blocks of data, the amount of data to be stored can be significantly reduced. When the size of the registry also increases enormously over time, searching and working using the jump link is urgently needed.

The present invention is described with reference to exemplary embodiments. However, those skilled in the art should appreciate that various modifications and variations of the present invention may be made without departing from the spirit and scope of the present invention, which are defined by the appended claims and their equivalents.

Claims (15)

1. System of verifiable pruning of registries, containing: a module for creating hierarchical (h-)skewed Merkle trees, in which, according to the linked list scheme, the root hash value R _n-1 of the previous subtree is included in the data block T _n , and the data block T _n in which the root hash value R is included _n-1 , is hashed, thereby obtaining h(T _n ), while the resulting h(T _n ) and the root hash value R _n-1 of the previous subtree and the transition reference R _{n-(base^offset)} are combined and then hashed , thereby obtaining h(h(T _n )|R _n-1 |R _{n-(base^offset)} , and the resulting h(h(T _n )|R _n-1 |R _{n-(base^offset)} is sequentially added to the corresponding nodes of the binary Merkle tree structure to create and unfold an h-skewed Merkle tree, while the transition reference R _{n-(base^offset)} is the root hash value for the node at the predefined previous time in the h-skewed Merkle tree, the base base represents the shortest distance of a predefined jump link to highlight that jump link at a predefined interval, offset represents the remainder of dividing the location n of the current node by the base, i.e. n % base, and the jump link distance is configured to be obtained by means of the base ^offset value. 2. The verifiable registry pruning system of claim 1, wherein the h-skew Merkle tree generating module is configured to extract each node's jump reference offset+(base ^offset )*k, and k is configured by a positive integer. 3. The verifiable registry pruning system of claim 1, further comprising a node integrity verification module, wherein the last root hash value of the h-skew Merkle tree is computed by successively performing an operation on the hash values by using T _k and a predetermined root hash value h(T _i ) (here, k<i≤n) of the h-skewed Merkle tree to verify whether or not the previous predefined data block T _k is included in the h-skewed Merkle tree, and compare whether or not the computed last the root hash value and the last root hash value known in advance, to check the integrity of the block T _k . 4. The verifiable registry pruning system of claim 3, wherein the node integrity verification module is configured to verify whether or not a hash value R _y or data block T _y exists in the h-skewed Merkle tree, according to the following procedure: 1) searching for a transition link or a link (node) that exists in the nearest previous time from among links (nodes) that are at the same time or further in the future than R _y based on the link (node) within a predetermined distance in the direction of the previous time from the last root hash value R _head , 2) searching for a transition link or a link (node) that exists in the nearest previous time from among links (nodes) that are at the same time or further in the future than R _y based on the link (node) within a predetermined distance in the direction of the previous time from the hash value of the transition link or a link that exists at the nearest previous time being searched, 3) repeating process 2) until R _y is reached, 4) computing future-directed root hashes sequentially for a set of transition or link (node) searched multiple times in processes 2) and 3) by using T _y , and 5) comparing whether or not the final received root hash value is equal to R _head , and verifying that the hash value R _y or data block T _y exists in the h-skewed Merkle tree when the final received root hash value is equal to R _head as a comparison result. 5. The verifiable registry pruning system of claim 4, wherein the predetermined distance is the base.

Images