Blockchain Transaction Data Storage Method Using Fountain Code and Apparatus Therefor

Abstract

To provide a robust block chain transaction data distribution storage method that is robust to change in the number of block chain nodes, and a block chain transaction data storage device therefor.SOLUTION: A block chain transaction data storage method comprises: selecting a transaction block corresponding to an encoding group; fountain-encoding the transaction block to generate at least one encoding chunk corresponding to each participating node; and storing the at least one encoding chunk corresponding to one of the participating nodes.SELECTED DRAWING: Figure 4

Description

Technical Field

[0001] The present invention relates to a blockchain transaction data storage system, and more particularly to a distributed storage system technology for distributing and storing encoding chunks generated by encoding blockchain transaction data.

Background Art

[0002] Since the emergence of Bitcoin, blockchain technology, which has attracted much attention, is a protocol that enables secure transactions between users of a network without the mediation of a trusted third party such as a bank. Even though some of the users participating in the network may perform malicious actions (such as double spending attacks where electronic money is paid twice), blockchain technology enables secure transactions by using cryptographic techniques. The core idea of blockchain technology is to block abnormal transactions by allowing all users to agree on and share a single unified ledger so that each user can verify the validity of a transaction by comparing it with the ledger. Blockchain technology can omit the unnecessary process of generating the mediation fee of a third party by having nodes verify integrity via a peer-to-peer (P2P) network without relying on a trusted third party such as a bank.

[0003] Basically, blockchain is an append-only technology that cannot delete stored data and can only add data, and maintains data integrity by having all nodes have the same data. For this reason, the storage capacity required by each node gradually increases over time, which becomes an obstacle preventing many nodes that cannot have sufficient storage capacity from easily participating in the blockchain. For example, as of August 2022, if participating as a full node in the Bitcoin network, a large storage space of about 400GB is required, and an additional storage capacity of about 50GB per year is needed. Considering that it is essential for many nodes to participate in the network to maintain decentralization, which is the core value of blockchain technology, it is necessary to reduce the size of the data that each node should store.

[0004] On the other hand, a distributed storage system is a system that divides large-sized data and stores it in a number of nodes with small storage capacities. In a distributed storage system, an encoding technique is generally applied to prepare for the case where a part of the nodes is inaccessible. At this time, the encoding technique is a technique that adds parity having a specific mathematical structure to the original data and enables the entire data to be read through the parity even when a part of the entire data is inaccessible.

[0005] When dispersedly storing blockchain transaction data, in order to solve the problem of insufficient storage space in the blockchain, research has been conducted on applying encoding techniques applicable to the distributed storage system to the transaction data to be stored. When encoding techniques are applied, each node does not store all the transaction data, but stores a part of the encoded data, reducing the burden on the storage space of each node. At this time, encoding techniques such as Reed-Solomon code and Fountain code were considered. Fountain code is a type of erasure code, also known as rateless erasure code, which can generate potentially infinite encoding symbols from a given number of source symbols.

[0006] In particular, in the blockchain system, frequent node participation / withdrawal occurs. However, existing technologies have the drawback that every time there is a change in the number of blockchain nodes, it is necessary to recover the original data and re-encode it, increasing the computational complexity. Similarly, in the case of conventional technologies using Fountain code, in the situation of dynamic node participation / withdrawal of nodes, complex operations are required for existing nodes to obtain the transaction data responsible for new nodes. Also, when encoding and dispersedly storing blockchain transaction data, there is a drawback that there is a large communication and computational burden for clients to read the transaction data.

Summary of the Invention

Problems to be Solved by the Invention

[0007] An object of the present invention is to provide a blockchain transaction data distributed storage technology that is robust to changes in the number of blockchain nodes.

[0008] Another object of the present invention is to enable easy acquisition of original data while reducing the burden on the storage space of nodes (users) participating in the blockchain network based on encoding.

[0009] Furthermore, an object of the present invention is to maintain the availability of transaction data with low computational complexity even in the situation of frequent node participation and withdrawal.

Means for Solving the Problems

[0010] The blockchain transaction data storage method according to the present invention for achieving the above object includes a step of selecting a transaction block corresponding to an encoding group, a step of generating at least one or more encoding chunks corresponding to each participating node by Fountain encoding the transaction block, and a step of storing the at least one or more encoding chunks corresponding to one of the participating nodes.

[0011] At this time, the blockchain transaction data storage method is performed by a blockchain transaction data storage device.

[0012] At this time, the blockchain transaction data storage method may further include a step of selecting at least one or more systematic transaction blocks of the transaction block and a step of storing the at least one or more systematic transaction blocks in a systematic transaction block set.

[0013] At this time, the remaining part of the transaction block excluding the systematic transaction block can be deleted.

[0014] At this time, the at least one or more encoding chunks are generated using an Encoding Vector Generator (EVG) that pseudo-randomly selects a part of the transaction block based on the identification information corresponding to each of the participating nodes.

[0015] At this time, the at least one or more systematic transaction blocks are selected using a Systematic Index Generator (SIG) that pseudo-randomly selects a part of the transaction block based on the identification information corresponding to each of the participating nodes.

[0016] At this time, the encoding vector generator and the systematic index generator can each operate further considering the bandwidth information and storage capacity information corresponding to each of the participating nodes in addition to the identification information.

[0017] At this time, the blockchain transaction data storage method may further include a step of storing a verifying set for verifying the encoding chunks corresponding to other nodes among the participating nodes.

[0018] At this time, when a new node is added to the participating nodes, it is possible to use the verification value for generating only the encoding chunk corresponding to the new node and adding it to the verification set while maintaining the already stored at least one or more encoding chunks as they are.

[0019] At this time, the blockchain transaction data storage method may further include a step of determining whether the number of the participating nodes satisfies the re-encoding condition, and a step of, when the re-encoding condition is satisfied, re-encoding after restoring the transaction block.

[0020] At this time, the re-encoding condition may be any one of a first condition for increasing the number of transaction blocks included in the encoding group corresponding to an increase in the number of the participating nodes, or a second condition for decreasing the number of transaction blocks included in the encoding group corresponding to a decrease in the number of the participating nodes.

[0021] In addition, the blockchain transaction data generation method according to the present invention includes a step of determining whether a requested transaction block is included in a systematic transaction block set, a step of, when not included in the systematic transaction block set, determining whether the requested transaction block is included in at least one systematic transaction block set of other participating nodes, a step of, when not included in at least one systematic transaction block set of the other participating nodes, receiving encoding chunks generated by Fountain encoding a transaction block from at least a part of the other participating nodes, and a step of decoding the encoding chunks to restore the requested transaction block.

[0022] At this time, the blockchain transaction data generation method is performed by a blockchain transaction data generation device.

[0023] At this time, if the requested transaction block is included in the systematic transaction block set, it is read from the systematic transaction block set and returned.

[0024] At this time, if the requested transaction block is included in the systematic transaction block set of at least one of the other participating nodes, it is provided (by being provided) and returned from the node that holds the requested transaction block among the other participating nodes.

[0025] At this time, whether it is included in the systematic transaction block of at least one of the other participating nodes is determined using a Systematic Index Generator (SIG) that pseudo-randomly selects a part of the transaction block based on the identification information corresponding to each of the other participating nodes.

[0026] In addition, a blockchain transaction data storage device according to an embodiment of the present invention includes one or more processors and an execution memory that stores at least one or more programs executed by the one or more processors.

[0027] At this time, the at least one or more programs select a transaction block corresponding to an encoding group, perform Fountain encoding on the transaction block to generate at least one or more encoding chunks corresponding to each of the participating nodes, and store the at least one or more encoding chunks corresponding to at least one of the participating nodes.

[0028] At this time, at least one of the above programs can select at least one systematic transaction block of the transaction block and store the at least one systematic transaction block in a systematic transaction block set.

[0029] At this time, the rest of the transaction block excluding the systematic transaction block can be deleted.

[0030] At this time, the at least one encoding chunk is generated using an Encoding Vector Generator (EVG) that pseudo-randomly selects a part of the transaction block based on the identification information corresponding to each of the participating nodes.

[0031] At this time, the at least one systematic transaction block is selected using a Systematic Index Generator (SIG) that pseudo-randomly selects a part of the transaction block based on the identification information corresponding to each of the participating nodes.

[0032] At this time, at least one of the above programs can store a verifying set for verifying the encoding chunks corresponding to other nodes among the participating nodes.

Advantages of the Invention

[0033] According to the present invention, not only can the burden on the storage capacity of blockchain nodes be reduced, but also in a blockchain system to which an encoding technique is applied, in a situation where nodes frequently participate and leave, the decoding and re-encoding processes with large communication and calculation loads can be reduced.

[0034] Also, according to the present invention, in a blockchain system capable of dynamic node participation / withdrawal, it is possible to obtain data stored by a new node newly participating in the blockchain with low communication and computational complexity, and a client can obtain a required transaction block with low computational complexity.

[0035] Furthermore, according to the present invention, since the storage capacity required for each node is reduced, a large number of nodes can participate in the network, which is an essential element for maintaining the decentralization, which is the core value of the blockchain.

Brief Description of the Drawings

[0036]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Modes for Carrying Out the Invention

[0037] The advantages and features of the present invention, and the method for achieving them, will become clear by referring to the embodiments described in detail hereinafter together with the attached drawings. However, the present invention is not limited to the embodiments disclosed hereinafter, and can be realized in various different forms. Merely, these embodiments are provided to make the disclosure of the present invention complete, and to fully inform those with ordinary knowledge in the technical field to which the present invention pertains of the scope of the invention. The present invention is defined only by the scope of the claims. The same reference numerals throughout the specification refer to the same components.

[0038] For example, terms such as "first" or "second" are used to describe various components, but such components are not limited by the above terms. The above terms are merely used to distinguish one component from another. Therefore, the first component mentioned hereinafter may be the second component within the technical idea of the present invention.

[0039] The terms used in this specification are for the purpose of explaining the embodiments and are not intended to limit the present invention. In this specification, the singular form also includes the plural form unless otherwise specifically stated in the text. The term "comprises" or "comprising" used in the specification includes the meaning that the mentioned component or step does not exclude the existence or addition of one or more other components or steps.

[0040] Unless otherwise defined, all terms used in this specification can be interpreted in a meaning commonly understood by those with ordinary knowledge in the technical field to which the present invention pertains. Also, generally used pre-defined terms are not interpreted ideally or excessively unless specifically defined otherwise.

[0041] Hereinafter, embodiments of the present invention will be described in detail with reference to the attached drawings. When describing with reference to the drawings, the same or corresponding components are denoted by the same drawing reference numerals, and duplicate descriptions thereof are omitted.

[0042] FIG. 1 is a diagram showing the concept of a blockchain transaction data storage method according to an embodiment of the present invention.

[0043] Referring to FIG. 1, the difference between a general blockchain transaction storage method and the blockchain transaction data storage method according to an embodiment of the present invention becomes apparent.

[0044] When there are k blocks of a blockchain including the breakdown of transactions, in an existing blockchain system, all nodes store the entire k blocks. In contrast, the blockchain transaction data storage method according to an embodiment of the present invention generates a number of encoding chunks (encoding blocks) by Fountain encoding the k blocks, and then each node stores a part of the encoding chunks to reduce the burden on the storage capacity of the nodes.

[0045] In FIG. 1, node i stores α i of the generated encoding chunks and systematically stores β i of the k original data blocks. At this time, the number of encoding chunks stored in all nodes may be the same or different from each other. At this time, the number of systematic blocks stored in all nodes may be the same or different from each other. For example, more systematic blocks are allocated to nodes having a high bandwidth and a high storage capacity.

[0046] If all nodes store only the encoding chunks and systematic blocks allocated to each node without storing all the data blocks in this way, when the hash value of the encoding chunks stored in other nodes and the size of the data of the block header are approximated to 0, the storage capacity is reduced by about (α i + β i ) / k times.

[0047] The present invention applies Fountain encoding to blockchain transaction data, and additionally stores the original transaction data systematically and additionally.

[0048] At this time, storing systematically means storing the original data so that the desired data can be accessed immediately without a decoding process. Therefore, each node according to the blockchain transaction data storage method according to an embodiment of the present invention stores a part of the encoding chunk encoded by the Fountain code and a part of the original transaction block.

[0049] The Fountain code is a type of erasure code and can potentially create an infinite number of encoding symbols with a given number of source symbols.

[0050] As shown in FIG. 1, the blockchain transaction data storage method according to an embodiment of the present invention divides blockchain transaction data to be encoded into a preset number (k) of data blocks, and encodes the preset number of data blocks to generate an infinite number of independent encoding chunks (encoding chunks or encoding blocks). Here, the fact that the encoding chunks are independent of each other means that the generation method of a certain encoding chunk is independent of the generation methods of all other encoding chunks. The fact that independent encoding chunks can be generated by a given number (k) of data blocks means that when a new participating node exists, the new node can calculate the encoding chunks to be stored by itself independently of the existing encoding chunks. Also, due to the characteristics of fountain coding, an infinite number of encoding chunks can be generated, so the blockchain transaction data storage method according to an embodiment of the present invention can operate effectively in a network situation where new node participation is frequent. Some of the encoding chunks are distributed and stored in blockchain nodes, thereby reducing the storage capacity burden of each node. Also, each node can systematically additionally store a part of the original data block in addition to the encoding chunks.

[0051] The blockchain transaction data storage method according to an embodiment of the present invention can have two merits by performing fountain coding-based encoding on blockchain transaction data and additionally storing systematic data blocks together with some of the encoding chunks. First, existing nodes can calculate the encoded blockchain data corresponding to new nodes with low complexity. Second, clients can obtain transaction blocks with low complexity.

[0052] The encoding chunks responsible for the new nodes may be the sum of some parts of the original data block. In a blockchain system applying Fountain codes, if all nodes store only the encoded chunks, when a new node joins the blockchain, it is necessary to go through the process of decoding the original data block by the encoding chunks before calculating the encoding chunks corresponding to the new node. Therefore, a system that stores only encoding chunks brings a large communication and computational load. In contrast, when additionally storing systematic blocks, some nodes can receive the systematic blocks they hold, construct the necessary original data, and obtain the encoding chunks responsible for the new node without a decoding process, thus reducing the communication and computational complexity.

[0053] Also, in the blockchain transaction data storage method according to an embodiment of the present invention, when a client reads data, by preferentially utilizing the systematic blocks stored by a large number of nodes, the data can be directly and quickly read out without going through the process of decoding the original data. The encoding chunks of Fountain code are used only when the desired data cannot be generated by the systematic blocks alone, and the desired data is read out by decoding using the encoding chunks.

[0054] Figure 2 is a diagram showing the process of generating k + m encoding chunks from k transaction blocks by the generator matrix of Fountain code.

[0055] Referring to Figure 2, it can be seen that Fountain encoding is applied to k transaction blocks to generate k + m encoding chunks (encoding blocks).

[0056] In FIG. 2, m may be any non - negative integer, and each column vector of the generator matrix may be independent of the other column vectors. At this time, when the sizes of the data blocks are different from each other in the encoding process, zero - padding can be used to make the sizes of all the data blocks the same.

[0057] FIG. 3 is a diagram showing the structure of a block of a blockchain and the groups formed by gathering the blocks.

[0058] Referring to FIG. 3, the blocks B 1 , B 2 ,..., B r each consist of a block header H i that incorporates meta - information about the block, and a block body T i that includes the breakdown of the transactions (where i is a natural number from 1 to r). That is, the example shown in FIG. 3 is regarded as a blockchain to which fountain coding is not applied, and the i - th block B i of the blockchain consists of a transaction block T i that incorporates transaction data, and a block header H i that incorporates meta - information about the block. The size of the block header and the size of the hash value of the encoding chunk are very small compared to the size of the block, so they are not significant in terms of storage capacity.

[0059] k blocks gather to form one group, and an encoding process is performed on the block body (transaction block) for each group. At this time, when the sizes of the transaction blocks stored in the blocks are different from each other, zero - padding technology can be used to make the sizes of all the transaction blocks within the group the same. For example, in the case of group 1, the transaction blocks T 1 , T 2 ,..., T kis encoded, and the transaction blocks T 1 , T 2 ,..., T k can all be set to the same size.

[0060] In the present invention, the reason for using fountain coding is as follows. First, since each encoding chunk is generated independently without being affected by other encoding chunks, when the number of nodes in the blockchain system changes, there is no need to re-encode the existing encoding chunks of the nodes to match the system with the changed number of nodes. To perform re-encoding, a large amount of communication resources are required to read the information stored in a large number of nodes, and since fountain coding has to be performed again with new parameters, a large amount of computing resources are also required. Therefore, a fountain-code-based encoded blockchain system is resource-efficient. Second, since fountain coding can generate an infinite number of encoding chunks, even if many new nodes participate in the blockchain system, the encoding chunks to be responsible for by the new nodes can be created.

[0061] Also, in the present invention, the reasons for systematically additionally storing the original transaction data (transaction block) are as follows. First, existing nodes can calculate the encoded chunks assigned to new nodes with low complexity. Existing nodes calculate the encoded chunks assigned to new nodes in order to verify the encoding chunks stored by the new nodes, and store the hash value obtained by hashing this as a proof. At this time, the encoding chunk may be the sum of a part of the original transaction block. At this time, a part of the original transaction block for generating the encoding chunk can be selected pseudo randomly. Therefore, if immediate access to the original data can be achieved through the systematically stored data, the encoding chunk can be obtained with low communication / computation complexity. If the original transaction block is not stored at all, the process of restoring the transaction data from the encoding chunk must always be passed through, so a lot of communication resources and computation resources are consumed. Second, if the original transaction data is systematically stored, the client can obtain the transaction block with very low complexity. If the client requests a specific transaction block, the node that directly stores the block can be preferentially requested to return the transaction block. At this time, the authenticity of the data can be verified using the hash value of the block header managed as metadata.

[0062] [Pseudo code 1] JPEG0007692458000001.jpg134145

[0063] Pseudo code 1 shows the process in which node i stores data by encoding in group m.

[0064] Referring to Pseudocode 1, the process of calculating the information stored in each node of the blockchain system can be understood. In the example of Pseudocode 1, α where all nodes store one encoding chunk i = 1 is taken as the center to describe an embodiment of the present invention, but each node can also store several encoding chunks.

[0065] The process described by Pseudocode 1 takes as input the k consecutive transaction blocks belonging to group m, the bandwidth resources and storage capacity resources of node i, and the public keys (node identification information) of the participating nodes participating in the system, and outputs the block header set H that node i must store, the systematic block set S i , the encoding chunk e i and the verification set (verifying set; V i ) required to verify the encoding chunks transmitted from other nodes. That is, the process of Pseudocode 1 takes as input k consecutive blocks belonging to a specific group, the bandwidth and storage resources of node i, and the public keys of the nodes participating in the system, and outputs the data stored by node i from the group. H in Pseudocode 1 is the block header set, S i is the systematic block set responsible for node i, e i is the encoding chunk responsible for node i, and V i is the verification set containing the hash values of the encoding chunks stored by other nodes.

[0066] Referring to Pseudocode 1, first, the block headers H 1 ,..., H k of all transaction blocks in the group are stored.

[0067] Also, the systematic block set and the verification set are each initialized to an empty set.

[0068] Also, using a Systematic Index Generator (SIG), β corresponding to the systematic transaction block responsible by node i i indices are generated. For example, if the 1st and 2nd blocks among k transaction blocks are selected as the transaction blocks for node i, indices 0 and 1 are generated.

[0069] At this time, the systematic index generator receives, as input, the identification information (public key) of node i, the bandwidth resource γ of node i i , and the storage capacity resource ρ i and can output β corresponding to the systematic transaction block responsible by node i i indices. Node i can systematically store only the transaction blocks corresponding to the output indices and delete the remaining transaction blocks. At this time, the systematic index generator can generate indices such that the more bandwidth resources and storage capacity resources node i has, the more systematic transaction blocks there are.

[0070] Once the generation of the indices of the systematic transaction blocks is completed, the systematic transaction blocks corresponding to the generated indices are stored in the systematic block set Si.

[0071] Also, using an Encoding Vector Generator (EVG), a binary vector of size k is generated for each of the n participating nodes. At this time, the binary vector can have 1 as an element for the transaction block used for encoding and 0 as an element for the transaction block not used for encoding. For example, if the transaction block used for generating the encoding chunk of node i is only the first block among k blocks, a binary vector {1, 0,..., 0} is generated.

[0072] At this time, the encoding vector generator receives, as input, the identification information (public key) of node j (where j is a natural number greater than or equal to 1 and less than or equal to n), and generates a binary vector v j each of whose elements has a length of k and is 0 or 1. The generated binary vector is used to generate an encoding chunk e j by taking the inner product with the transaction block and is responsible for node j. Node i hashes each of the encoding chunks responsible for participating nodes other than node i using a hash function h, and stores the hashed result value by adding it to a verifying set V i and storing it.

[0073] FIG. 4 is an operation flowchart showing a method for storing blockchain transaction data according to an embodiment of the present invention.

[0074] Referring to FIG. 4, a method for storing blockchain transaction data according to an embodiment of the present invention selects a transaction block corresponding to an encoding group (S410).

[0075] Also, the blockchain transaction data storage method according to an embodiment of the present invention fountain-encodes the transaction block to generate at least one or more encoding chunks corresponding to each participating node (S420).

[0076] At this time, the at least one or more encoding chunks are generated using an Encoding Vector Generator (EVG) that pseudo-randomly selects a part of the transaction block based on the identification information corresponding to each of the participating nodes.

[0077] Also, the blockchain transaction data storage method according to an embodiment of the present invention stores the at least one or more encoding chunks corresponding to one of the participating nodes (S430).

[0078] Furthermore, the blockchain transaction data storage method according to an embodiment of the present invention stores a verifying set for verifying the encoding chunks corresponding to other nodes among the participating nodes (S440).

[0079] Also, the blockchain transaction data storage method according to an embodiment of the present invention selects at least one or more systematic transaction blocks of the transaction block (S450).

[0080] At this time, the at least one or more systematic transaction blocks are selected using a Systematic Index Generator (SIG) that pseudo-randomly selects a part of the transaction block based on the identification information corresponding to each of the participating nodes.

[0081] At this time, the encoding vector generator and the systematic index generator can each operate while further considering, in addition to the identification information, bandwidth information and storage capacity information corresponding to each of the participating nodes.

[0082] Also, the blockchain transaction data storage method according to an embodiment of the present invention stores the at least one or more systematic transaction blocks in a systematic transaction block set (S460).

[0083] At this time, the remaining of the transaction blocks excluding the systematic transaction blocks can be deleted.

[0084] At this time, when a new node is added to the participating nodes, it is possible to use, for generating a verification value, only the encoding chunk corresponding to the new node newly generated and added to the verification set while maintaining the already stored at least one or more encoding chunks as they are.

[0085] Although not explicitly shown in FIG. 4, the blockchain transaction data storage method according to an embodiment of the present invention may further include a step of determining whether the number of the participating nodes satisfies a re-encoding condition, and a step of re-encoding after restoring the transaction block when the re-encoding condition is satisfied.

[0086] At this time, the re-encoding condition may be any one of a first condition for increasing the number of transaction blocks included in the encoding group corresponding to an increase in the number of the participating nodes, or a second condition for decreasing the number of transaction blocks included in the encoding group corresponding to a decrease in the number of the participating nodes.

[0087] Each step shown in FIG. 4 is performed by the blockchain transaction data storage device shown in FIG. 7.

[0088] [Pseudo-code 2] JPEG0007692458000002.jpg188140

[0089] Pseudo-code 2 shows the process by which node i reads transaction block T l from it.

[0090] First, if block T l is included in the systematic block set of node i, then T l can be read immediately.

[0091] Otherwise, search for the node that systematically has T l and request the data from that node. At this time, the authenticity of T l is verified by the hash value stored in the block header.

[0092] If there is no node that systematically has T l , then request the encoding chunks from all other participating nodes, and obtain T l from the received k + τ (τ is the decoding margin) verified encoding chunks through the decoding process. At this time, the authenticity of the encoding chunks can be verified by the verification set stored by node i.

[0093] In the process of Pseudo-code 2, since each node does not have all the transaction blocks, in order for a specific node to access a specific transaction block, the assistance of other participating nodes may be required. First, if the node stores the original data block T l , then the data block can be read immediately. Otherwise, if a specific node does not have the systematic data block T lRequest to read. No other participating node has the systematic data block T l If not, encoding chunks are requested from a number of nodes, and T is obtained by a decoding process that utilizes k + τ verified encoding chunks l The systematic blocks (systematic transaction blocks) and encoding chunks provided by other nodes are verified using the block header set H and the verification set V i is used for verification.

[0094] FIG. 5 is an operation flowchart showing a method for generating blockchain transaction data according to an embodiment of the present invention.

[0095] Referring to FIG. 5, a method for generating blockchain transaction data according to an embodiment of the present invention receives a request for a transaction block (S510).

[0096] Also, a method for generating blockchain transaction data according to an embodiment of the present invention determines whether the requested transaction block is included in the systematic transaction block set (S520).

[0097] If, as a result of the determination in step S520, the requested transaction block is not included in the systematic transaction block set, it is determined whether the requested transaction block is included in at least one systematic transaction block set of other participating nodes (S530).

[0098] Whether the transaction block requested in step S530 is included in at least one systematic transaction block of the other participating nodes is determined using a Systematic Index Generator (SIG) that pseudo-randomly selects a part of the transaction block based on the identification information corresponding to each of the other participating nodes.

[0099] If, as a result of the determination in step S520, the requested transaction block is included in the systematic transaction block set, the requested transaction block is read from the systematic transaction block set and returned (S590).

[0100] If, as a result of the determination in step S530, the requested transaction block is included in at least one systematic transaction block set of the other participating nodes, the blockchain transaction data generation method according to an embodiment of the present invention is provided from the node among the other participating nodes that holds the requested transaction block (S540).

[0101] After step S540, the requested transaction block is returned (S590).

[0102] If, as a result of the determination in step S530, the requested transaction block is not included in at least one systematic transaction block set of the other participating nodes, encoding chunks generated by fountain encoding the transaction block are received from at least a part of the other participating nodes (S550).

[0103] After step S550, the blockchain transaction data generation method according to an embodiment of the present invention decodes the encoding chunk to restore the requested transaction block (S560).

[0104] After step S560, the blockchain transaction data generation method according to an embodiment of the present invention returns the requested transaction block (S590).

[0105] Each step shown in FIG. 5 is performed by the blockchain transaction data generation device shown in FIG. 7.

[0106] The blockchain transaction data storage and generation method according to an embodiment of the present invention must maintain data availability when some of the nodes participating in the blockchain system are Byzantine nodes that perform malicious actions. At this time, availability means the ability to recover all transactions only with the information stored in honest nodes that are operating normally. Assuming that there are at most f faulty nodes (including Byzantine nodes and honest nodes that do not operate normally) in a system composed of n nodes, in order to ensure availability, all transactions must be recoverable only with n - f normally operating honest nodes.

[0107] Since fountain code generates each encoding chunk independently, the probability that the blockchain system satisfies availability cannot be exactly 100% (1). However, for a very small δ value, if the probability is 1 - δ or more, it can be assumed that the availability is satisfied. At this time, a δ value of about 10 -12 is considered.

[0108] When restoring the original transaction data, the maximum number of reliable encoding chunks that can be used is n - f, where n is the total number of nodes and f is the number of faulty nodes. To restore the original transaction block with a very high probability from n - f encoding chunks, the number k of transaction blocks included in one group is set to k = n - f - τ (τ ≥ 0), which is smaller than n - f. Together with the method in Pseudocode 1, using a Gaussian-elimination decoder can achieve δ = 10 with a small τ value independent of the n value -12 and meet the availability level of .

[0109] When a node is added to the blockchain system, first, the new node obtains the breakdown of all transactions. At this time, systematically transaction blocks are preferentially transferred from other nodes, and the breakdown of all transactions can be obtained without the decoding process. If a part of the systematic transaction block cannot be accessed, after the encoding chunks of the group are transferred from multiple nodes, the breakdown of the transactions that cannot be accessed can be obtained through the decoding process. After obtaining the breakdown of all transactions, the new node utilizes this to construct the state database of the blockchain. At this time, the new node utilizes the method in Pseudocode 1 to keep only the ledger information it stores itself and deletes the remaining data. On the other hand, the existing node i must additionally store the hash values of the encoding chunks stored by the new node in the verification set V i to verify the authenticity of the encoding chunks. The node i can obtain the encoding chunks responsible for the new node by utilizing the public key of the new node and the encoding vector generator (EVG). At this time, by preferentially requesting the systematic blocks that are essential for calculating the encoding chunks responsible for the new node, the necessary data can be read out while minimizing the communication and calculation burdens.

[0110] When many nodes are added, for the efficiency of the storage capacity of the blockchain system, additionally, after all nodes recover the original blocks, fountain coding is applied to the recovered original blocks with new parameters to perform re-encoding to newly specify the encoding chunks responsible for each node.

[0111] In the situation where many nodes leave the blockchain network, an availability problem may occur where it is impossible to obtain some of the original transaction data from the data of honest nodes. When it is determined in the system that the number of nodes decreases further and the probability of satisfying availability becomes less than 1 - δ, the system can perform re-encoding based on the current number of nodes and always maintain the probability of satisfying availability at 1 - δ or more.

[0112] Figure 6 is an operation flowchart showing a method for executing re-encoding in a situation where the number of nodes changes dynamically.

[0113] The n described in Figure 6 is the number of nodes in the current blockchain system. JPEG0007692458000003.jpg10170 is the current maximum allowable number of faulty nodes, k is the number of transaction blocks belonging to one group, τ is a fixed constant value determined to satisfy the availability of the system, and φ(n - f - k) represents the probability that the blockchain system does not satisfy availability (the probability that honest nodes alone cannot recover transaction data).

[0114] Initially, if the number of blockchain nodes is n, the number of transaction blocks belonging to one group is set to k = n - f - τ, and encoding is performed.

[0115] Referring to Figure 6, the method for executing re-encoding waits for a change in the number of nodes (S610).

[0116] Further, the re-encoding execution method determines whether a node has been added (S620).

[0117] If, as a result of the determination in step S620, it is determined that a node has been added, the number of nodes is increased by the added amount (S632).

[0118] After step S632, the maximum allowable number f of faulty nodes is updated (S634).

[0119] After step S634, it is determined whether the n - f - τ value is much larger than k (S636).

[0120] At this time, whether the n - f - τ value is much larger than k can be determined by comparing the result value obtained by applying a preset function to k with the n - f - τ value. At this time, whether the n - f - τ value is much larger than k can be determined by comparing the value obtained by multiplying k by a preset value with the n - f - τ value. At this time, whether the n - f - τ value is much larger than k can be determined by comparing the value obtained by adding a preset value to k with the n - f - τ value.

[0121] That is, when a large number of nodes are added to the system and the n - f - τ value is much larger than k, the storage space of the nodes is being used inefficiently.

[0122] If, as a result of the determination in step S636, the n - f - τ value is not much larger than k, the re - encoding execution method returns to step S610 and waits for a change in the number of nodes.

[0123] If, as a result of the determination in step S636, it is determined that the n - f - τ value is much larger than k, the re - encoding execution method updates k and performs re - encoding with the new k value (S660).

[0124] That is, when a large number of nodes are added to the system and the n-f-τ value is much larger than k, in order to increase the storage efficiency of the nodes, after restoring the original data block, re-encoding is performed with a new k value.

[0125] If it is determined in step S620 that the number of nodes has decreased, the number of nodes is decreased by the decreased amount (S642).

[0126] After step S642, update the allowable maximum number of faulty nodes f (S644).

[0127] After step S644, determine whether the probability φ(n - f - k) of not satisfying the availability is greater than a very small threshold value δ (S646).

[0128] That is, when a large number of nodes are removed, there may be an availability problem that the original transaction block cannot be recovered only with the information stored in the honest nodes, so it is necessary to prevent this.

[0129] If it is determined in step S646 that the probability φ(n - f - k) of not satisfying the availability is not greater than a very small threshold value δ, the re-encoding execution method returns to step S610 and waits for a change in the number of nodes.

[0130] If it is determined in step S646 that the probability φ(n - f - k) of not satisfying the availability is greater than a very small threshold value δ, the re-encoding execution method updates k and performs re-encoding with the new k value (S660).

[0131] That is, when there may be an availability problem in the system where a large number of nodes are removed and the original transaction block cannot be recovered only with the information stored in the honest nodes, for availability guarantee, after restoring the original data block, re-encoding is performed with a new k value.

[0132] FIG. 7 is a block diagram showing the configuration of a computer system according to an embodiment of the present invention.

[0133] The block chain transaction data storage device, block chain transaction data generation device, nodes and clients constituting the block chain according to the embodiment can be realized in a computer system 700 such as a computer-readable recording medium.

[0134] The computer system 700 can include one or more processors 710, a memory 730, a user interface input device 740, a user interface output device 750, and a storage 760 that communicate with each other via a bus 720. Further, the computer system 700 can further include a network interface 770 connected to a network 780. The processor 710 may be a semiconductor device that executes a program or processing instruction stored in a central processing unit or the memory 730 and the storage 760. The memory 730 and the storage 760 may be storage media including at least one or more of a volatile medium, a non-volatile medium, a separable medium, a non-separable medium, a communication medium, or an information transmission medium. For example, the memory 730 can include a ROM 731 and a RAM 732.

[0135] At this time, at least one program is recorded in the memory 730.

[0136] At this time, the processor 710 can execute the program. At this time, the program can select a transaction block corresponding to an encoding group, perform Fountain encoding on the transaction block to generate at least one or more encoding chunks corresponding to each participating node, and store the at least one or more encoding chunks corresponding to one of the participating nodes.

[0137] At this time, the at least one or more programs can select at least one or more systematic transaction blocks of the transaction block and store the at least one or more systematic transaction blocks in a systematic transaction block set.

[0138] At this time, the rest of the transaction block excluding the systematic transaction block can be deleted.

[0139] At this time, the at least one or more encoding chunks are generated using an Encoding Vector Generator (EVG) that pseudo-randomly selects a part of the transaction block based on the identification information corresponding to each of the participating nodes.

[0140] At this time, the at least one or more systematic transaction blocks are selected using a Systematic Index Generator (SIG) that pseudo-randomly selects a part of the transaction block based on the identification information corresponding to each of the participating nodes.

[0141] At this time, the encoding vector generator and the systematic index generator can each operate further considering the bandwidth information and storage capacity information corresponding to each of the participating nodes in addition to the identification information.

[0142] At this time, the at least one or more programs can store a verifying set for verifying the encoding chunks corresponding to other nodes among the participating nodes.

[0143] At this time, when a new node is added to the participating nodes, it is possible to use, for generating a verification value, only the encoding chunk corresponding to the new node newly generated and added to the verification set while maintaining the already stored at least one or more encoding chunks as they are.

[0144] At this time, the at least one or more programs determine whether the number of participating nodes satisfies a re-encoding condition, and if the re-encoding condition is satisfied, after restoring the transaction block, it can be encoded again.

[0145] At this time, the re-encoding condition may be any one of a first condition for increasing the number of transaction blocks included in the encoding group corresponding to an increase in the number of participating nodes, or a second condition for decreasing the number of transaction blocks included in the encoding group corresponding to a decrease in the number of participating nodes.

[0146] As described above, the blockchain transaction data storage method, the blockchain transaction data generation method, and the apparatus therefor according to the present invention are not limited to the configurations and methods of the embodiments described above, and the above embodiments may be configured by selectively combining all or part of each embodiment so that various modifications are made.

Explanation of Signs

[0147] 700: Computer system 710: Processor 720: Bus 730: Memory 731: ROM 732: RAM 740: User interface input device 750: User interface output device 760: Storage 770: Network interface 780: Network

Claims

1. In a method for storing blockchain transaction data performed by a blockchain transaction data storage device, selecting a transaction block corresponding to an encoding group; generating at least one or more encoding chunks corresponding to each participating node by Fountain encoding the transaction block; storing the at least one or more encoding chunks corresponding to one of the participating nodes; selecting at least one or more systematic transaction blocks of the transaction block; storing the at least one or more systematic transaction blocks in a systematic transaction block set; including A method for storing blockchain transaction data, characterized in that the rest of the transaction block excluding the systematic transaction block is deleted.

2. The at least one or more encoding chunks are generated using an Encoding Vector Generator (EVG) that pseudo-randomly selects a part of the transaction block based on the identification information corresponding to each of the participating nodes. The method for storing blockchain transaction data according to claim 1.

3. The at least one or more systematic transaction blocks are selected using a Systematic Index Generator (SIG) that pseudo-randomly selects a part of the transaction block based on the identification information corresponding to each of the participating nodes. The method for storing blockchain transaction data according to claim 2.

4. The encoding vector generator and the systematic index generator The method for storing blockchain transaction data according to claim 3, wherein each of the participating nodes operates by further considering, in addition to the identification information, bandwidth information and storage capacity information corresponding to each of the participating nodes.

5. The method for storing blockchain transaction data according to claim 1, further comprising the step of storing a verification set for verifying encoding chunks corresponding to other nodes among the participating nodes.

6. When a new node is added to the participating nodes, The method for storing blockchain transaction data according to claim 5, wherein, while maintaining the at least one or more already stored encoding chunks as they are, only the encoding chunks corresponding to the new node are newly generated and used to generate a verification value to be added to the verification set.

7. The step of determining whether the number of the participating nodes satisfies a re-encoding condition, and The method for storing blockchain transaction data according to claim 1, further comprising the step of re-encoding after restoring the transaction block when the re-encoding condition is satisfied.

8. The re-encoding condition is The method for storing blockchain transaction data according to claim 7, wherein it is any one of a first condition for increasing the number of transaction blocks included in the encoding group corresponding to an increase in the number of the participating nodes, or a second condition for decreasing the number of transaction blocks included in the encoding group corresponding to a decrease in the number of the participating nodes.

9. In a method for generating blockchain transaction data performed by a blockchain transaction data generation device, The step of determining whether the requested transaction block is included in a systematic transaction block set, and The step of determining whether the requested transaction block is included in at least one systematic transaction block set of other participating nodes when it is not included in the systematic transaction block set. If not included in at least one systematic transaction block set of the other participating nodes, receiving, from at least a part of the other participating nodes, an encoding chunk generated by Fountain encoding a transaction block; decoding the encoding chunk to restore the requested transaction block; and comprising wherein the requested transaction block if included in the systematic transaction block set, is read from and returned by the systematic transaction block set, a method for generating blockchain transaction data. **Claim 10** wherein the requested transaction block if included in at least one systematic transaction block set of the other participating nodes, is provided by (by being provided) and returned from a node among the other participating nodes that holds the requested transaction block, the method for generating blockchain transaction data according to claim 9. **Claim 11** In a method for generating blockchain transaction data performed by a blockchain transaction data generation device, determining whether a requested transaction block is included in a systematic transaction block set; if not included in the systematic transaction block set, determining whether the requested transaction block is included in at least one systematic transaction block set of other participating nodes; if not included in at least one systematic transaction block set of the other participating nodes, receiving, from at least a part of the other participating nodes, an encoding chunk generated by Fountain encoding a transaction block; decoding the encoding chunk to restore the requested transaction block; and comprising whether it is included in at least one systematic transaction block of the other participating nodes is A method for generating blockchain transaction data, characterized in that it is determined using a Systematic Index Generator (SIG) that pseudo-randomly selects a part of the transaction block based on the identification information corresponding to each of the other participating nodes.

12. One or more processors, and an execution memory storing at least one or more programs executed by the one or more processors, wherein the at least one or more programs select a transaction block corresponding to an encoding group, perform Fountain encoding on the transaction block to generate at least one or more encoding chunks corresponding to each of the participating nodes, store the at least one or more encoding chunks corresponding to one of the participating nodes, wherein the at least one or more programs select at least one or more systematic transaction blocks of the transaction block, store the at least one or more systematic transaction blocks in a systematic transaction block set, and a blockchain transaction data storage device, characterized in that the rest of the transaction block excluding the systematic transaction block is deleted.

13. The at least one or more encoding chunks are generated using an Encoding Vector Generator (EVG) that pseudo-randomly selects a part of the transaction block based on the identification information corresponding to each of the participating nodes, and the blockchain transaction data storage device according to claim 12 is characterized in that.

14. The at least one or more systematic transaction blocks The blockchain transaction data storage device according to claim 13, wherein a part of the transaction block is selected pseudo-randomly based on identification information corresponding to each of the participating nodes, using a Systematic Index Generator (SIG).

15. The at least one or more programs The blockchain transaction data storage device according to claim 12, characterized in that it stores a verifying set for verifying encoding chunks corresponding to other nodes among the participating nodes.

Images