KR20210047503A - Block chain data mapping method and node device using distributed file system to omit block sync process and to provide remote storage - Google Patents

Abstract

Disclosed are a block data mapping method utilizing a distributed file system for omitting a block synchronization process and providing a remote storage, and a node device. According to one embodiment of the present application, the block data mapping method utilizing a distributed file system comprises the steps of: (a) allowing a participating node of a blockchain network to form a part of the distributed file system by storing copies of a part of blockchain data included in the distributed file system in a local storage of the participating node, when the local storage of the participating node is determined to have a size capable of storing a part of blockchain data included in the distributed file system in addition to the blockchain data of the participating node; and (b) allowing the participating node to map at least a part of block data which is not mapped among the copies to a new node, when the participating node finds the new node to map at least a part of block data which is not mapped among the copies, wherein the new node owns at least a part of the block by a mapping method.

Description

Block data mapping method and node device using distributed file system to omit block synchronization process and provide remote storage {BLOCK CHAIN DATA MAPPING METHOD AND NODE DEVICE USING DISTRIBUTED FILE SYSTEM TO OMIT BLOCK SYNC PROCESS AND TO PROVIDE REMOTE STORAGE}

The present application relates to a block data mapping method and a node device using a distributed file system for omitting a block synchronization process and providing a remote storage.

After the advent of cryptocurrency, it guarantees data security and enables transparent management based on P2P distributed computing, and blockchain technology, which is evaluated as a core technology of the 4th industry, provides solid security for decentralized networks. Although it has been in the spotlight continuously, it is a situation where the temporal and spatial burdens placed on each node during the block synchronization process are large due to the nature that each node must store all of the blockchain data to participate in the network.

In this regard, a solution such as'Light Node' that stores only the block header without storing the entire block data has been introduced, but in this case, it leads to a small server of'Full Node' that stores all data, and blockchain technology There is a limit in that it can hinder the decentralization of the company.

In addition, due to the nature of blockchain technology that must store block data in the local storage of each node in order to participate in the network, the burden on the storage of each node increases as the block chain data grows. In addition, in a blockchain network where nodes participate in or withdraw from the network frequently, the block data synchronization process is a major cause of slowing the participation rate, and this problem can be particularly problematic in embedded systems such as drones with limited hardware performance. .

The technology behind the present application is disclosed in Korean Patent Publication No. 10-1950912.

The present application provides a block data mapping method and a node device capable of reducing the temporal and spatial burden required for block synchronization by omitting the block synchronization process when a new node participates in a block chain network, as to solve the above-described problems of the prior art. It is intended to be provided.

The present application is to solve the problems of the prior art described above, and the purpose of the present application is to provide a block data mapping method and a node device capable of providing remote storage to nodes with limited storage capacity such as drones and embedded systems through a distributed file system. do.

However, the technical problem to be achieved by the embodiments of the present application is not limited to the technical problems as described above, and other technical problems may exist.

As a technical means for achieving the above technical problem, the block data mapping method using a distributed file system according to an embodiment of the present application includes: (a) a node participating in the blockchain network, its own local storage, is its own blockchain. If it is determined that some of the block chain data included in the distributed file system can be stored in addition to the data, a copy of some of the block chain data included in the distributed file system is stored in its own local storage to be part of the distributed file system. And (b) when the participating node finds a new node to map at least a part of unmapped block data among the copies, mapping at least part of the unmapped block data among the copies to the new node. It may include steps.

In addition, by the step (b), the new node may own at least a part of the unmapped block data by a mapping method.

In addition, by the mapping method, the block synchronization process of the new node may be omitted.

In addition, the participating node may store the copy in its own local storage in the form of a stripe in step (a).

In addition, the participating node may be provided with an incentive corresponding to the size of the copy.

In addition, in step (b), when a discovery message for finding unmapped block data from a new node is received together with the public key of the new node, the participating node discloses the unmapped block data among the copies. It may include the step of mapping by transmitting the metadata signed with a key and temporarily stored to the new node.

In addition, only information on block data mapped to the new node may be opened to the new node by the signed public key and the metadata.

In addition, the block data mapping method using a distributed file system according to an embodiment of the present application includes: (c) When the participating node receives an withdrawal message for withdrawing from the blockchain network from the new node, it is mapped to the new node. The block data mapped to the new node may be converted into an unmapped state so that the block data can be mapped to another node.

In addition, the block data mapping method using a distributed file system according to an embodiment of the present application includes: (d) a copy completion message indicating that the participating node has finished copying the block data mapped to the new node to the local storage of the new node. When receiving from the new node, converting the block data mapped to the new node into an unmapped state so that the block data mapped to the new node can be mapped to another node.

On the other hand, the node device for mapping block data using a distributed file system according to an embodiment of the present application is capable of storing some of the block chain data included in the distributed file system in addition to the block chain data of the node device. If determined, a storage allocation unit that stores a copy of some of the block chain data included in the distributed file system in the local storage to form a part of the distributed file system, and maps at least a portion of unmapped block data among the copies. When a new node to be performed is found, a mapping unit for mapping at least a part of unmapped block data among the copies to the new node may be included.

In addition, by the mapping unit, the new node may own at least a part of the unmapped block data by a mapping method, and a block synchronization process of the new node may be omitted by the mapping method.

In addition, the storage allocator may store the copy in the local storage in a stripe form.

In addition, the node device may be provided with an incentive corresponding to the size of the copy.

In addition, the storage allocator temporarily stores metadata for the copy, and the mapping unit receives a discovery message for finding unmapped block data from a new node together with the public key of the new node, the copy Block data that is not mapped may be signed with the public key and then temporarily stored, and the metadata may be transmitted to the new node for mapping.

In addition, the node device for mapping block data utilizing a distributed file system according to an embodiment of the present application, when receiving an withdrawal message for withdrawing from the blockchain network from the new node, the block data mapped to the new node is different. A data management unit for converting block data mapped to the new node into an unmapped state so that it can be mapped to a node may be included.

In addition, when the data management unit receives a copy completion message from the new node indicating that the block data mapped to the new node has been copied to the local storage of the new node, the block data mapped to the new node is transferred to another node. Block data that has been mapped to the new node may be converted into an unmapped state so that it can be mapped.

In addition, the block data mapping method using a distributed file system according to an embodiment of the present application may be stored in a computer-readable recording medium in which a program for executing the method in a computer is recorded.

The above-described problem solving means are merely exemplary and should not be construed as limiting the present application. In addition to the above-described exemplary embodiments, additional embodiments may exist in the drawings and detailed description of the invention.

According to the above-described problem solving means of the present application, when a new node participates in a blockchain network, the block synchronization process can be omitted, thereby reducing the temporal and spatial burden required for block synchronization.

According to the above-described problem solving means of the present application, a remote storage can be provided to a node having a limited storage capacity, such as a drone or an embedded system, through a distributed file system.

According to the above-described problem solving means of the present application, since a block synchronization process is not required when participating in a block chain network, efficient scalability can be provided to a block chain network in which node participation and withdrawal is frequent.

According to the above-described problem solving means of the present application, storage of nodes that can occur as the size of the blockchain data continuously increases due to the increase in transaction occurrence and the number of participating nodes, without impeding the decentralization of the blockchain technology. The burden can be reduced.

However, the effect obtainable in the present application is not limited to the above-described effects, and other effects may exist.

1 is a conceptual diagram illustrating a block chain network including a node device for mapping block data using a distributed file system according to an embodiment of the present application.
2 is a conceptual diagram illustrating that a participating node distributes and stores copies of block chain data in a stripe form.
3 is a schematic configuration diagram of a node device for mapping block data using a distributed file system according to an embodiment of the present application.
4 is a flowchart illustrating an operation of a block data mapping method using a distributed file system according to an embodiment of the present application.
5 is a detailed operation flowchart showing each step of a method for mapping block data using a distributed file system according to an embodiment of the present application from the perspective of a participating node and a new node.

Hereinafter, embodiments of the present application will be described in detail with reference to the accompanying drawings so that those of ordinary skill in the art may easily implement the present application. However, the present application may be implemented in various different forms and is not limited to the embodiments described herein. In addition, in the drawings, parts irrelevant to the description are omitted in order to clearly describe the present application, and similar reference numerals are attached to similar parts throughout the specification.

Throughout the present specification, when a part is said to be "connected" with another part, it is not only the case that it is "directly connected", but also "electrically connected" or "indirectly connected" with another element interposed therebetween. "Including the case.

Throughout the present specification, when a member is positioned "on", "upper", "upper", "under", "lower", and "lower" of another member, this means that a member is located on another member. This includes not only the case where they are in contact but also the case where another member exists between the two members.

In the entire specification of the present application, when a certain part "includes" a certain component, it means that other components may be further included rather than excluding other components unless specifically stated to the contrary.

The present application relates to a block data mapping method using a distributed file system for omitting a block synchronization process and providing a remote storage, and a node device for mapping block data. In particular, the present application relates to a data management technique of copying and storing block chain data using a distributed file system, and mapping the stored data using a distributed file system to newly participating block chain nodes.

1 is a conceptual diagram illustrating a block chain network including a node device for mapping block data using a distributed file system according to an embodiment of the present application.

Referring to FIG. 1, the blockchain network 10 in the present application has one or more participating nodes 100 as participants, and a block chain on a distributed file system 20 that binds some storage of each participating node 100. It is implemented to make a copy of the data and map the copy made when the new node 200 participates to the new node 200 (Blockchain data mapping). In other words, the blockchain network 10 in the present application utilizes a distributed file system, so that a new node 20 that has owned some of the blockchain data (for example, block data) in a mapping method, without a separate synchronization process. It is designed to be able to participate in the blockchain network 10.

In addition, referring to FIG. 1, in one participating node 100, a blockchain client and a distributed file system (DFS) may be interlocked to operate.

For reference, in the description of the embodiment of the present application, the node device 100 for mapping block data utilizing a distributed file system according to an embodiment of the present application will be understood to be equivalent to the participating node 100, referring to FIG. I can. In other words, each of the plurality of participating nodes 100, which are participants of the block chain network 10, may operate as the node device 100 for mapping block data using the distributed file system in the present application. In addition, the node device 100 or the participating node 100 for block data mapping may be understood as a concept of a device included in the node itself or under the node. Hereinafter, for convenience of description, the node device 100 for mapping block data using a distributed file system will be unified and referred to as the'participating node 100'.

First, if the participating node 100 determines that its local storage is a size capable of storing some of the block chain data included in the distributed file system 20 in addition to its own block chain data 1 stored, the distributed file A part of the distributed file system 20 may be formed by storing a copy of some of the block chain data 1 included in the system 20 in its own local storage.

In other words, each participating node 100 may determine a local storage size (capacity) to be allocated to the distributed file system 20. In this case, each participating node 100 may be provided with an incentive corresponding to the size of a copy stored in its own local storage. In other words, the participating node 100 may be provided with an incentive corresponding to the local storage size (or the size of a copy to be stored) provided by itself to the distributed file system 20. As described above, in the present application, by providing an incentive for providing storage to the participating node 100, the distributed file system 20 may induce sufficient storage.

According to an embodiment of the present application, an incentive paid to the participating node 100 may be determined in a token format. Further, according to an exemplary embodiment of the present disclosure, the size of the incentive paid to the participating node 100 may be determined in proportion to the size of the local storage provided to the distributed file system 20, but is not limited thereto. As another example, in order to induce a large-sized local storage to be provided to the distributed file system 20, as the size of the provided local storage increases, the increase in incentives paid also increases (for example, in the form of an Exponential function). It can be implemented to be paid.

In addition, according to an embodiment of the present application, the participating node 100 may store a copy of some of the blockchain data 1 in its own local storage provided to the distributed file system 20 in a stripe form.

FIG. 2 is a conceptual diagram illustrating that a participating node distributes and stores copies of blockchain data in a stripe form. For reference, the block chain data (1) may mean that block data (2) generated according to a transaction occurring by a new transaction is connected in a chain form from the genesis block, which is the first block.

Referring to FIG. 2, the participating node 100 copies some of the block chain data 1 in the form of a stripe 3 in its own local storage (for example, storage allocated to the distributed file system 20). It may be to save. In other words, the block data 2 of the distributed file system 20 may be striped and stored in the form of a stripe 3 in the storage of each participating node 100. Unlike the conventional block chain network, which has formed a sequential block connection structure through hash values in units of blocks, in the present application, hash values for one block are determined by integrating hash values in units of stripes (3). In other words, a hash obtained by integrating the hashes of each of the stripes 3 constituting one block may be determined as the hash value of the corresponding block. In addition, after being distributed and stored in the storage of the participating node 100 in the form of stripes (3), the stripes (3) for the block data (2) mapped to the new node (200) are Since it is signed with a public key, the mapped block data (in other words, stripes 3 for the mapped block data) can be used only when the mapped new node 200 has a symmetric private key.

According to the exemplary embodiment of the present disclosure, the stripe 3 may be understood as a data unit obtained by dividing block data into small data units. For example, the stripe 3 may be referred to differently as segmented data, segment, or the like. In the present application, as the block data divided in the form of a stripe (3) is distributed and stored, not only the storage load applied to one participating node 100 is reduced, but also when the new node 200 accesses the mapped block data. , It can enable high-speed data access.

Hereinafter, a process in which the participating node 100 maps at least a portion of unmapped block data among copies to the new node 200 will be described in detail.

When the participating node 100 finds a new node 200 to map at least a part of the unmapped block data 2b among the copies, at least a part of the unmapped block data 2b among the copies Can be mapped. According to an embodiment of the present application, the block data 2 is mapped block data 2a in a state already mapped to the participating node 100 or the new node 200, referring to FIG. 1,'already mapped' Block data ) And unmapped block data (2b, referring to FIG. 1,'non-mapped' block data) in a state that is not mapped to a specific node. According to an embodiment of the present application, the participating node 100 is not mapped to another node among block data (specifically, a copy of some of the block chain data) existing on the distributed file system 20. At least a part of the unused block data 2b may be mapped to the new node 200. For reference, the mapping state (already mapped state or non-mapped state) of each of the block data 2 may be switched by the participating node 100.

At this time, the participating node 100 maps and transmits at least a portion of the unmapped block data 2b among the copies to the new node 200 that intends to newly participate in the block chain network 10, so that the new node 200 It may be understood that at least a part of the unmapped block data 2b is owned by a mapping method. Further, by the mapping method, a block synchronization process for the blockchain network 10 of the new node 200 may be omitted.

In addition, since the new nodes 200 participating in the blockchain network 10 of the present application can retain the block data stored in the distributed file system 20 in a mapping method, they have a storage capacity to store all blockchain data. Even if it does not exist, it will be possible to participate in the blockchain network 10 of the present application. In other words, the blockchain network 10 of the present application may allow the participation of nodes having a smaller capacity than the conventional blockchain network through a mapping method.

In addition, according to an embodiment of the present application, when the participating node 100 stores a copy in its own local storage (in other words, storage allocated to the distributed file system 20), the metadata for the copy is temporarily stored. I can.

In addition, according to an embodiment of the present application, when the participating node 100 receives a discover message for finding unmapped block data 2b from the new node 200 together with the public key of the new node 200, Mapping may be performed by the participating node 100 signing with the public key received in the unmapped block data 2b among the copies and transmitting metadata about the temporarily stored copy to the new node 200.

According to this mapping method, only information about the block data mapped to the new node 200 may be opened to the new node 200 newly participating in the blockchain network 10 by the signed public key and metadata. have. In other words, since the block data mapped to one new node 200 is signed with the node ID and the public key of the new node 200, the mapped block data is used through the private key held by only the new node 200. You will be able to.

In addition, unlike the existing distributed file system, the distributed file system 20 herein does not have a separate management server or a metadata server. The new node 200 directly stores only the information of the participating nodes 200 that are storing the block data mapped to itself in the form of a stripe 3 in the local storage as metadata. That is, the storage of the participating node 100 that is not related to the new node 200's own data (that is, does not store the stripes 3 for the block data 2 mapped to the new node 200) It is not visible from the perspective of the new node 200. In other words, the new node 200 cannot access the storage of the participating node 100 that stores only block data that is not related to the block data mapped to it.

According to an embodiment of the present application, the new node 200 may operate as a metadata server for a distributed file system instance through metadata transmitted from the participating node 100. That is, since the new node 200 directly stores the metadata for the participating nodes 100 that store the block data mapped to it and acts like a metadata server, in the present application, even without a centralized management server. It is possible to operate the distributed file system 20 that is decentralized and separated for each instance.

In addition, according to an embodiment of the present application, when the participating node 100 receives the withdrawal message to withdraw from the blockchain network from the new node 200, the block data mapped to the new node 200 is mapped to another node. Block data that has been mapped to the new node 200 may be converted to an unmapped state so that it can be performed.

In other words, when a node withdraws from a certain node, the node (new node 200) that wants to withdraw transmits a withdrawal message to the participating nodes 100 that were storing the mapped block data, and The stripes 3 that were being stored in the storage (specifically, the storage allocated to the distributed file system 20 by the participating nodes 100) become block data 2b in an unmapped state (non-mapped state), After that, it is converted to a state that can be mapped to a new node 200.

In addition, according to an embodiment of the present application, the participating node 100 transmits a copy completion message indicating that the block data mapped to the new node 200 has been copied to the local storage of the new node 200. When received from, block data mapped to the new node 200 may be converted into an unmapped state so that block data mapped to the new node 200 can be mapped to another node.

In other words, after a predetermined new node 200 participates in the blockchain network 10, the storage of the new node 200 is sufficient, so that the block chain data (1) is stored in its own local storage rather than the distributed file system 20. ), while the new node 200 synchronizes the blockchain data to the local storage, it joins the blockchain network 10 using the copy above the distributed file system 20, and the synchronization is completed. When this happens, the copy is unmapped and converted to a state where it can be mapped to another node.

That is, a node with sufficient local storage (new node 200) can copy (synchronize) the blockchain data mapped to itself to its own local storage through the distributed file system 20, and the mapped You can own and use the data. When the copying is complete, the copy completion message is transmitted to the participating nodes 100 that have been storing the mapped block data, and the block data becomes unmapped (non-mapped state) as with withdrawal, and thereafter, other nodes (For example, it may be mapped to a new node 200). In the case of nodes with sufficient local storage, incentives (e.g., by storing blockchain data directly in their local storage in this way) and allocating a larger amount of storage to the distributed file system (20) linked to the blockchain. For example, in the form of a token).

As a result, the present application can bring about the effect of giving more remote storage to nodes in environments with limited hardware capabilities, such as drones and embedded systems. That is, by mapping the block chain data copied in advance through the distributed file system 20 to the new node 200, the temporal overhead that occurs when the new node 200 participates in the blockchain network is eliminated, and incentives in the form of tokens Through the provision, sufficient storage can be secured in the distributed file system 20, so that a remote storage of sufficient size can be provided to devices (nodes) with limited hardware performance, such as drones and embedded systems, which lack local storage.

3 is a schematic configuration diagram of a node device for mapping block data using a distributed file system according to an embodiment of the present application.

Referring to FIG. 3, a node device 100 (in other words, a participating node 100) for mapping block data utilizing a distributed file system is a storage allocation unit 110, a mapping unit 120, and a data management unit 130. It may include.

When it is determined that the size of the local storage is capable of storing some of the block chain data included in the distributed file system 20 in addition to the block chain data of the node device 100, the distributed file system 20 A copy of some of the block chain data included in is stored in a local storage so that at least a part of the storage of the node device 100 forms part of the distributed file system 20.

Specifically, the storage allocator 110 may store a copy in the form of a stripe 3 in local storage. In addition, the node device 100 may be provided with an incentive corresponding to the size of the copy.

In addition, the storage allocator 110 may temporarily store metadata about the copy when storing the copy.

When the mapping unit 120 finds a new node 200 to map at least a portion of the unmapped block data 2b among the copies, the mapping unit 120 detects at least a portion of the unmapped block data 2b among the copies. Some can be mapped.

Therefore, by the mapping unit 120, the new node 200 owns at least a part of the unmapped block data 2b by the mapping method, and the block synchronization process of the new node 200 by the mapping method May be omitted.

Specifically, when the mapping unit 120 receives a discovery message for finding unmapped block data from the new node 200 together with the public key of the new node 200, the unmapped block data 2b ) And transmits metadata temporarily stored by the storage allocator 110 to the new node 200 to perform mapping.

When the data management unit 130 receives the withdrawal message for withdrawing from the blockchain network 10 from the new node 200, the new node ( 200) may be converted to an unmapped state.

In addition, the data management unit 130 receives a copy completion message from the new node 200 indicating that the block data mapped to the new node 200 has been copied to the local storage of the new node 200. Block data mapped to the new node 200 may be converted into an unmapped state so that block data mapped to) can be mapped to another node.

Hereinafter, based on the details described above, the operation flow of the present application will be briefly described.

4 is a flowchart illustrating an operation of a block data mapping method using a distributed file system according to an embodiment of the present application.

The method for mapping block data using a distributed file system illustrated in FIG. 4 may be performed by the node device 100 for the method for mapping block data using a distributed file system described above. Accordingly, even if omitted below, the description of the node device 100 for the method of mapping block data using the distributed file system may be equally applied to the description of the method of mapping block data using the distributed file system.

4, in step S410, the storage allocating unit 110, (a) the local storage of the node device 100 stores some of the block chain data included in the distributed file system 20 in addition to its own block chain data. If it is determined that the size is storable, a copy of some of the block chain data included in the distributed file system 20 may be stored in its own local storage to form a part of the distributed file system 20.

In addition, in step S410 (in other words, in step (a)), the storage allocating unit 110 may temporarily store metadata for the copy.

Next, in step S420, when the mapping unit 120 finds a new node 200 to map at least a part of the unmapped block data among the copies, the At least part of the data 2b may be mapped.

Specifically, in step S420 (in other words, in step (b)), the mapping unit sends a discovery message for finding unmapped block data 2b from the new node 200 together with the public key of the new node 200. Upon receipt, the unmapped block data 2b among the copies may be signed with the received public key, and the metadata temporarily stored in step S410 may be transmitted to the new node 200.

Next, in step S430, the data management unit 130, when (c) receiving the withdrawal message for withdrawing from the blockchain network 10 from the new node 200, the block data mapped to the new node 200 is a different node. Block data that has been mapped to the new node 200 may be converted to an unmapped state so that the data can be mapped to a new node 200.

In addition, in step S440, the data management unit 130 receives a copy completion message from the new node 200 indicating that (d) the block data mapped to the new node 200 has been copied to the local storage of the new node 200. Then, block data mapped to the new node 200 may be converted into an unmapped state so that block data mapped to the new node 200 may be mapped to another node.

In the above description, steps S410 to S440 may be further divided into additional steps or may be combined into fewer steps, according to an embodiment of the present disclosure. In addition, some steps may be omitted as necessary, or the order between steps may be changed.

5 is a detailed operation flowchart showing each step of a method for mapping block data using a distributed file system according to an embodiment of the present application from the perspective of a participating node and a new node.

Referring to FIG. 5, steps S511 to S517 are performed by the participating node 100 as a subject, and steps S521 to S524 may represent steps performed by the new node 200 as a subject, respectively.

In step S511, it may be determined whether a copy of the blockchain data is stored in the storage of the participating node 100. As a result of the determination in step S511, if the participating node 100 does not store a copy of the blockchain data (No), the process proceeds to step S513 and subsequent steps S514, S515, and the like may be performed. Conversely, if the participating node 100 already stores a copy of the blockchain data (Yes), the process proceeds to step S512, and in step S512, the participating node 100 performs steps S513, S514, and S515. Without doing so, it will remain in its current state.

Next, in step S513, the size of the current block chain data size S may be considered in order to determine whether to perform subsequent steps S514, S515, etc. through the participating node 100. Here, the size (S) of the block chain data may mean the size of local storage that the participating node 100 will allocate to the distributed file system.

In step S513, when the size (S) of the current block chain data satisfies the relational expression of S/10≥2, the process may proceed to step S514. Conversely, if the size (S) of the current block chain data satisfies the relational expression of S/10 <2, the process proceeds to step S512 and the participating node 100 maintains the current state without performing steps S514, S515, etc. do.

According to an embodiment of the present application, the size (S) of the current blockchain data may be measured in GB (gigabytes), but is not limited thereto. In addition, the specific numerical range of the formula applied to step S513 may be variously modified based on the number of participating nodes in the blockchain network 10 of the present application, the type of blockchain data, and the like.

Next, in step S514, when it is determined that the size (S) of the current blockchain data is larger than a predetermined level (for example, a level that satisfies the relational expression of S/10≥2), the participating node 100 Blocks a message to find (S/10-1) nodes in order to search for nodes to create copies of data and to distribute and store the generated copies in local storage (in other words, to build distributed file system 20). It can propagate within the chain network 10.

According to an embodiment of the present application, the number of nodes that the participating node 100 searches in step S514 is based on at least one of the number of participating nodes of the blockchain network 10 of the present application and the data type of the blockchain data ( It can be determined by a number other than S/10-1).

More specifically, the participating node 100 that propagates a message for node discovery in step S514 is a participating node that does not have a copy of the blockchain data (eg, a stripe of copy) by the preceding step S511. Since it is determined as (100), the participating node 100, which is storing a copy of the blockchain data (including both already mapped and non-mapped copies), does not propagate the message and does not propagate the message in the existing state. While maintaining, when receiving a message for creating a copy, it participates in the creation of a copy together with the participating node 100, which further propagated the message.

Next, in step S515, the participating node 100 that has propagated the message is searched for other participating nodes 100 (for example, (S/10-1) participating nodes 100) and themselves (ie, A distributed file system instance can be created including the participating node 100 that propagated the message, and a copy of the blockchain data can be created and stored. Here, the participating node 100 may temporarily store metadata about the copy. In other words, the S/10 participating nodes 100 including the participating nodes 100 that have started propagation in step S515 are connected to each other to create one distributed file system instance to create and distribute a copy of the block chain data, Metadata for this may be implemented to temporarily store the participating node 100 that has started message propagation.

Next, in step S516, the participating node 100 that has stored the metadata for the copy, when a new node 200 attempting to participate in the blockchain network 10 exists (in other words, the participating node ( 100) receives a discovery message (discover) to find unmapped block data (block data in a non-mapped state; 2b) from the new node 200), new to unmapped block data (copy) After signing with the public key transmitted from the node 200, metadata that has been temporarily stored may be transferred to the new node 200.

Through this, the new node 200 directly holds the information on the participating node 100, which stores the stripe 3 of the block data mapped to it, as metadata, and stores the block chain data in local storage. As if there is, it is possible to participate in the blockchain network 10 without the block synchronization process.

In addition, in step S517, when the new node 200 attempts to withdraw from the blockchain network 10 or when the block data to which the new node 200 has been mapped has been copied to its own local storage, from the new node 200 Upon receiving the return message indicating that the mapped block data and the metadata associated with the mapped block data are returned to the new node 200, the participating node 100 completes the return of the corresponding metadata and sends the message to the new node 200. Block data that has been mapped can be converted to a non-mapped state.

That is, the block data converted to the non-mapped state in step S517 is discovered when another new node 200 attempts to participate in the blockchain network 10 (in other words, discovers from another new node 200). When a message is transmitted), it may be mapped to the corresponding new node 200.

The above-described mapping process will be described from the perspective of the new node 200 as follows.

In step S521, the new node 200 may propagate a discover message for finding the non-mapped block data 2b together with its public key to the blockchain network 10.

Next, in step S522, the new node 200 receives the mapped block data and metadata for the mapped block data signed with its own public key transmitted from the participating node 200 in response to the spread discovery message. can do.

Next, in step S523, the new node 200 holds blockchain data (in other words, mapped block data) distributedly stored through the distributed file system 20, so that it is possible to participate in the blockchain network 10. do. In other words, the new node 200 may function as a metadata server for a distributed file system instance through the transmitted metadata.

In addition, in step S524, the new node 200 to withdraw from the blockchain network 10 or the new node 200 that has completed copying the mapped block data to its own local storage is the block data mapped to the participating node 100. And a return message indicating that meta data associated with the mapped block data will be returned.

In the above description, steps S511 to S517 and steps S521 to S524 may be further divided into additional steps or may be combined into fewer steps, according to an embodiment of the present invention. In addition, some steps may be omitted as necessary, or the order between steps may be changed.

The block data mapping method using a distributed file system according to an exemplary embodiment of the present disclosure may be implemented in the form of program instructions that can be executed through various computer means and recorded in a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, and the like alone or in combination. The program instructions recorded on the medium may be specially designed and configured for the present application, or may be known and usable to a person skilled in the art of computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs and DVDs, and magnetic media such as floptical disks. -A hardware device specially configured to store and execute program instructions such as magneto-optical media, and ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine language codes such as those produced by a compiler, but also high-level language codes that can be executed by a computer using an interpreter or the like. The hardware device described above may be configured to operate as one or more software modules to perform the operations of the present application, and vice versa.

In addition, the above-described method of mapping block data utilizing a distributed file system may be implemented in the form of a computer program or application executed by a computer stored in a recording medium.

The foregoing description of the present application is for illustrative purposes only, and those of ordinary skill in the art to which the present application pertains will be able to understand that it can be easily modified into other specific forms without changing the technical spirit or essential features of the present application. Therefore, it should be understood that the embodiments described above are illustrative and non-limiting in all respects. For example, each component described as a single type may be implemented in a distributed manner, and similarly, components described as being distributed may also be implemented in a combined form.

The scope of the present application is indicated by the claims to be described later rather than the detailed description, and all changes or modified forms derived from the meaning and scope of the claims and their equivalent concepts should be construed as being included in the scope of the present application.

10: Blockchain network
20: distributed file system
100: Node device for block data mapping using distributed file system, participating node
110: storage allocation unit
120: mapping unit
130: data management unit
200: new node
1: Blockchain data
2: block data
2a: mapped block data
2b: unmapped block data
3: stripe

Claims (16)

As a block data mapping method in a blockchain network,
(a) If the participating node of the blockchain network determines that its local storage is a size capable of storing some of the block chain data included in the distributed file system in addition to its own block chain data, Storing a copy of some of the blockchain data in its own local storage to form a part of the distributed file system; And
(b) when the participating node finds a new node to map at least part of the unmapped block data among the copies, mapping at least part of the unmapped block data among the copies to the new node, and ,
By the step (b), the new node owns at least a part of the unmapped block data by a mapping method. The method of claim 1,
By the mapping method, the block synchronization process of the new node is omitted. The method of claim 1,
The participating node,
In the step (a), the copy is stored in its own local storage in a stripe form. The method of claim 1,
The participating node is provided with an incentive corresponding to the size of the copy, block data mapping method using a distributed file system. The method of claim 1,
In the step (a), the participating node temporarily stores metadata for the copy,
The step (b),
When a discovery message for finding unmapped block data from a new node is received together with the public key of the new node, the participating node signs the unmapped block data among the copies with the public key and temporarily stores the metadata The method comprising the step of mapping by transmitting to the new node, distributed file system utilization block data mapping method. The method of claim 5,
The method for mapping block data using a distributed file system, wherein only information on block data mapped to the new node is opened to the new node by the signed public key and the metadata. The method of claim 1,
(c) When the participating node receives the withdrawal message for withdrawing from the blockchain network from the new node, block data mapped to the new node is stored so that the block data mapped to the new node can be mapped to another node. Block data mapping method utilizing a distributed file system further comprising the step of converting to an unmapped state. The method of claim 1,
(d) When the participating node receives a copy completion message from the new node indicating that the block data mapped to the new node has been copied to the local storage of the new node, the block data mapped to the new node is a different node. The block data mapping method using a distributed file system, further comprising converting the block data mapped to the new node into an unmapped state so that the data can be mapped to the new node. As a node device for mapping block data in a blockchain network,
If the size of the local storage is determined to be capable of storing some of the block chain data included in the distributed file system other than the block chain data of the node device, a copy of some of the block chain data included in the distributed file system is stored in the local storage. A storage allocator configured to store and form a part of the distributed file system; And
Block data mapping utilizing a distributed file system, including a mapping unit for mapping at least a part of unmapped block data among the copies to the new node when a new node to which at least part of unmapped block data is to be mapped is found among the copies. Node device for The method of claim 9,
By the mapping unit, the new node owns at least a part of the unmapped block data by a mapping method,
A node device for mapping block data utilizing a distributed file system, characterized in that the block synchronization process of the new node is omitted by the mapping method. The method of claim 9,
The storage allocating unit stores the copy in the local storage in a stripe form, a node device for mapping block data utilizing a distributed file system. The method of claim 9,
The node device is to be provided with an incentive corresponding to the size of the copy, the node device for mapping block data utilizing a distributed file system. The method of claim 9,
The storage allocating unit temporarily stores metadata for the copy,
The mapping unit, when receiving a discovery message for finding unmapped block data from a new node together with the public key of the new node, signs the unmapped block data among the copies with the public key and temporarily stores the metadata. The node device for mapping block data using a distributed file system to transmit and map the data to the new node. The method of claim 9,
Upon receiving the withdrawal message from the new node to withdraw from the blockchain network, the block data mapped to the new node is converted into an unmapped state so that the block data mapped to the new node can be mapped to another node. The node device for mapping block data utilizing a distributed file system, further comprising a data management unit. The method of claim 14,
When the data management unit receives a copy completion message from the new node indicating that the block data mapped to the new node has been copied to the local storage of the new node, the block data mapped to the new node is mapped to another node. A node device for mapping block data using a distributed file system to convert the block data mapped to the new node into an unmapped state so that the node can be mapped. A computer-readable recording medium storing a program for executing the method of claim 1 on a computer.

Images