Communication system, node, and program

Abstract

Each of a plurality of nodes as constituents of a peer-to-peer network comprises: a communication unit that performs inter-node communication in the peer-to-peer network; a storage unit that stores a communication history including information on past inter-node communication performed by the communication unit; and a control unit that, when the communication unit performs inter-node communication with another node, provides the communication history stored in the storage unit to the other node and acquires a communication history stored in the other node. The control unit updates the communication history stored in the storage unit using the acquired communication history.

Description

Communication system, node, and program

[0001] The present disclosure relates to a communication system, a node, and a program.

[0002] In recent years, blockchain, a type of distributed ledger technology, has been utilized in various fields. Blockchain generates units of data called blocks, and each node stores and manages a ledger in which the blocks are linked together like a chain. The data contained in a block includes the hash value of the previous block, a timestamp, and transaction data between participants (nodes).

[0003] In order to tamper with the data of a specific block, all subsequent blocks must be tampered with to ensure the consistency of the hash value, making it tamper-resistant. In addition, consensus among nodes is required when generating a block, which also contributes to its tamper-resistance in the sense that it prevents the recording of fraudulent transaction data.

[0004] In addition, blockchain uses a peer-to-peer (P2P) network in which data is exchanged directly between nodes, making it fault-tolerant, meaning that even if a failure occurs in one node, the entire system will not go down.

[0005] In blockchain, a P2P network consisting of multiple nodes that share the same ledger is also called a blockchain network. As the number of nodes participating in the blockchain network and / or the frequency of transactions increase, the size of the ledger managed by each node increases (i.e., becomes bloated), and the storage capacity of each node becomes strained.

[0006] Here, Patent Literature 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 histories (ledgers) maintained by each node. In this system, if a trading partner is present in the own network, transaction data is shared and stored only within the own network. With this technology, transactions occurring between nodes within the own network only need to be managed within the own network, preventing memory capacity constraints in nodes belonging to other networks. It is also possible to reduce the number of nodes and transactions within each group. Another proposed technology divides multiple nodes participating in a blockchain network into groups and manages a different ledger for each group (see, for example, Patent Literature 2). With this technology, for transactions occurring between nodes belonging to the same group, it is sufficient to update the ledger managed by that group, eliminating the need to update the ledgers of other groups. It is also possible to reduce the number of nodes and transactions within each group.

[0007] JP 2018-67108 A International Publication No. 2023 / 127530

[0008] A communication system according to a first aspect includes a plurality of nodes constituting a peer-to-peer network. Each of the plurality of nodes includes a communication unit that performs inter-node communication in the peer-to-peer network, a storage unit that stores a communication history including information on each past inter-node communication performed by the communication unit, and a control unit that, when the communication unit performs inter-node communication with another node, provides the communication history stored in the storage unit to the other node and acquires the communication history stored in the other node. The control unit updates the communication history stored in the storage unit using the acquired communication history.

[0009] A node according to a second aspect is a node included in a plurality of nodes constituting a peer-to-peer network. The node includes a communication unit that performs inter-node communication in the peer-to-peer network, a storage unit that stores a communication history including information on each past inter-node communication performed by the communication unit, and a control unit that, when the communication unit performs inter-node communication with another node, provides the communication history stored in the storage unit to the other node and acquires the communication history stored in the other node. The control unit updates the communication history stored in the storage unit using the acquired communication history.

[0010] A program according to a third aspect causes a node included in a plurality of nodes constituting a peer-to-peer network to store a communication history including information on each past inter-node communication conducted by the node, and when the node conducts inter-node communication with another node, to provide the stored communication history to the other node and acquire the communication history stored in the other node, and to update the stored communication history using the acquired communication history.

[0011] 1 is a diagram illustrating an example of the configuration of a P2P network in a communication system using general blockchain technology. FIG. 1 is a diagram illustrating an example of the configuration of a ledger managed by each node according to an embodiment. FIG. 2 is a diagram illustrating an example of an operation when adding a new block to a ledger (i.e., when updating the ledger). FIG. 3 is a diagram illustrating an example of an operation when adding a new block to a ledger. FIG. 4 is a diagram illustrating an example of the configuration of each node according to an embodiment. FIG. 5 is a diagram for explaining grouping of nodes according to an embodiment. FIG. 6 is a diagram for explaining grouping of nodes according to an embodiment. FIG. 7 is a diagram illustrating an example of the number of transactions in a certain period in the past before grouping according to an embodiment. FIG. 8 is a diagram for explaining a comparative example of aggregated management of communication histories according to an embodiment. FIG. 9 is a diagram illustrating the operation of each node regarding aggregated management of communication histories according to an embodiment. FIG. 10 is a diagram for explaining a specific example of aggregated management of communication histories according to an embodiment. FIG. 11 is a diagram for explaining a specific example of aggregated management of communication histories according to an embodiment. FIG. 12 is a diagram illustrating a change in the retention status of communication histories when there is a node that does not retain a communication histories according to an embodiment. FIG. 13 is a diagram illustrating a change in the retention status of communication histories when there is a node that retains a limited communication histories according to an embodiment. FIG. 14 is a diagram for explaining the role of each node before and after generation of a sub-ledger according to an embodiment. FIG. 15 is a diagram illustrating an example of an operation when a sub-ledger is generated according to an embodiment.

[0012] In the system described in Patent Document 1, when communication occurs between nodes belonging to different groups, it becomes necessary for each node in the different groups to store transaction data. Therefore, it is desirable to group nodes so that communication frequency between nodes belonging to the same group is high and communication frequency between nodes belonging to different groups is low.

[0013] To achieve this grouping that takes into account the frequency of communication between nodes, one possible method is to have at least one node act as a coordinator and consolidate and manage the communication history, which is the history of communication between nodes. However, with this method, nodes other than the coordinator node must send their own communication history to the coordinator node. This creates a problem in that unnecessary communication solely for the purpose of consolidating the communication history occurs in proportion to the number of nodes.

[0014] Therefore, an object of the present disclosure is to consolidate and manage the history of communication between nodes while suppressing the occurrence of unnecessary communication.

[0015] A communication system according to an embodiment will be described with reference to the drawings. In the description of the drawings, the same or similar parts are denoted by the same or similar reference numerals.

[0016] (1) Overview of Blockchain Technology and Communication Systems First, we will explain general blockchain technology.

[0017] 1 is a diagram showing an example of the configuration of a P2P network in a communication system using general blockchain technology. In FIG. 1, lines connecting nodes 100 represent communication connections (also referred to as "P2P links") between the nodes 100.

[0018] Each node 100 is a device, such as a personal computer (PC), that has at least a communication function and a calculation function. In general blockchain technology, it is assumed that each node 100 has sufficient performance (specifications).

[0019] In blockchain technology, a blockchain network, which is an autonomous decentralized 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. A P2P network in which data is exchanged directly between the nodes 100 provides fault tolerance in that the entire system will not go down even if a failure occurs in one of the nodes 100.

[0020] 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 calculation (verification) processing. This provides a mechanism for leaving 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. Note that the node that performs the calculation processing when a transaction occurs may be only a portion of the nodes participating in the network.

[0021] 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 a remittance or settlement. The transaction data may be data of communication. A transaction may be, for example, the joining or deletion of a node in a 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.

[0022] A plurality of nodes 100 that share the same ledger constitute a group 200. Note that, although Fig. 1 illustrates a total of five nodes, 100a to 100e, as the nodes that constitute the group 200, the number of nodes 100 is not limited to five.

[0023] FIG. 2 is a diagram illustrating an example of the configuration of a ledger managed by each node 100 according to the embodiment.

[0024] Each node 100 stores records of transactions that have occurred within the group 200 in blocks. Specifically, each node 100 stores and manages a ledger in which units of data called blocks are linked together in a chronological chain. Data contained in a block includes the hash value (also called "hash information") of the previous block, a timestamp, and transaction data between nodes (data on transaction details in the illustrated example).

[0025] Each block has a block header, which is a header portion, and a transaction data portion that stores data of at least one transaction (also simply referred to as "data"). 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. The block header may further include a chain ID, which is an identifier for identifying the ledger, a height (also referred to as "height information") representing the block number (block order identifier), and a nonce, which is a value used to calculate the hash value.

[0026] In order to tamper with the data of a specific block, all subsequent blocks must also be tampered with to ensure the consistency of the hash value. If the chain is longer than a certain length, the amount of calculation required to tamper with all blocks subsequent to the specific block whose data is to be tampered with becomes enormous, making it difficult to carry out the tampering secretly. These characteristics make blockchain tamper-resistant. In addition, consensus among the nodes 100 is required when generating a block, which also contributes to its tamper-resistance in the sense that it prevents fraudulent transaction data from being recorded.

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

[0028] As shown in FIG. 3, after a transaction occurs within a group 200 constituting a P2P network, a node 100 called a "proposer" generates a new block corresponding to the transaction and proposes it by notifying another node 100 called a "validator" of the new block. When a new block is proposed, a block ID may be assigned to the proposed block. The block ID is a value referenced by the node 100 to identify the block. By referencing the block ID, the node 100 can identify the block. Three or more of the nodes 100 in the group 200 act as validators.

[0029] For example, multiple nodes 100 calculate hash values ​​by changing the nonce value and combining it with transaction data, etc., and a node 100 (proposer) that finds a hash value that meets certain conditions notifies another node 100 (validator) of the generated block. The other node 100 that receives the proposed new block verifies the hash value of the new block. Here, we will proceed with the explanation assuming that the verification is successful.

[0030] Next, as shown in FIG. 4, another node 100 (validator) that receives the proposed new block votes for the node 100 (proposer) to accept the verified block as the new block. At this time, the other node 100 (validator) that receives the proposed new block and votes for the node 100 (proposer) may specify a block ID along with the voting result to indicate that it is a vote for the block. If the node 100 (proposer) receives a certain number of votes from other nodes 100 (voters), it confirms the proposed new block and updates the ledger by adding the new block to the ledger. The block header of the confirmed new block may include a height as information for identifying the block, and may also include the block ID assigned to the block.

[0031] The group 200 may include a seed node that manages node information and / or connection information within the group 200. One node 100 may have two or more roles among the validator, proposer, and seed node.

[0032] Each node 100 may be a full node that holds and manages the entire ledger. Alternatively, some of the multiple nodes 100 may be light clients. A light client may be a node 100 that holds only a portion of the ledger and uses blockchain technology (e.g., a node 100 that holds assets and / or stores data in the ledger).

[0033] FIG. 5 is a diagram illustrating an example of the configuration of each node 100 according to the embodiment.

[0034] 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 and a user interface 150.

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

[0036] The control unit 120 performs various types of control and processing in the node 100. The operations of the node 100 described above and below may be operations under the control of the control unit 120. The control unit 120 includes at least one processor 121. The processor 121 executes programs stored in the storage unit 130 to perform various types of processing.

[0037] 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. The storage unit 130 also stores a ledger.

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

[0039] The user interface 150 functions as an interface with the user and includes a display unit that displays various information and an operation unit that accepts operations from the user.

[0040] (2) Grouping of Nodes Next, grouping of the nodes 100 according to the embodiment will be described.

[0041] As the number of nodes 100 participating in a group 200 constituting a P2P network and / or the frequency of transactions increase, the size of the ledger managed by the group 200 increases (i.e., becomes bloated), resulting in a situation where the storage capacity of each node 100 becomes tight. In this case, as shown in Figure 6, by dividing the group 200 (group A) and managing a ledger for each divided group (subgroup B, subgroup C), the number of nodes and the number of transactions within the divided groups can be reduced, thereby alleviating or eliminating this problem.

[0042] In the example of Fig. 6(1), group A is made up of nodes 100a to 100h, and each of nodes 100a to 100h manages a ledger with chain ID: 0. Here, because the number of nodes in group A has increased, a new ledger with chain ID: 1 is generated, and some of the nodes 100 are made to participate in the ledger with chain ID: 1, as shown in Fig. 6(2).

[0043] In the example of Figure 6 (2), subgroup B is made up of nodes 100a to 100d, and subgroup C is made up of nodes 100e to 100h. Each node 100 in subgroup B continues to manage the ledger with chain ID: 0, and each node 100 in subgroup C newly manages the ledger with chain ID: 1.

[0044] In Figure 6 (2), if a transaction is issued specifying old chain ID: 0 with one of the nodes 100 in subgroup C as the transaction source, it may not be processed correctly because the transaction source is not participating in chain ID: 0. Also, if a transaction is issued from one of the nodes 100 in subgroup B to one of the nodes 100 in subgroup C by specifying old chain ID: 0, it may not be processed correctly either because the transaction destination is not chain ID: 0. Therefore, it is possible to assign a common chain ID to the sub-ledgers individually set up for each subgroup.

[0045] 7 is a diagram illustrating grouping of the nodes 100 according to the embodiment. In the following, an example in which group A is divided into two subgroups will be mainly described, but group A may also be divided into three or more subgroups.

[0046] In an embodiment, when group A is divided into multiple subgroups (subgroup B and subgroup C in the illustrated example), the multiple nodes 100 that make up group A that manages ledgers manage new sub-ledgers that are individually provided for each subgroup. The chain ID (new chain ID) of the sub-ledger of each subgroup may be the same as the chain ID (old chain ID) of the original ledger.

[0047] The chain ID of the ledger held by the nodes belonging to the subgroup does not change before and after the group split. As a result, even if group A is split to prevent the ledger from becoming too large, the correct chain ID can be specified when a transaction is issued in which a node belonging to the subgroup is the counterparty, thereby suppressing any adverse effects on the transaction issuance process. Note that even if the chain ID of the ledger held by the nodes belonging to the subgroup is different before and after the group split, if a new chain ID is correctly specified when a transaction related to a node belonging to the subgroup is issued, the transaction can be processed normally. However, the following description uses an example in which the chain ID of the ledger held by the nodes belonging to the subgroup does not change before and after the group split. Note that the ledger managed by subgroup B is also referred to as sub-ledger B, and the ledger managed by subgroup C is also referred to as sub-ledger C.

[0048] In the embodiment, when a transaction occurs between nodes 100 belonging to the same subgroup, each node 100 belonging to the same subgroup updates the subledger managed by the same subgroup. In other words, for a transaction that is completed within a subgroup, only the corresponding subledger is updated.

[0049] For example, when a transaction occurs between nodes 100 belonging to subgroup B, each node 100 belonging to subgroup B (nodes 100a to 100d) updates sub-ledger B managed by subgroup B. In this case, each node 100 belonging to subgroup C (nodes 100e to 100h) does not need to update sub-ledger C managed by subgroup C, thereby reducing the update processing load on sub-ledger C and the expansion of sub-ledger C.

[0050] Furthermore, when a transaction occurs between nodes 100 belonging to subgroup C, each node 100 belonging to subgroup C (nodes 100e to 100h) updates sub-ledger C managed by subgroup C. In this case, each node 100 belonging to subgroup B (nodes 100a to 100d) does not need to update sub-ledger B managed by subgroup B, thereby reducing the update processing load on sub-ledger B and the expansion of sub-ledger B.

[0051] In an embodiment, the multiple nodes 100a to 100h may continue to manage the ledger that existed before group A was divided into multiple subgroups. The ledger that continues to be managed is referred to as common ledger A. When a transaction occurs between nodes 100 that belong to different subgroups, a block related to the transaction may be added to the common ledger.

[0052] This makes it possible to manage transactions between nodes 100 belonging to different subgroups. Furthermore, for transactions that are completed within a subgroup, it is not necessary to update the common ledger A, which reduces the update processing load on the common ledger A and the expansion of the common ledger A.

[0053] Each node 100 (nodes 100a to 100d) belonging to subgroup B may manage two ledgers: a common ledger A and a sub-ledger B. Similarly, each node 100 (nodes 100e to 100h) belonging to subgroup C may manage two ledgers: a common ledger A and a sub-ledger C.

[0054] However, if transactions between different subgroups occur frequently, the frequency of adding blocks to the common ledger A increases. Because such updates to the common ledger A are performed by all nodes (nodes 100a to 100h), it is desirable that transactions between different subgroups occur as little as possible.

[0055] Therefore, in the embodiment, the nodes 100 (e.g., seed nodes) belonging to group A determine the nodes to belong to each subgroup based on the transaction occurrence status before group A was divided into multiple subgroups so as to suppress the occurrence of transactions between nodes 100 belonging to different subgroups. In the example of Fig. 7, the placement of each node 100 when dividing into subgroup B (subledger B) and subgroup C (subledger C) is determined so as to minimize the transaction frequency between different subgroups.

[0056] 8 is a diagram showing an example of the number of transactions of nodes 100a to 100h in a certain period of time in the past before grouping according to the embodiment. In the example shown, the number of communications between node 1 and node 2 was 5, the number of communications between node 3 and node 7 was 1, and so on. In FIG. 8, the underlined values ​​are high, and the other values ​​are low. In this case, in order to minimize transactions between different subgroups, it is optimal to divide the nodes into a subgroup consisting of nodes 100a to 100d and a subgroup consisting of nodes 100e to 100h.

[0057] In this manner, in this embodiment, the multiple nodes 100 participating in group A, which manages the original ledger, are divided into multiple subgroups. In the following, it is assumed that each node 100 participating in the same subgroup will newly hold a subledger and continue to hold the common ledger A. It is also assumed that both the common ledger A and each subledger (subledger B, subledger C) have a common chain ID.

[0058] In the operation example of Figure 7, the state initially is as shown in Figure 7(1), where all nodes 100 participate in group A and hold ledger A (common ledger). After that, the state changes to Figure 7(2), where all nodes 100 continue to participate in group A, but also participate in subgroup B or subgroup C. Nodes 100 participating in subgroup B hold ledger A and ledger B (sub-ledgers), and nodes 100 belonging to subgroup C hold ledger A and ledger C (sub-ledgers).

[0059] By arranging the nodes 100 so that the transaction frequency between the nodes 100 in different sub-groups is minimized, the frequency of adding blocks to the common ledger can be reduced. By basically managing transactions in the sub-ledgers while linking the common ledger as needed, it is possible to maintain the effect of reducing or eliminating issues such as the expansion of the capacity of each ledger and / or the tight capacity of each node 100. Furthermore, by making the chain IDs of the common ledger and multiple sub-ledgers the same, it is possible to achieve the additional effect of not affecting the issuance of transactions.

[0060] (3) Aggregated Management of Communication History Next, aggregated management of communication history according to the embodiment will be described.

[0061] As described above, the nodes to which each subgroup belongs are determined so as to suppress the occurrence of transactions between nodes belonging to different subgroups based on the transaction occurrence status (i.e., the occurrence status of communication between nodes as shown in FIG. 8 ) before the group is divided into multiple subgroups. Specifically, the nodes are grouped so that the communication frequency between nodes belonging to the same subgroup is high and the communication frequency between nodes belonging to different subgroups is low. In order to perform such grouping, it is necessary to aggregate and manage the communication history, which is the history of communication (transactions) between nodes.

[0062] FIG. 9 is a diagram illustrating a comparative example of the centralized management of communication histories according to the embodiment. In the illustrated example, a plurality of nodes 100 participating in a blockchain network (P2P network) include a coordinating node and nodes N1 to N4 other than the coordinating node. Each of the nodes N1 to N4 transmits its own communication history to the coordinating node. The coordinating node receives the communication histories from each of the nodes N1 to N4 and consolidates and manages the received communication histories. The communication history of each node includes information on each inter-node communication that the node has previously conducted. Information on each inter-node communication that constitutes the communication history is also referred to as a communication record. Each communication record in the communication history includes time information indicating the time when the node conducted inter-node communication and identification information indicating the node with which the inter-node communication was communicated. The communication history is a chronological arrangement of the communication records. In the comparative example shown in FIG. 9, each node is required to transmit its communication history to the coordinating node. This poses a problem in that unnecessary communication solely for the purpose of aggregating the communication history occurs in proportion to the number of nodes.

[0063] The following describes the aggregated management of communication histories that enables the aggregation and management of communication histories between nodes while suppressing the occurrence of unnecessary communication. Fig. 10 is a diagram showing the operation of each node 100 regarding the aggregated management of communication histories according to the embodiment. In the embodiment, each node 100 participating in the blockchain network (P2P network) performs the operation shown in Fig. 10.

[0064] In step S1, the storage unit 130 of the node 100 stores a communication history including information on past inter-node communications performed by the communication unit 110 of the node 100. Note that the node 100 manages its own communication history separately from the ledger.

[0065] In step S2, the communication unit 110 of the node 100 performs inter-node communication with another node 100. The inter-node communication is communication that accompanies a normal transaction in a P2P network.

[0066] In step S3, when the communication unit 110 of the node 100 performs inter-node communication with another node 100, the control unit 120 of the node 100 provides the communication history stored in the memory unit 130 of the node 100 to the other node 100, and also acquires the communication history stored in the other node 100.

[0067] In step S4, the control unit 120 of the node 100 updates the communication history stored in the storage unit 130 of the node 100 using the communication history acquired in step S3.

[0068] According to this operation, when each node 100 communicates with another node, it passes and shares the communication history it holds (i.e., the communication history stored in the storage unit 130). By repeating this process, each node 100 will hold communication history, including that between third-party nodes. By issuing transactions using the communication history collected by each node 100 (i.e., the aggregated communication history) as data, when a block is generated, the aggregated communication history is also written into the block. Therefore, the node 100 that synchronizes the block can propose optimal structural changes based on the communication history.

[0069] 11 to 13 are diagrams illustrating a specific example of the aggregated management of communication histories according to the embodiment. In this example, it is assumed that four nodes 100, nodes N1 to N4, exist as multiple nodes 100 participating in the blockchain network (P2P network), and the operation of nodes N1 and N2 will be described.

[0070] First, as shown in Fig. 11, each of nodes N1 and N2 stores its own communication history. Since each communication history is the communication history of the own node, it is sufficient to store the identification information of the communication partner of the inter-node communication. However, in this example, information on both nodes that performed inter-node communication is stored in order to share the communication history with third parties. In addition, in the illustrated example, the communication time is also linked and stored, but since it is sufficient to know the number of inter-node communications as shown in Fig. 8, linking the communication time is not necessary.

[0071] In the illustrated example, the communication history of node N1 includes a communication record indicating that inter-node communication was performed with node N2 at 10:00, a communication record indicating that inter-node communication was performed with node N3 at 10:06, and a communication record indicating that inter-node communication was performed with node N4 at 10:14. The communication history of node N2 includes a communication record indicating that inter-node communication was performed with node N1 at 10:00, a communication record indicating that inter-node communication was performed with node N4 at 10:07, and a communication record indicating that inter-node communication was performed with node N3 at 10:18.

[0072] Second, suppose that nodes N1 and N2 communicate with each other at 10:20. As shown in FIG. 12, nodes N1 and N2 also exchange the communication history that they hold. Specifically, node N1 transmits the communication history of node N1 to node N2, and node N2 transmits the communication history of node N2 to node N1. Here, node N1 provides node N2 with the communication history of node N1 and acquires node N2's communication history from node N2. Furthermore, node N2 provides node N1 with the communication history of node N2 and acquires node N1's communication history from node N1.

[0073] 13, each of nodes N1 and N2 updates the communication history held by the node itself using the acquired communication history. Specifically, each of nodes N1 and N2 identifies, from the acquired communication history, information on inter-node communication (communication records) that is not included in the communication history held by the node itself, and adds the identified information (communication records) to the communication history held by the node itself. Furthermore, each of nodes N1 and N2 adds the information on inter-node communication at 10:20 (communication record) to the communication history held by the node itself.

[0074] In the illustrated example, node N1 identifies, from the communication history acquired from node N2, the communication record of the inter-node communication conducted between nodes N2 and N4 at 10:07 and the communication record of the inter-node communication conducted between nodes N2 and N3 at 10:18, and adds the identified communication records to the communication history of node N1. Node N1 also adds the communication record of the inter-node communication conducted between nodes N1 and N2 at 10:20 to the communication history of node N1. Meanwhile, node N2 identifies, from the communication history acquired from node N1, the communication record of the inter-node communication conducted between nodes N1 and N3 at 10:06 and the communication record of the inter-node communication conducted between nodes N1 and N4 at 10:14, and adds the identified communication records to the communication history of node N2. Node N2 also adds the communication record of the inter-node communication conducted between nodes N1 and N2 at 10:20 to the communication history of node N2.

[0075] In this way, each of nodes N1 and N2 aggregates and manages the communication history of inter-node communications between multiple nodes 100 participating in the blockchain network (P2P network). Then, at a predetermined timing, any node issues a transaction using the communication history held by that node as data. As a result, based on the issuance of the transaction, each node 100 adds a new block including the communication history issued as data for that transaction to the ledger held by that node. Thus, the aggregated communication history is written to the ledger. Each node 100 may delete (discard) the communication history (communication record) that has already been written to the ledger from the communication history of its own node 100.

[0076] Here, the predetermined timing for issuing a transaction using the communication history as data may be the timing when a certain amount of communication history held by the node 100 has accumulated. For example, the node 100 may issue a transaction using the communication history held by the node 100 as data when the amount of data or the number of communication records of the communication history held by the node 100 exceeds a threshold.

[0077] The predetermined timing for issuing a transaction that uses a communication history as data may be the timing when a certain amount of time has elapsed since the previous transaction that uses a communication history as data was issued. For example, each node 100 may store the time when it issued a transaction that uses a communication history held by that node 100 as data as a timestamp, and issue a new transaction that uses a communication history held by that node 100 as data when a certain amount of time has elapsed from that time. Alternatively, each node 100 may start a timer set for a certain amount of time when it issues a transaction that uses a communication history held by that node 100 as data, and issue a new transaction that uses a communication history held by that node 100 as data when the timer expires.

[0078] The predetermined timing for issuing a transaction using the communication history as data may be the timing of block generation. For example, if blocks are added to the ledger at predetermined time intervals, the node 100 may issue a transaction using the communication history stored in the node 100 as data at the block generation timing determined by the time intervals.

[0079] When a node 100 issues a transaction using a communication history stored in the node 100 as data, the node 100 may delete the communication history stored in the node 100. This prevents the storage capacity of the node 100 from becoming congested due to the communication history.

[0080] However, depending on the performance (specifications) of the node 100, it may not be possible to store a communication history due to reasons such as a small storage capacity. In such a case, some of the nodes 100 may have the option of not storing a communication history. In this case, the multiple nodes 100 participating in the blockchain network (P2P network) may include not only multiple nodes (first nodes) that store a communication history, but also one or more nodes (second nodes) that do not store a communication history.

[0081] 14 is a diagram illustrating a change in the state of holding a communication history when there is a node that does not hold a communication history according to the embodiment. In the illustrated example, six nodes 100, nodes N1 to N6, are assumed to be present as multiple nodes 100 participating in the blockchain network (P2P network), and of these, nodes N5 and N6 do not hold a communication history due to their small storage capacity.

[0082] In Figure 14, "ID" is an identifier that identifies inter-node communication, "time" is the time when the inter-node communication took place, "communicating nodes" are the pair of nodes 100 that performed the inter-node communication, and "held communication history (ID list)" shows the communication history held by each node 100 (nodes N1 to N6) as a list of "IDs."

[0083] Assume that nodes N1 to N6 performed inter-node communication (specifically, transaction communication) between the nodes shown in "Communication Nodes" at each "time." In "Retained Communication History (ID List)," the nodes that performed communication at each time are underlined. Of these, node N5 / node N6 are nodes that do not store communication history because their storage capacity is small.

[0084] As shown by ID0, inter-node communication is carried out between nodes N1 and N2 at 10:00. Each of nodes N1 and N2 adds a communication record of the inter-node communication of ID0 to the communication history held by that node.

[0085] As shown by ID1, inter-node communication takes place between nodes N2 and N3 at 10:01. Each of nodes N2 and N3 adds the communication record of the inter-node communication of ID1 to the communication history held by that node. Furthermore, node N3 adds the communication record of the inter-node communication of ID0, which is not held by node N3, from the communication history held by node N2 to the communication history held by node N3.

[0086] As shown by ID2, inter-node communication takes place between nodes N1 and N5 at 10:02. Since node N5 does not have a communication history, only node N1 adds the communication record of the inter-node communication of ID2 to the communication history it holds.

[0087] As shown by ID3, inter-node communication takes place between nodes N4 and N5 at 10:03. Since node N5 does not have a communication history, only node N4 adds the communication record of the inter-node communication of ID3 to its own communication history.

[0088] As shown by ID4, inter-node communication takes place between nodes N4 and N6 at 10:04. Since node N6 does not have a communication history, only node N4 adds the communication record of the inter-node communication of ID4 to the communication history it holds.

[0089] As shown by ID5, inter-node communication takes place between nodes N3 and N4 at 10:05. Each of nodes N3 and N4 adds the communication record of the inter-node communication of ID5 to the communication history held by itself. Furthermore, node N3 adds the communication records of the inter-node communication of ID3 and ID4 that are not held by node N3 to the communication history held by node N3. Node N4 adds the communication records of the inter-node communication of ID0 and ID1 that are not held by node N4 to the communication history held by node N4.

[0090] In this way, when the communications for ID0 to ID10 are completed, nodes N1 and N4 accumulate a communication history containing 10 communication records. Here, the absence of a communication record for ID8 is due to node communication between nodes N5 and N6, which do not have a communication history, and is not held by any node at that time. However, even if some communication records are missing, this does not often cause much of a problem in proposing optimal groupings.

[0091] When it is desired to completely aggregate communication histories, nodes N5 and N6, which do not retain communication histories, may retain communication histories only during inter-node communication between nodes N5 and N6. That is, nodes N5 and N6 (second nodes) each retain a limited communication history (also referred to as a "limited communication history"). In this case, nodes N5 and N6 (second nodes) do not add communication records of inter-node communication with nodes N1 to N4 (first nodes) to their limited communication history, but add communication records of inter-node communication between nodes N5 and N6 to their limited communication history. Then, when nodes N5 and N6 (second nodes) communicate with one of nodes N1 to N4 (first nodes), they provide the limited communication history stored in their own nodes to the first node and delete the limited communication history.

[0092] 15 is a diagram showing a change in the state of communication history storage when there is a node that stores a limited communication history according to the embodiment. In Fig. 15, IDs that are different from Fig. 14 are shown in italics.

[0093] As shown by ID8, inter-node communication is carried out between nodes N5 and N6 at 10:08. Each of nodes N5 and N6 adds the communication record of the inter-node communication of ID8 to the limited communication history held by that node.

[0094] As shown by ID9, inter-node communication takes place between nodes N4 and N5 at 10:09. Node N4 adds the communication record of inter-node communication with ID8, which it does not have, to the communication history it has. Node N5 deletes the communication record of inter-node communication with ID8 that it has had.

[0095] By doing this, it becomes possible for each of the nodes N1 and N4 to ultimately store all of the communication histories. Also, each of the nodes N5 and N6 only needs to store the minimum necessary communication history (limited communication history), which saves storage capacity compared to the nodes N1 to N4.

[0096] Because nodes N5 and N6 have small storage capacities, in order to further conserve storage capacity, only one of nodes N5 and N6 may have a limited communication history (communication record) during inter-node communication between them. One possible method for determining which of nodes N5 and N6 will have a limited communication history (communication record) is to make a decision based on the following indicators 1) to 3) of both nodes.

[0097] 1) The proportion of communications with either of the second nodes (nodes N5 or N6) that are limited in the retention of communication history among inter-node communications over a certain period of time in the past. For example, only the node that is less likely to perform inter-node communications with node N5 or node N6 is allowed to retain a limited communication history (communication record).

[0098] 2) The number of communication histories (communication records) that can be stored, determined according to the storage capacity. For example, of nodes N5 and N6, only the node that can store more communication records is allowed to store limited communication histories (communication records).

[0099] 3) The number of communication histories (communication records) currently held. For example, between nodes N5 and N6, only the node that already holds fewer communication records is allowed to hold a limited communication history (communication record).

[0100] Using these indicators 1) to 3), it is possible to estimate the probability that the upper limit for the number of communication histories that can be stored will be exceeded before the next inter-node communication with one of the first nodes (nodes N1 to N4) that has no limit on the storage of communication histories is performed and the communication history is discarded. For example, when nodes N5 and N6 communicate with each other, the probability can be presented to each other, and only the node with the lower probability can retain the communication history. If storage capacity is still expected to be limited, communication records can be appropriately discarded using a last in first out (LIFO) or first in first out (FIFO) method when the number of records that can be retained is exceeded.

[0101] In this way, for the second nodes (nodes N5 and N6) with small storage capacities, by not storing communication histories or storing only partial communication histories, it is possible to prevent storage capacity from becoming congested.

[0102] (4) Example of Operation During Grouping Next, an example of operation during grouping according to the embodiment will be described. In the description of the drawings referred to below, subgroup B and subgroup C will be abbreviated as group B and group C, respectively.

[0103] FIG. 16 is a diagram for explaining the role of each node 100 before and after the generation of the sub-ledgers (ledger B, ledger C) according to the embodiment.

[0104] As shown in FIG. 16, each node 100 in group A also joins subgroups, group B or group C, due to group division. Here, one node 100 in each subgroup becomes a new seed node. A seed node is a node 100 that holds connection information such as IP addresses of all nodes 100 in a group, and one of the nodes 100 in a group plays the role of a seed node. Different subgroups are only allowed to access each other's seed nodes 100.

[0105] The seed node of group A may subsequently become the seed node 100 of group B or group C. Alternatively, a node 100 other than the seed node of group A may become the seed node 100 of group B and group C. Methods for selecting seed nodes include selecting the node 100 with the best specifications (e.g., CPU performance, memory capacity, and / or battery capacity).

[0106] In the example of Fig. 16(1), node 100a is the seed node of group A, and the other nodes 100b to 100h are validators of group A. A validator is a node 100 that performs consensus building activities such as adding blocks, and three or more of the nodes 100 in the group play this role.

[0107] In the example of FIG. 16(2), when subgroups B and C are formed, node 100a becomes the seed node of subgroup B, and node 100e becomes the seed node of subgroup C.

[0108] 17 is a diagram showing an example of the operation when generating sub-ledgers (ledger B, ledger C). In this example, an example is described in which the seed node of group A is set as the seed node of subgroup B, but a node 100 different from the seed node of group A may also be set as the seed node of subgroup B.

[0109] In step S101, node 100a, which is the seed node of group A, decides to split group A (i.e., to create sub-ledgers). For example, node 100a decides to create sub-ledgers when the number of nodes in group A exceeds a threshold. Node 100a may also decide to create sub-ledgers when the number of transactions (occurrence frequency) in group A over a certain period of time exceeds a threshold.

[0110] In step S102, node 100a sends a proposal to create a sub-ledger based on the above-mentioned communication history (aggregated communication history stored in the ledger) to a validator of group A (e.g., node 100b).

[0111] In step S103, the validators of group A (e.g., nodes 100b, 100e, and 100g) reach a consensus on the allocation of nodes to each subgroup. As described above, the nodes 100 are allocated to the subgroups so that the frequency of transactions between different subgroups is minimized.

[0112] In step S104, the validator of group A (for example, node 100b) sends a notification of completion of consensus building (return) to node 100a, which is the seed node of group A.

[0113] In steps S105 to S107, the node 100a, which is a seed node of group A, transmits a node placement notification to the validators of group A (for example, the nodes 100b, 100e, and 100g).

[0114] In step S108, the node 100a, which is the seed node of group A, also serves as the seed node of subgroup B.

[0115] In step S109, the node 100b, which is the validator of group A, also serves as the validator of subgroup B.

[0116] In step S110, node 100e, which is a validator of group A, also serves as a seed node of subgroup C.

[0117] In step S111, the node 100g, which is the validator of group A, also serves as the validator of subgroup C.

[0118] Even after grouping in this manner, each node 100 may continue to manage the communication history in order to reconfigure the groups.

[0119] (5) Other Embodiments The aggregated management of communication histories according to the above-described embodiments may be applied to the hierarchical network described in Patent Document 2. The hierarchical network described in Patent Document 2 is a blockchain network having a hierarchical structure. Such a hierarchical network manages a different ledger for each group, and a group in a higher hierarchy also reflects transactions of a group in a lower hierarchy in the ledger (parent ledger) of the group in the higher hierarchy. The communication history obtained by the aggregated management of communication histories according to the above-described embodiments can also be used for grouping in such a hierarchical network.

[0120] Furthermore, the communication history obtained by the aggregated management of communication histories according to the above-described embodiment is not limited to use for grouping in a blockchain network. For example, a node 100 that has not performed any inter-node communication for a certain period of time may be identified based on the communication history. Such a node 100 may be assumed to have a failure such as a malfunction.

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

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

[0123] The functions performed by node 100 may be implemented in circuitry or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), a CPU (Central Processing Unit), conventional circuitry, and / or combinations thereof, programmed to perform the described functions. A processor includes transistors and other circuits and is considered to be circuitry or processing circuitry. A processor may also be a programmed processor that executes a program stored in memory. In this specification, circuitry, unit, or means refers to hardware that is programmed to perform or executes the described functions. The hardware may be any hardware disclosed herein or any hardware known to be programmed or capable of performing the described functions. If the hardware is a processor, the circuitry, means, or unit is a combination of hardware and software used to configure the hardware and / or processor.

[0124] 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 including 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., 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, 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 precede the second element in some way. 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.

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

[0126] This application claims priority from Japanese Patent Application No. 2023-168708 (filed September 28, 2023), the entire contents of which are incorporated herein by reference.

[0127] (6) Supplementary Notes The following are additional notes regarding the features of the above-described embodiment.

[0128] (Supplementary Note 1) A communication system comprising a plurality of nodes constituting a peer-to-peer network, each of the plurality of nodes comprising: a communication unit that performs inter-node communication in the peer-to-peer network; a memory unit that stores a communication history including information on each past inter-node communication performed by the communication unit; and a control unit that, when the communication unit performs inter-node communication with another node, provides the other node with the communication history stored in the memory unit and acquires the communication history stored in the other node, and the control unit updates the communication history stored in the memory unit using the acquired communication history.

[0129] (Supplementary Note 2) In the process of updating the communication history stored in the storage unit, the control unit identifies, from the acquired communication history, information on inter-node communication that is not included in the communication history stored in the storage unit, and adds the identified information to the communication history stored in the storage unit. This is the communication system described in Supplementary Note 1.

[0130] (Supplementary Note 3) The communication system according to Supplementary Note 1 or 2, wherein the control unit issues a transaction using the communication history stored in the storage unit as data at a predetermined timing.

[0131] (Supplementary Note 4) The communication system according to Supplementary Note 3, wherein the control unit deletes the communication history stored in the storage unit in response to issuing the transaction.

[0132] (Supplementary Note 5) The communication system according to Supplementary Note 3, wherein the predetermined timing is a timing when a certain amount of the communication history is accumulated in the storage unit.

[0133] (Supplementary Note 6) The communication system according to Supplementary Note 4, wherein the predetermined timing is a timing when a certain time has elapsed since the transaction was issued last time.

[0134] (Supplementary Note 7) The communication system described in Supplementary Note 3, wherein each of the plurality of nodes stores a ledger that is managed in a distributed manner by the plurality of nodes, and adds a new block including the communication history issued as data of the transaction to the ledger of the own node based on the issuance of the transaction.

[0135] (Supplementary Note 8) The communication system according to Supplementary Note 7, wherein the predetermined timing is a timing of block generation.

[0136] (Supplementary Note 9) The communication system according to any one of Supplementary Notes 1 to 8, wherein the plurality of nodes are a plurality of first nodes that store the communication history, and the peer-to-peer network further includes one or more second nodes that do not store the communication history.

[0137] (Supplementary Note 10) The communication system described in any of Supplementary Notes 1 to 9, wherein the plurality of nodes are a plurality of first nodes that store the communication history, the peer-to-peer network further includes a plurality of second nodes that store a limited communication history, and each of the plurality of second nodes does not add information about inter-node communication with the first node to the limited communication history, but adds information about inter-node communication with the second node to the limited communication history.

[0138] (Supplementary Note 11) The communication system described in Supplementary Note 10, wherein each of the plurality of second nodes provides the limited communication history stored in the node to the first node during inter-node communication with the first node, and deletes the limited communication history stored in the node.

[0139] (Supplementary Note 12) A node included in a plurality of nodes constituting a peer-to-peer network, comprising: a communication unit that performs inter-node communication in the peer-to-peer network; a memory unit that stores a communication history including information on each past inter-node communication performed by the communication unit; and a control unit that, when the communication unit performs inter-node communication with another node, provides the communication history stored in the memory unit to the other node and acquires the communication history stored in the other node, wherein the control unit uses the acquired communication history to update the communication history stored in the memory unit.

[0140] (Supplementary Note 13) A program that causes a node included in a plurality of nodes that make up a peer-to-peer network to store a communication history including information on each past inter-node communication conducted by the node; when the node conducts inter-node communication with another node, providing the stored communication history to the other node and acquiring the communication history stored in the other node; and updating the stored communication history using the acquired communication history.

[0141] 100: Node 110: Communication unit 120: Control unit 121: Processor 130: Storage unit 140: Battery 150: User interface 200: Group

Claims

1. A communication system comprising a plurality of nodes constituting a peer-to-peer network, each of the plurality of nodes comprising: a communication unit which performs inter-node communication in the peer-to-peer network; a memory unit which stores a communication history including information on each past inter-node communication performed by the communication unit; and a control unit which, when the communication unit performs inter-node communication with another node, provides the other node with the communication history stored in the memory unit and acquires the communication history stored in the other node, and the control unit uses the acquired communication history to update the communication history stored in the memory unit.

2. The communication system described in claim 1, wherein the control unit, in the process of updating the communication history stored in the memory unit, identifies information on inter-node communication from the acquired communication history that is not included in the communication history stored in the memory unit, and adds the identified information to the communication history stored in the memory unit.

3. The communication system according to claim 1 or 2, wherein the control unit issues a transaction at a predetermined timing, the transaction using the communication history stored in the memory unit as data.

4. The communication system according to claim 3, wherein the control unit deletes the communication history stored in the storage unit in response to issuing the transaction.

5. The communication system according to claim 3, wherein the predetermined timing is a timing when a certain amount of the communication history has been accumulated in the storage unit.

6. The communication system according to claim 4, wherein the predetermined timing is a timing when a fixed time has elapsed since the transaction was issued the previous time.

7. The communication system according to claim 3, wherein each of the plurality of nodes stores a ledger that is managed in a distributed manner among the plurality of nodes, and, based on the issuance of the transaction, adds a new block including the communication history issued as data of the transaction to the ledger of the own node.

8. The communication system according to claim 7, wherein the predetermined timing is a timing of block generation.

9. The communication system of claim 1, wherein the plurality of nodes are a plurality of first nodes that store the communication history, and the peer-to-peer network further includes one or more second nodes that do not store the communication history.

10. The communication system of claim 1, wherein the plurality of nodes are a plurality of first nodes that store the communication history, the peer-to-peer network further includes a plurality of second nodes that store a limited communication history, and each of the plurality of second nodes adds information about inter-node communication with the second node to the limited communication history without adding information about inter-node communication with the first node to the limited communication history.

11. The communication system described in claim 10, wherein each of the plurality of second nodes, when communicating with the first node, provides the limited communication history stored in the own node to the first node and deletes the limited communication history stored in the own node.

12. A node included in a plurality of nodes constituting a peer-to-peer network, comprising: a communication unit that performs inter-node communication in the peer-to-peer network; a memory unit that stores a communication history including information on each past inter-node communication performed by the communication unit; and a control unit that, when the communication unit performs inter-node communication with another node, provides the communication history stored in the memory unit to the other node and acquires the communication history stored in the other node, wherein the control unit updates the communication history stored in the memory unit using the acquired communication history.

13. A program that causes a node included in a plurality of nodes constituting a peer-to-peer network to store a communication history including information on each past inter-node communication conducted by the node; when the node performs inter-node communication with another node, the stored communication history is provided to the other node and the communication history stored in the other node is acquired; and the stored communication history is updated using the acquired communication history.

Images