Blockchain systems, nodes, and programs

Abstract

In this blockchain system in which a network having a hierarchical structure is formed from a plurality of nodes, a node belonging to a first group in a first hierarchical level different from the lowest hierarchical level manages a first ledger, including transaction data relating to transaction in the first group, and performs ledger locking so as not to update the first ledger after update of the first ledger during a locking period. The node, upon completion of the locking period and when a second ledger which is managed in a second group in a second hierarchical level which is lower than the first hierarchical level is updated during the locking period, updates the first ledger so as to include, in the first ledger, ledger information relating to the updated second ledger.

Description

[Technical Field]

[0001] The present disclosure relates to a blockchain system, a node, and a program. [Background technology]

[0002] Blockchain technology has been attracting attention in recent years. Blockchain technology has the advantage of preventing system downtime because it forms an autonomous decentralized network, specifically a P2P (Peer to Peer) network, using multiple nodes.

[0003] Blockchain technology has a mechanism in which each node manages the history of transactions within a P2P network as a ledger. This mechanism is also known as distributed ledger technology. When a transaction occurs at one node, all participating nodes perform a calculation (check) process. This provides a mechanism that leaves a correct transaction history that is extremely difficult to tamper with, even if there is fraud and / or malfunction among the participating nodes.

[0004] Here, Patent Document 1 describes a system that divides a P2P network into multiple hierarchical networks and manages transaction data independently for each network, in order to solve the problem of node capacity constraints caused by the expansion of transaction history (ledgers) held by each node. In this system, if a trading partner exists in the same network, transaction data is shared and stored only within the same network. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Application Publication No. 2018-67108 Summary of the Invention

[0006] A blockchain system according to a first aspect is a blockchain system in which a network having a hierarchical structure is formed by a plurality of nodes. A node belonging to a first group in a first hierarchical layer, which is different from the lowest hierarchical layer, manages a first ledger including transaction data related to transactions within the first group, and performs ledger locking to prevent the first ledger from being updated for a lock period after the first ledger is updated. When the lock period ends, if a second ledger managed by a second group in a second hierarchical layer below the first hierarchical layer has been updated within the lock period, the node updates the first ledger to include ledger information related to the updated second ledger in the first ledger.

[0007] A node according to a second aspect is a node belonging to a first group in a first hierarchical layer different from the lowest hierarchical layer in a blockchain system in which a plurality of nodes form a hierarchical network. The node includes a processor that executes the following processes: a process of managing a first ledger including transaction data related to transactions in the first group; a process of performing a ledger lock to prevent the first ledger from being updated for a lock period after the first ledger is updated; and a process of updating the first ledger at the end of the lock period, if a second ledger managed by a second group in a second hierarchical layer below the first hierarchical layer has been updated within the lock period, to include information about the updated second ledger in the first ledger.

[0008] A program according to a third aspect causes a node belonging to a first group in a first layer different from the lowest layer in a blockchain system in which a network having a hierarchical structure is formed by a plurality of nodes to execute the following processes: managing a first ledger including transaction data related to transactions within the first group; locking a ledger so that the first ledger is not updated for a lock period after the first ledger is updated; and, when the lock period ends, if a second ledger managed by a second group in a second layer below the first layer has been updated within the lock period, updating the first ledger so that information related to the updated second ledger is included in the first ledger. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a diagram illustrating an example of a network configuration in a typical blockchain system. [Figure 2] FIG. 2 is a diagram illustrating an example of the configuration of a ledger managed by each node according to the embodiment. [Figure 3] FIG. 10 is a diagram illustrating an example of an operation when a new block is added to a ledger according to an embodiment (that is, when the ledger is updated). [Figure 4] FIG. 10 is a diagram illustrating an example of an operation when a new block is added to a ledger according to an embodiment. [Figure 5] FIG. 2 is a diagram illustrating an example of the configuration of each node according to the embodiment. [Figure 6] FIG. 1 is a diagram illustrating an example of a network configuration according to an embodiment. [Figure 7] FIG. 10 is a diagram illustrating a ledger management method according to an embodiment. [Figure 8] FIG. 10 is a diagram illustrating a ledger management method according to an embodiment. [Figure 9] 10A and 10B are diagrams for explaining the effect of reducing the amount of calculation when a hierarchical structure network according to an embodiment is compared with a general network configuration; [Figure 10] 10 is a diagram for explaining a link between a higher-level ledger and a lower-level ledger according to an embodiment. FIG. [Figure 11]FIG. 10 is a diagram showing an example of operation in the case where, after a group (A) according to the embodiment has been formed, a new group (B) is formed below the group (A). [Figure 12] FIG. 10 is a diagram showing an example of operation in a case where, after a group (A) according to an embodiment is formed, a new group (B) is formed below the group (A), and then a new group (C) is formed below the group (A). [Figure 13] FIG. 10 is a diagram showing an example of operation in a case where, after a group (A) according to an embodiment is formed, a new group (B) is formed below the group (A), and then a new group (C) is formed below the group (A). [Figure 14] FIG. 10 is a diagram for explaining grouping of lower hierarchical groups according to the embodiment. [Figure 15] FIG. 10 is a diagram for explaining grouping of lower hierarchical groups according to the embodiment. [Figure 16] FIG. 10 is a diagram illustrating priority within a group according to the embodiment. [Figure 17] FIG. 10 is a diagram illustrating priority within a group according to the embodiment. [Figure 18] FIG. 10 is a diagram illustrating an example of node parameters stored in a ledger according to the embodiment. [Figure 19] FIG. 10 is a diagram illustrating locking of a ledger according to an embodiment. [Figure 20] 10A and 10B are diagrams for explaining a locking operation for updating a ledger according to an embodiment; [Figure 21] FIG. 10 is a diagram illustrating an example of an operation according to an embodiment. [Figure 22] 10A and 10B are diagrams for explaining a method for setting a lock period according to an embodiment. [Figure 23] 10A and 10B are diagrams for explaining a method for setting a lock period according to an embodiment. [Figure 24] FIG. 10 is a diagram illustrating a specific example 1 of operations related to ledger locking according to the embodiment. [Figure 25]FIG. 10 is a diagram illustrating a specific example 2 of the operation related to ledger locking according to the embodiment. [Figure 26] FIG. 10 is a diagram illustrating an example of a flow when a node is added to a hierarchical structure network according to an embodiment. [Figure 27] FIG. 10 is a diagram illustrating an example of a flow of parent node rotation in a hierarchical structure network according to an embodiment. [Figure 28] FIG. 10 is a diagram showing an example of a flow when a node is added to a lower layer (a lower layer group is added) in a hierarchical structure network according to an embodiment. [Figure 29] FIG. 10 is a diagram illustrating an example of a flow when a node is deleted from a hierarchical structure network according to an embodiment. [Figure 30] FIG. 10 is a diagram illustrating an example of a main process of ledger locking according to an embodiment. [Figure 31] FIG. 10 is a diagram illustrating an example of transaction data processing according to an embodiment. [Figure 32] FIG. 10 is a diagram illustrating an example of a process for searching for another node with a memory margin according to the embodiment. [Figure 33] FIG. 10 is a diagram illustrating an example of processing on the node side having a memory surplus according to the embodiment. [Figure 34] FIG. 10 is a diagram illustrating an example of processing when there is no other node with a memory surplus in the group according to the embodiment; [Figure 35] FIG. 10 is a diagram illustrating an example of processing when ledgers (child ledgers) of multiple child groups according to the embodiment are updated. [Figure 36] FIG. 10 is a diagram illustrating an example of processing when a ledger of a child group according to an embodiment is updated multiple times. [Figure 37] FIG. 10 is a diagram illustrating an example of processing when a child ledger update fails according to an embodiment. [Figure 38] FIG. 10 is a diagram illustrating an example of a child ledger update process according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0010] As with the technology described in Patent Document 1, it is believed that by grouping nodes in a P2P network and managing a ledger separately for each group, it is possible to reduce the frequency of ledger updates and curb the expansion of the ledger. However, this method has the problem that the contents of each group's ledger are not linked to the ledgers of other groups, which can reduce the reliability of blockchain technology.

[0011] Therefore, the present disclosure aims to suppress a decline in reliability while suppressing the frequency and expansion of ledger updates when applying blockchain technology.

[0012] The embodiments will be described with reference to the drawings, in which the same or similar parts are designated by the same or similar reference numerals.

[0013] (Overview of Blockchain Technology) First, general blockchain technology will be described with reference to FIGS. 1 to 4.

[0014] Figure 1 is a diagram showing an example of a network configuration in a typical blockchain system. In Figure 1, the lines connecting nodes represent communication connections between the nodes.

[0015] In blockchain technology, an autonomous distributed network, specifically a P2P network, is formed by a plurality of nodes 100. The nodes 100 are connected to each other so that they can communicate with each other. Communication between the nodes 100 may be performed via a public communication network and / or a local communication network. Although FIG. 1 illustrates a total of five nodes, nodes 100a to 100e, the number of nodes 100 is not limited to five. Each node 100 is a device, such as a PC (Personal Computer), that has at least communication and processing functions. In general blockchain technology, it is assumed that each node 100 has sufficient performance (specifications).

[0016] Each node 100 manages the history of transactions within the network as a ledger. When a transaction occurs at one node 100 (for example, node 100a), all participating nodes (nodes 100a to 100e) perform a calculation (verification) process. This provides a mechanism that leaves a correct transaction history that is extremely difficult to tamper with, even if a participating node 100 is found to be fraudulent and / or does not operate normally.

[0017] A transaction may be, for example, a remittance or settlement of money or points, or the occurrence of communication. In this case, the transaction data stored in a block of the ledger may be data of the remittance or settlement. Alternatively, the transaction data may be data of the communication. A transaction may be the joining or deletion of a node in the network. In this case, the transaction data stored in a block of the ledger may be data (parameters) of the node 100. A transaction may be an update of the ledger. The transaction data stored in a block of the ledger may be data (parameters) of the node 100.

[0018] In the embodiment, an example is mainly assumed in which transaction data stored in blocks of a ledger includes data (parameters) of the node 100. By managing such data (parameters) of the node 100 in the ledger, it becomes easy to guarantee that the node 100 in the network is a genuine device.

[0019] FIG. 2 is a diagram showing an example of the structure of a ledger managed by each node 100. As shown in FIG.

[0020] Each node 100 stores records of transactions that occur within the network in blocks. A block has a block header, which is a header portion, and a transaction data portion that stores data of at least one transaction. The block header stores a hash value calculated from the block generated immediately before. For example, the block header of block n+1 stores a hash value calculated from block n. In this way, the ledger has a data structure in which each generated block is linked in a chain in chronological order. The block header may further include a bit representing the number of the corresponding block and a nonce, which is a value used to calculate the hash value.

[0021] 3 and 4 are diagrams showing an example of the operation when a new block is added to the ledger (that is, when the ledger is updated).

[0022] As shown in Figure 3, after a transaction occurs within a group that makes up a P2P network, a node 100 called a "proposer" generates a new block corresponding to that transaction and proposes the new block by notifying other nodes 100 of the new block. For example, multiple nodes 100 calculate a hash value by combining the nonce value with transaction data, etc. while changing it, and the node 100 (proposer) that finds a hash value that meets certain conditions notifies the other nodes 100 of the generated block. The other nodes 100 that receive the proposed new block verify the hash value of the new block. Here, we will proceed with the explanation assuming that the verification is successful.

[0023] Next, as shown in Figure 4, other nodes 100 that receive the new block proposal vote for the node 100 (proposer) to accept the verified block as the new block. The other nodes 100 that vote are called "voters." If the node 100 (proposer) receives a certain number of votes from the other nodes 100 (voters), it confirms the proposed new block and adds the new block to the ledger.

[0024] FIG. 5 is a diagram illustrating an example of the configuration of each node 100. As shown in FIG.

[0025] 5, the node 100 includes a communication unit 110, a control unit 120, and a storage unit 130. The node 100 may also include a battery 140.

[0026] The communication unit 110 includes a communication interface for communicating with other nodes. The communication interface may be a wireless communication interface or a wired communication interface.

[0027] The control unit 120 performs various controls and processes in the node 100. Such processes include the processes described above and the processes described below. The control unit 120 includes at least one processor 121. The processor 121 executes programs stored in the storage unit 130 to perform various processes.

[0028] The storage unit 130 stores programs executed by the processor 121 and information used in processing by the processor 121. The storage unit 130 includes a non-volatile memory and a volatile memory.

[0029] The battery 140 stores power to be supplied to each part of the node 100 (device).

[0030] (Hierarchical network) Next, a blockchain system according to an embodiment will be described with reference to Fig. 6. The blockchain system according to an embodiment includes a network 10 having a hierarchical structure (hereinafter referred to as a "hierarchical structure network").

[0031] As described above, blockchain technology assumes that each node 100 has sufficient performance, and if a transaction occurs at any one node 100, calculations (checks) are performed at all nodes 100. Therefore, it is difficult to apply blockchain technology to devices with poor performance, such as those with small battery capacity, low computing power, or small storage capacity, such as IoT devices such as sensor devices.

[0032] In the embodiment, a hierarchical network 10 is formed, and each node 100 is placed at a tier according to the performance of the node 100. The hierarchical structure allows higher tiers to have a higher calculation frequency (i.e., ledger update frequency), while lower tiers have a lower calculation frequency. By placing high-performance devices at higher tiers and low-performance devices at lower tiers, devices can participate in the blockchain hierarchical network 10 regardless of performance.

[0033] Fig. 6 is a diagram showing an example of a network configuration according to an embodiment. In the example of Fig. 6, a hierarchical-structure network 10 has a hierarchical structure consisting of three hierarchies, namely, hierarchies 1 to 3. While an example using three hierarchies will be mainly described below, the number of hierarchies may be two, four, or more. In the example shown in Fig. 6, hierarchical level 1 is the highest hierarchical level, and hierarchical level 3 is the lowest hierarchical level.

[0034] In such a hierarchical network 10, each node 100 manages a ledger. Based on the performance of the node 100, each node 100 is placed in one of three hierarchical levels according to the performance of the node 100. Here, the performance of the node 100 refers to at least one of computational power (e.g., processor power), storage capacity (e.g., memory size), and battery capacity. The performance of the node 100 may also include a sleep time, which will be described later. For example, when a new node is added, the new node or another node determines the hierarchical level in which the new node is placed based on the performance of the new node.

[0035] Each node 100 arranged in hierarchical layer 1 and each node 100 arranged in hierarchical layer 2 form an upper hierarchical layer group. In Fig. 6, an example is shown in which the only node 100 belonging to hierarchical layer 1 is node 100A, but multiple nodes 100 may be arranged in hierarchical layer 1.

[0036] The three nodes 100 arranged on hierarchical level 2 are node 100B1, node 100C1, and node 100D1. Each node 100 belonging to group (A) 200A, which is an upper hierarchical group, manages ledger (A), which is an upper hierarchical ledger.

[0037] Each node 100 placed on tier 2 and each node 100 placed on tier 3 form a lower tier group that manages a lower tier ledger. For example, high-performance equipment is placed on tier 1 (or tier 2), and equipment with lower performance than the high-performance equipment is placed on tier 3. In other words, the nodes 100 belonging to the lower tier group have lower performance than the nodes 100 belonging to the higher tier group.

[0038] 6 shows an example in which a total of three lower hierarchical groups, group (B) to group (D), are formed. However, the number of lower hierarchical groups is not limited to three, and the number of lower hierarchical groups may be one, or four or more.

[0039] Group (B) includes one node 100B1 located on hierarchical level 2 and multiple nodes 100B2 located on hierarchical level 3. Each node 100B belonging to group (B) manages ledger (B), which is a lower-level ledger. Node 100B1 belongs to both group (A) and group (B), and manages both ledger (A) and ledger (B). Node 100B1 is the parent node of group (B). Node 100B2 belongs only to group (B), and therefore manages only ledger (B).

[0040] Similarly, group (C) has one node 100C1 located on hierarchical level 2 and multiple nodes 100C2 located on hierarchical level 3. Each node 100C belonging to group (C) manages ledger (C), which is a lower-level ledger. Node 100C1 belongs to both group (A) and group (C), and manages both ledgers (A) and (C). Node 100C1 is the parent node of group (C). Node 100C2 belongs only to group (C), and therefore manages only ledger (C).

[0041] Similarly, group (D) has one node 100D1 placed on hierarchical level 2 and multiple nodes 100D2 placed on hierarchical level 3. Each node 100D belonging to group (D) manages ledger (D), which is a lower-level ledger. Node 100D1 belongs to both group (A) and group (D), and manages both ledger (A) and ledger (D). Node 100D1 is the parent node of group (D). Node 100D2 belongs only to group (D), and therefore manages only ledger (D).

[0042] Within each group (A) to (D), the nodes 100 are connected to each other so that they can communicate with each other, and a common ledger is maintained and managed within the group, and processing within the group is performed in the same way as in conventional blockchains. This type of grouping makes it possible to reduce the number of nodes within each group, thereby preventing the ledger from becoming too large.

[0043] Furthermore, generally, a low-performance node 100 (for example, an IoT device such as a sensor device) generates transactions less frequently than a high-performance node 100. For example, a low-performance node 100 performs communication intermittently to reduce power consumption, goes into a sleep state when not communicating, and does not generate transactions during the sleep period.

[0044] In group (A), which is an upper hierarchical group formed by high-performance nodes 100, ledger (A) may be updated more frequently and the amount of data in ledger (A) is likely to become larger than in lower hierarchical groups. On the other hand, in group (B) formed by low-performance nodes 100, the update frequency of ledger (B) can be reduced and the increase in the amount of data in ledger (B) can be suppressed. Similarly, in group (C) formed by low-performance nodes 100, the update frequency of ledger (C) can be reduced and the increase in the amount of data in ledger (C) can be suppressed. Similarly, in group (D) formed by low-performance nodes 100, the update frequency of ledger (D) can be reduced and the increase in the amount of data in ledger (D) can be suppressed.

[0045] However, while managing a ledger individually for each group can reduce the frequency of ledger updates and the size of the ledger, if the contents of each group's ledger are not linked to the ledgers of other groups, the reliability of blockchain technology may decrease. Therefore, in the embodiment, by linking the contents of ledgers between groups, it is possible to reduce the frequency of ledger updates and the size of the ledger while also suppressing a decrease in reliability.

[0046] Specifically, in a hierarchical network 10 consisting of multiple groups including a first group formed by one or more nodes 100 that manage a first ledger, and a second group formed by one or more nodes 100 that manage a second ledger different from the first ledger, a node 100 belonging to the second group notifies the first group of ledger information related to the second ledger. Each node 100 belonging to the first group manages the notified ledger information as part of the first ledger. This allows the contents of ledgers to be linked between groups.

[0047] Here, the first group is one of the upper hierarchical group and the lower hierarchical group, and the second group is the other of the upper hierarchical group and the lower hierarchical group. In other words, ledgers are linked between groups that have a direct communication connection. On the other hand, ledgers are not linked between lower hierarchical groups, i.e., between groups that do not have a direct communication connection. This makes it possible to manage ledgers independently between lower hierarchical groups, without the ledger updates in one lower hierarchical group affecting the ledgers in other lower hierarchical groups.

[0048] (Ledger management method) Next, a ledger management method according to the embodiment will be described with reference to FIGS.

[0049] As shown in FIG. 7, a node 100 belonging to an upper hierarchical group that manages an upper hierarchical ledger updates the upper hierarchical ledger in accordance with transactions within the upper hierarchical group and transactions within the lower hierarchical group.

[0050] For example, the nodes 100 (nodes 100A, 100B1, 100C1, and 100D1) belonging to group (A) 200A, which is an upper hierarchical group, not only update ledger (A), which is an upper hierarchical ledger, in accordance with transactions within group (A) 200A, but also update ledger (A) in accordance with transactions within any of the lower hierarchical groups (group (B) 200B, group (C) 200C, group (D) 200D). Figure 7 shows an example in which the nodes 100 (nodes 100A, 100B1, 100C1, and 100D1) belonging to group (A) 200A update ledger (A) in accordance with an update to ledger (B) in group (B) 200B.

[0051] The update frequency of the upper hierarchical ledger in the upper hierarchical group is the same as the update frequency of the ledger in a general hierarchical network 10 (see Figure 1) that does not have a hierarchical structure. By reflecting transactions within the lower hierarchical groups (group (B) 200B, group (C) 200C, group (D) 200D) in ledger (A), which is the upper hierarchical ledger, reliability in blockchain technology can be maintained.

[0052] On the other hand, as shown in Figure 8, nodes 100 belonging to a lower hierarchical group that manages a lower hierarchical ledger do not update the lower hierarchical ledger in response to transactions within a higher hierarchical group, but instead update the lower hierarchical ledger in response to transactions within the lower hierarchical group. In other words, even if the higher hierarchical ledger is updated, the lower hierarchical ledger is not updated. This reduces the frequency of updates to the lower hierarchical ledger in the lower hierarchical group.

[0053] For example, nodes 100B (nodes 100B1 and 100B2) belonging to group (B) 200B, a lower hierarchical group, update ledger (B), a lower hierarchical ledger, in response to transactions within group (B) 200B, but do not update ledger (B) in response to transactions within group (A) 200A. Similarly, nodes 100C (nodes 100C1 and 100C2) belonging to group (C) 200C, a lower hierarchical group, update ledger (C), a lower hierarchical ledger, in response to transactions within group (C) 200C, but do not update ledger (C) in response to transactions within group (A) 200A. Similarly, nodes 100D (nodes 100D1 and 100D2) belonging to group (D) 200D, a lower hierarchical group, update ledger (D), a lower hierarchical ledger, in response to transactions within group (D) 200D, but do not update ledger (D) in response to transactions within group (A) 200A.

[0054] 7, a node 100 belonging to a lower hierarchical group that manages a lower hierarchical ledger does not update the lower hierarchical ledger in response to transactions within other lower hierarchical groups. For example, even if ledger (B) is updated in group (B) 200B, which is a lower hierarchical group, other lower hierarchical groups, group (C) 200C and group (D) 200D, do not update ledgers (C) and (D). This reduces the frequency with which lower hierarchical ledgers are updated in lower hierarchical groups.

[0055] In this way, when a transaction occurs in a lower hierarchical group, the upper hierarchical ledger in the higher hierarchical group is updated, but no ledger update is required in other lower hierarchical groups. Also, even if a transaction occurs in a higher hierarchical group, no lower hierarchical ledger update is required in lower hierarchical groups. This reduces the overall amount of calculation. Therefore, blockchain technology can be applied to devices with low computing power and / or memory capacity.

[0056] 9 is a diagram for explaining the effect of reducing the amount of calculation when the hierarchical structure network 10 according to the embodiment is compared with a general network configuration (see FIG. 1). Here, an example is shown in which a hierarchical structure using a binary tree is adopted. Also, it is assumed that there are n (n≧4) nodes 100, and that the transaction occurrence frequency in each node 100 is the same.

[0057] As shown in Figure 9, the node 100 in the top layer (Layer 1) needs to calculate transactions for all nodes, so the calculation frequency is the same as that of general blockchain technology. On the other hand, the node 100 in the bottom layer only needs to calculate transactions for the group in which it participates. In the case of a binary tree, the number of nodes in each group is three, so the calculation frequency can be reduced to 3 / n.

[0058] For example, if all layers except the top layer are two-layered (n=7), it is possible to reduce the total calculations by approximately 38%. If all layers except the top layer are three-layered (n=15), it is possible to reduce the total calculations by approximately 61%. If n is sufficiently large (limit → infinity), it is possible to reduce the total calculations by approximately 67%. In other words, the lower the layer, the more the calculation frequency can be reduced. Therefore, compared to general blockchain technology, it is possible to reduce the amount of communication and the number of calculations. As a result, blockchain technology can be used even on devices with performance that is not possible to participate in general blockchain technology.

[0059] In the network configuration shown in Fig. 9, an upper hierarchical group and a lower hierarchical group are formed between two groups having a direct communication connection. For example, when group 200B is used as a reference, group 200A is the upper hierarchical group, and groups 200D and 200E are each lower hierarchical groups. When groups 200D and 200E are used as references, group 200B is the upper hierarchical group. Similarly, when group 200C is used as a reference, group 200A is the upper hierarchical group, and groups 200F and 200G are each lower hierarchical groups. When groups 200F and 200G are used as references, group 200C is the upper hierarchical group.

[0060] (Link between upper and lower level ledgers) Next, the link between the upper level ledger and the lower level ledger according to the embodiment will be described with reference to FIGS.

[0061] As shown in FIG. 10, a hierarchical network 10 is configured by a group (A) 200A formed by nodes 100 (nodes 100A, 100B1) that manage ledger (A) and a group (B) 200B formed by nodes 100 (nodes 100B1, 100B2) that manage ledger (B).

[0062] A node 100 belonging to group (A) 200A notifies group (B) 200B of ledger information related to ledger (A). For example, node 100B1 belonging to group (A) 200A notifies another node 100B2 in group (B) 200B of ledger information related to ledger (A). Then, each node 100 (nodes 100B1, 100B2) belonging to group (B) 200B manages the ledger information as part of ledger (B). In this way, each node 100 belonging to a lower hierarchical group that manages a lower hierarchical ledger manages ledger information related to a higher hierarchical ledger as part of the lower hierarchical ledger. This makes it possible to link a lower hierarchical ledger with a higher hierarchical ledger.

[0063] For example, ledger information managed as part of ledger (B), which is a lower-level ledger, may include a chain ID indicating ledger (A), which is a higher-level ledger. Ledger information managed as part of ledger (B) may include a hash value calculated from a block of ledger (A). Ledger information managed as part of ledger (B) may include a block height indicating a block number of ledger (A). Here, each node 100 (nodes 100B1 and 100B2) belonging to group (B) may store the ledger information in the header portion (block header) of a block of ledger (B). This makes it easy to identify ledger (A) and search for which block in ledger (A) it is linked to when verifying accounts in group (B) 200B, and also makes it easy to transmit information such as verification results from group (B) 200B to group (A) 200A.

[0064] On the other hand, the node 100 belonging to group (B) 200B notifies group (A) 200A of ledger information related to ledger (B). For example, node 100B1 belonging to group (B) 200B notifies other nodes 100A in group (A) 200A of ledger information related to ledger (B). Then, each node 100 (nodes 100B1, 100A) belonging to group (A) 200A manages the ledger information as part of ledger (A). In this way, each node 100 belonging to the upper hierarchical group that manages the upper hierarchical ledger manages ledger information related to the lower hierarchical ledger as part of the upper hierarchical ledger. This makes it possible to link the upper hierarchical ledger with the lower hierarchical ledger.

[0065] For example, ledger information managed as part of ledger (A), which is a higher-level ledger, may include a chain ID indicating ledger (B), which is a lower-level ledger. Ledger information managed as part of ledger (A) may include a hash value calculated from a block in ledger (B). Ledger information managed as part of ledger (A) may include a block height indicating a block number in ledger (B). Each node 100 (nodes 100B1 and 100A) belonging to group (A) may store the ledger information in the transaction data portion of a block in ledger (A). This prevents a decrease in security strength by merging ledger (B) with a sufficiently long ledger (A), even if ledger (B) is updated infrequently and its length is not sufficient. For example, this makes it easier to verify the fork protection of ledger (B) during verification in group (A) 200A. This prevents incorrect (fake) blockchains from branching, making it easier to verify the correct ledger (B).

[0066] 11 is a diagram showing an example of an operation when, after group (A) 200A is formed, a new group (B) 200B is formed below group (A) 200A. Here, a node belonging to group (A) 200A is referred to as node (A), and a node belonging to group (B) 200B is referred to as node (B). However, because a parent node belongs to both group (A) 200A and group (B) 200B, the operation in FIG. 11 may be executed within the same node (parent node).

[0067] 11, first, node (A) managing ledger (A) updates ledger (A) by adding the (m-1)th block to ledger (A). The (m-1)th block has a block header including a hash value calculated from the previous block in ledger (A) and transaction data for at least one transaction in group (A) 200A. The block header may further include at least one of a chain ID (parent chain ID) indicating ledger (A) and a block height indicating the block number (m-1) of the block.

[0068] Second, group (B) 200B is formed. Node (B) managing ledger (B) updates (creates) ledger (B) by adding the first block in ledger (B), i.e., the 0th block, to ledger (B). The 0th block includes, in its block header portion, the block in ledger (A) that is the latest at the time of adding the 0th block, i.e., the block header of the (m-1)th block in ledger (A), as ledger information related to ledger (A). The 0th block also includes, in its transaction data portion, transaction data related to at least one transaction in group (B) 200B. Here, the transaction may be, for example, a node addition (node ​​join) in group (B) 200B. The transaction data may include node parameters of the added node.

[0069] Third, node (A) managing ledger (A) updates ledger (A) by adding the mth block to ledger (A). The mth block includes, in its block header section, a hash value calculated from the (m-1)th block, which is the previous block in ledger (A). The mth block also includes, in its transaction data section, transaction data for at least one transaction in group (A) 200A and ledger information for ledger (B). The ledger information includes a hash value calculated from the most recent block in ledger (B) at the time the mth block is added, i.e., the 0th block of ledger (B), and a chain ID indicating ledger (B). The ledger information may further include a block height indicating 0, which is the block number of the 0th block.

[0070] Fourth, node (B) managing ledger (B) updates ledger (B) by adding the first block in ledger (B) to ledger (B). The first block includes, in its block header portion, the block header of the latest block in ledger (A) at the time the first block is added, as ledger information related to ledger (A). The first block also includes, in its block header portion, a hash value calculated from the 0th block of ledger (B). The first block also includes, in its transaction data portion, transaction data related to at least one transaction in group (B) 200B. Here, the transaction may be, for example, a node addition (node ​​join) in group (B) 200B. The transaction data may include node parameters of the added node.

[0071] Fifth, node (A) managing ledger (A) updates ledger (A) by adding the nth block to ledger (A). The nth block includes, in its block header section, a hash value calculated from the (n-1)th block, which is the previous block in ledger (A). The nth block also includes, in its transaction data section, transaction data for at least one transaction in group (A) 200A and ledger information for ledger (B). The ledger information includes a hash value calculated from the most recent block in ledger (B) at the time the nth block is added, i.e., the first block of ledger (B), and a chain ID indicating ledger (B). The ledger information may further include a block height indicating 1, which is the block number of the first block.

[0072] 12 and 13 are diagrams showing an example of operation in a case where, after group (A) 200A is formed, a new group (B) 200B is formed below group (A) 200A, and then a new group (C) 200C is formed below group (A) 200A. Here, a node belonging to group (A) 200A is referred to as node (A), a node belonging to group (B) 200B is referred to as node (B), and a node belonging to group (C) 200C is referred to as node (C). Here, differences from the operation in FIG. 11 will be mainly explained.

[0073] As shown in FIG. 13, first, node (A) managing ledger (A) updates ledger (A) by adding the (m-1)th block to ledger (A). Second, group (B) 200B is formed. Node (B) managing ledger (B) updates (generates) ledger (B) by adding the first block in ledger (B), i.e., the 0th block, to ledger (B). Third, node (A) managing ledger (A) updates ledger (A) by adding the mth block to ledger (A). This operation is similar to the operation in FIG. 11.

[0074] Fourth, node (A) managing ledger (A) updates ledger (A) by adding the (n-1)th block to ledger (A). The (n-1)th block has a block header including a hash value calculated from the previous block in ledger (A) and transaction data for at least one transaction in group (A) 200A. The block header may further include at least one of a chain ID (parent chain ID) indicating ledger (A) and a block height indicating the block number (n-1) of the block.

[0075] Fifth, group (C) 200C is formed. Node (C) managing ledger (C) updates (generates) ledger (C) by adding the first block in ledger (C), i.e., the 0th block, to ledger (C). The 0th block includes, in its block header section, the block in ledger (A) that is the latest at the time of adding the 0th block, i.e., the block header of the n-1th block in ledger (A), as ledger information related to ledger (A). Furthermore, the 0th block includes, in its transaction data section, transaction data related to at least one transaction in group (C) 200C. Here, the transaction may be, for example, a node addition (node ​​join) in group (C) 200C. The transaction data may include node parameters of the added node.

[0076] Sixth, node (A) managing ledger (A) updates ledger (A) by adding the nth block to ledger (A). The nth block includes, in its block header section, a hash value calculated from the (n-1)th block, which is the previous block in ledger (A). The nth block also includes, in its transaction data section, transaction data for at least one transaction in group (A) 200A and ledger information for ledger (C). The ledger information includes a hash value calculated from the most recent block in ledger (C) at the time the nth block is added, i.e., the 0th block of ledger (C), and a chain ID indicating ledger (C). The ledger information may further include a block height indicating 0, which is the block number of the 0th block.

[0077] Seventh, node (C) managing ledger (C) updates ledger (C) by adding the first block in ledger (C) to ledger (C). The first block includes, in its block header section, the block header of the latest block in ledger (A) at the time the first block is added, i.e., the nth block in ledger (A), as ledger information related to ledger (A). The first block also includes, in its transaction data section, transaction data related to at least one transaction in group (C) 200C. Here, the transaction may be, for example, a node addition (node ​​join) in group (C) 200C. The transaction data may include node parameters of the added node.

[0078] Eighth, node (B) managing ledger (B) updates ledger (B) by adding the first block in ledger (B) to ledger (B). The first block includes, in its block header section, the block header of the latest block in ledger (A) at the time the first block is added, i.e., the nth block in ledger (A), as ledger information related to ledger (A). The first block also includes, in its transaction data section, transaction data related to at least one transaction in group (B) 200B. Here, the transaction may be, for example, a node addition (node ​​join) in group (B) 200B. The transaction data may include node parameters of the added node.

[0079] Ninth, node (A) managing ledger (A) updates ledger (A) by adding the n+1th block to ledger (A). The n+1th block includes, in its block header, a hash value calculated from the nth block, which is the previous block in ledger (A). The n+1th block also includes, in its transaction data portion, transaction data for at least one transaction in group (A) 200A, ledger information for ledger (B), and ledger information for ledger (C). The ledger information for ledger (B) includes a hash value calculated from the most recent block in ledger (B) at the time the n+1th block is added, i.e., the first block of ledger (B), and a chain ID indicating ledger (B). The ledger information may further include a block height indicating 0, which is the block number of the first block in ledger (B). The ledger information for the ledger (C) includes the latest block of the ledger (C) at the time of adding the n+1th block, i.e., the hash value calculated from the first block of the ledger (C), and a chain ID indicating the ledger (C). The ledger information may further include a block height indicating 0, which is the block number of the first block of the ledger (C).

[0080] (Grouping of lower-level groups) Next, the grouping of lower hierarchical groups according to this embodiment will be described with reference to FIGS.

[0081] As shown in FIG. 14, the hierarchical network 10 has a plurality of lower hierarchical groups, group (B) 200B to group (D) 200D. Nodes 100 belonging to the plurality of lower hierarchical groups are placed in one of the plurality of lower hierarchical groups according to the length of the sleep time of the node 100. As described above, low-performance nodes such as IoT devices communicate intermittently to reduce power consumption, enter a sleep state (standby state) when not communicating, and no transactions occur during the sleep time (standby time). By dividing nodes into groups according to the range of sleep time at the second lower hierarchical level and below, they can be grouped into groups with long and short sleep times.

[0082] Specifically, devices are divided into groups based on similar sleep times. Devices with long sleep times have a low transaction frequency and therefore a low calculation frequency, which makes it possible to reduce the calculation frequency. Here, devices with long sleep times tend to have low performance, so this grouping is effective. In this way, by grouping nodes based on the frequency of transaction occurrence, it is possible to reduce the amount of calculation and prevent the ledger from becoming too large.

[0083] The sleep time of each node 100 belonging to one of the multiple lower hierarchical groups may be within a first predetermined time range. The sleep time of each node 100 belonging to another lower hierarchical group different from the one lower hierarchical group may be within a second predetermined time range different from the first predetermined time. In the example of FIG. 14 , each node 100 belonging to group (B) 200B has a sleep time longer than one day. Each node 100 belonging to group (C) 200C has a sleep time of one day or less and one hour or more. Each node 100 belonging to group (D) 200D has a sleep time of less than one hour. Note that this grouping is merely an example and is not limited to the example of FIG. 14 .

[0084] The maximum number of nodes 100 belonging to each group may be determined according to the performance of the nodes 100 belonging to that group. For example, the limit on the number of nodes in one group may be determined depending on the node with the lowest performance among the nodes participating in that group. The greater the number of nodes in one group, the greater the update frequency and size of the ledger are likely to be. Therefore, the maximum number of groups to which the node with the lowest performance belongs is determined according to the performance of the node with the lowest performance.

[0085] As shown in Figure 15, if the number of nodes 100 belonging to a lower hierarchical group exceeds the maximum number of nodes 100 belonging to that lower hierarchical group, a new lower hierarchical group may be formed. Figure 15 shows an example in which the number of nodes 100 with sleep times longer than one day exceeds the maximum number (limit number) of group (B) 200B, and a new group (E) 200E consisting of nodes 100 with sleep times longer than one day is formed. In this way, if there are more nodes than the limit number, a new group with the same sleep time range is added. Alternatively, if the number of nodes 100 belonging to a lower hierarchical group exceeds the maximum number of nodes 100 belonging to that lower hierarchical group, a layer lower than that may be added, and an even lower group may be formed.

[0086] (Priority within the group) Next, the priority order within a group according to the embodiment will be described with reference to FIGS.

[0087] As shown in FIG. 16, performance parameters are used to assign priorities to nodes in each group. The priorities are calculated based on at least one of the performance parameters: battery capacity, computing power, storage capacity, and sleep time. Within a group, the node with the highest priority is set as the parent node, the node with the second highest priority is set as the sub-parent node, and the remaining nodes are set as child nodes. In FIG. 16, the priority of each node 100 in group (B) 200B, which is a lower hierarchical group, is indicated by a number. For example, when a new node 100 is added to a lower hierarchical group, the new node 100 or another node 100 determines whether to set the new node 100 as a parent node, sub-parent node, or child node based on the performance of the new node 100.

[0088] The multiple nodes 100 that form one group include a parent node that belongs to both the upper hierarchy group and the lower hierarchy group and manages the lower hierarchy ledger and the upper hierarchy ledger, a sub-parent node that belongs to the lower hierarchy group and is changed to a new parent node when the parent node no longer functions as the parent node, and a child node 100 that belongs to the lower hierarchy group and does not correspond to either the parent node 100 or the sub-parent node 100.

[0089] Here, the sub-parent node 100 has higher performance than the child node 100, and the parent node 100 has higher performance than the sub-parent node 100. Also, the sub-parent node 100 plays more roles than the child node 100, and the parent node 100 plays more roles than the sub-parent node 100. For this reason, the roles played by the nodes 100 are matched with their performance.

[0090] For example, when a transaction occurs in a lower hierarchical group and the lower hierarchical ledger is updated, the parent node notifies the upper hierarchical group of the update. As a result, a transaction occurs in the upper hierarchical group (the upper hierarchical ledger is updated). Specifically, the parent node notifies the nodes 100 belonging to the upper hierarchical group of the update to the lower hierarchical ledger in response to the transaction within the lower hierarchical group, and the nodes 100 belonging to the upper hierarchical group update the upper hierarchical ledger in response to the notification from the parent node.

[0091] Furthermore, when the upper-level ledger of the upper-level group is updated, the parent node passes the upper-level ledger to the sub-parent node. In other words, when the upper-level ledger is updated, the parent node shares the updated upper-level ledger with the sub-parent node.

[0092] In the example of Figure 16, when a transaction occurs in group (B) 200B and the ledger (B) is updated, the parent node of group (B) 200B notifies group (A) 200A that the ledger (B) has been updated. As a result, a transaction occurs in group (A) 200A (the ledger (A) is updated). Furthermore, when the ledger (A) of group (A) 200A is updated, the parent node of group (B) 200B passes the ledger (A) to the sub-parent node of group (B) 200B.

[0093] As shown in Figure 17, if a parent node is deleted from a group for some reason (for example, by leaving the group itself or by being forcibly deleted due to fraudulent activity), the sub-parent node with second priority automatically becomes the first priority, i.e., the new parent node. The priority of each other node is also raised by one. Furthermore, if a sub-parent node is changed to a new parent node, or if a sub-parent node no longer functions as the sub-parent node, the child node with the highest priority among multiple child nodes is changed to the new sub-parent node. Note that, because priority must be linked to each group, each node 100 has a priority parameter value linked to its chain ID.

[0094] The node 100 initially set as the parent node is selected based on performance parameters, so there is no problem. However, the new parent node set when a parent node is deleted may have insufficient performance parameters. Therefore, a threshold may be set for the performance parameters of each layer, and parent nodes whose performance is below the threshold may be changed (rotated) every certain number of transactions. In other words, if a sub-parent node is set as the new parent node following the deletion of a parent node, and the performance of the new parent node does not meet a predetermined standard, the node 100 set as the parent node may be changed every certain number of transactions. When changing, the node sets its own priority to the lowest in the group, and the sub-parent node becomes the next parent node. The number of transactions required to rotate a parent node is stored as a node parameter and can be changed.

[0095] (An example of node parameters to be stored in the ledger) Next, an example of node parameters stored in the ledger according to the embodiment will be described with reference to FIG.

[0096] As described above, in the embodiment, node parameters may be stored in a ledger. For example, when a new node 100 is added to the upper hierarchical group, each node 100 belonging to the upper hierarchical group may update the upper hierarchical ledger to add the parameters of the new node 100 added to the upper hierarchical group to the upper hierarchical ledger. When a new node 100 is added to the lower hierarchical group, each node 100 belonging to the lower hierarchical group may update the lower hierarchical ledger to add the parameters of the new node 100 added to the lower hierarchical group to the lower hierarchical ledger.

[0097] As shown in FIG. 18, nodes 100 other than node 100A in the highest hierarchy and node 100B2 in the lowest hierarchy, i.e., node 100B1, belong to two groups. Therefore, node 100B1 needs to maintain a common ledger for each group, and has two ledgers (ledger (A) and ledger (B)). Here, the two groups (group (A) and group (B)) each have parameters that allow them to be distinguished in a manner linked to a chain ID. As described above, ledger (A), which is the higher hierarchy ledger, contains the hash value, etc., of ledger (B), which is the lower hierarchy ledger, and therefore when ledger (B) is updated, ledger (A) also needs to be updated.

[0098] The node parameters stored in the ledger are, for example, at least one of the following parameters:

[0099] Chain ID: A maximum of two are required. The chain ID allows you to determine which of two groups is the higher-level group.

[0100] Ledger hash value: A value linked to the chain ID, and up to two are required.

[0101] Node priority: A value associated with the chain ID, with a maximum of two required.

[0102] Parent Chain ID: The ID of the higher-level chain in which the parent node of the group participates. By clarifying the parent-child relationship of the group, it is possible to smoothly automate the hierarchical structure.

[0103] Validator node ID: The ID of the node that verified the ledger.

[0104] Parent node rotation value: The number of transactions that will cause parent node rotation. When the number of parent node transactions reaches this value, parent node rotation will occur.

[0105] Parent node transaction count: The number of transactions that have occurred since becoming a parent node.

[0106] Node performance parameters: For example, at least one of battery capacity, computing power, storage capacity (memory margin information), and sleep time.

[0107] (Ledger Lock) Next, with reference to FIGS. 19 to 24, the locking of the ledger according to the embodiment will be described.

[0108] As described above, by configuring the hierarchical structure network 10, it is possible for low-spec devices to participate in the blockchain as nodes. Also, in the embodiment, when updating the lower hierarchical ledger of a lower hierarchical group, first, the information of the upper hierarchical ledger is included in the lower hierarchical ledger to update the lower hierarchical ledger, and second, the information of the updated lower hierarchical ledger is included in the upper hierarchical ledger to update the upper hierarchical ledger, thereby linking the upper hierarchical ledger and the lower hierarchical ledger (see FIG. 11). That is, in the embodiment, the operations such as steps S1 to S3 shown in FIG. 19 are repeated to link the upper hierarchical ledger and the lower hierarchical ledger in chronological order.

[0109] 19, in step S1, a node (A) belonging to group (A) 200A that manages ledger (A), which is a higher-level ledger, updates ledger (A) by adding a new block to ledger (A). The new block has a block header that includes a hash value calculated from the previous block in ledger (A) and transaction data for at least one transaction in group (A) 200A.

[0110] In step S2, node (B) belonging to group (B) 200B, which manages ledger (B), a lower-level ledger, updates ledger (B) by adding a new block to ledger (B). The new block includes, in its block header section, the block header of the block in ledger (A) that is the latest at the time of adding the block, as ledger information related to ledger (A), and also includes, in its transaction data section, transaction data related to at least one transaction in group (B) 200B.

[0111] In step S3, node (A) belonging to group (A) 200A that manages ledger (A) updates ledger (A) by adding a new block to ledger (A). The new block includes, in its block header section, a hash value calculated from the previous block in ledger (A), and, in its transaction data section, transaction data for at least one transaction in group (A) 200A and ledger information for ledger (B). The ledger information includes a hash value calculated from the latest block in ledger (B) at the time of block addition and a chain ID indicating ledger (B). The ledger information may further include a block height, which is the block number of the block added in ledger (B).

[0112] In this way, after a new block is added to ledger (B) in step S2, information about the added new block must be written to a new block in ledger (A) in step S3. However, if step S2 occurs after step S3, that is, if the update process for ledger (B) is not completed in time for the update of ledger (A), ledger (A) and ledger (B) cannot be linked in chronological order. In that case, group (A) 200A cannot be used when verifying group (B) 200B, and security cannot be guaranteed if ledger (B) is not long enough.

[0113] Therefore, in the embodiment, such a problem is solved by not updating the ledger for a predetermined period (hereinafter referred to as the "lock period") after the ledger is updated (i.e., locking the ledger). That is, in the embodiment, a node 100 belonging to a first group (upper hierarchical group) in a first hierarchical level different from the lowest hierarchical level manages a first ledger (upper hierarchical ledger) including transaction data related to transactions within the first group, and performs a ledger lock so that the first ledger is not updated for the lock period after the first ledger is updated. When the lock period ends (i.e., the lock is released), if a second ledger (lower hierarchical ledger) managed by a second group (lower hierarchical group) in a second hierarchical level below the first hierarchical level has been updated within the lock period, the node 100 updates the first ledger so that ledger information related to the updated second ledger is included in the first ledger.

[0114] In this way, by locking the upper hierarchical ledger for the lock period, it becomes easier to avoid the situation where the update process of the lower hierarchical ledger is not completed in time for the update of the upper hierarchical ledger, and it becomes easier to link the upper hierarchical ledger and the lower hierarchical ledger in chronological order. As a result, it becomes easier to use the upper hierarchical group when checking the calculations of the lower hierarchical group, and it becomes easier to ensure security even if the length of the lower hierarchical ledger is not sufficient. Note that, although an example in which the first group is group (A) 200A and the second group is group (B) 200B will be described below, the first group may be group (B) 200B and the second group may be a group in a lower hierarchical level than group (B) 200B.

[0115] FIG. 20 is a diagram illustrating a locking operation for updating a ledger according to the embodiment.

[0116] 20, in step S11, node (A) belonging to group (A) 200A updates ledger (A) by adding a new block to ledger (A). The new block has a block header including a hash value calculated from the previous block in ledger (A) and transaction data for at least one transaction in group (A) 200A.

[0117] In step S12, node (A) belonging to group (A) 200A starts a timer (hereinafter also referred to as a "lock timer") when the update of ledger (A) is completed in step S11, and locks ledger (A) for the lock period corresponding to the lock timer.

[0118] In step S13, node (B) belonging to group (B) 200B updates ledger (B) by adding a new block to ledger (B) during the lock period. The new block includes, in its block header section, the block header of the block in ledger (A) that is latest at the time of adding the block, as ledger information related to ledger (A), and includes, in its transaction data section, transaction data related to at least one transaction in group (B) 200B. Thereafter, if there is no transaction, node (B) belonging to group (B) 200B waits until a transaction occurs.

[0119] In step S14, node (A) belonging to group (A) 200A updates ledger (A) by adding a new block to ledger (A) after the lock timer expires. The new block includes, in its block header section, a hash value calculated from the previous block in ledger (A), and, in its transaction data section, transaction data for at least one transaction in group (A) 200A and ledger information for ledger (B). The ledger information includes a hash value calculated from the latest block in ledger (B) at the time of block addition and a chain ID indicating ledger (B). The ledger information may further include a block height, which is the block number of the block added in ledger (B).

[0120] In step S15, node (A) belonging to group (A) 200A starts a lock timer when updating ledger (A) is completed in step S14, and locks ledger (A) for the lock period corresponding to the lock timer. It is assumed that ledger (B) is not updated during this lock period.

[0121] In step S16, after the lock timer expires, node (A) belonging to group (A) 200A updates ledger (A) by adding a new block to ledger (A). The new block includes, in its block header portion, a hash value calculated from the previous block in ledger (A), and includes, in its transaction data portion, transaction data for at least one transaction in group (A) 200A.

[0122] In step S17, node (A) belonging to group (A) 200A starts a lock timer when updating ledger (A) is completed in step S16, and locks ledger (A) for the lock period corresponding to the lock timer.

[0123] In this way, each time a node (A) belonging to group (A) 200A updates ledger (A), it locks ledger (A) for a certain period of time after the update. While ledger (A) is locked, transaction data generated in group (A) 200A cannot be stored in ledger (A).

[0124] Therefore, during the locking period, it is conceivable that the proposer, which is the node that generates the block to be added to ledger (A), will hold the transaction data. However, if the proposer is a node with low specifications, there is a concern that the node will not be able to hold the transaction data. Alternatively, during the locking period, it is conceivable that the node that generated the transaction will hold the transaction data for that transaction. However, if the node that generated the transaction is a node with low specifications, there is a concern that the node will not be able to hold the transaction data.

[0125] Therefore, in an embodiment, when a transaction occurs in the node (A) belonging to group (A) 200A within a locking period, if the node (A) has sufficient memory capacity (hereinafter referred to as "memory capacity") to hold transaction data related to the transaction, the node (A) holds the transaction data. On the other hand, if the node (A) does not have sufficient memory capacity, the node (A) has another node with sufficient memory capacity hold the transaction data. As a result, even if a node with low specifications generates a transaction during a locking period, the transaction data can be held by having the other node hold the transaction data. In this way, by having a node with sufficient memory capacity hold the transaction data, even a node with low specifications can participate in a hierarchical blockchain group incorporating a locking technique.

[0126] Here, when a transaction occurs in the node (A) within the lock period, if the node (A) belonging to the group (A) 200A does not have sufficient memory and there is no other node (A) in the group (A) 200A with sufficient memory, the node (A) may cause another node belonging to a group in a higher hierarchical level than the group (A) 200A to hold the transaction data. The higher hierarchical level group is formed by nodes with higher specifications, so it is easy to hold the transaction data.

[0127] If a node (A) belonging to group (A) 200A is not the proposer and has held transaction data during the lock period, the node (A) transmits the transaction data held by the node (A) to the proposer when the lock period ends. This allows the proposer to generate a new block in the ledger (A) using the held transaction data. Note that the proposer may be a node in group (A) 200A with high specifications indicated by the specification information in the ledger (A). In other words, the proposer may be a node that has been set in advance within group (A) 200A. The proposer may also be a parent node.

[0128] In the embodiment, the ledger (A) includes memory margin information regarding the memory capacity of each node (A) belonging to the group (A) 200A. When a transaction occurs in the node (A) within the lock period and the node (A) does not have memory margin, the node (A) belonging to the group (A) 200A determines another node from the group (A) 200A that will hold the transaction data based on the memory margin information included in the ledger (A). This makes it possible to use the common ledger (A) to search for a node with sufficient memory margin when a transaction occurs in the node (A) within the lock period.

[0129] When a new node (A) joins group (A) 200A, node (A) belonging to group (A) 200A updates ledger (A) so that information about the memory capacity of the new node (A) is included in the memory margin information in ledger (A). In other words, when a new node (A) joins group (A) 200A, information about the memory capacity of the new node (A) is stored in ledger (A). This makes it possible for ledger (A) to contain information about the memory capacity of all nodes (A) belonging to group (A) 200A.

[0130] When a transaction occurs in the node (A) belonging to the group (A) 200A within the lock period and the node (A) does not have sufficient memory, the node (A) transmits flag information (hereinafter referred to as a "sufficient memory flag") indicating that the node (A) does not have sufficient memory along with the transaction data to other nodes (specifically, other nodes with sufficient memory). The flag information is managed within the group (A) 200A as part of the memory sufficiency information in the ledger (A). This allows the ledger (A) to contain information regarding the real-time memory sufficiency of each node (A) in the group (A) 200A.

[0131] Thus, according to the embodiment, when a node with low specifications generates transaction data during a lock period, it searches for another node with sufficient memory to store the transaction data on its behalf. Because each node stores specification information (especially memory availability) in the ledger when joining a group, it can use the ledger to search for a node with sufficient memory.

[0132] For example, the memory margin information of each node stored in the ledger may be the "memory size" and "margin flag" of each node. "Memory size" refers to the size (capacity) of memory determined by the node's specifications. "Memory" may be any memory capable of storing transaction data, and may be non-volatile memory and / or volatile memory. The "margin flag" is managed as follows:

[0133] First, when a new node is registered (i.e., when it joins a group), the node's performance (memory size) information is stored in the group's ledger. At this time, if the memory size is equal to or greater than the specified value, the "margin flag" is set to ON ("1") as the initial value, and if the memory size is less than the specified value, the "margin flag" is set to OFF ("0") as the initial value.

[0134] Second, when a transaction occurs, the margin flag is updated in the following steps 1 to 3.

[0135] STEP 1: When a transaction occurs on the local node, check the remaining memory capacity of the local node.

[0136] STEP 2: If "transaction data size ≦ remaining memory", the "margin flag" is set to ON. On the other hand, if "transaction data size > remaining memory", the "margin flag" is set to OFF.

[0137] STEP 3: The transaction data and the margin flag are sent to another node that has memory margin.

[0138] Other nodes with sufficient memory will return an Ack (positive acknowledgement) if they have successfully received the transaction data, and a Nak (negative acknowledgement) if they have not successfully received the transaction data. Note that other nodes with sufficient memory will not return anything if they are unable to receive the transaction data because they are in sleep mode or for other reasons.

[0139] If there are no other nodes with memory to spare in the group, the node that generated the transaction data passes the transaction data to another node in a higher hierarchical group with memory to spare via the parent node of the group. Alternatively, an external database can be used in case there are no other nodes with memory to spare in the group. However, using an external database has the problem of lower security compared to using a ledger.

[0140] Fig. 21 is a diagram showing an example of operation according to the embodiment. In Fig. 21, a group (herein referred to as "group (X)") including nodes 100a to 100e is formed, and each node 100 holds a ledger (herein referred to as "ledger (X)") specific to the group (X). Each node 100 manages a lock timer set with a common timer value, starts the lock timer every time the ledger (X) is updated, and locks the ledger (X) while the lock timer is running (i.e., during the lock period).

[0141] As shown in Fig. 21, in step S21, when each node 100 is newly registered (i.e., when it joins group (X)), performance information (including memory margin information) of the node is stored in ledger (X). At this time, if the memory size is equal to or greater than a specified value, the initial value of the "margin flag" is set to ON, and if the memory size is less than the specified value, the initial value of the "margin flag" is set to OFF. For example, nodes 100a to 100d have their "margin flag" set to OFF, and node 100e has its "margin flag" set to ON.

[0142] In step S22, the node 100a generates transaction data during the lock period of the ledger (X).

[0143] In step S23, since node 100a does not have enough memory to store the transaction data, it checks the memory margin information included in ledger (X) and searches for other nodes with memory margins. That is, node 100a determines from group (X) which other nodes will store the transaction data, based on ledger (X). Here, it is assumed that node 100a has determined that node 100e, which has enough memory margins, will store the transaction data. Note that if there is no other node in group (X) with enough memory margins, node 100a may determine that the transaction data will be stored in another node in a group higher in the hierarchy than group (X) via a parent node in group (X).

[0144] In step S24, node 100a passes the transaction data to node 100e, which has spare memory. If node 100e has received the transaction data successfully, it returns an Ack (positive acknowledgement), and if it has not received the transaction data successfully, it returns a Nak (negative acknowledgement). Here, it is assumed that node 100e has received the transaction data successfully. Node 100e holds the transaction data. However, it is assumed that node 100e is not the proposer.

[0145] In step S25, when the lock timer expires (when the lock is released), node 100e passes the transaction data to the proposer. The proposer may be any of nodes 100a to 100d. The proposer generates a new block including the transaction data and updates ledger (X) by adding the new block to ledger (X). The new block is shared by each node in group (X), and each node in group (X) updates ledger (X).

[0146] In this way, a node 100e with sufficient specifications (specifically, memory capacity) can hold transaction data during the locking period, allowing even nodes with low specifications to participate in a hierarchical blockchain group that incorporates locking techniques.

[0147] Next, a method for setting a lock period according to an embodiment will be described. As described above, the lock period is determined by a lock timer. The lock timer is set individually for each group and determines the update interval of the ledger for that group. Figures 22 and 23 are diagrams for explaining a method for setting a lock period according to an embodiment.

[0148] 22 and 23, the hierarchical network 10 includes groups 200A to 200G and is configured with three hierarchical levels. Groups 200A to 200G manage ledgers (A) to (G), respectively. Group 200A is the group in the highest hierarchical level, groups 200D to 200G are groups in the lowest hierarchical level, and groups 200B and 200C are groups in intermediate hierarchical levels.

[0149] Each node 100 belonging to each group 200 manages a lock timer specific to the group. The value of the lock timer in a certain group 200, i.e., the ledger update interval in that group 200, is determined by the frequency of transactions occurring in that group 200 and the sleep time of the nodes 100 participating in that group 200.

[0150] However, as shown in FIG. 22, the ledger update interval in the group 200 is set so that "the lock timer of the higher hierarchical level is smaller than the lock timer of the lower hierarchical level." In other words, the ledger update interval is set so that the lock timer value (ledger update interval) is shorter for higher hierarchical levels, and the lock timer value is longer for lower hierarchical levels. For example, the lock timer value used in group 200A is smaller than the lock timer value used in group 200B. Since the performance (specifications) of nodes 100 are lower for lower hierarchical levels, even nodes 100 with low performance can participate in the blockchain group by setting the lock timer value (ledger update interval) to be longer for lower hierarchical levels.

[0151] Also, as shown in Figure 23, the setting is such that "lock timer of upper hierarchical level>ledger update processing time of lower hierarchical level." Ledger update processing time refers to the time (required time) required for ledger update processing. For example, the value of the lock timer used in group 200A is longer than the update processing time of ledger (B) in group 200B. By setting it in this way, it is possible to prevent the ledger of a higher hierarchical level from being updated during ledger update processing of a lower hierarchical level.

[0152] Even with this setting, a situation may arise where a ledger at a higher level is updated during ledger update processing at a lower level. For example, a situation may arise where ledger (A) at group 200A is updated during ledger update processing at group 200B. Hereinafter, a group at a certain level will also be referred to as a "parent group," a ledger managed by the parent group will also be referred to as a "parent ledger," a group at the level immediately below that level will also be referred to as a "child group," and a ledger managed by the child group will also be referred to as a "child ledger."

[0153] If the parent ledger is updated before the child ledger is updated, the parent node of the child group will notify the parent ledger that it has been updated. In this case, the child ledger will fail to update, and the child ledger update process will be performed again immediately. For example, if ledger (A) in group 200A is updated while ledger (B) in group 200B is being updated, the parent node in group 200B will notify the other nodes in group 200B that ledger (A), the parent ledger, has been updated. In this case, each node in group 200B will consider the update process for ledger (B) to have failed, and will redo the update of ledger (B). In other words, if each node in group 200B detects that ledger (A) has been updated while ledger (B) is being updated, it will consider the update of ledger (B) to have failed, and will perform the update process for ledger (B) again. Specifically, if each node in group 200B fails to update ledger (B), it regenerates a block that also includes the transactions that occurred within group 200B during that time, and performs the ledger (B) update process. Note that even if multiple child ledger blocks are generated from the same parent ledger, they can each be updated if they are able to update the parent ledger in time.

[0154] However, if updates to a child ledger fail consecutively, the lock timer for the parent ledger may be too short. Therefore, if updates to a child ledger fail consecutively, the lock timer for the parent ledger is extended. For example, when each node belonging to group 200A detects that updates to ledger (B) have failed a predetermined number of times in succession, it extends the lock period used in group 200A, i.e., the lock timer for ledger (A).

[0155] When updating a child ledger, the child group notifies the parent group of the child ledger update information. If the parent ledger update and child ledger update information notification occur simultaneously, the parent ledger update takes priority because the child ledger update information notification must come before the parent ledger update process. Therefore, the child ledger update is confirmed after the information has been input into the parent ledger.

[0156] 24 is a diagram showing a first specific example of operation related to ledger locking according to an embodiment. In this first specific example, groups 200A, 200B, and 200D manage ledgers (A), (B), and (D), respectively, and group 200A is the parent group of group 200B, which is also the parent group of group 200D. In other words, group 200B is a child group of group 200A, and group 200D is a child group of group 200B.

[0157] 24, in step S31, each node in group 200A updates ledger (A) and then locks ledger (A) for the lock period of ledger (A) from the update. The lock period of ledger (A) is longer than the update processing time of child ledger (B).

[0158] In step S32, each node in group 200B updates ledger (B) using parent ledger (A) during the lock period of parent ledger (A), and then locks ledger (B) from the update for the lock period of ledger (B). Here, the lock period of ledger (B) is longer than the lock period of parent ledger (A). Furthermore, the lock period of ledger (B) is longer than the update processing time of child ledger (D).

[0159] In step S33, when the lock period of ledger (A) ends, each node in group 200A updates ledger (A) using child ledger (B) updated during the lock period, and then locks ledger (A) from the update until the lock period of ledger (A).

[0160] In step S34, each node in group 200D updates ledger (D) using parent ledger (B) during the lock period of parent ledger (B), and then locks ledger (D) from the update for the lock period of ledger (D), which is longer than the lock period of parent ledger (B).

[0161] In step S35, each node in group 200A updates ledger (A) and then locks ledger (A) for the lock period of ledger (A) from the update.

[0162] In step S36, each node in group 200B updates ledger (B) during the lock period of parent ledger (A) using the latest parent ledger (A) at that time and child ledger (D) updated during the lock period of ledger (B), and then locks ledger (B) from the update for the lock period of ledger (B).

[0163] In step S37, when the lock period of ledger (A) ends, each node in group 200A updates ledger (A) using child ledger (B) that was updated during the lock period, and then locks ledger (A) from the update until the lock period of ledger (A).

[0164] 25 is a diagram showing a second specific example of operation related to ledger locking according to an embodiment. In this second specific example, groups 200A, 200B, and 200C manage ledgers (A), (B), and (C), respectively, and group 200A is the parent group of groups 200B and 200C. In other words, groups 200B and 200C are each child groups of group 200A.

[0165] As shown in FIG. 25, in step S41, each node in group 200A updates ledger (A) and then locks ledger (A) for a lock period of ledger (A) from the update.

[0166] In step S42, each node in group 200C updates ledger (C) using the latest parent ledger (A) at that time during the lock period of parent ledger (A), and then locks ledger (C) from the update for the lock period of ledger (C).

[0167] In step S43, each node in group 200B updates ledger (B) using the latest parent ledger (A) at that time during the lock period of parent ledger (A), and then locks ledger (B) from the update for the lock period of ledger (B).

[0168] In step S44, when the lock period of ledger (B) ends during the lock period of parent ledger (A), each node in group 200B updates ledger (B) using the latest parent ledger (A) at that time, and then locks ledger (B) from the update for the lock period of ledger (B).

[0169] In step S45, when the lock period of ledger (A) ends, each node in group 200A updates ledger (A) using child ledgers (B) and (C) updated during that lock period. Here, during the lock period of ledger (A), child ledger (B) is updated twice (steps S43 and S44). Each node in group 200A updates ledger (A) to include in ledger (A) the ledger information (B information) of each of the two blocks of child ledger (B) added in steps S43 and S44. By including the height in the ledger information, it is possible to identify the ledger information of each of the two blocks by the height. In addition, during the lock period of ledger (A), child ledger (C) is updated once (step S42). Each node in group 200A updates ledger (A) to include in ledger (A) the ledger information (C information) of the block of child ledger (C) added in step S42. Since each of the B information and C information includes a chain ID, it is possible to identify which child ledger the information corresponds to by the chain ID.

[0170] Then, in step S46, each node in group 200A updates ledger (A) and then locks ledger (A) for the lock period of ledger (A) from the update. Here, it is assumed that ledger (C) is in the process of being updated when ledger (A) is updated.

[0171] In step S47, if each node in group 200C detects that the parent ledger (A) has been updated while the ledger (C) is being updated, it considers the update process of ledger (C) to have failed. In this case, even if each node in group 200A receives notification of update information for ledger (C) from a node in group 200C, it rejects the notification (step S48).

[0172] In step S49, in response to the failure of the ledger (C) update process, each node in group 200C regenerates a block to which the transactions in group 200C during that time have been added, and performs the ledger (C) update process again.

[0173] (Basic operation flow example) Next, an example of a basic operation flow according to the embodiment will be described with reference to FIGS.

[0174] (1) Example of flow when adding a node Fig. 26 is a diagram showing an example of a flow when a node is added to the hierarchical structure network 10 according to the embodiment. In Fig. 26, steps that can be omitted are indicated by dashed lines.

[0175] In step S101, the newly added node applies for addition to the nodes already participating in the group.

[0176] In step S102, the node that has received the addition request or another node uses, for example, a quarantine network to perform a preliminary check to see if the node that has made the addition request has sufficient computing power and is not in an illegal state.

[0177] If the result of the preliminary check is NG (step S102: NO), the node or other node that received the addition request rejects the addition request in step S103. On the other hand, if the result of the preliminary check is OK (step S102: YES), the process proceeds to step S104.

[0178] In step S104, the node or other node that has received the addition request decides whether to approve the addition request. The method for approving the addition may be decided by an administrator. Alternatively, the method may involve voting by all or some of the nodes to decide whether to allow the addition. In the case of a public type group (open to anyone), step S104 may be skipped.

[0179] If it is determined that the addition is not permitted (step S104: NO), the node or other node that received the addition request rejects the addition request in step S105. On the other hand, if it is determined that the addition is permitted (step S104: YES), the process proceeds to step S106.

[0180] In step S106, the node that has received the addition request or another node determines the tier to which the newly added node will be added (placed) based on the performance of the newly added node. Here, the tier may be determined automatically by comparing a preset threshold with a performance parameter. Alternatively, the tier may be determined based on the performance superiority or inferiority of other nodes. Alternatively, the tier may be determined by voting by all or some of the nodes.

[0181] In step S107, the node or other nodes that have received the addition request determine a group to which the newly added node will be added (placed) based on the sleep time of the newly added node. Here, the group may be determined automatically by comparing the sleep time with a preset threshold. Alternatively, the group may be determined by comparing the sleep time with that of other nodes. Alternatively, the group may be determined by voting by all or some of the nodes. Note that if the newly added node is to be added to the top layer or if there is only one group in the same layer, step S107 may be skipped.

[0182] In step S108, each node belonging to the group to which the newly added node will join adds the performance parameters of the newly added node to its own ledger. As described above, the ledger stores the performance parameters of each node participating in the group.

[0183] In step S109, the node that received the addition request or another node determines the priority of the newly added node according to the performance of the newly added node. Agreement on the priority may be performed using the same process as consensus formation for normal transactions.

[0184] (2) Example of parent node rotation flow FIG. 27 is a diagram showing an example of the flow of parent node rotation in the hierarchical structure network 10 according to the embodiment.

[0185] In step S201, the parent node or another node determines whether the performance parameter of the parent node is equal to or less than the threshold. If the performance parameter of the parent node is higher than the threshold (step S201: NO), parent node rotation is unnecessary (step S202). On the other hand, if the performance parameter of the parent node is equal to or less than the threshold (step S201: YES), parent node rotation is enabled.

[0186] In step S203, a transaction involving the parent node occurs.

[0187] In step S204, the parent node or another node determines whether the parent node transaction count has reached the parent node rotation value. If the parent node transaction count has not reached the parent node rotation value (step S204: NO), the parent node transaction count is incremented (added 1) in step S205.

[0188] On the other hand, if the parent node transaction count reaches the parent node rotation value (step S204: YES), in step S206, each node in the group to which the parent node belongs changes its priority within the group. For example, the parent node (with the highest priority) is changed to the lowest priority, and the priorities of the other nodes are raised by one, and the sub-parent nodes are set as new parent nodes.

[0189] In step S207, the new parent node or another node deploys (notifies) the performance parameters of the new parent node to the node in the upper hierarchical group. The node in the upper hierarchical group adds the performance parameters of the new parent node to the upper hierarchical ledger.

[0190] In step S208, the nodes belonging to the upper hierarchical group (including the new parent node) determine their priority in the upper hierarchical group. Because the new parent node has lower performance parameters than the previous parent node, it will not have the highest priority in the upper hierarchical group, but as an exception, a condition may be included to make it second or lower.

[0191] (3) Example of flow when adding a node to a lower hierarchy FIG. 28 is a diagram showing an example of a flow when a node is added to a lower layer (a lower layer group is added) in the hierarchical structure network 10 according to the embodiment.

[0192] In step S301, a child node is added to a lower layer.

[0193] In step S302, the priority of the node added to the lower layer is determined. When one node is added to a new group, it will necessarily have second priority and become a sub-parent node.

[0194] In step S303, a lower hierarchy ledger for the lower hierarchy (new lower hierarchy group) is generated. As described above, the lower hierarchy ledger may include the block header and parent chain ID of the upper hierarchy ledger at that time.

[0195] In step S304, the upper level ledger is updated in response to the generation of the lower level ledger. As described above, the upper level ledger may include information of the lower level ledger (such as a hash value and / or a chain ID).

[0196] (4) Example of a flow when deleting a node Fig. 29 is a diagram showing an example of a flow when a node is deleted from the hierarchical structure network 10 according to the embodiment. In Fig. 29, steps that can be omitted are indicated by dashed lines.

[0197] In step S401, a node in the group to which the node to be deleted that made the deletion request belongs or another node determines whether to permit the deletion request, for example, by using a quarantine network. For example, it determines whether inconsistencies or the like will occur even if the node that made the deletion request is deleted.

[0198] If the deletion request is rejected (not permitted) (step S401: NO), in step S402, the node to be deleted determines whether to resubmit the deletion request. Here, restrictions may be imposed so that the deletion request can be resubmitted only after the cause of the denial has been removed. If the deletion request is to be resubmitted (step S402: YES), the process returns to step S401.

[0199] In step S403, it is determined whether the node to be deleted is a parent node. If the node to be deleted is not a parent node (step S403: NO), the priority level below the node to be deleted is raised by one (step S404), and the node to be deleted is deleted from the group (S405). The deletion process is performed in the same way as a normal transaction.

[0200] On the other hand, if the node to be deleted is a parent node (step S403: YES), the priority of the node in the group is raised by one (step S406), and the node to be deleted is deleted from the group (S407). The deletion process is processed in the same way as a normal transaction. Then, in step S408, the performance parameters of the new parent node are expanded (notified) to the nodes in the upper hierarchical group. In step S409, the nodes belonging to the upper hierarchical group (including the new parent node) determine their priority in the upper hierarchical group. Since the new parent node has lower performance parameters than the previous parent node, it will not have the highest priority in the upper hierarchical group, but as an exception, a condition may be included to make it second or lower.

[0201] (Example of operation flow for ledger locking) Next, an example of an operational flow regarding ledger locking according to the embodiment will be described with reference to FIGS.

[0202] (1) Main process of ledger lock FIG. 30 is a diagram illustrating an example of a main process of ledger locking according to the embodiment.

[0203] In step S501, when a node 100 joins a certain group 200, each node 100 in the group 200 stores memory margin information of the newly joining node 100 in the ledger of the group 200.

[0204] In step S502, the node 100 in the group 200 generates a transaction and generates transaction data.

[0205] In step S503, each node 100 in the group 200 updates the ledger of the group 200 in accordance with the transaction that occurred in step S502, and starts a lock timer to lock the ledger.

[0206] In step S504, the node 100 in the group 200 generates a transaction and generates transaction data.

[0207] In step S505, the node 100 that generated the transaction in step S504 determines whether or not the node 100 has sufficient memory.

[0208] If it is determined that the local node 100 has sufficient memory (step S505: YES), the local node 100 stores the transaction data in the local node 100 in step S506.

[0209] On the other hand, if it is determined that the node 100 does not have sufficient memory (step S505: NO), the node 100 executes a process of searching for another node 100 that has sufficient memory in step S507. Details of this process will be described later with reference to FIG.

[0210] In step S508, each node 100 in the group 200 detects the expiration of the lock timer, releases the ledger lock, and returns the process to step S503.

[0211] (2) Transaction data processing FIG. 31 is a diagram illustrating an example of transaction data processing according to the embodiment.

[0212] In step S601, the node 100 in the group 200 initiates a transaction and generates transaction data.

[0213] In step S602, the node 100 checks the current remaining memory capacity of the node 100 itself.

[0214] In step S603, the node 100 determines whether the remaining memory is equal to or greater than the size of the transaction data. If it is determined that the remaining memory is equal to or greater than the size of the transaction data (step S603: YES), the node 100 turns on the margin flag (step S604) and stores the transaction data in the node 100 itself.

[0215] On the other hand, if it is determined that the remaining memory capacity is less than the size of the transaction data (step S603: NO), the node 100 turns off the margin flag (step S606) and transmits the transaction data and the margin flag to the other node 100.

[0216] (3) Searching for other nodes with sufficient memory FIG. 32 is a diagram illustrating an example of a process for searching for another node 100 with a memory margin according to the embodiment.

[0217] In step S701, the node 100 that has generated the transaction checks the ledger held by the node 100 itself (specifically, the ledger of the group 200 to which the node 100 itself belongs) and searches for other nodes 100 with a margin flag set to ON.

[0218] In step S702, the node 100 determines whether or not another node 100 with a margin flag set to ON exists in the own group 200. If it is determined that another node 100 with a margin flag set to ON does not exist (step S702: NO), the node 100 proceeds to processing for when another node 100 with memory margin does not exist in the own group 200 (step S703). Details of this processing will be described later with reference to FIG.

[0219] On the other hand, if it is determined that another node 100 with a margin flag set to ON exists (step S702: YES), then in step S704, the node 100 transmits the transaction data and the margin flag to the other node 100 with a margin flag set to ON. If an Ack is returned from the other node 100 with a margin flag set to ON (step S705: YES), the process ends.

[0220] If no Ack is returned from another node 100 with a margin flag = ON (step S705: NO), it is determined in step S706 whether or not another node 100 with a margin flag = ON exists in the own group 200. If it is determined that another node 100 with a margin flag = ON does not exist in the own group 200 (step S706: NO), the process proceeds to a process for when another node 100 with memory margin does not exist in the own group 200 (step S707). Details of this process will be described later with reference to FIG.

[0221] If it is determined that another node 100 with a margin flag set to ON exists in the own group 200 (step S706: YES), the node 100 returns the process to step S704 and transmits the transaction data and margin flag to the other node 100.

[0222] (4) Processing on the node with sufficient memory FIG. 33 is a diagram illustrating an example of processing on the side of the node 100 having a memory surplus according to the embodiment.

[0223] In step S800, a node 100 with sufficient memory capacity receives the transaction data. However, if the node 100 is in sleep mode, it cannot receive the transaction data.

[0224] In step S801, the node 100 determines whether or not it is possible to send a reply to the transaction data. If it is not possible to send a reply (step S801: NO), the node 100 ignores the transaction data without sending a reply (step S802).

[0225] If a reply is possible (step S801: YES), in step S803, it is determined whether or not the transaction data was received. If the transaction data was not received (step S803: NO), the node 100 replies with Nak (step S804).

[0226] If the node 100 receives the transaction data (step S803: YES), it returns an Ack (step S805). After that, when the lock timer expires, the node 100 passes the transaction data to the proposer (step S806). However, if the node 100 is the proposer, the node 100 generates a new block using the transaction data.

[0227] (5) What to do if there is no other node with sufficient memory FIG. 34 is a diagram illustrating an example of processing when there is no other node 100 with a memory surplus in the own group 200 according to the embodiment.

[0228] In pattern 1, in step S901, the node 100 that has generated a transaction passes the transaction data to an external database (DB).

[0229] In pattern 2, the following steps S911 to S915 are performed. Specifically, in step S911, the node 100 that generated the transaction passes the transaction data to the parent node 100 of the group 200 to which the node 100 belongs. However, if the node 100 is the parent node 100, step S911 is omitted.

[0230] The parent node 100 checks the parent ledger of the parent group 200 one level above the group 200 to which the node 100 that generated the transaction belongs (step S912), and searches for a node 100 within the parent group 200 that has spare memory (step S913).

[0231] After that, in step S914, when the lock timer expires, a node 100 in the parent group 200 with spare memory passes the transaction data to the parent node 100. The parent node 100 passes the transaction data to a proposer in the group 200 (child group) to which the node 100 that generated the transaction belongs (step S915).

[0232] (6) Processing when multiple child group ledgers are updated 35 is a diagram illustrating an example of processing when ledgers (child ledgers) of multiple child groups according to an embodiment are updated. Here, it is assumed that a transaction occurs in two child groups (referred to as "child 1" and "child 2").

[0233] In step S1001, a transaction occurs at node 100 of child 1.

[0234] In step S1002, the child 1 node 100 acquires ledger information from the latest parent ledger of the parent group 100. Also, locking of the parent ledger is initiated.

[0235] In step S1003, the node 100 of the child 1 starts updating the ledger of the child 1.

[0236] If the ledger update process for child 1 is not complete (step S1004: NO), a transaction occurs in child 2 node 100 (step S1005). Here, if the parent ledger is not locked (step S1006: NO), in step S1007, child 2 node 100 obtains ledger information from the latest parent ledger of parent group 100 and updates child 2's ledger. In addition, the parent ledger is locked. If the parent ledger is locked (step S1006: YES), in step S1008, child 1 node 100 performs ledger update process for child 1. However, if the parent ledger is not locked (step S1009: NO), the ledger update fails for both child 1 and child 2. If the parent ledger is locked (step S1009: YES), the process proceeds to step S1015.

[0237] Alternatively, if the ledger update process for child 1 has been completed (step S1004: YES), a transaction occurs in child 2 node 100 (step S1011). If the parent ledger is not locked (step S1012: NO), in step S1013, child 2 node 100 obtains ledger information from the latest parent ledger of the parent group 100 and updates child 2's ledger. The parent ledger is also locked. If the parent ledger is locked (step S1012: YES), child 2 node 100 performs ledger update process for child 2 in step S1014. If the parent ledger is not locked (step S1015: NO), child 2 fails to update its ledger (step S1016). If the parent ledger is locked (step S1015: YES), the ledger updates for both child 1 and child 2 are successful (completed) (step S1017).

[0238] (7) What to do when a child group ledger is updated multiple times FIG. 36 is a diagram illustrating an example of processing when the ledger of a child group according to the embodiment is updated multiple times.

[0239] In step S1101, a transaction occurs at node 100 of child 1.

[0240] In step S1102, the child 1 node 100 acquires ledger information from the latest parent ledger of the parent group 100.

[0241] In step S1103, node 100 of child 1 starts updating the ledger of child 1. If the parent ledger is not locked (step S1104: NO), updating the ledger of child 1 fails (step S1105). If the parent ledger is locked (step S1104: YES), updating the ledger of child 1 is completed in step S1106.

[0242] In step S1107, a transaction occurs at node 100 of child 1.

[0243] In step S1108, the child 1 node 100 acquires ledger information from the latest parent ledger of the parent group 100.

[0244] In step S1109, node 100 of child 1 starts updating the ledger of child 1. If the parent ledger is not locked (step S1109: NO), updating the ledger of child 1 fails (step S1110). If the parent ledger is locked (step S1109: YES), updating the ledger of child 1 is completed in step S1111. Then, the process returns to step S1107.

[0245] (8) Processing for failure to update child ledger FIG. 37 is a diagram illustrating an example of processing when a child ledger update fails according to the embodiment.

[0246] In step S1200, the ledger update for a certain child group 200 fails.

[0247] In step S1201, the node 100 of the child group 200 determines whether there is a new transaction in the child group 200. If there is a new transaction in the child group 200 (step S1201: YES), in step S1202 the node 100 (proposer) of the child group 200 adds the new transaction to generate a new block, and the process proceeds to step S1203. If there is no new transaction in the child group 200 (step S1201: NO), the process proceeds to step S1203.

[0248] In step S1203, the node 100 of the child group 200 acquires ledger information from the latest parent ledger of the parent group 100 and restarts the update process for the child group 200. If the parent ledger is locked (step S1204: YES), the node 100 of the child group 200 sets the consecutive failure flag managed by the node 100 to OFF (step S1205), and the ledger update process for the child group 200 is successful (completed) (step S1206).

[0249] On the other hand, if the parent ledger is not locked (step S1204: NO), in step S1207, the node 100 of the child group 200 determines whether the consecutive failure flag managed by the node 100 is ON. If the consecutive failure flag is not ON (step S1207: NO), in step S1208, the node 100 of the child group 200 sets the consecutive failure flag to ON. If the consecutive failure flag is ON (step S1207: YES), in step S1209, the node 100 of the parent group 200 extends the lock timer of the parent group 200.

[0250] (9) Child ledger update process FIG. 38 is a diagram illustrating an example of a child ledger update process according to the embodiment.

[0251] In step S1301, the node 100 (proposer) of the child group 200 adds the new transaction and generates a new block. At this point, the new block is not yet finalized.

[0252] In step S1302, the node 100 of the child group 200 notifies the parent group 200 of the update information (ledger information of the child group 200).

[0253] In step S1303, the node 100 of the child group 200 determines whether or not it has received notification that the ledger information of the child group 200 has been added to the ledger of the parent group 200. If it has not received such notification (step S1303: NO), in step S1304, the ledger update of the child group 200 fails.

[0254] If the notification is received (step S1303: YES), in step S1305, the new block for the child group 200 is confirmed, and the ledger update is successful.

[0255] (Other embodiments) In the above-described embodiment, it is primarily assumed that the node 100 is a battery-powered device. However, the hierarchical network 10 may also include devices that are powered by external power sources. For example, a device connected to an external power source may be located at the highest hierarchical level in the hierarchical network 10.

[0256] The above-described operational flows are not limited to being implemented independently, but can also be implemented by combining two or more operational flows. For example, some steps of one operational flow may be added to another operational flow, or some steps of one operational flow may be replaced with some steps of another operational flow. Furthermore, the order of the steps in each of the above-described operational flows is merely an example, and the order of the steps may be changed as appropriate.

[0257] A program may be provided that causes a computer to execute each process performed by the node 100. 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. Furthermore, circuits that execute each process performed by the node 100 may be integrated, and at least a part of the node 100 may be configured as a semiconductor integrated circuit (chip set, SoC: System on a chip).

[0258] As used in this disclosure, the terms "based on" and "depending on" do not mean "based only on" or "depending only on," unless otherwise specified. 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 mean including 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. Furthermore, any reference to elements using designations such as "first," "second," etc., used in this disclosure does not generally limit the quantity or order of those elements. These designations may be used herein as a convenient method of distinguishing between two or more elements. Thus, a reference to a first and a second element does not imply that only two elements may be employed therein, or that the first element must in some way precede the second element. In this disclosure, where 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.

[0259] 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.

[0260] This application claims priority from Japanese Patent Application No. 2022-104031 (filed June 28, 2022), the entire contents of which are incorporated herein by reference.

[0261] (Addendum) The following additional notes are about the features of the above-described embodiment.

[0262] (Appendix 1) A blockchain system in which a network having a hierarchical structure is formed by a plurality of nodes, Nodes that belong to the first group in the first hierarchy that is different from the lowest hierarchy are maintaining a first ledger containing transaction data relating to transactions in said first group; performing a ledger lock so that the first ledger is not updated for a lock period after the first ledger is updated; When the lock period ends, if a second ledger managed by a second group in a second layer below the first layer has been updated within the lock period, the first ledger is updated so that ledger information relating to the updated second ledger is included in the first ledger. Blockchain system.

[0263] (Appendix 2) The nodes belonging to the first group include at least one of a chain ID indicating the second ledger, a hash value calculated from a new block of the second ledger, and a block height indicating the block number of the new block in the first ledger as the ledger information. 1. The blockchain system described in Appendix 1.

[0264] (Appendix 3) When a transaction occurs in the node belonging to the first group within the lock period, If the node has sufficient memory capacity to store transaction data related to the transaction, the node stores the transaction data. If the node does not have the margin, the other node that has the margin stores the transaction data. 1. A blockchain system as set forth in Appendix 1 or 2.

[0265] (Appendix 4) When a transaction occurs in the node within the lock period, if the node belonging to the first group does not have the margin and if there is no other node in the first group that has the margin, the node causes another node belonging to a group in a layer higher than the first layer to hold the transaction data. The blockchain system described in Appendix 3.

[0266] (Appendix 5) The plurality of nodes includes a proposer that is a node that generates a new block for updating the first ledger; If the node belonging to the first group is not the proposer, the node transmits the transaction data held by the node to the proposer when the lock period ends. 1. A blockchain system as set forth in Appendix 3 or 4.

[0267] (Appendix 6) the first ledger includes memory margin information regarding memory capacity of each node belonging to the first group, When a transaction occurs in the node belonging to the first group within the lock period and the node does not have the margin, the node determines the other node from the first group that will hold the transaction data based on the memory margin information included in the first ledger. 6. A blockchain system according to any one of appendix 3 to 5.

[0268] (Appendix 7) In response to a new node joining the first group, the node belonging to the first group updates the first ledger so as to include information about the memory capacity of the new node in the memory margin information. 6. The blockchain system described in Appendix 6.

[0269] (Appendix 8) When a transaction occurs in the node belonging to the first group within the lock period and the node does not have the margin, the node transmits flag information indicating that the node does not have the margin together with the transaction data to the other node; The flag information is managed in the first group as part of the memory margin information. 1. A blockchain system as set forth in Appendix 6 or 7.

[0270] (Appendix 9) The nodes belonging to the second group are performing a ledger lock so that the second ledger is not updated for a lock period after the second ledger is updated; When the lock period ends, if a ledger managed by a group at a lower level than the second level has been updated during the lock period, updating the second ledger so that information about the updated ledger is included in the second ledger; The lock period used in the first group is shorter than the lock period used in the second group. 9. A blockchain system according to any one of appendices 1 to 8.

[0271] (Appendix 10) The lock period used in the first group is longer than a ledger update processing time required for updating the second ledger. 1. The blockchain system described in Appendix 9.

[0272] (Appendix 11) If a node belonging to the second group detects that the first ledger has been updated during the update process of the second ledger, it considers the update of the second ledger to have failed and performs the update process of the second ledger again. 11. A blockchain system according to any one of appendixes 1 to 10.

[0273] (Appendix 12) When a node belonging to the first group fails to update the second ledger a predetermined number of times in succession, the node extends the lock period used in the first group. 11. The blockchain system described in Appendix 11.

[0274] (Appendix 13) the second layer includes the second group and a third group, When the lock period ends, if the second ledger managed by the second group and the third ledger managed by the third group have been updated within the lock period, the node belonging to the first group updates the first ledger so that information about the updated second ledger and information about the updated third ledger are included in the first ledger. 13. A blockchain system according to any one of appendixes 1 to 12.

[0275] (Appendix 14) Each of the plurality of nodes is arranged in a tier corresponding to the performance of the node among a plurality of tiers in the hierarchical structure based on the performance of the node. 14. A blockchain system according to any one of appendixes 1 to 13.

[0276] (Appendix 15) The nodes belonging to the first group have higher performance than the nodes belonging to the second group. 14. The blockchain system described in Appendix 14.

[0277] (Appendix 16) The nodes belonging to the first group update the first ledger according to the transactions in the first group and the transactions in the second group, The nodes belonging to the second group do not update the second ledger in response to transactions in the first group, but update the second ledger in response to transactions in the second group. 16. A blockchain system according to any one of appendixes 1 to 15.

[0278] (Appendix 17) In a blockchain system in which a network having a hierarchical structure is formed by a plurality of nodes, a node belonging to a first group in a first layer different from the lowest layer, managing a first ledger containing transaction data relating to transactions in the first group; A process of locking the ledger so that the first ledger is not updated for a lock period after the first ledger is updated; When the lock period ends, if a second ledger managed by a second group in a second layer below the first layer has been updated within the lock period, updating the first ledger so that information about the updated second ledger is included in the first ledger. node.

[0279] (Appendix 18) In a blockchain system in which a hierarchical network is formed by a plurality of nodes, a node belonging to a first group in a first layer different from the lowest layer is managing a first ledger containing transaction data relating to transactions in the first group; A process of locking the ledger so that the first ledger is not updated for a lock period after the first ledger is updated; When the lock period ends, if a second ledger managed by a second group in a second layer below the first layer has been updated within the lock period, a process of updating the first ledger so that information about the updated second ledger is included in the first ledger is executed. program. [Explanation of symbols]

[0280] 10: Hierarchical network 100: Node 110: Communications Department 120: Control unit 121: Processor 130: Storage section 140: Battery 200: Group

Claims

1. A blockchain system in which a network having a hierarchical structure is formed by a plurality of nodes, The nodes belonging to the first group in the first hierarchy that is different from the lowest hierarchy are maintaining a first ledger containing transaction data relating to transactions in the first group; performing a ledger lock so that the first ledger is not updated for a lock period after the first ledger is updated; When the lock period ends, if a second ledger managed by a second group in a second hierarchy that is lower than the first hierarchy has been updated within the lock period, the first ledger is updated so that ledger information relating to the updated second ledger is included in the first ledger. Blockchain system.

2. The nodes belonging to the first group include at least one of a chain ID indicating the second ledger, a hash value calculated from a new block of the second ledger, and a block height indicating the block number of the new block in the first ledger as the ledger information. The blockchain system according to claim 1 .

3. When a transaction occurs in the node belonging to the first group within the lock period, If the node has sufficient memory capacity to store transaction data related to the transaction, the node stores the transaction data. If the node does not have the margin, the other node that has the margin stores the transaction data. The blockchain system according to claim 1 .

4. When a transaction occurs in the node within the lock period, if the node belonging to the first group does not have the margin and if there is no other node in the first group that has the margin, the node causes another node belonging to a group in a layer higher than the first layer to hold the transaction data. The blockchain system according to claim 3.

5. The plurality of nodes includes a proposer that is a node that generates a new block for updating the first ledger, If the node belonging to the first group is not the proposer, the node transmits the transaction data held by the node to the proposer when the lock period ends. The blockchain system according to claim 3.

6. the first ledger includes memory margin information regarding memory capacity of each node belonging to the first group, When a transaction occurs in the node belonging to the first group within the lock period and the node does not have the margin, the node determines the other node from the first group that will hold the transaction data based on the memory margin information included in the first ledger. The blockchain system according to claim 3.

7. In response to a new node joining the first group, the node belonging to the first group updates the first ledger so as to include information about the memory capacity of the new node in the memory margin information. The blockchain system according to claim 6.

8. When a transaction occurs in the node belonging to the first group within the lock period and the node does not have the margin, the node belonging to the first group transmits flag information indicating that the node does not have the margin together with the transaction data to the other node; The flag information is managed in the first group as part of the memory margin information. The blockchain system according to claim 6.

9. The nodes belonging to the second group are performing a ledger lock so that the second ledger is not updated for a lock period after the second ledger is updated; When the lock period ends, if a ledger managed by a group at a lower level than the second level has been updated during the lock period, updating the second ledger so that information about the updated ledger is included in the second ledger; The lock period used in the first group is shorter than the lock period used in the second group. The blockchain system according to claim 1 .

10. The lock period used in the first group is longer than a ledger update processing time required for updating the second ledger. The blockchain system according to claim 9.

11. When a node belonging to the second group detects that the first ledger has been updated during the update process of the second ledger, the node considers the update of the second ledger to have failed and performs the update process of the second ledger again. The blockchain system according to claim 1 .

12. When a node belonging to the first group fails to update the second ledger a predetermined number of times in succession, the node extends the lock period used in the first group. The blockchain system of claim 11.

13. the second layer includes the second group and a third group, When the lock period ends, if a second ledger managed by the second group and a third ledger managed by the third group have been updated within the lock period, the node belonging to the first group updates the first ledger so that information about the updated second ledger and information about the updated third ledger are included in the first ledger. The blockchain system according to claim 1 .

14. Each of the plurality of nodes is arranged in a tier corresponding to the performance of the node among a plurality of tiers in the hierarchical structure based on the performance of the node. The blockchain system according to any one of claims 1 to 13.

15. The nodes belonging to the first group have higher performance than the nodes belonging to the second group. The blockchain system of claim 14.

16. The nodes belonging to the first group update the first ledger according to the transactions in the first group and the transactions in the second group, The nodes belonging to the second group do not update the second ledger in response to transactions within the first group, but update the second ledger in response to transactions within the second group. The blockchain system according to any one of claims 1 to 13.

17. In a blockchain system in which a network having a hierarchical structure is formed by a plurality of nodes, a node belonging to a first group in a first layer different from the lowest layer, managing a first ledger containing transaction data relating to transactions in the first group; A process of locking the ledger so that the first ledger is not updated for a lock period after the first ledger is updated; When the lock period ends, if a second ledger managed by a second group in a second hierarchical level that is lower than the first hierarchical level has been updated within the lock period, updating the first ledger so that information about the updated second ledger is included in the first ledger. node.

18. In a blockchain system in which a network having a hierarchical structure is formed by a plurality of nodes, a node belonging to a first group in a first layer different from the lowest layer is managing a first ledger containing transaction data relating to transactions in the first group; A process of locking the ledger so that the first ledger is not updated for a lock period after the first ledger is updated; When the lock period ends, if a second ledger managed by a second group in a second layer below the first layer has been updated within the lock period, a process of updating the first ledger so that information about the updated second ledger is included in the first ledger is executed. program.

Images