Blockchain transaction data storage method, device, and distributed storage system using the same

Abstract

To provide a method and apparatus for storing blockchain transaction data and a system, configured to solve problems of waste of storage space and concentration of data ownership, which are caused when blockchain transaction data is redundantly stored in participating nodes.SOLUTION: A method for storing blockchain transaction data includes the steps of: selecting at least one block file storing blockchain transactions as an encoding block file target; generating encoded chunks including parity chunks using the encoding block file target; and associating at least one of the encoded chunks with at least one of blockchain nodes that stores at least one of the encoded chunks.SELECTED DRAWING: Figure 10

Description

[Technical field]

[0001] The present invention relates to a blockchain transaction data storage system, and more particularly to a technology for expanding the transaction data storage capacity of an entire blockchain system by distributing and storing blockchain transaction data in a large number of participating nodes while ensuring Byzantine Fault Tolerance. [Background technology]

[0002] Blockchain technology, which maintains a distributed ledger among a large number of participants who do not trust each other, is attracting attention as a way to solve problems such as the centralization of ownership of personal data among trusted third parties, and the leakage and manipulation of personal data from trusted third parties, thereby ensuring the integrity and reliability of data.

[0003] Recently, as the value of virtual currencies such as Bitcoin and Ethereum has skyrocketed, virtual currency transactions have also increased rapidly, and interest in blockchain technology has also increased sharply. Blockchain technology is attempting to expand its scope of application beyond existing virtual currency-related fields to general industry and business.

[0004] There have been attempts to develop and commercialize blockchain-based application services in various industrial sectors, but many attempts have failed due to the limitations of blockchain's scalability in areas such as consensus, storage, and analysis, and blockchain technology is still primarily used for virtual currencies.

[0005] The scalability issue of the blockchain storage hierarchy is that as the utilization of the blockchain increases, the size of the stored ledger (consisting of transaction data and status data) will increase exponentially. If the size of the ledger increases exponentially, it will become impossible to store or process it on a general-purpose personal computer (PC) or server.

[0006] In most blockchain platforms, such as Bitcoin, Ethereum, and Hyperledger Fabric, ledgers consist of state data, which manages the latest state data of data or assets, and transaction data, which manages the history of transactions that cause state changes. State data is usually managed using a key / value store or document store such as LevelDB, RocksDB, or CouchDB, and transaction data is managed using files on a file system (in the case of Bitcoin or Hyperledger Fabric) or a key / value store (in the case of Ethereum).

[0007] In particular, transaction data is collected in blocks of a preset size and reflected in the final state data through processes such as consensus and verification among participating nodes, and the agreed-upon blocks are linked together and distributed and stored among a large number of participating nodes to act as a shared ledger, thereby ensuring the integrity and reliability of the data.

[0008] However, blockchain transaction data is stored redundantly in all participating nodes, which poses a problem as it requires excessive disk / memory capacity.

[0009] Bitcoin transaction data was approximately 213GB in April 2019, and reached approximately 360GB as of October 2021, an increase of approximately 150GB compared to 2019.

[0010] Due to this rapid increase in blockchain transaction data and the duplicated storage method, new nodes joining the blockchain network must spend days or weeks to receive existing transaction data, and only nodes with very high levels of computing resources and capabilities can join the blockchain as full nodes. This has resulted in an increase in the share of large mining pools, ultimately reversing decentralization and creating the problem of centralizing data ownership again.

[0011] Recently, various blockchain transaction distributed storage methods have been proposed using distributed hash tables (DHTs), sharding, erasure codes (ECs), etc., in order to solve storage capacity and performance issues by distributing blockchain transaction data without storing it redundantly among participating nodes.

[0012] In the case of distributed hash table (DHT)-based technology, which stores and manages large amounts of data in a distributed manner across participating nodes on a network, some research institutions are conducting initial research, but the majority of research has only been discussed at a theoretical level without being put into practical use. In addition, the partially realized technologies have not been sufficiently verified to ensure Byzantine fault tolerance, and much more research and verification is still needed before they can be used in practice.

[0013] Sharding-based technology, which divides and stores data into multiple logical groups, divides transaction data primarily on an account basis and stores the data in duplicate only within the relevant shard, thereby addressing the increase in ledger capacity. However, problems have been pointed out, such as the complexity of processing when trading between different shards and the fact that data still gets duplicated within the shard, making it vulnerable to malicious attacks.

[0014] Recently, research has been conducted on methods of splitting and distributing blockchain transaction data based on encoding technologies such as ECC (Error Correction Code) and EC (Erasure Code), which are methods of ensuring data availability that have been primarily used in communication and storage systems. However, there are still many issues to be resolved, such as ensuring Byzantine fault tolerance, encoding / decoding overhead, read performance of blocks that have been split and distributed, and the need for re-encoding when adding / removing participating nodes.

[0015] The IEEE paper "BFT-Store: Storage Partition for Permissioned Blockchain via Erasure Coding" published in 2020 proposes a technology to apply erasure coding to a large number of blocks to generate encoded blocks, which are then distributed across multiple nodes for storage. However, as it does not take into account the environment in which blocks are actually stored in files, etc., it is difficult to apply this to existing blockchain systems, and efficiency is reduced as it does not take into account access frequency, computational load, or storage space efficiency.

[0016] Korean Patent Publication No. 10-2021-0058744 proposes a technology to apply encoding to one or more blocks and divide and store the encoded blocks among all participating nodes in the blockchain network. However, when access to the encoded data occurs, there is a problem that the encoded blocks must be collected and decoded from a large number of nodes each time in order to access the data.

[0017] Therefore, there is an urgent need for a new blockchain distributed storage technology that can ensure optimal performance by taking into account the actual blockchain storage status of blocks and handle access to encoded blocks more efficiently. Summary of the Invention [Problem to be solved by the invention]

[0018] The objective of the present invention is to distribute and store blockchain transaction data, which is expressed in the form of blocks and stored in a file system in the form of files, in a number of participating nodes while ensuring Byzantine fault tolerance, thereby resolving the problems of wasted storage space and centralized data ownership that arise when transaction data is stored in duplicate in participating nodes.

[0019] Another object of the present invention is to improve the efficiency of storage space management in a blockchain system so that blockchain technology can be used for large-scale storage / management in various industrial fields. [Means for solving the problem]

[0020] To achieve the above-mentioned objective, a blockchain transaction data storage method performed by a blockchain transaction data storage device according to the present invention includes the steps of selecting at least one block file that stores blockchain transactions as an encoding block file target, generating encoded chunks including a parity chunk using the encoding block file target, and associating at least one of the encoded chunks with at least one blockchain node that stores at least one of the encoded chunks.

[0021] In this case, there are M parity chunks (M is a natural number), there are 3M+1 blockchain nodes, there are 3M+1 encoded chunks, and there is a 1:1 correspondence between the encoded chunks and the blockchain nodes.

[0022] In this case, each blockchain node can store the encoded chunk as is for a corresponding one of the encoded chunks, and store only the hash values ​​for at least some of the remaining chunks except for the one.

[0023] In this case, the method for storing block chain transaction data may further include the steps of: determining whether the number of blocks included in the encoding block file target corresponds to 2M+1; and, if the number of blocks included in the encoding block file target does not correspond to 2M+1, generating 2M+1 blocks to be encoded using the blocks included in the encoding block file target and duplicate blocks that are part of the blocks included in the encoding block file target. In this case, the encoded chunk is generated by performing encoding using the blocks to be encoded.

[0024] At this time, the duplicate block is selected from among the blocks included in the encoding block file target based on the access frequency.

[0025] In this case, the encoding block file object can include no more than 2M+1 blocks.

[0026] In this case, the blocks not exceeding 2M+1 do not all have the same size and are padded based on the maximum block size before generating the encoded chunk.

[0027] At this time, the encoding block file target is selected from the block files storing the block chain transactions, taking into consideration the access frequency of the block file or the blocks contained in the block file.

[0028] The hash value is then used to verify blocks read from other nodes.

[0029] At this time, 2M+1 or more of the encoded chunks are used for decoding to restore the current block.

[0030] Furthermore, a blockchain transaction data storage device according to one embodiment of the present invention includes one or more processors and an execution memory storing at least one or more programs executed by the one or more processors.

[0031] In this case, the at least one or more programs may select at least one block file that stores blockchain transactions as an encoding block file target, generate encoded chunks including a parity chunk using the encoding block file target, and correspond at least one of the encoded chunks to at least one blockchain node that stores the at least one encoded chunk.

[0032] In this case, there are M parity chunks (M is a natural number), there are 3M+1 blockchain nodes, there are 3M+1 encoded chunks, and there is a 1:1 correspondence between the encoded chunks and the blockchain nodes.

[0033] In this case, each blockchain node can store the encoded chunk as is for a corresponding one of the encoded chunks, and store only the hash values ​​for at least some of the remaining chunks except for the one.

[0034] At this time, at least one program may determine whether the number of blocks included in the encoding block file object corresponds to 2M+1, and if the number of blocks included in the encoding block file object does not correspond to 2M+1, generate 2M+1 blocks to be encoded using the blocks included in the encoding block file object and duplicate blocks which are some of the blocks included in the encoding block file object. At this time, the encoded chunk is generated by performing encoding using the blocks to be encoded.

[0035] At this time, the duplicate block is selected from among the blocks included in the encoding block file target based on the access frequency.

[0036] In this case, the encoding block file object includes blocks whose sizes are not all the same, and the blocks whose sizes are not all the same are padded based on a maximum block size before generating the encoded chunks.

[0037] At this time, the encoding block file target is selected from the block files storing the block chain transactions, taking into consideration the access frequency of the block file or the blocks contained in the block file.

[0038] The hash value is then used to verify blocks read from other nodes.

[0039] At this time, 2M+1 or more of the encoded chunks are used for decoding to restore the current block.

[0040] In addition, a blockchain transaction data distributed storage system according to one embodiment of the present invention includes a first blockchain node that stores a first chunk among the encoded chunks as is and stores a hash value corresponding to the remaining chunks excluding the first chunk, and a second blockchain node that stores a second chunk different from the first chunk as is and stores a hash value corresponding to the remaining chunks excluding the second chunk.

[0041] At this time, the encoded chunks are generated based on the encoding performed using an encoding block file target selected from the block files that store the blockchain transactions. Effect of the Invention

[0042] According to the present invention, in the existing blockchain system, transaction data is redundantly stored in the blockchain network participating nodes to ensure data reliability, thereby solving the problem that scalability is limited in terms of storage space capacity and space efficiency of transaction data even if the number of blockchain network participating nodes is increased.

[0043] In addition, according to the present invention, blockchain transaction data can be distributed and stored in a large number of participating nodes while ensuring Byzantine fault tolerance, thereby improving storage space efficiency and minimizing the use of storage space in each participating node.

[0044] Furthermore, according to the present invention, the efficiency of the storage space of participating nodes is improved, minimizing the use of storage space of each participating node, thereby maximizing the storage capacity of the entire blockchain system. [Brief description of the drawings]

[0045] [Figure 1]FIG. 1 is a block diagram illustrating a blockchain transaction data distributed storage system according to one embodiment of the present invention. [Diagram 2] FIG. 1 is a block diagram showing the structure of a blockchain transaction data distributed storage system according to one embodiment of the present invention. [Diagram 3] FIG. 3 is a block diagram illustrating an example of a blockchain data manager shown in FIG. [Figure 4] A diagram showing the storage flow of blockchain data in a blockchain transaction data distributed storage system according to one embodiment of the present invention. [Diagram 5] FIG. 2 is a block diagram showing the concept of block file storage. [Figure 6] FIG. 2 is a diagram showing an example of a block file list in which blocks are stored in a file system in the form of block files. [Figure 7] FIG. 2 illustrates an example of a block file storage structure. [Figure 8] FIG. 13 is a diagram illustrating an example of a case where encoding is applied on a block file basis according to an embodiment of the present invention. [Figure 9] A block diagram showing an example of a method for encoding blockchain transaction data based on block file encoding according to one embodiment of the present invention. [Figure 10] 1 is an operational flowchart illustrating a method for storing blockchain transaction data according to one embodiment of the present invention. [Figure 11] FIG. 1 illustrates an example of how encoding of blockchain transaction data is applied on a multi-block file basis. [Figure 12] 4 is an operational flowchart illustrating a method for selecting a block file to be encoded according to an embodiment of the present invention. [Figure 13] 1 is an operational flowchart showing an example of a block access method according to an embodiment of the present invention. [Figure 14]1 is an operational flowchart illustrating an example of a method for re-encoding a node that has found a block error according to an embodiment of the present invention. [Figure 15] 4 is an operational flowchart illustrating an example of a re-encoding method of a node that receives a re-encoding request according to an embodiment of the present invention. [Figure 16] A diagram showing the replication of frequently accessed blockchain transaction data in a blockchain transaction data distributed storage system according to one embodiment of the present invention. [Figure 17] 1 is a block diagram showing a configuration of a computer system according to an embodiment of the present invention; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0046] The advantages and features of the present invention, and the method of achieving them, will become clear from the following detailed description of the embodiments in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, and may be realized in various different forms. The embodiments are provided merely to complete the disclosure of the present invention, and to fully inform those skilled in the art of the present invention of the scope of the invention. The present invention is defined only by the scope of the claims. The same reference numerals refer to the same elements throughout the specification.

[0047] Although "first" or "second" is used to describe various components, such components are not limited by such terms. Such terms are used merely to distinguish one component from another component. Therefore, a first component referred to below may be a second component within the technical spirit of the present invention.

[0048] The terms used in the present specification are for describing the embodiments and are not intended to limit the present invention. In the present specification, the singular form includes the plural form unless otherwise specified in the text. The term "comprises" or "comprising" used in the specification includes the meaning that the mentioned components or steps do not exclude the presence or addition of one or more other components or steps.

[0049] Unless otherwise defined, all terms used in this specification are to be interpreted in a manner commonly understood by those having ordinary skill in the art to which the present invention pertains. Furthermore, terms defined in commonly used dictionaries are not to be interpreted ideally or excessively unless otherwise clearly defined.

[0050] Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. When describing with reference to the drawings, the same or corresponding components will be given the same reference numerals, and duplicate descriptions thereof will be omitted.

[0051] FIG. 1 is a block diagram illustrating a blockchain transaction data distributed storage system according to one embodiment of the present invention.

[0052] Referring to Figure 1, in a blockchain transaction data distributed storage system, if transaction data that manages transaction history in the form of a block chain (blockchain) is stored in duplicate in participating nodes, a problem may arise in which excessive disk / memory capacity is required.

[0053] The blockchain node illustrated in FIG. 1 may include a first blockchain node that stores a first chunk of the encoded chunks as is and stores a hash value corresponding to the remaining chunks excluding the first chunk, and a second blockchain node that stores a second chunk different from the first chunk as is and stores a hash value corresponding to the remaining chunks excluding the second chunk. At this time, the encoded chunks are generated based on encoding performed using an encoding block file target selected from block files storing blockchain transactions. At this time, the encoding block file target may correspond to one or more block files. For example, the encoding block file target may correspond to one block file, the encoding block file target may correspond to two block files, or the encoding block file target may correspond to ten block files.

[0054] A blockchain data distributed storage system according to one embodiment of the present invention can minimize the disk / memory space required for each node in the blockchain transaction data storage system by having at least a portion of the nodes that store blockchain transaction data encode the blockchain transaction data in block file units and store only a portion of the encoded chunks as is.

[0055] FIG. 2 is a block diagram showing the structure of a blockchain transaction data distributed storage system according to one embodiment of the present invention.

[0056] Referring to FIG. 2, a blockchain transaction data distributed storage system according to one embodiment of the present invention can be constructed in the form of a blockchain network consisting of a number of blockchain nodes 210, 220, 230, and 240 that share blockchain data.

[0057] The blockchain node 210 consists of a blockchain data manager for ensuring data reliability, a blockchain core interface for application program development, and modules for other base and application technologies.

[0058] In this case, the blockchain data manager may include storage, a state manager, and a transaction manager.

[0059] At this time, the blockchain core interface may include an administration interface and a software development tool.

[0060] At this time, modules for other base and application technologies may include a cryptographic module, security hardware, a platform account manager, a P2P / communication protocol unit, an agreement protocol unit, and a smart contract unit.

[0061] The decentralized application (DApp) shown in Figure 2 can provide users with trust-based data storage / management application services using the functions and interfaces provided by the blockchain platform and blockchain network.

[0062] FIG. 3 is a block diagram illustrating an example of the blockchain data manager shown in FIG. 2.

[0063] Referring to FIG. 3, the blockchain data manager may include a ledger manager 310, a state manager 320, a composite state manager 330, a simple state manager 340, a composite state database 341, a simple state database 342, a transaction manager 350, a file-based block manager 360, and block files 371, 372.

[0064] The blockchain data manager shown in Figure 3 provides management functionality for the blockchain ledger (consisting of state data and transaction data).

[0065] Transactions generated in a decentralized application (DApp) are transmitted to the state manager 320 and the transaction manager 350 via the ledger manager 310.

[0066] The state manager 320 is made up of a composite state manager 330 and a simple state manager 340 , and the transaction manager 350 is made up of a file-based block manager 360 .

[0067] The storage consists of a compound state database 341 for storing states, a simple state database 342, and a blockchain in the form of a block file for storing transactions.

[0068] Although not explicitly shown in Figure 3, block files in storage can be encoded on a block file basis to generate encoded chunks, and each blockchain node can store only one of the encoded chunks as is, and store only the hash values ​​of the rest.

[0069] FIG. 4 is a diagram showing the storage flow of blockchain data in a blockchain transaction data distributed storage system according to one embodiment of the present invention.

[0070] Referring to FIG. 4, the blockchain application service (SDK) transmits a transaction to an endorsing node among the blockchain nodes (S410).

[0071] The endorsing node executes a smart contract to simulate the transmitted transaction within the node, generates a simulation result (S420), and then transmits the generated simulation result to the application service (S430).

[0072] The application service submits a transaction including the simulation result to a block generating node (Ordering Service Node) (S440).

[0073] The Ordering Service Node collects the submitted transactions, determines the order of the transactions, and creates a block (S450).

[0074] Once a block is constructed, it is communicated to all block storing nodes (Committing Nodes) (S460).

[0075] Each block storage node (Committing Node) verifies each transaction in the transmitted block and stores (commits) it in the storage within the node (S470). At this time, changes occur to the blockchain (transaction data history) and state data. The new transaction is recorded in the back of the existing blockchain in the form of a block, and the existing state data is changed to a new value.

[0076] In the example shown in FIG. 4, an endorsing node can act not only as a signing node but also as a committing node at the same time.

[0077] FIG. 5 is a block diagram illustrating the concept of block file storage.

[0078] Referring to FIG. 5, it can be seen that blocks (bundles of transaction data) are generated, distributed to each node, and stored in each node in the form of a file system-based block file.

[0079] In other words, in the blockchain data storage flow shown in Figure 4, when a new block is generated by a block generating node, it is distributed to a block storing node and stored in the form of a block file. This is considered the block mining process.

[0080] The block storage node does not store the transferred blocks in a separate file, but collects and stores them in the form of a block file of a certain size. Therefore, one block file contains multiple blocks. In this case, each block storage node can manage the same blocks and block files in duplicate to ensure the consistency of the blockchain data, but in this case, a problem of insufficient storage space may occur.

[0081] FIG. 6 is a diagram showing an example of a block file list in which blocks are stored in the form of block files in a file system.

[0082] Referring to FIG. 6, it can be seen that Bitcoin blocks are stored in the blkNNNNN.dat block file in the ~ / .bitcoin / blocks directory in all nodes. Blocks are stored starting with the blk00000.dat block file, and as each block file reaches its maximum size, it is stored in the next file. For example, the size of a Bitcoin block is 1MB on average, and the maximum size of a block file is defined by MAX_BLOCKFILE_SIZE, with a default value of 128MiB (134, 271, 728 bytes). For example, Hyperledger Fabric, similar to Bitcoin, collects and stores multiple blocks in one block file. In this case, the default value of the maximum block file size may be 64MB.

[0083] FIG. 7 is a diagram showing an example of a block file storage structure.

[0084] 7, it can be seen that blocks are stored in the form of block files. The example shown in FIG. 7 may show a storage structure of block files and blocks stored in block files in a blockchain system such as Bitcoin or Hyperledger Fabric.

[0085] Unlike Bitcoin and Hyperledger Fabric, Ethereum can store blocks that record transactions in a Transaction Trie. In this case, the Transaction Trie can be in the form of Modified MPT (Merkle Patricia Trie), and the MPT can store data using a key / value store such as LevelDB or RocksDB to guarantee durability.

[0086] 8 is a diagram illustrating an example of a case where encoding is applied in block file units according to an embodiment of the present invention. At this time, data availability can be guaranteed by applying encoding in block file units.

[0087] Referring to FIG. 8, input data in text format (in.txt) is encoded into K+M (K=4, M=2) chunks and managed.

[0088] Input data is divided into K (=2) data chunks of the same size and stored. At this time, M (=2) parity chunks of the same size are generated to ensure data availability. Here, K may be the number of data chunks corresponding to the input data, and M may be the number of data chunks corresponding to the parity.

[0089] In this way, the data encoded into K+M chunks has the availability to restore the original input data (in.txt) as it is even if up to M failures occur.

[0090] TIFF0007603647000001.tif45170

[0091] In this way, the six chunks encoded on a block file basis are stored in different nodes. In this case, even if up to two nodes fail or a Byzantine situation occurs (minimum four chunks are available), the output data (out.txt) can be restored to the original data (in.txt) by decoding. If only the parity chunks (in.txt.4, in.txt.5) fail and all four original chunks (in.txt.0, in.txt.1, in.txt.2, in.txt.3) are accessible, the decoding process can be omitted and the original chunks can be simply spliced ​​together to restore the original data (in.txt), saving decoding time.

[0092] As shown in the example of Figure 8, when K is 4 and M is 2, the storage space efficiency is as shown in Table 1 below. At this time, it can be seen that the encoding method provides higher storage space utility (using 1.58 times the storage space of the original) than the duplication method (using 3 times the storage space of the original) that was previously used to guarantee availability.

[0093] [Table 1]

[0094] For example, encoding is performed in various ways such as Reed-Solomon, Cauchy Reed-Solomon, Vandermonde Reed-Solomon, Fountain Code, Local Reconstruction Code (or Local Repairable Code), which have various different characteristics in terms of whether or not original data is retained, storage space efficiency, degree of availability, encoding / decoding speed, whether or not re-encoding is necessary, etc. In the distributed storage method of blockchain transaction data based on block file encoding of the present invention, one or more of various encoding methods can be selected and used. Hereinafter, the present invention will be described mainly with reference to an example using the Reed-Solomon method, which is the most basic encoding method, to make the proposed method easier to understand. If data is encoded in block file units to satisfy the Byzantine Fault Tolerance condition K>=2M+1, the total number of chunks is K+M=3M+1, and each chunk is divided and stored on K+M=3M+1 nodes, then it will have the ability to recover the original data even if physical node failures or Byzantine actions occur in up to 1 / 3 of the total nodes, i.e., Byzantine Fault Tolerance (BFT).

[0095] On the other hand, if encoding is applied and only some chunks of the original data are stored in each node, when a node needs to access a chunk that the node does not have, the node must receive data from another node, which causes a delay in access speed. Therefore, to apply the encoding method to a data storage system, the encoding must be applied while considering the read speed problem.

[0096] In order to utilize the high storage space efficiency of such an encoding method, the present invention applies encoding for storing blockchain transaction data on a block file basis, thereby ensuring high availability at a Byzantine fault tolerance level while minimizing the storage space required for each blockchain node. In particular, the present invention applies encoding on a block file basis, not on a transaction or block basis, taking into account the storage characteristics of an actual blockchain system.

[0097] FIG. 9 is a block diagram illustrating an example of a method for encoding block chain transaction data based on block file encoding according to one embodiment of the present invention.

[0098] Referring to FIG. 9, it can be seen that encoding is applied on a block file basis, rather than encoding one block at a time or simply matching the number of encoded blocks with the number of nodes.

[0099] That is, the present invention applies encoding for distributed storage of blockchain transaction data, and applies encoding taking into account the universal block storage structure of blockchain systems that store multiple blocks in one block file, such as Bitcoin and Hyperledger Fabric.

[0100] In the example shown in FIG. 9, blocks are stored in block files (BLOCK FILE0, ..., BLOCK FILE10, ...), and multiple blocks of various sizes are stored in one block file. For example, blocks 101 to 107 are stored in block file 10. The size of each block file does not exceed the maximum size value of the block file set in the blockchain system (e.g., 64 MB). Blocks of different sizes are generated depending on the maximum block size set in the blockchain system, the block generation cycle, the amount of transactions occurring at the time of block generation, the size of transactions occurring at the time of block generation, etc.

[0101] At this time, each blockchain node is assigned one of the encoded chunks.

[0102] In the example of FIG. 9, one blockchain node stores and manages the original data block for the assigned block (block 104), and stores and manages only the hash value of the unassigned block (blocks 101, 102, 103, 105, 106, 107, parity 1, 2). As a result, information on all blocks originally distributed is stored in each node, but for blocks not assigned at the time of encoding, only the hash value that occupies a small amount of storage space is stored, so that storage space can be saved. At this time, when access to the block is required later and a block is provided from another node, the hash value can be used to check whether an operation has occurred on the provided block.

[0103] In the example shown in Figure 9, encoding is applied to one block file, but the blockchain transaction data distributed storage method based on block file encoding of the present invention can apply encoding to multiple block files taking into account the number of blocks and the number of nodes.

[0104] The criteria for selecting a block file to which encoding is applied from among a number of pre-stored block files are as follows.

[0105] -Select the least frequently accessed blocks or block files.

[0106] -Select old blocks and block files.

[0107] -Taking into account the number of nodes, if necessary, select blocks or block files adjacent to the selected block (block file).

[0108] FIG. 10 is an operational flowchart illustrating a method for storing blockchain transaction data according to one embodiment of the present invention.

[0109] Referring to FIG. 10, the method for storing blockchain transaction data according to one embodiment of the present invention checks the number of blockchain nodes (3M+1) (S1015).

[0110] In addition, the method for storing block chain transaction data according to one embodiment of the present invention sets the number of parity chunks to M (S1017).

[0111] At this time, the number of blockchain nodes is set to 3M + 1. That is, when the number of blockchain nodes is determined, the appropriate number of parity chunks may be determined accordingly, and conversely, when the number of parity chunks is determined, the appropriate number of blockchain nodes may be determined accordingly.

[0112] In step S1015, if the number of nodes is N, encoding must be applied to satisfy the condition N=3M+1 in order to guarantee against Byzantine failures of transaction data, and encoding must be performed to have M parity chunks. Also, the number of blocks to be encoded (K), i.e., the number of blocks included in the encoding block file target or encoding block file, must be 2M+1.

[0113] Meanwhile, in a method for storing block chain transaction data according to one embodiment of the present invention, first, one of pre-stored block files is selected as a block file to be encoded, and parameters (K, prevK) are initialized (S1010).

[0114] At this time, the block file to be encoded is selected from among the block files that store blockchain transactions, taking into consideration the frequency of access to the block file or the block containing the block file.

[0115] At this time, the parameter K may indicate the number of blocks to be encoded, and the parameter prevK may indicate the number of blocks to be encoded up to the previous block file.

[0116] In addition, the method for storing block chain transaction data according to one embodiment of the present invention checks the number of blocks (B) included in the block file (S1020).

[0117] At this time, the number of blocks included in each block file may be different.

[0118] In addition, the method for storing block chain transaction data according to one embodiment of the present invention sets the number (K) of blocks to be encoded (S1030).

[0119] That is, in step S1030, the number of blocks included in the block file is counted so as to be included in the block to be encoded.

[0120] At this time, the parameter prevK is set to K, and the parameter K is set to K + B. At this time, the parameter prevK is set to K, which means that the number (K) of blocks to be coded calculated up to the previous block file is stored in the parameter prevK.

[0121] In addition, the method for storing block chain transaction data according to one embodiment of the present invention determines whether the number (K) of blocks to be encoded is less than 2M+1 (M is the number of parity chunks) (S1040).

[0122] If the number (K) of blocks to be encoded included in the block file to be encoded is less than 2M+1, blocks of the next block file are added to the blocks to be encoded so that 2M+1 blocks are to be encoded, and the number (K) of blocks to be encoded approaches 2M+1 (S1045).

[0123] After step S1045 is performed, step S1020 is performed again.

[0124] If the number (K) of blocks to be encoded included in the block file to be encoded is greater than or equal to 2M+1, it is determined whether the number (K) of blocks to be encoded included in the block file to be encoded is equal to 2M+1 (S1050).

[0125] If it is determined in step S1050 that the number (K) of blocks to be encoded included in the block file to be encoded is equal to 2M+1, all of the K=2M+1 blocks to be encoded are selected as blocks to be encoded (S1055).

[0126] If it is determined in step S1050 that the number (K) of blocks to be encoded included in the block file to be encoded is not equal to 2M+1, then since K>2M+1, only the previous block file is set as the encoding block file target (S1060).

[0127] In this case, the encoding block file object may indicate one or more integer number of encoding files.

[0128] In this way, if only the previous block file is the target of encoding block files, the number of blocks to be encoded is less than 2M+1, so a block to be replicated (R) is selected to make up for the missing number of blocks (S1070).

[0129] At this time, the number of selected blocks to be replicated (R) may be 2M+1-K.

[0130] At this time, the blocks to be copied are selected from among the blocks included in the encoding block file based on their access frequency. For example, the blocks to be copied may be blocks selected in descending order of access frequency from among the blocks in the block file.

[0131] In this way, since the number of nodes that have a replicated block when a read request is made is increased compared to a non-replicated block, even if encoding is applied to the block, there is less access delay, and ultimately the increase in block access time is minimized.

[0132] In addition, the method for storing block chain transaction data according to an embodiment of the present invention replicates the selected blocks to be replicated so that the total number of encoding targets becomes 2M+1 (S1080).

[0133] When the number of blocks to be encoded is determined to be 2M+1 in step S1080 or step S1055, encoding is performed on the blocks to be encoded to generate encoded chunks including M parity chunks (S1090).

[0134] In this case, the blocks to be encoded do not all need to have the same size, and the blocks to be encoded are padded based on the maximum block size before generating the encoded chunks.

[0135] In addition, the method for storing blockchain transaction data according to one embodiment of the present invention maps 3M+1 chunks corresponding to the encoding results 1:1 to the entire 3M+1 blockchain nodes (S1095).

[0136] At this time, each blockchain node stores only the mapped chunks as is, and can store only the hash values ​​of other chunks.

[0137] Ultimately, the 2M+1 blocks to be encoded are encoded using the method shown in FIG. 10, generating a total of 3M+1 chunks including 2M+1 original blocks (chunks) and M parity chunks, and these 3M+1 chunks are assigned to N=3M+1 blockchain nodes.

[0138] FIG. 11 shows an example where encoding of blockchain transaction data is applied on a multi-block file basis.

[0139] Referring to FIG. 11, it can be seen that encoding is applied to two block files (BLOCK FILE10, BLOCK FILE11) among a plurality of block files (BLOCK FILE10, BLOCK FILE11, BLOCK FILE12, ...).

[0140] In FIG. 11, K indicates an original block, R indicates a replicated block, and M indicates a parity chunk.

[0141] In the example shown in Fig. 11, the number of blocks included in the block files to be encoded (BLOCK FILE10, BLOCK FILE11) is less than 2M+1, R copies are selected and copied, a total of 2M+1 blocks to be encoded are determined, and encoding is performed on the 2M+1 blocks to be encoded to generate M parity chunks. In this way, systematic encoding can be applied to preserve the original data (2M+1 data chunks) after encoding is performed.

[0142] The encoding results in 3M+1 encoded chunks, including a total of 2M+1 original data chunks and M parity chunks.

[0143] FIG. 12 is a flowchart illustrating a method for selecting a block file to be encoded according to an embodiment of the present invention.

[0144] The method for selecting a block file to be encoded according to one embodiment of the present invention is not applied immediately when a transaction, block or block file is generated, but can be applied at an appropriate timing taking into consideration the efficiency (E) of the total storage space in the blockchain system, the computational resources and storage space of the blockchain node, etc.

[0145] In addition, encoding is not applied to all blocks or block files, and a block file (or block) with a low access frequency is selected, and encoding can be performed on the selected block file (or block) only when the computational resource load (L) of the blockchain system is not high. Even if the computational resource load (L) of the blockchain system is high, if the efficiency of the overall storage space is greatly reduced, encoding can be performed (S1290) to secure storage space.

[0146] Referring to FIG. 12, the method for selecting a block file to be encoded according to an embodiment of the present invention calculates the efficiency (E) of the total storage space in the block chain system (S1210).

[0147] In addition, the method for selecting a block file to be encoded according to an embodiment of the present invention determines whether the calculated efficiency of the storage space is less than a preset comparison value (threshold_E) (S1220).

[0148] If it is determined in step S1220 that the efficiency of the storage space is not less than the preset comparison value, there is no need to secure storage space, and the operation is terminated.

[0149] If it is determined in step S1220 that the efficiency of the storage space is less than a preset comparison value, the block access frequency (B) is collected (S1230).

[0150] If the efficiency of the storage space is less than a preset comparison value, the block file access frequency (F) is calculated (S1240).

[0151] Furthermore, the method for selecting a block file to be encoded according to an embodiment of the present invention sorts the block files in order of access frequency using one or more of the block access frequency (B) and the block file access frequency (F) (S1250).

[0152] In addition, the method for selecting a block file to be encoded according to an embodiment of the present invention selects a low-frequency access block file using the sorted block files (S1260).

[0153] At this time, the low-access block file is selected based on whether the access frequency of the blocks included in the block file is less than a preset reference value (threshold_F).

[0154] In addition, the method for selecting a block file to be encoded according to an embodiment of the present invention calculates the computational resource load (L) of the blockchain system (S1270).

[0155] Furthermore, in the method for selecting a block file to be encoded according to an embodiment of the present invention, it is determined whether the calculated computation resource load (L) is smaller than a preset reference value (threshold_L) (S1280).

[0156] If it is determined in step S1280 that the load on the computational resources is less than the reference value (threshold_L), encoding is performed (S1290).

[0157] If it is determined in step S1280 that the load of the computational resources is not less than the threshold_L, the efficiency of the entire storage space is recalculated (S1285).

[0158] In addition, in the method for selecting a block file to be encoded according to one embodiment of the present invention, it is determined whether the calculated efficiency of the total storage space is less than a second reference value (threshold_S) (S1287), and only if the efficiency of the total storage space is less than the second reference value, proceeds to step S1290 to perform encoding, and if the efficiency of the total storage space is not less than the second reference value, the operation is terminated since the efficiency of the total storage space has not significantly decreased.

[0159] When the method for distributed storage of blockchain transaction data based on block file encoding according to one embodiment of the present invention is used, when access to a distributed stored block is required, the desired block can be provided via a node that holds the block as is, generally without the need for a decoding process.

[0160] As explained in Figure 9, all blockchain nodes have hash values ​​for unallocated blocks due to the encoding of blockchain transaction data based on block file encoding, so they can check whether blocks provided by other nodes can be operated. Depending on the block, a process of removing additionally stored padding parts may be required to make all blocks the same size.

[0161] FIG. 13 is an operational flowchart showing an example of a block access method according to an embodiment of the present invention.

[0162] Referring to FIG. 13, the block access method according to an embodiment of the present invention checks whether a corresponding node has a requested block (chunk) (S1310).

[0163] If the node holds the requested block as a result of the check in step S1310, it removes unnecessary padding from the stored block (S1320) and provides the requested block data to the requester (S1330).

[0164] If it is determined in step S1310 that the node does not hold the requested block, the node that holds the requested block is identified (S1311).

[0165] If a node that holds the requested block is identified, the node is requested to send the requested block (S1313), and after the block is transmitted (S1315), the hash value of the transmitted block is checked (S1317). That is, in step S1317, the hash value of the transmitted block is calculated, and the calculated hash value is compared with a previously stored hash value.

[0166] In addition, a block access method according to one embodiment of the present invention checks whether there is an abnormality in the hash value of the transmitted block, and if there is no abnormality, proceeds to step S1320, removes unnecessary padding, and provides the block data, and if there is an abnormality, performs a retry a preset number of times (S1319).

[0167] That is, in the block access method according to one embodiment of the present invention, if the hash value of a block provided from another node is not the same as the hash value held by a node, the block is provided again from another node that holds the block. If blocks are received from all holding nodes after several retries, but all hash values ​​calculated based on the blocks received from all nodes are abnormal, the operation is terminated, and block access can be started again after undergoing a decoding and re-encoding procedure described below.

[0168] FIG. 14 is a flowchart illustrating an example of a method for re-encoding a node that has found a block error according to an embodiment of the present invention.

[0169] Referring to FIG. 14, it can be seen that a decoding procedure is performed if a problem occurs in at least one of the encoded blocks (chunks) (storage node failure or Byzantine behavior execution).

[0170] That is, if a block error is found (S1410), all nodes are requested to perform re-encoding (S1420).

[0171] Of course, if no problem (storage node failure or Byzantine behavior) occurs with at least one of the encoded blocks (chunks), the process shown in Figure 13 allows the desired block to be read immediately without a decoding process.

[0172] However, if a data block is damaged, it may be necessary to restore the block through a re-encoding process.

[0173] FIG. 15 is a flowchart illustrating an example of a re-encoding method of a node that receives a re-encoding request according to an embodiment of the present invention.

[0174] Referring to FIG. 15, a blockchain node receives a re-encoding request (S1510).

[0175] The blockchain node that receives the re-encoding request performs re-encoding agreement (S1520), and if the agreement fails, terminates the operation.

[0176] If the agreement is successful, the blockchain node that received the re-encoding request receives unheld blocks (chunks) from the different nodes (S1540) and checks the hash value of the received block (S1550).

[0177] If there is no abnormality in the hash value, the blockchain node performs decoding (S1560) and re-encodes the data obtained by decoding to generate the encoded chunk again (S1570).

[0178] If a new node joins the blockchain network in addition to the existing blockchain nodes, the number of nodes (N) will be different, and therefore it may be impossible to guarantee BFT if the existing encoded chunks are stored. In the present invention, it is possible to encode block file-based blockchain transaction data using various encoding methods, and depending on the encoding method used, some encoding methods do not require re-encoding, while other encoding methods require the number of copies to be added to guarantee BFT. In some cases, it may be possible to guarantee BFT only by performing the re-encoding described in FIG. 15.

[0179] Conversely, if a node participating in the blockchain network leaves or fails, a problem may occur in which the blocks stored and managed by that node become inaccessible. Depending on the encoding method used and the blocks managed by the node, there are encoding methods that can still guarantee BFT in such cases, or BFT can be guaranteed only by duplicating related blocks or by performing re-encoding as described in Figure 15.

[0180] Figure 16 is a diagram showing replication of frequently accessed blockchain transaction data in a blockchain transaction data distributed storage system according to one embodiment of the present invention.

[0181] Referring to Figure 16, if the number of nodes does not change due to a change in workload from the blockchain network, but the frequently accessed blocks change, the number of replicas of the block can be increased to minimize the access delay to the block.

[0182] The configuration and operation method of the present invention described above can be utilized and applied not only to the BFT guarantee method for fault guarantee for up to 1 / 3 of participating nodes, but also to various guarantee levels with stronger or weaker availability guarantees.

[0183] In this way, when the block file-based encoding of the present invention is applied, the amount of data stored in each node in a blockchain system that stores large-scale blockchain transaction data can be reduced, improving the efficiency of storage space in the entire blockchain network, and storing and managing large-scale blockchain transaction data with fewer nodes.

[0184] In addition, the blockchain distributed storage technology using the block file-based encoding of the present invention is widely applicable to general forms of blockchain platforms that store and manage blockchain transaction data on a file system.

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

[0186] The blockchain transaction data storage device and nodes constituting the blockchain according to the embodiment can be realized in a computer system 1700 such as a computer-readable recording medium.

[0187] The computer system 1700 may include one or more processors 1710, memory 1730, user interface input devices 1740, user interface output devices 1750, and storage 1760, which communicate with each other via a bus 1720. The computer system 1700 may further include a network interface 1770 coupled to a network 1780. The processor 1710 may be a central processing unit or a semiconductor device that executes programs or processing instructions stored in the memory 1730 or storage 1760. The memory 1730 and storage 1760 may be storage media including at least one of a volatile medium, a non-volatile medium, a separate medium, a non-separate medium, a communication medium, or an information transmission medium. For example, the memory 1730 may include a ROM 1731 and a RAM 1732.

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

[0189] At this time, the processor 1710 may execute the program. At this time, the program may select at least one block file that stores blockchain transactions as an encoding block file target, generate encoded chunks including a parity chunk using the encoding block file target, and associate at least one of the encoded chunks with at least one of the blockchain nodes that stores at least one of the encoded chunks.

[0190] In this case, there are M parity chunks (M is a natural number), there are 3M+1 blockchain nodes, there are 3M+1 encoded chunks, and there is a 1:1 correspondence between the encoded chunks and the blockchain nodes.

[0191] In this case, each blockchain node can store the encoded chunk as is for a corresponding one of the encoded chunks, and store only the hash values ​​for at least some of the remaining chunks except for the one.

[0192] In this case, the program may determine whether the number of blocks included in the encoding block file object corresponds to 2M+1, and if the number of blocks included in the encoding block file object does not correspond to 2M+1, generate 2M+1 blocks to be encoded using the blocks included in the encoding block file object and duplicate blocks which are some of the blocks included in the encoding block file object. In this case, the encoded chunk is generated by performing encoding using the blocks to be encoded.

[0193] At this time, the duplicate block is selected from among the blocks included in the encoding block file target based on the access frequency.

[0194] In this case, the encoding block file object can include no more than 2M+1 blocks.

[0195] In this case, the blocks not exceeding 2M+1 do not all have the same size and are padded based on the maximum block size before generating the encoded chunk.

[0196] At this time, the encoding block file target is selected from the block files storing the block chain transactions, taking into consideration the access frequency of the block file or the blocks contained in the block file.

[0197] The hash value is then used to verify blocks read from other nodes.

[0198] At this time, 2M+1 or more of the encoded chunks are used for decoding to restore the current block.

[0199] As described above, the blockchain transaction data storage method, device, and blockchain transaction data distributed storage system 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 can be made. [Explanation of symbols]

[0200] 1700: Computer Systems 1710: Processor 1720: Bus 1730:Memory 1731:ROM 1732:RAM 1740: User interface input device 1750: User interface output device 1760:Storage 1770: Network interface 1780: Network

Claims

1. A blockchain transaction data storage method performed by a blockchain transaction data storage device, Selecting at least one block file that stores blockchain transactions as an encoding block file target; determining whether the number of blocks included in the encoding block file object is 2M+1 (M is a natural number); generating 2M+1 blocks to be encoded using the blocks included in the encoding block file target and duplicate blocks that are parts of the blocks included in the encoding block file target if the number of blocks included in the encoding block file target is not 2M+1; generating an encoded chunk including a parity chunk using the block to be encoded; mapping at least one of the encoded chunks to at least one of the blockchain nodes that stores at least one of the encoded chunks; Including, The number of the parity chunks is M, the number of the blockchain nodes is 3M+1, the number of the encoded chunks is 3M+1, and the encoded chunks are mapped to the blockchain nodes in a 1:1 correspondence; A method for storing blockchain transaction data, characterized in that each of the blockchain nodes stores the mapped chunks of the encoded chunks without any changes, and stores only hash values ​​for at least a portion of the remaining chunks excluding the mapped chunks.

2. The replication block is The method for storing block chain transaction data according to claim 1, characterized in that blocks are selected from among the blocks included in the encoding block file target based on access frequency.

3. The encoding block file object is:

2. The method for storing blockchain transaction data as claimed in claim 1, characterized in that it includes no more than 2M+1 blocks.

4. 4. The method for storing blockchain transaction data as claimed in claim 3, wherein the blocks not exceeding 2M+1 are not all the same size, and before generating the encoded chunk, padding is performed to make the blocks not exceeding 2M+1 have the same size based on a maximum block size.

5. The encoding block file object is: The method for storing blockchain transaction data according to claim 1, characterized in that from among the block files storing the blockchain transactions, a block file is selected based on the access frequency to the block file or the blocks contained in the block file.

6. The hash value is The method for storing blockchain transaction data according to claim 1, characterized in that it is used to verify blocks read from other nodes.

7. At least 2M+1 of the encoded chunks The method for storing blockchain transaction data according to claim 1, characterized in that it is used for decoding to restore the block to be encoded.

8. one or more processors; an execution memory for storing at least one program executed by the one or more processors; The at least one program is Selecting at least one block file that stores blockchain transactions as an encoding block file target; generating encoded chunks including a parity chunk using the encoding block file object; Mapping at least one of the encoded chunks to at least one of the blockchain nodes that stores at least one of the encoded chunks; The number of the parity chunks is M (M is a natural number), the number of the blockchain nodes is 3M+1, the number of the encoded chunks is 3M+1, and the encoded chunks are mapped to the blockchain nodes in a 1:1 correspondence; Each of the blockchain nodes stores the mapped chunks of the encoded chunks without modification, and stores only hash values ​​for at least a portion of the remaining chunks excluding the mapped chunks; the at least one program determines whether a number of blocks included in the encoding block file object is 2M+1; If the number of blocks included in the encoding block file target is not 2M+1, the at least one program generates 2M+1 blocks to be encoded using the blocks included in the encoding block file target and duplicate blocks that are part of the blocks included in the encoding block file target, A blockchain transaction data storage device, characterized in that the encoded chunk is generated by performing encoding using the block to be encoded.

9. The replication block is The block chain transaction data storage device of claim 8, characterized in that the blocks are selected from among the blocks included in the encoding block file target based on their access frequency.

10. The encoding block file object includes blocks that are not all the same size, The blockchain transaction data storage device of claim 8, wherein before generating the encoded chunks, padding is performed to make the blocks that are not all the same size the same size based on a maximum block size.

11. The encoding block file object is: The blockchain transaction data storage device according to claim 8, characterized in that from among the block files storing the blockchain transactions, a block file is selected based on the access frequency to the block file or the blocks contained in the block file.

12. The hash value is The blockchain transaction data storage device of claim 8, which is used to verify blocks read from other nodes.

13. At least 2M+1 of the encoded chunks The blockchain transaction data storage device according to claim 8, characterized in that it is used for decoding to restore the block to be encoded.

14. A first blockchain node that stores a first chunk of the encoded chunks as is and stores hash values ​​for the remaining chunks excluding the first chunk; a second block chain node that stores a second chunk different from the first chunk as is and stores hash values ​​for the remaining chunks excluding the second chunk; The encoded chunks are generated based on encoding performed using an encoding block file target selected from block files storing block files, the encoded chunks include a parity chunk; At least one of the encoded chunks is mapped to at least one blockchain node, including the first blockchain node and the second blockchain node; The number of the parity chunks is M (M is a natural number), the number of the blockchain nodes is 3M+1, the number of the encoded chunks is 3M+1, and the encoded chunks are mapped in a 1:1 correspondence to blockchain nodes including the first blockchain node and the second blockchain node; Each of the blockchain nodes stores the mapped chunks of the encoded chunks without modification, and stores only hash values ​​for at least a portion of the remaining chunks excluding the mapped chunks; if the number of blocks included in the encoding block file target is not 2M+1, 2M+1 blocks to be encoded are generated using the blocks included in the encoding block file target and duplicate blocks that are parts of the blocks included in the encoding block file target; A blockchain transaction data distributed storage system, characterized in that the encoded chunk is generated by performing encoding using the block to be encoded.

Images