Systems and nodes

Abstract

This system uses blockchain technology, forms a network having a hierarchical structure, and comprises a plurality of nodes which each manage a ledger. On the basis of the performance of each of the plurality of nodes, each of the plurality of nodes is disposed in a level corresponding to the performance thereof, such levels being from among the plurality of levels in the hierarchical structure.

Description

[Technical Field]

[0001] The present disclosure relates to a system, a node, and a program that use blockchain technology. [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 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 system according to a first aspect is a system that uses blockchain technology. The system forms a network with a hierarchical structure and includes multiple nodes that each manage a ledger. Each of the multiple nodes is placed in a tier of the hierarchical structure that corresponds to the node's performance, based on the node's performance.

[0007] A node according to a second aspect is a node that forms a network having a hierarchical structure in a system using blockchain technology. The node includes a memory unit that stores a ledger, a communication unit that communicates with other nodes in the network, and a control unit that determines the hierarchical level at which a target node is placed in the network based on the performance of the target node. The target node is the node or the other node.

[0008] A program according to a third aspect causes a node forming a hierarchical network in a system using blockchain technology to execute a process of storing a ledger, a process of communicating with other nodes in the network, and a process of determining a hierarchical level in which a target node is to be placed in the network according to the performance of the target node. The target node is the node or the other node.

[0009] A system according to a fourth aspect is a system that uses blockchain technology. The system includes a network configured with multiple groups, including a first group formed by one or more nodes that manage a first ledger, and a second group formed by one or more nodes that manage a second ledger different from the first ledger. Nodes belonging to the second group notify the first group of ledger information related to the second ledger. Each node belonging to the first group manages the ledger information as part of the first ledger.

[0010] A node according to a fifth aspect is a node that belongs to a first group formed by one or more nodes that manage a first ledger in a system using blockchain technology. The node includes a memory unit that stores the first ledger, a communication unit that receives ledger information about a second ledger from a second group formed by one or more nodes that manage a second ledger different from the first ledger, and a control unit that manages the ledger information as part of the first ledger.

[0011] A program according to a sixth aspect, in a system using blockchain technology, causes a node belonging to a first group formed by one or more nodes managing a first ledger to perform the following processes: storing the first ledger; receiving ledger information regarding a second ledger from a second group formed by one or more nodes managing a second ledger different from the first ledger; and managing the ledger information as part of the first ledger. [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 is a diagram illustrating an example of a network configuration in a general blockchain technology. [Figure 2] FIG. 10 is a diagram illustrating an example of the configuration of a ledger managed by each node. [Figure 3] FIG. 1 is a diagram illustrating an example of the configuration of a hierarchical network according to an embodiment. [Figure 4] FIG. 10 is a diagram illustrating a ledger management method according to an embodiment. [Figure 5] FIG. 10 is a diagram illustrating a ledger management method according to an embodiment. [Figure 6] 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 7] 10 is a diagram for explaining the link between the upper-level ledger and the lower-level ledger according to the embodiment. FIG. [Figure 8] FIG. 10 is a diagram illustrating an example of an operation when, after a group is formed according to the embodiment, a new group is formed below the group. [Figure 9] FIG. 10 is a diagram illustrating an example of an operation when, after a group is formed according to the embodiment, a new group is formed below the group. [Figure 10] FIG. 10 is a diagram illustrating an example of an operation when, after a group is formed according to the embodiment, a new group is formed below the group. [Figure 11] FIG. 10 is a diagram illustrating grouping of lower layer groups according to an embodiment. [Figure 12] FIG. 10 is a diagram illustrating grouping of lower layer groups according to an embodiment. [Figure 13] FIG. 10 is a diagram illustrating priorities within a group according to the embodiment. [Figure 14] FIG. 10 is a diagram illustrating priorities within a group according to the embodiment. [Figure 15] FIG. 10 is a diagram illustrating an example of node parameters stored in a ledger according to an embodiment. [Figure 16] FIG. 2 is a diagram illustrating an example of the configuration of a node according to the embodiment. [Figure 17] 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 18] 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 19] FIG. 10 is a diagram showing an example of a flow when adding a node to a lower layer (adding a lower layer group) in a hierarchical structure network according to an embodiment. [Figure 20] 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. DETAILED DESCRIPTION OF THE INVENTION

[0013] Blockchain technology is based on the premise that each node has sufficient performance (specs), and if a transaction occurs at any one node, calculations must be performed at all nodes. Therefore, even if a node does not frequently generate transactions, it must perform calculations frequently if nodes that frequently generate transactions participate in the same group.

[0014] Therefore, it is difficult to apply existing blockchain technology to devices with poor performance, such as devices with small battery capacity, low computing power, or small storage capacity, such as IoT (Internet of Things) devices such as sensor devices. The technology described in Patent Document 1 does not take into account such differences in performance between nodes, making it difficult to allow devices with low performance to participate as nodes.

[0015] Therefore, the first objective of this disclosure is to make it possible to apply blockchain technology even to nodes with low performance.

[0016] Furthermore, as with the technology described in Patent Document 1, it is believed that the frequency of ledger updates and the expansion of the ledger can be reduced by grouping nodes in a P2P network and managing a ledger for each group individually. 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.

[0017] Therefore, a second object of the present disclosure is to make it possible to suppress a decrease in reliability while suppressing the update frequency and expansion of the ledger when applying blockchain technology.

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

[0019] (Overview of Blockchain Technology) Before describing the system according to the embodiment, a general blockchain technology will be described with reference to FIGS. 1 and 2.

[0020] Figure 1 is a diagram showing an example of a network configuration in general blockchain technology. In the following diagram, the lines connecting nodes represent communication connections between the nodes. Such communication connections are also called direct communication connections.

[0021] 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).

[0022] 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 ensures that correct transaction history, which is extremely difficult to tamper with, remains even if a participating node 100 is found to be fraudulent or does not operate normally.

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

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

[0025] The block header may further include a block height indicating the number of the corresponding block and a nonce, which is a value used to calculate the hash value. For example, multiple nodes 100 calculate the hash value by combining the nonce with transaction data, etc. while changing the value of the nonce, and a node 100 that finds a hash value that meets certain conditions distributes the generated block to other nodes. Then, all nodes 100 on the network verify the hash value of the block and recognize it as a new block, thereby finalizing the block.

[0026] 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. The transaction data may also 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 also be an update of the ledger.

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

[0028] (Hierarchical network) Next, a network 10 having a hierarchical structure according to an embodiment (hereinafter referred to as a "hierarchical structure network") will be described with reference to FIG.

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

[0030] 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. By creating a hierarchical structure, the calculation frequency for the lower tiers can be suppressed by making the upper tiers tiers with a high calculation frequency (i.e., ledger update frequency) and the lower tiers tiers with a low calculation frequency. By placing high-performance devices at higher tiers and low-performance devices at lower tiers, it becomes possible to participate in the blockchain hierarchical network 10 regardless of performance.

[0031] Fig. 3 is a diagram showing an example of a network configuration according to an embodiment. The hierarchical structure network 10 has a hierarchical structure consisting of three hierarchies, namely, a first hierarchical layer, a second hierarchical layer, a third hierarchical layer, and so on. In the following, an example using three hierarchies will be mainly described, but the number of hierarchies may be two, or four or more. In the example shown in Fig. 3, the first hierarchical layer is the highest hierarchical layer, and the third hierarchical layer is the lowest hierarchical layer.

[0032] In such a hierarchical network 10, each node 100 manages a ledger. Each node 100 is placed in one of three hierarchical levels based on its performance. 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 will be placed based on the performance of the new node. The new node may also be a node already placed in one of the three hierarchical levels in the hierarchical network 10. If the performance of the node changes, the node may be relocated to a level different from the hierarchical level in which it is currently placed. For example, if a limit is placed on the processor usage rate of the node, the performance of the node will decrease, and the node may be relocated to a level lower than the hierarchical level in which it is currently placed.

[0033] The nodes 100 arranged in the first layer and the nodes 100 arranged in the second layer form an upper layer group. In Fig. 3, an example is shown in which the only node 100 belonging to the first layer is node 100A, but multiple nodes 100 may be arranged in the first layer.

[0034] 3, there are three nodes 100 arranged in the second layer: node 100B1, node 100C1, and node 100D1. Each node 100 belonging to group (A) 200A, which is an upper layer group, manages ledger (A), which is an upper layer ledger.

[0035] Each node 100 placed on the second layer and each node 100 placed on the third layer form a lower layer group that manages the lower layer ledger. For example, high-performance devices are placed on the first layer (or second layer), and devices with lower performance than these devices are placed on the third layer. In other words, the nodes 100 belonging to the lower layer group have lower performance than the nodes 100 belonging to the upper layer group.

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

[0037] Group (B) includes one node 100B1 located in the second layer and multiple nodes 100B2 located in the third layer. Each node 100B belonging to group (B) manages ledger (B), which is a lower-layer 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).

[0038] Similarly, group (C) has one node 100C1 placed in the second layer and multiple nodes 100C2 placed in the third layer. Each node 100C belonging to group (C) manages ledger (C), which is a lower-layer 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).

[0039] Similarly, group (D) has one node 100D1 placed in the second layer and multiple nodes 100D2 placed in the third layer. Each node 100D belonging to group (D) manages ledger (D), which is a lower-layer 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).

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

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

[0042] In group (A), which is an upper tier 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 tier 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.

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

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

[0045] Here, the first group is one of the upper layer group and the lower layer group, and the second group is the other of the upper layer group and the lower layer 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 layer groups, i.e., between groups that do not have a direct communication connection. This makes it possible to manage ledgers independently between lower layer groups, without updates to the ledger in one lower layer group affecting the ledgers in other lower layer groups.

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

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

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

[0049] The update frequency of the upper layer ledger in the upper layer 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 layer groups (group (B) 200B, group (C) 200C, group (D) 200D) in ledger (A), which is the upper layer ledger, reliability in blockchain technology can be maintained.

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

[0051] For example, nodes 100B (nodes 100B1 and 100B2) belonging to group (B) 200B, a lower layer group, update ledger (B), a lower layer 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 layer group, update ledger (C), a lower layer 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 layer group, update ledger (D), a lower layer ledger, in response to transactions within group (D) 200D, but do not update ledger (D) in response to transactions within group (A) 200A.

[0052] Also, as shown in Figure 4, nodes 100 belonging to a lower layer group that manages a lower layer ledger do not update that lower layer ledger in response to transactions within other lower layer groups. For example, even if ledger (B) is updated in group (B) 200B, which is a lower layer group, other lower layer groups, group (C) 200C and group (D) 200D, do not update ledger (C) and ledger (D). This reduces the frequency of updates to lower layer ledgers in lower layer groups.

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

[0054] 6 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.

[0055] As shown in Figure 6, 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.

[0056] 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 would not be able to participate in general blockchain technology.

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

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

[0059] As shown in Figure 7, a hierarchical network 10 is composed of 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).

[0060] 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 layer group that manages a lower layer ledger manages ledger information related to an upper layer ledger as part of the lower layer ledger. This makes it possible to link the lower layer ledger with the upper layer ledger.

[0061] 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 accounting in group (B) 200B, and also makes it easy to transmit information such as verification results from group (B) 200B to group (A) 200A.

[0062] 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 layer group that manages the upper layer ledger manages ledger information related to the lower layer ledger as part of the upper layer ledger. This makes it possible to link the upper layer ledger with the lower layer ledger.

[0063] 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). Furthermore, if ledger (B) is updated infrequently and is not long enough, and all blocks contained in ledger (B) are tampered with before a new block is added to ledger (B), the node managing ledger (B) will not be able to recognize that ledger (B) has been tampered with. Even in such a case, by linking ledger (A) and ledger (B), the node managing ledger (A) can recognize that ledger (B) has been tampered with, thereby preventing a decrease in security strength.

[0064] 8 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, since a parent node belongs to both group (A) 200A and group (B) 200B, the operation in FIG. 8 may be executed within the same node (parent node).

[0065] As shown in Figure 8, 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.

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

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

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

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

[0070] 9 and 10 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. 8 will be mainly explained.

[0071] As shown in FIG. 10, 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. 8.

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

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

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

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

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

[0077] 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).

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

[0079] As shown in FIG. 11, the hierarchical network 10 has a plurality of lower layer groups, group (B) 200B to group (D) 200D. Nodes 100 belonging to the plurality of lower layer groups are placed in one of the plurality of lower layer 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). In the second lower layer and below, groups can be divided into groups with long and short sleep times by dividing nodes into groups according to the range of sleep time.

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

[0081] The sleep time of each node 100 belonging to one of the multiple lower tier groups may be within a first predetermined time range. The sleep time of each node 100 belonging to another lower tier group different from the one lower tier group may be within a second predetermined time range different from the first predetermined time. In the example of FIG. 11, 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. 11.

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

[0083] As shown in Figure 12, if the number of nodes 100 belonging to a lower tier group exceeds the maximum number of nodes 100 belonging to that lower tier group, a new lower tier group may be formed. Figure 12 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 tier group exceeds the maximum number of nodes 100 belonging to that lower tier group, a layer may be added below, and an even lower group may be formed.

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

[0085] As shown in FIG. 13, 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 rest are set as child nodes. In FIG. 13, the priority of each node 100 in group (B) 200B, which is a lower layer group, is indicated by a number. For example, when a new node 100 is added to a lower layer 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.

[0086] The multiple nodes 100 that form one group include a parent node that belongs to both the upper layer group and the lower layer group and manages the lower layer ledger and the upper layer ledger, a sub-parent node that belongs to the lower layer 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 layer group and does not correspond to either the parent node 100 or the sub-parent node 100.

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

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

[0089] In addition, when the upper layer ledger of the upper layer group is updated, the parent node passes the upper layer ledger to the sub-parent node. In other words, when the upper layer ledger is updated, the parent node shares the updated upper layer ledger with the sub-parent node.

[0090] In the example of Figure 13, 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.

[0091] As shown in Figure 14, 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.

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

[0093] (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.

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

[0095] As shown in FIG. 15, nodes 100 other than node 100A in the top layer and node 100B2 in the bottom layer, 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 upper-layer ledger, contains the hash value, etc., of ledger (B), which is the lower-layer ledger, and therefore when ledger (B) is updated, ledger (A) also needs to be updated.

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

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

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

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

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

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

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

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

[0104] Performance parameters of the node, such as at least one of battery capacity, computing power, storage capacity, and sleep time.

[0105] (Node configuration example) Next, with reference to FIG. 16, a configuration example of the node 100 (device) according to the embodiment will be described.

[0106] As shown in FIG. 16, the node 100 includes a communication unit 110, a control unit 120, a storage unit 130, and a battery 140.

[0107] The communication unit 110 includes a communication interface for communicating with other nodes. The communication interface may be a wireless communication interface. Alternatively, the communication interface may be a wired communication interface.

[0108] 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 a processor 121. The processor 121 executes programs stored in the storage unit 130 to perform various processes.

[0109] 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 storage device and a volatile storage device.

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

[0111] The nodes 100 configured in this manner form a hierarchical network 10 in a system using blockchain technology. The memory unit 130 stores the ledger. The communication unit 110 communicates with other nodes in the hierarchical network 10, specifically, other nodes that have a direct communication connection with the node itself. The control unit 120 determines the hierarchical level at which the target node is placed in the hierarchical network 10, depending on the performance of the target node 100. The target node is the node itself or another node.

[0112] Node 100 may belong to an upper layer group. In this case, storage unit 130 stores the upper layer ledger as a ledger. Control unit 120 may update the upper layer ledger according to transactions within the upper layer group and transactions within the lower layer group. Furthermore, communication unit 110 may receive ledger information regarding the lower layer ledger from the lower layer group. Control unit 120 may manage ledger information regarding the lower layer ledger as part of the upper layer ledger.

[0113] Node 100 may belong to a lower layer group. In that case, storage unit 130 stores the lower layer ledger as a ledger. Control unit 120 may update the lower layer ledger in accordance with transactions within the lower layer group without updating the lower layer ledger in accordance with transactions within the upper layer group. Also, communication unit 110 may receive ledger information regarding the upper layer ledger from the upper layer group. Control unit 120 may manage ledger information regarding the upper layer ledger as part of the lower layer ledger.

[0114] (Example of operation flow) Next, an example of an operation flow according to the embodiment will be described with reference to FIGS.

[0115] (1) Example of flow when adding a node 17 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. 17, steps that can be omitted are indicated by dashed lines.

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

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

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

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

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

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

[0122] 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 a preset threshold with the sleep time. 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.

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

[0124] In step S109, the node that has 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 a normal transaction.

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

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

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

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

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

[0130] 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 layer group. The node in the upper layer group adds the performance parameters of the new parent node to the upper layer ledger.

[0131] In step S208, the nodes belonging to the upper tier group (including the new parent node) determine their priority in the upper tier 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 tier group, but as an exception, a condition may be included to make it second or lower.

[0132] (3) Example of flow when adding a node to a lower layer FIG. 19 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.

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

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

[0135] In step S303, a lower layer ledger for the lower layer (new lower layer group) is generated. As described above, the lower layer ledger may include the block header and parent chain ID of the current upper layer ledger.

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

[0137] (4) Example of a flow when deleting a node 20 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. 20, steps that can be omitted are indicated by dashed lines.

[0138] In step S401, a node in the group to which the node to be deleted belongs, which has made the deletion request, 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 has made the deletion request is deleted.

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

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

[0141] On the other hand, if the node to be deleted is a parent node (step S403: YES), the priority of the node within 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 tier group. In step S409, the nodes belonging to the upper tier group (including the new parent node) determine their priority in the upper tier 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 tier group, but as an exception, a condition may be included to make it second or lower.

[0142] (Other embodiments) In the above-described embodiment, a case where a new node is added to the hierarchical network 10 and a case where a node is deleted from the hierarchical network 10 have been described, but the embodiment is not limited thereto. For example, in response to a change in the performance of a node already placed in a group in the hierarchical network 10, the node may be relocated to a group different from the group in which the node is currently placed. In addition, in response to a change in the performance of a node already placed in a layer in the hierarchical network 10, the node may be relocated to a layer different from the layer in which the node is currently placed. In response to the formation of a new layer or group in the hierarchical network 10, the node may be relocated to a layer or group different from the layer or group in which the node is currently placed. When the layer or group in which the node is placed changes, the node may be deleted from the layer or group in which it was originally placed, and then added to the layer or group to which it is to be relocated.

[0143] 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 in the highest layer of the hierarchical network 10.

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

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

[0146] As used in this disclosure, the terms "based on" and "depending on" do not mean "based only on" or "depending only on," unless expressly stated otherwise. The term "based on" means both "based only on" and "based at least in part on." Similarly, the term "depending on" means both "based only on" and "at least in part on." Furthermore, "obtain" may mean obtaining information from stored information, obtaining information from information received from another node, or obtaining information by generating the information. The terms "include," "comprise," and variations thereof do not mean including only the listed items, but may also mean including only the listed items or including additional items in addition to the listed items. Furthermore, as used in this disclosure, the term "or" is not intended to mean an exclusive or. Furthermore, any reference to elements using designations such as "first," "second," etc., as 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, reference to first and second elements does not imply that only two elements may be employed therein or that the first element must precede the second element in some manner. In this disclosure, where articles are added by translation, such as a, an, and the in English, these articles shall include the plural unless the context clearly indicates otherwise.

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

[0148] This application claims priority to Japanese Patent Application No. 2021-214070 (filed December 28, 2021) and Japanese Patent Application No. 2021-214085 (filed December 28, 2021), the entire contents of which are incorporated herein by reference.

[0149] (Addendum) The features of the above-described embodiment will now be described.

[0150] (1) A system using blockchain technology, A hierarchical network is formed, and multiple nodes manage ledgers. 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. system.

[0151] (2) The performance includes at least one of computing power, memory capacity, and battery capacity. The system described in (1) above.

[0152] (3) When a new node is added, the new node or another node determines the tier in which the new node is placed based on the performance of the new node. The system described in (1) or (2) above.

[0153] (4) An upper layer group formed by one or more nodes arranged at a predetermined layer and managing an upper layer ledger; A lower layer group is formed by one or more nodes arranged at a layer lower than the predetermined layer, and manages a lower layer ledger different from the upper layer ledger, The nodes belonging to the lower layer group have lower performance than the nodes belonging to the upper layer group. A system according to any one of (1) to (3) above.

[0154] (5) The nodes belonging to the upper layer group update the upper layer ledger according to the transactions within the upper layer group and the transactions within the lower layer group. The system described in (4) above.

[0155] (6) A node belonging to the lower layer group does not update the lower layer ledger in response to transactions within the upper layer group, but updates the lower layer ledger in response to transactions within the lower layer group. The system described in (4) or (5) above.

[0156] (7) a plurality of lower layer groups including the lower layer group; A node belonging to one of the plurality of lower layer groups is placed in a lower layer group according to the length of the sleep time of the node. The system described in (6) above.

[0157] (8) the sleep time of each node belonging to one of the plurality of lower tier groups is within a first predetermined time range; The sleep time of each node belonging to another lower tier group different from the one lower tier group is within a second predetermined time range different from the first predetermined time range. The system described in (7) above.

[0158] (9) The maximum number of nodes that belong to each group is determined according to the performance of the nodes that belong to that group. A system according to any one of (4) to (8) above.

[0159] (10) If the number of nodes belonging to the lower layer group exceeds the maximum number of nodes belonging to the lower layer group, a new lower layer group is formed. The system described in (9) above.

[0160] (11) The plurality of nodes A parent node that belongs to both the upper layer group and the lower layer group and manages the lower layer ledger and the upper layer ledger; a sub-parent node that belongs to the lower layer group and is changed to a new parent node when the parent node ceases to function as the parent node; a child node that belongs to the lower layer group and does not correspond to either the parent node or the sub-parent node, A system according to any one of (4) to (10) above.

[0161] (12) The sub-parent node has higher performance than the child node, The parent node has higher performance than the sub-parent node The system according to (11) above.

[0162] (13) When a new node is added to the lower layer group, the new node or another node determines whether to set the new node as the parent node, the sub-parent node, or the child node based on the capabilities of the new node. The system according to (11) or (12) above.

[0163] (14) When the sub-parent node is changed to a new parent node, or when the sub-parent node ceases to function as the sub-parent node, the child node with the highest priority among the multiple child nodes is changed to a new sub-parent node. A system according to any one of (11) to (13) above.

[0164] (15) The parent node notifies the nodes belonging to the upper layer group of updates to the lower layer ledger in response to transactions within the lower layer group; The nodes belonging to the upper layer group update the upper layer ledger in response to the notification from the parent node. A system according to any one of (11) to (12) above.

[0165] (16) When the upper layer ledger is updated, the parent node shares the updated upper layer ledger with the sub-parent node. A system according to any one of (11) to (15) above.

[0166] (17) In response to the deletion of the parent node, the sub-parent node is set as a new parent node, and if the performance of the new parent node does not satisfy a predetermined standard, the node set as the parent node is changed every predetermined number of transactions. A system according to any one of (11) to (16) above.

[0167] (18) When a new node is added to the upper layer group, each node belonging to the upper layer group updates the upper layer ledger so as to add parameters of the new node to the upper layer group; When a new node is added to the lower layer group, each node belonging to the lower layer group updates the lower layer ledger so as to add the parameters of the new node added to the lower layer group to the lower layer ledger. A system according to any one of (4) to (17) above.

[0168] (19) A node that forms a network having a hierarchical structure in a system using blockchain technology, a storage unit that stores the ledger; a communication unit for communicating with other nodes in the network; a control unit that determines a tier in which a target node is placed in the network according to performance of the target node; The target node is the node or the other node. node.

[0169] (20) If the node belongs to an upper layer group formed by one or more nodes arranged in a predetermined layer, The storage unit stores an upper layer ledger as the ledger, The control unit updates the upper layer ledger in accordance with transactions within the upper layer group and transactions within a lower layer group formed by one or more nodes located at a layer lower than the predetermined layer. The node described in (19) above.

[0170] (twenty one) If the node belongs to the lower layer group, The storage unit stores a lower layer ledger as the ledger, The control unit updates the lower layer ledger in accordance with transactions within the lower layer group without updating the lower layer ledger in accordance with transactions within the upper layer group. The node described in (20) above.

[0171] (twenty two) In a system using blockchain technology, nodes that form a hierarchical network are a process for storing the ledger; A process of communicating with other nodes in the network; determining a tier in which a target node is to be placed in the network in accordance with the performance of the target node; The target node is the node or the other node. program.

[0172] (twenty three) A system using blockchain technology, A network is provided which is made up of a plurality of groups including a first group formed by one or more nodes which manage a first ledger, and a second group formed by one or more nodes which manage a second ledger which is different from the first ledger, The node belonging to the second group notifies the first group of ledger information related to the second ledger; Each node belonging to the first group manages the ledger information as a part of the first ledger. system.

[0173] (twenty four) The ledger information includes a chain ID indicating the second ledger. The system according to (23) above.

[0174] (twenty five) The ledger information includes a hash value calculated from a block of the second ledger. The system according to (23) or (24) above.

[0175] (26) The ledger information includes a block height indicating a block number of the second ledger. A system according to any one of (23) to (25) above.

[0176] (27) The first group is an upper layer group that manages an upper layer ledger as the first ledger, The second group is a lower-layer group that manages a lower-layer ledger as the second ledger, Each node belonging to the upper layer group stores the ledger information notified from the lower layer group in the transaction data portion of the block of the upper layer ledger. A system according to any one of (23) to (26) above.

[0177] (28) The first group is a lower-level group that manages a lower-level ledger as the first ledger, The second group is an upper layer group that manages an upper layer ledger as the second ledger, Each node belonging to the lower layer group stores the ledger information notified from the upper layer group in the header portion of the block of the lower layer ledger. A system according to any one of (23) to (26).

[0178] (29) The nodes belonging to the upper layer group update the upper layer ledger according to the transactions within the upper layer group and the transactions within the lower layer group. The system according to (27) or (28) above.

[0179] (30) A node belonging to the lower layer group does not update the lower layer ledger in response to transactions within the upper layer group, but updates the lower layer ledger in response to transactions within the lower layer group. A system according to any one of (27) to (29) above.

[0180] (31) In a system using blockchain technology, a node belonging to a first group formed by one or more nodes that manage a first ledger, a storage unit that stores the first ledger; a communication unit that receives ledger information regarding a second ledger from a second group formed by one or more nodes that manage a second ledger different from the first ledger; a control unit that manages the ledger information as part of the first ledger node.

[0181] (32) In a system using blockchain technology, a node belonging to a first group formed by one or more nodes that manage a first ledger, A process of storing the first ledger; A process of receiving ledger information regarding a second ledger from a second group formed by one or more nodes that manage a second ledger different from the first ledger; and managing the ledger information as part of the first ledger. program. [Explanation of symbols]

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

Claims

1. A system using blockchain technology, A network is provided which is made up of a plurality of groups including a first group formed by one or more nodes which manage a first ledger, and a second group formed by one or more nodes which manage a second ledger which is different from the first ledger, The node belonging to the second group notifies the first group of ledger information regarding the second ledger in accordance with a transaction within the second group; Each node belonging to the first group manages the ledger information as a part of the first ledger. system.

2. The ledger information includes a chain ID indicating the second ledger. The system of claim 1 .

3. The ledger information includes a hash value calculated from a block of the second ledger. The system of claim 1 .

4. The ledger information includes a block height indicating a block number of the second ledger. A system according to any one of claims 1 to 3.

5. The first group is an upper layer group that manages an upper layer ledger as the first ledger, The second group is a lower-level group that manages a lower-level ledger as the second ledger, Each node belonging to the upper layer group stores the ledger information notified from the lower layer group in the transaction data portion of the block of the upper layer ledger. The system of claim 1 .

6. The first group is a lower-level group that manages a lower-level ledger as the first ledger, The second group is an upper layer group that manages an upper layer ledger as the second ledger, Each node belonging to the lower layer group stores the ledger information notified from the upper layer group in the header portion of the block of the lower layer ledger. A system according to any one of claims 1 to 3.

7. The nodes belonging to the upper layer group update the upper layer ledger according to the transactions within the upper layer group and the transactions within the lower layer group. The system of claim 5.

8. A node belonging to the lower layer group does not update the lower layer ledger in response to transactions within the upper layer group, but updates the lower layer ledger in response to transactions within the lower layer group. The system of claim 5.

9. In a system using blockchain technology, a node belonging to a first group formed by one or more nodes that manage a first ledger, a storage unit that stores the first ledger; a communication unit that receives ledger information regarding a second ledger from a second group formed by one or more nodes that manage a second ledger different from the first ledger, in accordance with a transaction within the second group; a control unit that manages the ledger information as part of the first ledger; node.

Images