Node, distributed ledger system, distributed ledger transfer method, and distributed ledger transfer program

Abstract

To provide a node that can maintain the number of nodes and continuity of transactions even when a specification change occurs in a distributed ledger program that causes inconsistencies in consensus formation.SOLUTION: Provided is a node for a first distributed ledger system that manages a first distributed ledger, comprising: a control unit for, together with some other nodes of the first distributed ledger system, generating a second distributed ledger and registering contents of a plurality of blocks included in the first distributed ledger as blocks of the second distributed ledger by performing consensus formation in order from the lowest block height; and a communication unit for, after the contents of all blocks included in the first distributed ledger have been registered in the second distributed ledger, synchronizing the blocks registered in the second distributed ledger with the remaining other nodes of the first distributed ledger system.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a node, a distributed ledger system, a distributed ledger transfer method, and a distributed ledger transfer program. [Background technology]

[0002] In recent years, blockchain, a type of distributed ledger technology, has been utilized in a variety of fields. Blockchain generates units of data called blocks, and creates a distributed ledger in which blocks are linked together like a chain by configuring the next block to include the hash value of each block. In such a distributed ledger, new blocks are registered through consensus among multiple nodes and are stored and managed by each node, making it difficult to tamper with data and ensuring transparency of transactions.

[0003] Patent Document 1 discloses a transaction recording system that can reduce the amount of data held by each node and can solve or alleviate the problem of node capacity shortage caused by an bloated transaction history. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2018-67108 Summary of the Invention [Problem to be solved by the invention]

[0005] In the operation of distributed ledgers such as blockchains, large-scale specification changes, such as changes to the consensus algorithm, may be made, for example, to resolve security risks. In such specification changes, if the consensus formation after the specification change is incompatible with the consensus formation before the specification change, consistency in consensus formation will be lost, and a new distributed ledger that is different from the distributed ledger before the specification change (hereinafter referred to as the "old distributed ledger") will be created separately (a hard fork).

[0006] When a new distributed ledger is created in this way, some nodes will switch from the old distributed ledger to the new one, but it is also possible that some nodes will continue to use the old distributed ledger, which will result in a decrease in the number of nodes participating in each distributed ledger. Furthermore, since consistency in consensus building will no longer be achieved, it is possible that transaction continuity will be lost between the old and new distributed ledgers. This decrease in the number of nodes participating in the distributed ledger and loss of transaction continuity could lead to a decline in the value of assets recorded in the distributed ledger and a decline in the credibility of the distributed ledger itself.

[0007] The present invention has been made in consideration of the above circumstances, and aims to provide a node, a distributed ledger system, a distributed ledger transfer method, and a distributed ledger transfer program that can maintain the number of nodes and the continuity of transactions even if a specification change occurs in the distributed ledger program that causes consistency in consensus building. [Means for solving the problem]

[0008] The node of the present disclosure is a node of a first distributed ledger system that manages a first distributed ledger, and is equipped with: a control unit that generates a second distributed ledger together with some other nodes in the first distributed ledger system, and that reaches consensus on and registers the contents of multiple blocks included in the first distributed ledger as blocks of the second distributed ledger, in order of decreasing block height; and a communication unit that synchronizes the blocks registered in the second distributed ledger with some other remaining nodes in the first distributed ledger system after the contents of all blocks included in the first distributed ledger have been registered in the second distributed ledger.

[0009] The node of the present disclosure is a node that includes a control unit that stops proposing new blocks in a first distributed ledger, and a communication unit that synchronizes the second distributed ledger stored in the transfer node after the contents of all blocks included in the first distributed ledger are registered in the second distributed ledger by the transfer node.

[0010] The distributed ledger system disclosed herein comprises a first distributed ledger system that manages a first distributed ledger, and a second distributed ledger system that manages a second distributed ledger generated by multiple transfer nodes selected from multiple nodes in the first distributed ledger system, wherein the multiple transfer nodes reach consensus and register the contents of multiple blocks included in the first distributed ledger as blocks in the second distributed ledger, in order from lowest to highest block height, and after the contents of all blocks included in the first distributed ledger have been registered in the second distributed ledger, non-transfer nodes among the nodes in the first distributed ledger system other than the transfer node synchronize the second distributed ledger stored on the transfer node.

[0011] The distributed ledger transfer method disclosed herein is a distributed ledger transfer method in which a node selected from multiple nodes in a first distributed ledger system that manages a first distributed ledger generates a second distributed ledger, reaches consensus on the contents of multiple blocks included in the first distributed ledger, registers the contents of the blocks included in the first distributed ledger as blocks of the second distributed ledger, in ascending order of block height, and, after the contents of all blocks included in the first distributed ledger have been registered in the second distributed ledger, synchronizes the blocks registered in the second distributed ledger with a remaining portion of the nodes in the first distributed ledger system.

[0012] The distributed ledger transfer program disclosed herein is a distributed ledger transfer program that causes a computer to execute the following steps: selecting from multiple nodes in a first distributed ledger system that manages a first distributed ledger; generating a second distributed ledger and registering the contents of multiple blocks included in the first distributed ledger as blocks of the second distributed ledger through consensus building, in order of decreasing block height; and, after the contents of all blocks included in the first distributed ledger have been registered in the second distributed ledger, synchronizing the blocks registered in the second distributed ledger with a remaining portion of the nodes in the first distributed ledger system. [Effects of the Invention]

[0013] The nodes, distributed ledger system, distributed ledger transfer method, and distributed ledger transfer program disclosed herein can maintain the number of nodes and the continuity of transactions even if a specification change occurs in the distributed ledger program that causes inconsistency in consensus building. [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 1 is a diagram illustrating a configuration example of a distributed ledger system according to an embodiment of the present disclosure. [Figure 2] FIG. 2 is a diagram illustrating an example of a hardware configuration of a node. [Figure 3] This is a sequence diagram showing the processing of the transfer node in the transfer process to transfer from the first distributed ledger system to the second distributed ledger system. [Figure 4] FIG. 10 is a schematic diagram illustrating changes in the distributed ledger stored in each node during the transfer process. DETAILED DESCRIPTION OF THE INVENTION

[0015] A node, a method, a program, and a distributed ledger system according to the present disclosure will be described with reference to the drawings. In the description, similar elements are designated by the same reference numerals, and duplicate descriptions will be omitted as appropriate.

[0016] Figure 1 is a diagram illustrating an example configuration of a distributed ledger system 1 according to an embodiment of the present disclosure. As shown in Figure 1, the distributed ledger system 1 includes nodes 2A-2E and a communication network 3. The nodes 2A-2E are each configured as so-called information processing devices, and in this embodiment, when referring to matters common to the nodes 2A-2E or matters that do not specify any of the nodes 2A-2E, the nodes 2A-2E may be referred to simply as nodes 2 without distinction.

[0017] FIG. 2 illustrates an example of the hardware configuration of node 2. As illustrated in this figure, node 2 includes a control unit 21, a communication unit 22, and a storage unit 23. It can be a so-called information processing device, primarily composed of electronic circuits using semiconductor circuit elements. For example, the control unit 21 primarily includes a central processing unit (CPU) and a volatile storage unit such as a random access memory (RAM). The communication unit 22 connects to the communication network 3 for communication. The storage unit 23 primarily includes a nonvolatile storage unit such as a flash memory or a hard disk, and stores data and programs. The control unit 21, communication unit 22, and storage unit 23 may each include a CPU, a volatile storage unit, and a nonvolatile storage unit. Information processing, including communication, performed by the control unit 21 can be realized by the hardware illustrated in FIG. 2 operating in conjunction with the programs and data stored in the storage unit 23. The storage unit 23 of each node 2 in the distributed ledger system 1 stores programs for configuring the distributed ledger system 1.

[0018] Returning to Fig. 1, the communication network 3 can be a communication network using a public communication network such as the Internet, a local communication network, or the like. Each of the nodes 2A to 2E is capable of one-to-one confidential communication, such as that referred to in peer-to-peer communication (P2P). Here, in Fig. 1, the number of nodes 2 is five, i.e., nodes 2A to 2E, but the number of nodes 2 can be any number as long as it is plural.

[0019] Here, the distributed ledger system 1 can be, for example, a blockchain. In a distributed ledger system 1, a centralized distributed ledger is typically constructed and managed by multiple participating nodes 2. Data is stored in small units called blocks, linked to the previous block by a hash value, and each block is stored by multiple nodes 2, making data tampering difficult and ensuring security and reliability. Each block can also contain information such as transaction information, such as asset transactions between nodes. Adding transaction information requires consensus building in the distributed ledger system 1. Rules that apply to consensus building include signatures by all nodes 2 participating in the distributed ledger system 1, signatures by 51% of nodes 2, or signatures by more than two-thirds of nodes 2. Here, all nodes may be full nodes or validator nodes, as described below.

[0020] Furthermore, the nodes 2 in Figure 1 may all have the same role, or may include nodes 2 with different roles. Different roles may be, for example, seed nodes, full nodes, validator nodes, light client nodes, and client nodes. Here, a seed node is a node that manages the nodes to which the distributed ledger belongs and their roles. A full node is a node that holds the entire distributed ledger and verifies individual blocks. A validator node is a node that holds the entire distributed ledger and generates, verifies, and signs blocks. A light client node is a node that holds a portion of the distributed ledger and references the distributed ledger and checks its status. A client node is a node that operates accounts that store data on the distributed ledger.

[0021] Each block in the distributed ledger may consist of a block header, a transaction data section, and a signature section, where the block header may include the accumulator of the previous block, the accumulator of the transaction data section, a distributed ledger chain identifier, a distributed ledger number, a timestamp, and a public key associated with the distributed ledger.

[0022] FIG. 3 is a sequence diagram showing the processing of the transfer node 26 in the distributed ledger transfer process S100, which transfers data from a first distributed ledger system 11 having the configuration as the distributed ledger system 1 described above to a second distributed ledger system 12 having the configuration as the distributed ledger system 1 described above. FIG. 4 is a schematic diagram illustrating changes to the distributed ledger stored in each node in the distributed ledger transfer process S100. Step S101 in FIG. 4 shows the first distributed ledger system 11 consisting of node 25A, which stores the first distributed ledger. The subscript A of node 25A indicates that node 25 stores the first distributed ledger (or participates in the first distributed ledger). Note that the subscript B, which will be described later, indicates that node 25 stores both the first and second distributed ledgers (or participates in both the first and second distributed ledgers), and the subscript C indicates that node 25 stores the second distributed ledger (or participates in the second distributed ledger). Here, for example, the consensus algorithm of the first distributed ledger system 11, which is the source of the transfer, may be PoW (Proof of Work), and the consensus algorithm of the second distributed ledger system 12, which is the destination of the transfer, may be PoS (Proof of Stake), or vice versa.

[0023] The distributed ledger transfer process S100 in the transfer node 26 will be explained using the sequence diagram in Figure 3. First, in step S102, a transfer node 26 is selected from among multiple nodes 25 in the first distributed ledger system 11 that manages the first distributed ledger. The selection may be made by, for example, a seed node, which is a node in the first distributed ledger system 11.

[0024] Next, in step S103, the control unit 21 generates a second distributed ledger together with the other selected transfer nodes 26. Step S103 in FIG. 4 shows a transfer node 26A included in the second distributed ledger system 12 that manages the second distributed ledger, and a non-transfer node 27A that has not been selected as a transfer node 26. Here, the number of other selected transfer nodes 26 can be at least two. In other words, the total number of transfer nodes 26, including the transfer node itself, can be at least three. This allows blocks to be registered through consensus building.

[0025] Returning to Figure 3, in step S104, the control unit 21 consensus-registers the contents of blocks in the first distributed ledger as blocks in the second distributed ledger, in ascending order of block height. By registering blocks in the second distributed ledger in this way, in ascending order of block height in the first distributed ledger, the blocks are also registered in the second distributed ledger in the order in which they were consensus-registered and registered in the first distributed ledger. This prevents discrepancies in transactions, such as a break in continuity due to asset transfers or a negative cryptocurrency value, caused by a change in the order in which blocks are registered.

[0026] Subsequently, in step S105, the control unit 21 determines whether the number of blocks in the first distributed ledger that have not been registered as blocks in the second distributed ledger is a predetermined number or less, or whether that number is a predetermined percentage or less of the number of blocks in the first distributed ledger. Here, if the number of blocks that have not been registered in the second distributed ledger is not a predetermined number or percentage or less (step S105: No), the control unit 21 returns to step S104 and repeats the process. If the number of blocks that have not been registered in the second distributed ledger is a predetermined number or percentage or less (step S105: Yes), in step S106, proposals of new blocks to the first distributed ledger may be stopped. Subsequently, in step S107, consensus can be reached on and registration of blocks that have already been proposed in the first distributed ledger. In this way, new block proposals to the first distributed ledger are halted when the number or percentage of blocks not yet registered in the second distributed ledger falls below a predetermined number, so it is possible to complete the registration of the contents of all blocks in the first distributed ledger as blocks in the second distributed ledger while shortening the period during which new block proposals are suspended in the first distributed ledger. Therefore, it is possible to complete the replication of blocks to the second distributed ledger while shortening the period during which new block proposals are suspended.

[0027] Subsequently, in step S108, the contents of blocks corresponding to the first distributed ledger that have not yet been registered in the second distributed ledger are registered as blocks of the second distributed ledger through consensus building, in ascending order of block height. Next, in step S109, it is determined whether the contents of all blocks included in the first distributed ledger have been registered in the second distributed ledger, and if the contents of all blocks included in the first distributed ledger have not been registered in the second distributed ledger (step S109: No), the process returns to step S108 and repeats the process.

[0028] If the contents of all blocks included in the first distributed ledger have been registered in the second distributed ledger (step S109: Yes), proceed to step S110. Step S109 in Figure 4 shows the first distributed ledger system 11 (dashed line) that has stopped proposing new blocks, and the transfer node 26B that has registered all the contents of the first distributed ledger in the second distributed ledger.

[0029] In step S110, the communication unit 22 synchronizes the blocks registered in the second distributed ledger to the non-transfer node 27B in the first distributed ledger system 11. Step S110 in Figure 4 shows the non-transfer node 27B having completed synchronization with the transfer node 26B for the second distributed ledger. Here, "synchronization" refers to the transfer node 26B sending the blocks registered in the second distributed ledger to the non-transfer node 27B belonging to the first distributed ledger system 11, and allowing the non-transfer node 27B to join the second distributed ledger system 12.

[0030] Subsequently, if the transfer node 26B does not hold the first distributed ledger (step S111: No), it deletes the first distributed ledger from the storage unit 23 and proceeds to step S113. If it holds the first distributed ledger, it proceeds to step S113. In step S113, the second distributed ledger accepts a proposal for a new block other than the first distributed ledger. Here, in step S112 of FIG. 4, the transfer node 26B is set to hold the first distributed ledger, but the first distributed ledger may also be deleted by the transfer node 26B. The first distributed ledger may also be deleted by some of the non-transfer nodes 27B. In this way, by deleting the first distributed ledger after synchronization is completed, the old distributed ledger (first distributed ledger) is left only in some of the nodes 25, making it possible to refer to the old distributed ledger while saving overall storage capacity. Step S112 of FIG. 4 shows the non-transferring node 27C being deleted from the first distributed ledger that has stopped proposing new blocks.

[0031] As described above, the transfer node 26 is selected from the multiple nodes 25 in the first distributed ledger system 11 that manage the first distributed ledger. The control unit 21 of the transfer node 26 generates the second distributed ledger together with some other nodes 25 (non-transfer nodes 27) in the first distributed ledger system 11. The control unit 21 of the transfer node 26 also consensus-registers the contents of multiple blocks included in the first distributed ledger as blocks in the second distributed ledger, in ascending order of block height. After the contents of all blocks included in the first distributed ledger have been registered in the second distributed ledger, the communication unit 22 of the transfer node 26 synchronizes the blocks registered in the second distributed ledger with the remaining nodes 25 (non-transfer nodes 27) in the first distributed ledger system 11. As a result, the transfer node 26 can migrate to the second distributed ledger while maintaining the consistency of the block order, since it forms consensus on blocks in the second distributed ledger in order from the lowest block height in the first distributed ledger. Therefore, even if a specification change occurs in the distributed ledger program that causes the consistency of consensus to be lost, the number of nodes and the continuity of transactions can be maintained.

[0032] Furthermore, the control unit 21 of the transfer node 26 may be configured not to propose new blocks other than blocks in the first distributed ledger to the second distributed ledger from the generation of the second distributed ledger until synchronization with some of the remaining nodes 25 (non-transfer nodes 27) in the first distributed ledger system 11 is complete. As a result, no new blocks are proposed until synchronization with the first distributed ledger is complete, so no new blocks are inserted between blocks in the first distributed ledger, and the consistency of the first distributed ledger can be maintained when it is transferred to the second distributed ledger. Note that this is not limited to not accepting proposals of new blocks other than blocks in the first distributed ledger to the second distributed ledger from the generation of the second distributed ledger until synchronization is complete.

[0033] Furthermore, the control unit 21 of the transfer node 26 may suspend the proposal of new blocks in the first distributed ledger and register blocks already proposed in the first distributed ledger by reaching consensus when the number of blocks in the first distributed ledger that have not yet been registered as blocks in the second distributed ledger falls below a predetermined number or a predetermined percentage of the number of blocks in the first distributed ledger. This allows the registration of the contents of all blocks in the first distributed ledger as blocks in the second distributed ledger to be completed while shortening the period during which new block proposals are suspended in the first distributed ledger. Therefore, the transfer to the second distributed ledger can be completed while shortening the period during which new block proposals are suspended.

[0034] Furthermore, before registering a block in the second distributed ledger, the control unit 21 of the transfer node 26 may perform a summarization process in which the contents of multiple blocks included in the first distributed ledger are combined into one block and registered in the first distributed ledger. This reduces the size of one block to be transferred, thereby saving storage capacity and shortening the transfer work time.

[0035] The first distributed ledger system 11 and the second distributed ledger system 12 may use different consensus algorithms. For example, even if the consensus algorithm of the first distributed ledger system 11 is PoW (Proof of Work) and the consensus algorithm of the second distributed ledger system 12 is PoS (Proof of Stake), the PoS second distributed ledger system 12 can hold the contents of the PoW first distributed ledger system 11. In other words, even if the consensus algorithm of the first distributed ledger system 11 is PoW, consensus is again reached using the PoS consensus algorithm when creating blocks in the second distributed ledger system 12, making transfer between different consensus algorithms possible.

[0036] Furthermore, the control unit 21 of the transfer node 26 may delete the first distributed ledger after completing synchronization with the remaining nodes 25 (non-transfer nodes 27) of the first distributed ledger system 11. By leaving the old distributed ledger only on some of the nodes 25, it is possible to save storage capacity overall while still being able to refer to the old distributed ledger.

[0037] Meanwhile, the control unit 21 of the non-transferring node 27 can also stop proposing new blocks in the first distributed ledger. Furthermore, the communication unit 22 of the non-transferring node 27 can synchronize the second distributed ledger stored in the transferor node 26 after the contents of all blocks included in the first distributed ledger have been registered in the second distributed ledger by the transferor node 26. After stopping the proposal of new blocks, the control unit 21 of the non-transferring node 27 can further reach a consensus on blocks that have already been proposed in the first distributed ledger and write them to the first distributed ledger. In this way, in cooperation with the transferor node 26, the non-transferring node 27 can also store a second distributed ledger containing the contents of blocks in the first distributed ledger.

[0038] Furthermore, the control unit 21 of the non-transfer node 27 can delete the first distributed ledger after synchronization of the second distributed ledger is complete. This allows the old distributed ledger to remain only in some nodes 26B and 27B, making it possible to refer to the old distributed ledger while saving storage capacity overall.

[0039] The non-transferring node 27 of the first distributed ledger system 11 may propose new blocks in the first distributed ledger and register them through consensus even while the transferring node 26 is registering the contents of multiple blocks included in the first distributed ledger in the second distributed ledger. Furthermore, when the number of corresponding blocks in the first distributed ledger that have not yet been registered as blocks in the second distributed ledger falls below a predetermined number or a predetermined percentage of the number of blocks in the first distributed ledger, the non-transferring node 27 may stop proposing new blocks in the first distributed ledger and register already proposed blocks through consensus. This allows the registration of all the contents of blocks in the first distributed ledger as blocks in the second distributed ledger to be completed while shortening the period during which new block proposals are suspended in the first distributed ledger. Therefore, the transfer to the second distributed ledger can be completed while shortening the period during which new block proposals are suspended.

[0040] The operational flows and operational examples in the above-described embodiments do not necessarily have to be executed in chronological order according to the order depicted in the flow diagrams or sequence diagrams. For example, steps in the operations may be executed in an order different from that depicted in the flow diagrams or sequence diagrams, or may be executed in parallel. Some steps in the operations may be deleted, or additional steps may be added to the processing. The operational flows and operational examples in the above-described embodiments may be executed independently, or two or more operational flows and operational examples may be combined and executed. For example, some steps in one operational flow may be added to another operational flow, or some steps in one operational flow may be replaced with some steps in another operational flow.

[0041] A program may be provided that causes a computer to execute the operations according to the above-described embodiments. The program may be recorded on a computer-readable medium. The computer-readable medium can be used to install the program on a computer. Here, the computer-readable medium on which the program is recorded may be a non-transitory recording medium. The non-transitory recording medium is not particularly limited, and may be, for example, a recording medium such as a CD-ROM or a DVD-ROM.

[0042] As used in this disclosure, the terms "based on" and "depending on" do not mean "based only on" or "depending only on," unless expressly stated otherwise. The term "based on" means both "based only on" and "based at least in part on." Similarly, the term "depending on" means both "depending only on" and "depending at least in part on." Furthermore, the terms "include," "comprise," and variations thereof do not mean including only the listed items, but may include only the listed items, or may include additional items in addition to the listed items. Furthermore, the term "or" as used in this disclosure is not intended to mean an exclusive or. In this disclosure, when articles are added by translation, such as a, an, and the in English, these articles are intended to include the plural unless the context clearly indicates otherwise.

[0043] The above describes the embodiments in detail with reference to the drawings, but the specific configuration is not limited to that described above, and various design changes can be made within the scope that does not deviate from the gist of the invention.

[0044] The following additional notes are about the features of the above-described embodiment.

[0045] (Appendix 1) A node in a first distributed ledger system that manages the first distributed ledger, a control unit that generates a second distributed ledger together with some other nodes of the first distributed ledger system, and that consensus-builds and registers the contents of multiple blocks included in the first distributed ledger as blocks of the second distributed ledger in ascending order of block height; a communication unit that synchronizes the blocks registered in the second distributed ledger with a remaining portion of the nodes in the first distributed ledger system after the contents of all blocks included in the first distributed ledger have been registered in the second distributed ledger.

[0046] (Appendix 2) 2. The node described in Appendix 1, wherein the control unit does not propose new blocks other than blocks of the first distributed ledger to the second distributed ledger from the generation of the second distributed ledger until synchronization with the remaining portion of nodes in the first distributed ledger system is completed.

[0047] (Appendix 3) 3. The node according to claim 1, wherein the control unit stops proposing new blocks in the first distributed ledger and reaches consensus on and registers blocks that have already been proposed in the first distributed ledger when the number of blocks in the first distributed ledger that have not yet been registered as blocks in the second distributed ledger falls below a predetermined number or a predetermined percentage of the number of blocks in the first distributed ledger.

[0048] (Appendix 4) 4. The node according to any one of claims 1 to 3, wherein the control unit performs a summarization process to combine the contents of the plurality of blocks included in the first distributed ledger into a single block and register the block in the first distributed ledger before registering the block in the second distributed ledger.

[0049] (Appendix 5) 5. The node according to any one of claims 1 to 4, wherein the number of the other part of nodes is at least two.

[0050] (Appendix 6) 6. The node of claim 1, wherein the first distributed ledger and the second distributed ledger differ from each other in their consensus algorithms.

[0051] (Appendix 7) 7. The node according to any one of claims 1 to 6, wherein the control unit deletes the first distributed ledger after synchronization with the remaining portion of nodes in the first distributed ledger system is completed.

[0052] (Appendix 8) a control unit that stops the proposal of new blocks in the first distributed ledger; A node comprising: a communication unit that synchronizes the second distributed ledger stored on the transfer node after the contents of all blocks included in the first distributed ledger are registered in the second distributed ledger by the transfer node.

[0053] (Appendix 9) 9. The node of claim 8, wherein after the control unit stops proposing the new block, the control unit reaches consensus on blocks already proposed in the first distributed ledger and writes the blocks to the first distributed ledger.

[0054] (Appendix 10) 10. The node according to claim 8, wherein the control unit deletes the first distributed ledger after synchronization of the second distributed ledger is completed.

[0055] (Appendix 11) a first distributed ledger system that manages the first distributed ledger; a second distributed ledger system that manages a second distributed ledger generated by multiple transfer nodes selected from the multiple nodes of the first distributed ledger system; the plurality of transfer nodes reach consensus on and register the contents of the plurality of blocks included in the first distributed ledger as blocks of the second distributed ledger in ascending order of block height; A distributed ledger system in which, after the contents of all blocks included in the first distributed ledger are registered in the second distributed ledger, non-transferring nodes, which are nodes in the first distributed ledger system other than the transfer node, synchronize the second distributed ledger stored in the transfer node.

[0056] (Appendix 12) 12. The distributed ledger system of claim 11, wherein the second distributed ledger system does not propose new blocks other than blocks of the first distributed ledger to the second distributed ledger from the time the second distributed ledger is generated until synchronization of the second distributed ledger of all the non-transferring nodes is completed.

[0057] (Appendix 13) 13. The distributed ledger system of claim 11 or 12, wherein some nodes in the second distributed ledger system delete the first distributed ledger after synchronization of the second distributed ledger of all non-transferring nodes is complete.

[0058] (Appendix 14) The nodes of the first distributed ledger system propose and register new blocks in the first distributed ledger through consensus building, even during the period in which the transfer node is registering the contents of multiple blocks included in the first distributed ledger in the second distributed ledger; 14. The distributed ledger system of any one of appendixes 11 to 13, wherein when the number of corresponding blocks in the first distributed ledger that have not yet been registered as blocks in the second distributed ledger falls below a predetermined number or a predetermined percentage of the number of blocks in the first distributed ledger, proposals for new blocks in the first distributed ledger are stopped and consensus is reached on and already proposed blocks are registered.

[0059] (Appendix 15) 15. The distributed ledger system of any one of appendixes 11 to 14, wherein the number of the plurality of transfer nodes is at least three.

[0060] (Appendix 16) selected from a plurality of nodes in a first distributed ledger system that manages the first distributed ledger; A second distributed ledger is generated, and the contents of the plurality of blocks included in the first distributed ledger are registered as blocks of the second distributed ledger through consensus building in order from the lowest block height; A distributed ledger transfer method in which, after the contents of all blocks included in the first distributed ledger are registered in the second distributed ledger, the blocks registered in the second distributed ledger are synchronized with a remaining portion of the nodes in the first distributed ledger system.

[0061] (Appendix 17) selecting from a plurality of nodes of a first distributed ledger system that manages the first distributed ledger; generating a second distributed ledger, and registering the contents of a plurality of blocks included in the first distributed ledger as blocks of the second distributed ledger by consensus building in ascending order of block height; and after the contents of all blocks included in the first distributed ledger have been registered in the second distributed ledger, synchronizing the blocks registered in the second distributed ledger with a remaining portion of the nodes in the first distributed ledger system. [Explanation of symbols]

[0062] 1. Distributed Ledger System 11. First Distributed Ledger System 12 Second Distributed Ledger System 2, 2A to 2E nodes 21 Control Unit 22 Communications Department 23 Memory section 25,25A node 26, 26A, 26B Transfer Node 27, 27A, 27B, 27C Non-transferring nodes

Claims

1. A node in a first distributed ledger system that manages a first distributed ledger, a control unit that generates a second distributed ledger together with some other nodes of the first distributed ledger system, and that forms a consensus on the contents of multiple blocks included in the first distributed ledger, in ascending order of block height, as blocks of the second distributed ledger, and registers the contents of the multiple blocks included in the first distributed ledger; a communication unit that synchronizes the blocks registered in the second distributed ledger with a remaining portion of the nodes in the first distributed ledger system after the contents of all blocks included in the first distributed ledger have been registered in the second distributed ledger.

2. 2. The node according to claim 1, wherein the control unit does not propose new blocks other than blocks of the first distributed ledger to the second distributed ledger from the generation of the second distributed ledger until synchronization with the remaining portion of nodes in the first distributed ledger system is completed.

3. 2. The node according to claim 1, wherein the control unit stops proposing new blocks in the first distributed ledger and reaches consensus on and registers blocks that have already been proposed in the first distributed ledger when the number of blocks in the first distributed ledger that have not yet been registered as blocks in the second distributed ledger falls below a predetermined number or a predetermined percentage of the number of blocks in the first distributed ledger.

4. 2. The node according to claim 1, wherein the control unit performs a summarization process in which, before registering a block in the second distributed ledger, the contents of the plurality of blocks included in the first distributed ledger are summarized into a single block and registered in the first distributed ledger.

5. The node of claim 1 , wherein the number of the other subset of nodes is at least two.

6. The node of claim 1 , wherein the first distributed ledger and the second distributed ledger differ from each other in their consensus algorithms.

7. The node according to claim 1 , wherein the control unit deletes the first distributed ledger after synchronization with the remaining portion of nodes in the first distributed ledger system is completed.

8. a control unit that stops the proposal of new blocks in the first distributed ledger; A node comprising: a communication unit that synchronizes the second distributed ledger stored on the transfer node after the contents of all blocks included in the first distributed ledger are registered in the second distributed ledger by the transfer node.

9. 9. The node according to claim 8, wherein, after stopping the proposal of the new block, the control unit reaches a consensus on a block that has already been proposed in the first distributed ledger and writes the block to the first distributed ledger.

10. The node according to claim 8 , wherein the control unit deletes the first distributed ledger after synchronization of the second distributed ledger is completed.

11. a first distributed ledger system that manages the first distributed ledger; a second distributed ledger system that manages a second distributed ledger generated by multiple transfer nodes selected from the multiple nodes of the first distributed ledger system; the plurality of transfer nodes reach consensus on and register the contents of the plurality of blocks included in the first distributed ledger as blocks of the second distributed ledger in ascending order of block height; A distributed ledger system in which, after the contents of all blocks included in the first distributed ledger are registered in the second distributed ledger, non-transferring nodes in the first distributed ledger system other than the transfer node synchronize the second distributed ledger stored on the transfer node.

12. 12. The distributed ledger system of claim 11, wherein the second distributed ledger system does not propose new blocks other than blocks of the first distributed ledger to the second distributed ledger from the generation of the second distributed ledger until synchronization of the second distributed ledger of all the non-transferring nodes is completed.

13. 12. The distributed ledger system of claim 11, wherein some nodes in the second distributed ledger system delete the first distributed ledger after synchronization of the second distributed ledger of all non-transferring nodes is complete.

14. The nodes of the first distributed ledger system propose and register new blocks in the first distributed ledger through consensus building, even during the period in which the transfer node is registering the contents of multiple blocks included in the first distributed ledger in the second distributed ledger; 12. The distributed ledger system of claim 11, wherein when the number of corresponding blocks in the first distributed ledger that have not yet been registered as blocks in the second distributed ledger falls below a predetermined number or a predetermined percentage of the number of blocks in the first distributed ledger, proposals for new blocks in the first distributed ledger are stopped and consensus is reached on and already proposed blocks are registered.

15. 12. The distributed ledger system of claim 11, wherein the number of transfer nodes is at least three.

16. selected from a plurality of nodes of a first distributed ledger system that manages the first distributed ledger; generating a second distributed ledger, and registering the contents of a plurality of blocks included in the first distributed ledger as blocks of the second distributed ledger by consensus building in order from lowest to highest block height; A distributed ledger transfer method in which, after the contents of all blocks included in the first distributed ledger have been registered in the second distributed ledger, the blocks registered in the second distributed ledger are synchronized with a remaining portion of the nodes in the first distributed ledger system.

17. selecting from a plurality of nodes of a first distributed ledger system that manages the first distributed ledger; generating a second distributed ledger, and registering the contents of a plurality of blocks included in the first distributed ledger as blocks of the second distributed ledger by consensus building in ascending order of block height; and after the contents of all blocks included in the first distributed ledger have been registered in the second distributed ledger, synchronizing the blocks registered in the second distributed ledger with a remaining portion of the nodes in the first distributed ledger system.

Images