Control method, control device, and program

Abstract

In a distributed ledger system having a plurality of devices having distributed ledgers, a control method executed by a first device among the plurality of devices receives second identification information of a second device via short-range wireless communication from the second device different from the first device among the plurality of devices (S1), generates a block including transaction data selected from a transaction pool of the first device, the second identification information, and first identification information of the first device (S2), and executes a storage process of storing the generated block in the distributed ledgers held by the plurality of devices (S3).

Description

[Technical Field]

[0001] The present invention relates to a control method, a control device, and a program. [Background technology]

[0002] In distributed ledger technology (for example, blockchain technology), methods for controlling approval when creating blocks include Proof of Work (hereinafter, PoW) and Proof of Stake (hereinafter, PoS) (for example, see Non-Patent Documents 1 and 2). [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] Satoshi Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System”, [online], 2008, [Retrieved April 1, 2021], Internet<URL:https: / / bitcoin.org / bitcoin.pdf> [Non-patent document 2] Sunny King, Scott Nadal, “PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake”, [online], 2012, [Retrieved April 1, 2021], Internet<URL:https: / / decred.org / research / king2012.pdf> Summary of the Invention [Problem to be solved by the invention]

[0004] However, when using methods such as PoW or PoS, there is a problem in that the amount of processing related to the distributed ledger executed by the device is unevenly distributed among the devices.

[0005] Therefore, the present invention provides a control method that suppresses imbalance in the processing volume of each device in a distributed ledger system. [Means for solving the problem]

[0006] A control method according to one aspect of the present invention is a control method executed by a first device of a distributed ledger system including a plurality of devices each holding a distributed ledger, the control method receiving a second identification information of the second device from a second device different from the first device of the plurality of devices via near field wireless communication, generating a block including transaction data selected from a transaction pool held by the first device, the second identification information, and the first identification information of the first device, and executing a storage process to store the generated block in the distributed ledger held by the plurality of devices.

[0007] These comprehensive or specific aspects may be realized as a system, device, integrated circuit, computer program, or computer-readable recording medium such as a CD-ROM, or may be realized as any combination of a system, device, integrated circuit, computer program, and recording medium. [Effects of the Invention]

[0008] According to the present invention, it is possible to prevent imbalance in the processing volume of each device in a distributed ledger system. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is an explanatory diagram showing the overall configuration of a blockchain system according to the first embodiment. [Figure 2] FIG. 2 is an explanatory diagram showing the functional configuration of a node according to the first embodiment. [Figure 3] FIG. 3 is an explanatory diagram showing the data structure of a block according to the first embodiment. [Figure 4] FIG. 4 is a sequence diagram showing the process of generating and storing blocks in the first embodiment. [Figure 5] FIG. 5 is a sequence diagram showing the process of sharing and storing a block in the first embodiment. [Figure 6] FIG. 6 is a flowchart showing the process of generating and storing blocks in the second embodiment. [Figure 7] FIG. 7 is an explanatory diagram showing the functional configuration of a control device in a modified example. [Figure 8] FIG. 8 is a flow chart showing a control method in the modified example. DETAILED DESCRIPTION OF THE INVENTION

[0010] The present inventor has found that the following problems arise with the blockchain technology described in the "Background Art" section.

[0011] In distributed ledger technology (such as blockchain technology), methods such as PoW and PoS are used to control approval when creating blocks.

[0012] PoW controls block approval based on the computing power of the devices (also called nodes) participating in the blockchain, while PoS controls block approval based on the amount of currency held in the blockchain.

[0013] However, in PoW, nodes must perform a huge amount of computational processing to approve blocks. This requires hardware resources or electricity to perform such massive computational processing, which increases costs. In addition, the authority to approve blocks is biased toward nodes or groups of nodes with relatively high computational performance, resulting in a bias in the amount of processing performed by each node, which can lead to problems with maintaining the permanence and fairness of the blockchain.

[0014] On the other hand, in PoS, the authority to approve a block is determined by the amount of cryptocurrency held by the node, which solves the above problems of PoW without requiring a high-performance computer.

[0015] However, in PoS, the authority to approve blocks is biased toward nodes that hold a relatively large amount of virtual currency, which results in a bias in the processing volume per node, which can lead to problems such as the inability to maintain the permanence and fairness of the blockchain.Furthermore, this can lead to a decrease in the liquidity of the currency, which in turn can lead to the problem of currency oligopoly.

[0016] As described above, a distributed ledger system has a problem in that the amount of processing performed by nodes related to the distributed ledger is unevenly distributed among devices. When the amount of processing is unevenly distributed among devices, the operation of maintaining and updating the distributed ledger may not be performed appropriately.

[0017] Therefore, the present invention provides a control method that suppresses imbalance in the processing volume of each device in a distributed ledger system, which can contribute to the proper operation of the distributed ledger system.

[0018] It can also be said that the present invention provides a control method for suppressing bias in the voting rights of individual devices in a distributed ledger system. In other words, the "bias in processing volume of individual devices" in this specification can be rephrased as bias in the voting rights of individual devices in a distributed ledger system. Here, voting rights refer to the right to vote in the system. The control method provided by the present invention can suppress bias in the voting rights of a system due to dependence on the amount of processing volume in PoW or the amount of virtual currency held in PoS.

[0019] In order to solve such problems, one aspect of the present invention provides a control method executed by a first device in a distributed ledger system having a plurality of devices each holding a distributed ledger, the control method receiving a second identification of the second device from a second device different from the first device via near field wireless communication, generating a block including transaction data selected from a transaction pool held by the first device, the second identification information, and the first identification information of the first device, and executing a storage process to store the generated block in the distributed ledger held by the plurality of devices.

[0020] According to the above aspect, among multiple devices constituting a distributed ledger system, two devices that are physically close to each other, i.e., two devices that have performed short-range wireless communication, execute a block storage process based on the short-range wireless communication. Since two devices are located within a distance where short-range wireless communication is possible with a relatively high frequency, the speed of block approval can be maintained without reduction. Furthermore, the two devices that perform short-range wireless communication can be selected evenly from the multiple nodes constituting the distributed ledger system. Therefore, the above control method can prevent imbalances in the processing volume of each device in the distributed ledger system.

[0021] Furthermore, the above control method does not require the massive computational processing required in PoW, eliminating the need for hardware resources or power required for performing such massive computational processing, thereby reducing costs. Therefore, even computers with relatively low computing power (e.g., smartphones or personal computers) can approve blocks. This can contribute to preventing the monopolization of currencies, or in other words, increasing the liquidity of currencies. Furthermore, the above control method prevents imbalances in block approval authority according to the amount of currency held, which occurs in PoS, thereby reducing imbalances in the processing volume of each device.

[0022] In this way, the control method of the present invention controls block approval based on the physical proximity of devices when generating blocks, regardless of the computing performance of the computers or the amount of currency held. This makes it possible to realize a distributed ledger system that is not dependent on the performance of computers or the amount of currency held, while maintaining the resistance to falsification and reliability inherent in distributed ledger technology.

[0023] For example, in the storage process, the fewer the number of blocks stored in the distributed ledger that are generated based on near-field wireless communication between the first device and the second device, the higher the probability that the generated blocks will be stored in the distributed ledger.

[0024] According to the above aspect, a block generated based on close proximity wireless communication between two devices that have generated blocks based on close proximity wireless communication in the past is more likely to be stored in the distributed ledger. This prevents a concentration of devices involved in block generation among a small number of specific devices. This makes it possible to prevent a concentration of processing load among devices in the distributed ledger system.

[0025] For example, in the storage process, if the number of blocks generated based on near-field wireless communication between the first device and the second device among the blocks stored in the distributed ledger is less than a predetermined number, the generated blocks may be stored in the distributed ledger.

[0026] According to the above aspect, blocks generated through close proximity wireless communication between two devices that have previously generated a predetermined number of blocks through close proximity wireless communication or less can be stored in the distributed ledger. This more appropriately prevents devices involved in block generation from being over-represented in a small number of specific devices. This more appropriately prevents the over-representation of processing loads among devices in the distributed ledger system.

[0027] For example, in the storage process, the fewer the number of blocks generated based on near-field wireless communication between the first device and the second device among the latest predetermined number of blocks stored in the distributed ledger, the higher the probability that the generated blocks will be stored in the distributed ledger.

[0028] According to the above aspect, blocks generated based on close proximity wireless communication between two devices during a predetermined period ending at the current time point are more likely to be stored in the distributed ledger. This more appropriately prevents devices involved in block generation from being over-represented in a small number of specific devices. This more appropriately prevents the over-representation of processing loads among devices in the distributed ledger system.

[0029] For example, in the storage process, if the number of blocks generated based on near-field wireless communication between the first device and the second device among the latest predetermined number of blocks stored in the distributed ledger is less than or equal to a predetermined number, the generated blocks may be stored in the distributed ledger.

[0030] According to the above aspect, blocks generated through close proximity wireless communication between two devices that have generated a predetermined number of blocks through close proximity wireless communication within a predetermined period ending at the current time point can be stored in the distributed ledger. This more appropriately prevents devices involved in block generation from being over-represented in a small number of specific devices. This more appropriately prevents the over-representation of processing loads among devices in the distributed ledger system.

[0031] For example, in the storage process, if the latest block among the blocks stored in the distributed ledger is a block generated based on near-field wireless communication between the first device and the second device, the generated block may be prohibited from being stored in the distributed ledger.

[0032] According to the above aspect, blocks generated based on close proximity wireless communication between two devices that generated blocks based on close proximity wireless communication immediately before the current time are prohibited from being stored in the distributed ledger. This prevents two specific devices from consecutively storing blocks in the distributed ledger. This makes it possible to prevent imbalances in the processing volume of each device in the distributed ledger system.

[0033] For example, in the storage process, if the generated block is to be stored in the distributed ledger, the generated block is sent to the multiple devices, thereby storing it in the distributed ledger held by the multiple devices, and if the generated block is not to be stored in the distributed ledger, the generated block does not need to be sent to the multiple devices.

[0034] According to the above aspect, by controlling whether or not to send a generated block to multiple devices, it is possible to more easily control whether or not to store the block in the distributed ledger, thereby more easily preventing imbalance in the processing load of each device in the distributed ledger system.

[0035] For example, in the storage process, when the generated block is to be stored in the distributed ledger, the generated block may be sent to the second device, thereby attaching the digital signature of the second device to the sent block, the block with the digital signature of the second device attached is received, the received block is attached with the digital signature of the first device, and the block with the digital signatures of the first device and the second device attached may be stored in the distributed ledger held by the multiple devices.

[0036] According to the above aspect, a generated block is assigned the digital signatures of the two devices that performed the close proximity wireless communication and stored in the distributed ledger. This clarifies that the block was indeed generated based on close proximity wireless communication between the two devices, and allows for subsequent verification. Therefore, the above control method clarifies the devices involved in the generation of the block, while suppressing imbalances in the processing load of each device in the distributed ledger system.

[0037] For example, the second identification information may include authentication information generated using the private key of the second device, and when the second identification information is received, the authentication information included in the second identification information may be verified using the public key of the second device, and the block may be generated only if the verification is successful.

[0038] According to the above aspect, blocks can be generated based on proximity to devices verified as legitimate devices in the distributed ledger system. Therefore, the above control method can more appropriately suppress imbalance in the processing volume of each device in the distributed ledger system by using near-field communication with legitimate devices.

[0039] In order to solve such problems, a control device according to one embodiment of the present invention is a control device that is a first device of a distributed ledger system having a plurality of devices that hold a distributed ledger, the control device comprising: a short-range communication unit that receives, via short-range wireless communication, a second identification information of the second device from a second device different from the first device of the plurality of devices; and a control unit that (a) generates a block that includes transaction data selected from a transaction pool held by the first device, the second identification information, and the first identification information of the first device, and (b) executes a storage process that stores the generated block in the distributed ledger held by the plurality of devices.

[0040] According to the above aspect, the same effects as those of the above control method are achieved.

[0041] In order to solve such a problem, a program according to one aspect of the present invention is a program for causing a computer to execute the above control method.

[0042] According to the above aspect, the same effects as those of the above control method are achieved.

[0043] These comprehensive or specific aspects may be realized as a system, device, integrated circuit, computer program, or computer-readable recording medium such as a CD-ROM, or may be realized as any combination of a system, device, integrated circuit, computer program, or recording medium.

[0044] Hereinafter, the embodiments will be specifically described with reference to the drawings.

[0045] The embodiments described below are all comprehensive or specific examples. The numerical values, shapes, materials, components, component placement and connection configurations, steps, and step order shown in the following embodiments are merely examples and are not intended to limit the present invention. Furthermore, among the components in the following embodiments, components that are not described in the independent claims that represent the highest concepts are described as optional components.

[0046] (Embodiment 1) In this embodiment, a method for controlling nodes constituting the blockchain system 1 that suppresses imbalance in the processing volume of each device in the distributed ledger system will be described.

[0047] 1. System Configuration Here, we will explain an example in which a new block is stored in the blockchain based on two nodes belonging to the blockchain system 1 passing each other.

[0048] In the following, a blockchain system 1 will be described as an example of a distributed ledger system. It is also possible to adopt a distributed ledger of a type other than blockchain (for example, IOTA or hash graph).

[0049] 1.1 Overall system configuration Figure 1 is an explanatory diagram showing the overall configuration of a blockchain system 1 in this embodiment. The blockchain system 1 includes nodes 100a, 100b, and 100c (also referred to as nodes 100a, etc.). The nodes 100a, etc. are nodes of a blockchain that make up the blockchain system 1. The nodes 100a, etc. are realized by computer devices, and more specifically, are realized by personal computers, smartphones, tablets, etc.

[0050] The nodes 100a and the like are communicatively connected via a network N. Furthermore, the nodes 100a and 100b can be communicatively connected via short-range wireless communication. For example, the nodes 100a and 100b are each carried by a user, and when the user of the node 100a and the user of the node 100b pass each other, the nodes 100a and 100b are connected via short-range wireless communication. The following description will be given assuming this case. The node 100a corresponds to a first device, and the node 100b corresponds to a second device.

[0051] The blockchain system 1 may or may not include a network N.

[0052] The nodes 100a, etc. each have the same hardware configuration and functional configuration, and each node 100a, etc. operates independently.

[0053] 1.2 Configuring the Node FIG. 2 is an explanatory diagram showing the functional configuration of the node 100a as a representative of the nodes 100a and the like in this embodiment.

[0054] 2, the node 100a includes, as functional units, a short-range communication unit 101, an encryption processing unit 102, a client unit 103, a storage unit 104, and a communication unit 105. The client unit 103 also includes a determination unit 107. The functional units of the node 100a are realized by a processor (e.g., a CPU (Central Processing Unit)) (not shown) included in the node 100a executing a predetermined program using a memory (not shown).

[0055] The short-distance communication unit 101 is a functional unit that performs short-distance wireless communication, and includes a communication interface that performs close proximity wireless communication. The close proximity wireless communication is, for example, close proximity wireless communication that complies with the Bluetooth (registered trademark) standard.

[0056] When node 100a approaches another node, that is, when the distance to the other node is within a range where short-range wireless communication is possible, short-range communication unit 101 exchanges connection information by performing short-range wireless communication with the short-range communication unit 101 of the other node. The approach of node 100a to another node corresponds to node 100a passing by the other node. Note that such short-range communication may also be generally referred to as passing-by communication.

[0057] The connection information includes identification information that can uniquely identify the node, and key information for connecting to the blockchain system 1. The identification information includes authentication information generated using the private key of the node.

[0058] For example, when the node 100a and the node 100b pass each other, the short-range communication unit 101 of the node 100a receives connection information of the node 100b from the node 100b.

[0059] The cryptographic processing unit 102 is a processing unit that decrypts information received by the short-range communication unit 101 and encrypts information to be transmitted by the short-range communication unit 101. Based on the information received and decrypted by the short-range communication unit 101, the cryptographic processing unit 102 verifies that the node 100b, which is the connection partner, is a legitimate node connected to the blockchain system 1. If the verification is successful, the cryptographic processing unit 102 maintains the close proximity wireless communication by the short-range communication unit 101, and if the verification is unsuccessful, the cryptographic processing unit 102 disconnects the close proximity wireless communication.

[0060] The information decrypted or encrypted by the cryptographic processing unit 102 includes connection information. By encrypting the connection information, intervention or eavesdropping from devices outside the blockchain system 1 is prevented.

[0061] The client unit 103 is a functional unit that executes processing for the node 100a to operate as a blockchain client. The client unit 103 generates blocks, approves blocks using the determination unit 107, adjusts parameters of conditional expressions for approving blocks, communicates with other nodes using the communication unit 105 (including, for example, sending and receiving block information), and controls writing and reading of data to the storage unit 104. The client unit 103 stores approved blocks in the blockchain, but does not store unapproved blocks in the blockchain.

[0062] The determination unit 107 is a functional unit that makes a determination about the approval of a block. The determination unit 107 makes a determination about the approval of a block by using a predetermined conditional expression and taking into consideration the combination of nodes (also called a node pair) that generated the approved block that is already shared in the blockchain system 1.

[0063] More specifically, the client unit 103 generates a block including one or more transaction data selected from the transaction pool held by the node 100a, the identification information of the node 100b, and the identification information of the node 100a. The client unit 103 then executes a storage process to store the generated block in the distributed ledger held by the node 100a, etc. In the storage process, the client unit 103 controls whether or not to store the block in the blockchain using the determination result by the determination unit 107 as to whether or not to approve the generated block.

[0064] In the storage process, the fewer the number of blocks stored in the blockchain that are generated based on near-field wireless communication between node 100a and node 100b, the higher the probability that the generated blocks will be stored in the blockchain.

[0065] In addition, in the storage process, if the number of blocks generated based on near-field wireless communication between node 100a and node 100b among the blocks stored in the blockchain is less than a predetermined number, the generated blocks may be stored in the blockchain.

[0066] In addition, in the storage process, the fewer the number of blocks generated based on near-field wireless communication between node 100a and node 100b among the latest predetermined number of blocks stored in the blockchain, the higher the probability that the generated blocks will be stored in the blockchain.

[0067] In addition, in the storage process, if the number of blocks generated based on near-field wireless communication between node 100a and node 100b among the latest predetermined number of blocks stored in the blockchain is less than or equal to a predetermined number, the generated blocks may be stored in the blockchain.

[0068] In addition, in the storage process, if the latest block among the blocks stored in the blockchain is a block generated based on near-field wireless communication between node 100a and node 100b, the generated block may be prohibited from being stored in the blockchain.

[0069] When the client unit 103 receives the identification information included in the connection information of the node 100b, it may verify the authentication information included in the identification information using the public key of the node 100b, and generate a block only if the verification is successful.

[0070] In the storage process, if the generated block is to be stored in the distributed ledger, the client unit 103 stores the generated block in the distributed ledger held by the nodes 100b and 100c by transmitting the generated block to the nodes 100b and 100c using the communication unit 105. If the generated block is not to be stored in the distributed ledger, the client unit 103 does not transmit the generated block to the nodes 100b and 100c.

[0071] The memory unit 104 is a functional unit that stores various types of information and includes a storage device. The memory unit 104 stores information used in processing by the cryptographic processing unit 102 and the client unit 103. The memory unit 104 stores, for example, identification information of other nodes, blockchain data, and parameters (such as α or β) in conditional expressions (described later) for block approval. The parameters are values ​​shared by each node included in the blockchain system 1.

[0072] The communication unit 105 is a functional unit that is communicatively connected to the network N and includes a communication interface. The communication unit 105 includes, for example, a communication interface that connects to an access network of a mobile phone carrier, or a communication interface that connects to a wireless LAN (Local Area Network) such as WiFi (registered trademark). The communication unit 105 may also include a communication interface that connects to a wired network such as Ethernet.

[0073] 1.3 Block Data Structure Next, the data structure of a block will be described.

[0074] 3 is an explanatory diagram showing the data structure of the block 20 in this embodiment. The block 20 is generated by the client unit 103.

[0075] As shown in FIG. 3, the block 20 includes a transaction section 21, a header section 22, and a signature section .

[0076] The transaction unit 21 includes one or more transaction data (for example, transaction data 211, 212, ...). The one or more transaction data included in the transaction unit 21 includes information about transactions generated in the blockchain system 1, and is selected from a transaction pool held by the node 100a.

[0077] The header section 22 includes a hash value 221 , a block number 222 , identification information 223 and 224 , a creation date and time 225 , and a parameter 226 .

[0078] The hash value 221 is the hash value of the block immediately preceding the block in question in the blockchain, and is a hash value calculated using a predetermined hash function.

[0079] The block number 222 is the number of the block in question in the blockchain.

[0080] The identification information 223 is the identification information of one of the two nodes involved in the generation of the block.

[0081] The identification information 224 is the identification information of the other of the two nodes involved in generating the block.

[0082] The creation date and time 225 is information indicating the date and time when the block was created.

[0083] Parameter 226 includes parameters α and β.

[0084] Signature section 23 includes signatures 231 and 232 as the electronic signatures of two nodes related to the generation of the block. When block 20 is generated based on the passing communication between node 100a and node 100b, signatures 231 and 232 include the signatures of node 100a and node 100b. Note that the term "signature" simply means an electronic signature. The same applies hereinafter.

[0085] 1.4 Conditions for Approving a Block The conditions used by client section 103 (more specifically, determination section 107) to determine the approval of a block will be described below.

[0086] As described above, client section 103 stores the generated block in the blockchain with a higher probability as the number of blocks generated based on the proximity wireless communication between nodes 100a and 100b among the blocks stored in the blockchain is smaller.

[0087] To implement such processing, client section 103 approves the block when the hash value H(100a, 100b) calculated by a predetermined hash function is smaller than the threshold Th (Equation 1 below), and does not approve the block when it is not (Equation 2 below).

[0088] H(100a, 100b) < Th ··· Approval (Equation 1) H(100a, 100b) ≥ Th ··· Non-approval (Equation 2)

[0089] The hash value H(100a, 100b) is a value obtained by calculating the identification information of node 100a and the identification information of node 100b using a predetermined hash function.

[0090] <00..0318>The threshold Th is, for example,

Equation

[0091] where α and β are parameters that control the probability of approving a block.

[0092] α uniformly increases or decreases the probability of approving a block by uniformly increasing or decreasing the threshold Th.

[0093] β increases or decreases the degree to which the number of occurrences of pairs of two nodes involved in the generation of blocks already existing in the blockchain contributes to the threshold Th.

[0094] N is the number of blocks in the existing blockchain. COUNT(B i,j ) indicates the number of blocks in the existing blockchain that were generated based on the passing communication between node i and node j.

[0095] The threshold value Th will be explained below using a specific example.

[0096] In the configuration of Fig. 1, it is assumed that the number of blocks N included in the existing blockchain is 1, and that this block was generated based on passing communication between node 100a and node 100b. In this case, the condition determination when generating and approving the second block of the blockchain will be explained as an example.

[0097] For simplicity of explanation, α in the threshold Th is set to 100.0 and β is set to 1.0. Suppose that the hash value H(100a, 100b) obtained by calculating the identification information of node 100a and the identification information of node 100b using a hash function is 10. Suppose that the hash value H(100a, 100c) obtained by calculating the identification information of node 100a and the identification information of node 100c using a hash function is 20.

[0098] First, when a block is generated based on passing communication between nodes 100a and 100b, the threshold value Th is 100.0 × (1 − 1.0 × 1 ÷ 1), that is, 0. Since the hash value H(100a, 100b), which is 10, is greater than the result of the above calculation, 0, the client unit 103 does not approve the generated block (see above (Equation 2)).

[0099] Next, when a block is generated as a result of node 100a and node 100c passing each other, the threshold Th is 100.0 × (1 − 1.0 × 0 ÷ 1), or 100. Since the hash value H(100a, 100c), which is 20, is smaller than the result of the above calculation, 100, the client unit 103 approves the generated block (see above (Equation 1)).

[0100] Note that COUNT(B i,j ) may be a block included in an existing blockchain and may indicate the number of blocks generated based on the passing communication between node i and node j among the latest predetermined number of blocks. In this way, by controlling the approval of new blocks using only the latest predetermined number of blocks, it is possible to prevent imbalance in the processing volume of each device in the distributed ledger system.

[0101] 1.5 Block Creation, Sharing, and Storage Process The process of generating, sharing, and storing blocks by the nodes 100a and the like will be described below.

[0102] 4 is a sequence diagram showing the process of generating and storing a block in this embodiment. Here, the process of generating a block based on the node 100a and node 100b performing in-passing communication will be described.

[0103] 4, in step S101, the short-range communication unit 101 of the node 100a or the like establishes short-range communication with another node. For example, when the node 100a and the node 100b come close enough to each other to establish short-range wireless communication, the short-range communication unit 101 of the node 100a and the short-range communication unit 101 of the node 100b establish short-range wireless communication. If short-range communication is established, the process proceeds to step S102; otherwise, the short-range communication unit 101 waits in step S101 until short-range communication is established.

[0104] The node 100a may proceed to step S102 not only when short-range wireless communication is established, but also whenever a predetermined time has elapsed while short-range wireless communication is established.

[0105] In step S102, node 100a transmits connection information to node 100b, which is the connection partner with which the short-range wireless communication connection was established in step S101. Similarly, short-range communication unit 101 of node 100b transmits the connection information to node 100a, which is the connection partner, thereby sharing the connection information with node 100a. As a result, node 100a and node 100b share the connection information.

[0106] In step S103, node 100a determines, based on the connection information received in step S102, whether the connection partner (i.e., node 100b) is a legitimate node in the blockchain system 1. If it is determined that the connection partner is a legitimate node (Yes in step S103), the process proceeds to step S104; if not (No in step S103), the process ends. Node 100b also performs a similar process.

[0107] In step S104, the client unit 103 of node 100a selects transaction data to be included in a block to be generated from its own transaction pool. The client unit 103 of node 100a then generates a block containing the selected transaction data, the hash value of the latest block included in the blockchain, the identification information of node 100a, the identification information of node 100b, and the creation date and time. At this point, the signature unit 23 of the generated block does not contain a signature.

[0108] In selecting the transaction data, for example, the node 100a selects the transaction data based on the fee that can be obtained by approving the transaction data. For example, the client unit 103 may select transaction data with a higher priority, the higher the fee that can be obtained by approving the transaction data.

[0109] In step S105, the client unit 103 of the node 100a determines whether to approve the block generated in step S104. At this time, the client unit 103 determines whether to approve the block using at least the identification information of the node 100a and the identification information of the node 100b. If it is determined that the block is approved (Yes in step S105), the process proceeds to step S106; if not (No in step S105), the series of processes shown in FIG. 4 ends.

[0110] In step S106, the client unit 103 of the node 100a transmits the block generated in step S104 to the node 100b, thereby requesting that a signature be added to the block. The node 100b receives the transmitted block.

[0111] In step S107, node 100b determines whether to approve the block using the block identification information received in step S106. If it is determined that the block is approved (Yes in step S107), the process proceeds to step S108; if not (No in step S107), the process ends.

[0112] In step S108, the node 100b adds a signature to the signature section 23 of the block received in step S106.

[0113] In step S109, the node 100b transmits the block to which the signature was added in step S108 to the node 100a. The node 100a receives the transmitted block.

[0114] In step S110, the node 100a adds a signature to the signature section 23 of the block received in step S109.

[0115] In step S111, the node 100a stores the block to which the signature was added in step S110 in the blockchain.

[0116] In step S200, the node 100a broadcasts the block received in step S109 within the blockchain system 1 to share it. Details of the processing in step S200 will be described later.

[0117] 1.6 Sharing Blocks The process of sharing a block among nodes 100a, 100b, and 100c will now be described.

[0118] Fig. 5 is a sequence diagram showing the process of sharing and storing a block in this embodiment. Fig. 5 shows the process of propagating a block generated by node 100a to nodes 100b and 100c by broadcasting it within the blockchain system 1, thereby sharing the block within the blockchain system 1. The process shown in Fig. 5 shows in detail the process included in step S200 shown in Fig. 4.

[0119] Here, it is assumed that the node 100a and the node 100b are connected to each other on the P2P network of the blockchain system 1, and the node 100b and the node 100c are also connected to each other.

[0120] In step S201, the node 100a transmits the block to which the signature was added in step S110 to the node 100b. The node 100b receives the transmitted block.

[0121] In step S202, node 100b determines whether to approve the block received in step S201. Specifically, node 100b determines whether the condition for approving a block (the above (Equation 1)) is satisfied for the block. If node 100b approves the block, that is, if it determines that the above condition is satisfied (Yes in step S202), it proceeds to step S203, and if it determines that the condition is not satisfied (No in step S202), it discards the block and ends the series of processes shown in FIG. 5.

[0122] In step S203, node 100b determines whether the block received in step S201 contains fraudulent transaction data. Determining whether the transaction data is fraudulent includes, for example, determining whether multiple transaction data indicating the same payment will be included in the blockchain (i.e., whether a double payment will occur). If it is determined that the block contains fraudulent transaction data (Yes in step S203), the node 100b discards the block and terminates the series of processes shown in FIG. 5; if not (No in step S203), the node 100b proceeds to step S204.

[0123] In step S204, the node 100b stores the block received in step S201 in the blockchain.

[0124] In step S205, the node 100b transmits the block received in step S201 to the node 100c, which receives the transmitted block.

[0125] In step S206, node 100c determines whether the condition for approving the block (the above (Equation 1)) is satisfied for the block received in step S205. If node 100c determines that the block is to be approved (Yes in step S206), it proceeds to step S207, and if it determines that the block is not to be approved (No in step S202), it discards the block and ends the series of processes shown in FIG.

[0126] In step S207, node 100c determines whether the block received in step S205 contains fraudulent transaction data. If it is determined that the block contains fraudulent transaction data (Yes in step S207), node 100c discards the block and terminates the series of processes shown in Fig. 5; if not (No in step S207), node 100c proceeds to step S208.

[0127] In step S208, the node 100c stores the block received in step S205 in the blockchain.

[0128] 1.7 Effects of the First Embodiment As shown in the first embodiment, the blockchain system 1 generates blocks by utilizing the proximity or passing of nodes. This enables block generation without constant calculations using a high-performance computer. In this case, the success or failure of block generation or approval is controlled using the frequency of occurrence of pairs of nodes involved in the generation of the block. This allows the blockchain system 1 to prevent oligopoly or a decrease in liquidity.

[0129] (Embodiment 2) 2. System Configuration In this embodiment, a different configuration from that of the first embodiment will be described, such as a control method for nodes constituting the blockchain system 1 that suppresses uneven distribution of processing volume among devices in the distributed ledger system.

[0130] Specifically, in the first embodiment, a configuration was described in which one of the nodes belonging to the blockchain system 1 that pass each other generates a block, but in this embodiment, a configuration is described in which both of the nodes that pass each other each generate a block. Note that the following mainly describes the differences between the first embodiment and the second embodiment.

[0131] 2.1 Block Creation, Sharing, and Storage Process The process of generating, sharing, and storing blocks by the nodes 100a and the like will be described below.

[0132] Fig. 6 is a flow diagram showing the process of generating and storing blocks in this embodiment. Specifically, Fig. 6 explains the process of each node generating a block based on passing communication between node 100a and node 100b.

[0133] Steps S301 to S303 are the same as steps S101 to S103 in the first embodiment.

[0134] In step S304, the client unit 103 of node 100a selects transaction data from its own transaction pool and generates a block (also referred to as block A) containing the selected transaction data, etc., similar to step S104 in embodiment 1. Similarly to step S104 in embodiment 1, the client unit 103 of node 100b selects transaction data from its own transaction pool and generates a block (also referred to as block B) containing the selected transaction data, etc. Note that the transaction data selected by nodes 100a and 100b may be different.

[0135] In step S305, the client unit 103 of node 100a determines whether to approve the block generated in step S304. At this time, the client unit 103 determines whether to approve the block using at least the identification information of node 100a and the identification information of node 100b. If it is determined that the block is to be approved (Yes in step S305), the process proceeds to step S306; if not (No in step S305), the series of processes shown in FIG. 6 ends. Similarly, the client unit 103 of node 100b determines whether to approve the block generated in step S304. Note that the parameters α and β in the conditional equation (above (Equation 1)) used by node 100a and node 100b for the above determination may be different.

[0136] In step S306, the node 100a transmits the block A generated in step S304 to the node 100b. Similarly, the node 100b transmits the block B generated in step S304 to the node 100a.

[0137] In step S307, node 100a determines which of block A generated in step S304 and block B received in step S306 to store in the blockchain. Similarly, node 100b determines which of block B generated in step S304 and block A received in step S306 to store in the blockchain. At this time, nodes 100a and 100b determine which of the above blocks to store in the blockchain based on a common criterion.

[0138] In the above step S307, the block may be determined based on the reward. For example, the block that will provide the larger reward when stored in the blockchain is determined. Here, as an example, the process will be described in which block A generated by node 100a is determined as the block to be stored in the blockchain.

[0139] In step S308, the node 100b affixes a signature to the signature part 23 of the block A received in step S306.

[0140] In step S309, node 100b transmits block A to which the signature was added in step S308 to node 100a. Node 100a receives block A that has been transmitted.

[0141] In step S310, the node 100a attaches a signature to the block A received in step S309.

[0142] In step S311, the node 100a stores the block A to which the signature was added in step S310 in the blockchain.

[0143] In step S200, the node 100a shares the block A received in step S309 by broadcasting it within the blockchain system 1. Step S200 is the same as step S200 in the first embodiment.

[0144] 2.2 Conditions for Approving a Block In this embodiment, the threshold Th may include a hash value of a block. For example, if α includes a hash value of a block, the nodes 100a and 100b can decide whether to approve each block containing transaction data individually selected by them.

[0145] 2.3 Effects of the Second Embodiment In the second embodiment, in addition to the effects of the first embodiment, the blockchain of the present system can attempt to generate two blocks in response to a single miss, thereby improving the transaction processing speed across the entire network. Also, since nodes are more likely to receive rewards by approving blocks, there is a possibility that this will have the effect of providing an incentive for nodes to participate in the network.

[0146] (Variation) Below, modifications of the nodes and control methods of the above-described embodiments will be described.

[0147] The node 110 in this modification will be described with reference to FIG.

[0148] 7, a node 110 in this modification includes a short-range communication unit 111 and a control unit 112. The node 110 corresponds to each of the nodes 100a and the like in the above-described embodiment.

[0149] The short-range communication unit 111 receives, via short-range wireless communication, identification information of a node different from the node 110 from among the multiple nodes belonging to the blockchain system 1. The short-range communication unit 111 corresponds to the short-range communication unit 101 in the above embodiment.

[0150] The control unit 112 generates a block including transaction data selected from the transaction pool held by the node 110, the identification information of the different node, and the identification information of the node 110. The control unit 112 also executes a storage process to store the generated block in the blockchain held by the multiple nodes. The control unit 112 corresponds to the client unit 103 in the above embodiment.

[0151] By having the above configuration, node 110 can prevent the imbalance of processing volume among devices in the distributed ledger system.

[0152] Next, a control method in this modified example will be described.

[0153] As shown in FIG. 8, in the control method of this modification, in step S1, identification information of the different node is received from the different node via short-range wireless communication.

[0154] In step S2, a block is generated that includes transaction data selected from the transaction pool held by node 110, the identification information of the different node, and the identification information of node 110.

[0155] In step S3, a storage process is executed to store the generated block in the blockchain held by the plurality of nodes.

[0156] By using the above control method, node 110 can prevent the imbalance of processing volume among devices in the distributed ledger system.

[0157] (Other variations) Although the present invention has been described based on the above-mentioned embodiments, it goes without saying that the present invention is not limited to the above-mentioned embodiments. The following cases are also included in the present invention.

[0158] (1) In the first embodiment, whether to approve a new block is determined using the frequency of occurrence of a pair of nodes that generated a new block among all approved blocks stored in the blockchain, but other criteria may also be used for the determination. For example, whether to approve a new block may be determined using the frequency of occurrence of a pair of nodes that generated a new block among the most recent N blocks.

[0159] (2) In the first embodiment, whether to approve a new block is determined using the frequency of occurrence of pairs of nodes involved in the generation of the new block, but whether to approve a new block may also be determined using the total number of all or some of the misses that occurred between the nodes constituting the blockchain system 1. For example, a new block may be approved based on the Nth miss that occurred on the chain.

[0160] (3) In the first embodiment, the frequency of occurrence of a pair of nodes involved in the generation of a new block is used to determine whether to approve the new block. However, the frequency of occurrence of one of the nodes may also be used.

[0161] (4) In the above embodiment, the frequency of occurrence of pairs of nodes involved in the generation of a new block is used to determine whether to approve a new block, but the time of block generation may also be used to make the determination. For example, the difficulty may be lowered as the generation time of the previous block is older, or the generation time of the previous block of the same node pair may be used.

[0162] (5) In the first embodiment, a method of transmitting blocks sequentially in the process of sharing blocks has been described, but blocks may also be transmitted in parallel.

[0163] (6) In the second embodiment, the selection criteria for the blocks generated by the nodes that have passed each other are the reward levels. However, other criteria such as the time at which the blocks were generated (e.g., selecting the block generated first) may also be used.

[0164] (7) In the above embodiment, the criteria for selecting transactions to be included in a block are the fees involved, but other criteria may be used. For example, the processing costs of smart contracts, etc. may be used. In this case, the load on nodes due to transaction verification can be reduced.

[0165] (8) In the above embodiment, the parameter α in the conditional expression (Equation 1) is described as a constant, but it may be a variable value determined by any calculation. For example, the hash value of the previous block may be included as a factor. In this case, the connectivity of the blocks can also be guaranteed by the conditional judgment.

[0166] (9) In the above embodiment, the parameter β in the conditional expression (Equation 2) is described as a constant, but it may be a variable value determined by any calculation. For example, if the parameter β is set to be inversely proportional to the difference between the current time and the creation time of the previous block, the probability of a block being approved over time can be increased even if there is a passing communication between the same pair of nodes.

[0167] (10) Each device in the above embodiments is specifically a computer system comprising a microprocessor, ROM, RAM, hard disk unit, display unit, keyboard, mouse, etc. A computer program is recorded in the RAM or hard disk unit. Each device achieves its function by the microprocessor operating in accordance with the computer program. Here, the computer program is composed of a combination of multiple instruction codes that indicate commands to a computer to achieve a predetermined function.

[0168] (11) In each of the above embodiments, some or all of the constituent elements may be configured from a single system LSI (Large Scale Integration). A system LSI is an ultra-multifunctional LSI manufactured by integrating multiple components on a single chip, and specifically, is a computer system configured to include a microprocessor, ROM, RAM, etc. A computer program is recorded in the RAM. The system LSI achieves its functions when the microprocessor operates in accordance with the computer program.

[0169] Furthermore, each of the components constituting each of the above devices may be individually integrated into a single chip, or some or all of them may be integrated into a single chip.

[0170] Although we refer to it as a system LSI here, it may also be called an IC, LSI, super LSI, or ultra LSI depending on the level of integration. Furthermore, the method of integration is not limited to LSI, but may be realized using dedicated circuits or general-purpose processors. It is also possible to use FPGAs (Field Programmable Gate Arrays), which can be programmed after LSI manufacturing, or reconfigurable processors, which allow the connections and settings of circuit cells within LSI to be reconfigured.

[0171] Furthermore, if an integrated circuit technology that can replace LSI emerges due to advances in semiconductor technology or other derivative technologies, it is natural that such technology may be used to integrate functional blocks. The application of biotechnology, etc. is also a possibility.

[0172] (12) Some or all of the components constituting each of the above devices may be configured as an IC card or a standalone module that can be attached to each device. The IC card or module is a computer system composed of a microprocessor, ROM, RAM, etc. The IC card or module may include the above-mentioned ultra-multifunctional LSI. The IC card or module achieves its functions when the microprocessor operates according to a computer program. The IC card or module may be tamper-resistant.

[0173] (13) The present invention may be the methods described above, or may be a computer program that implements these methods on a computer, or may be a digital signal that comprises the computer program.

[0174] The present invention may also be the computer program or the digital signal recorded on a computer-readable recording medium, such as a flexible disk, hard disk, CD-ROM, MO, DVD, DVD-ROM, DVD-RAM, BD (Blu-ray (registered trademark) Disc), semiconductor memory, etc. Alternatively, the present invention may be the digital signal recorded on such a recording medium.

[0175] Furthermore, the present invention may be such that the computer program or the digital signal is transmitted via a telecommunications line, a wireless or wired communication line, a network such as the Internet, or data broadcasting.

[0176] The present invention may also be a computer system having a microprocessor and a memory, wherein the memory stores the computer program, and the microprocessor operates in accordance with the computer program.

[0177] The program or the digital signal may also be implemented by another independent computer system by recording it on the recording medium and transferring it, or by transferring it via the network or the like.

[0178] (14) The above-described embodiments and modifications may be combined with each other.

[0179] In each of the above embodiments, each component may be configured with dedicated hardware, or may be realized by executing a software program suitable for each component. Each component may be realized by a program execution unit such as a CPU or processor reading and executing a software program recorded on a recording medium such as a hard disk or semiconductor memory. Here, the software that realizes the control device and the like in each of the above embodiments is the following program.

[0180] In other words, this program causes a computer to execute a control method in a distributed ledger system having multiple devices that hold a distributed ledger, the control method being executed by a first device of the multiple devices, the control method receiving, via near-field wireless communication, from a second device different from the first device of the multiple devices, a second identification information of the second device, generating a block including transaction data selected from a transaction pool held by the first device, the second identification information, and the first identification information of the first device, and storing the generated block in the distributed ledger held by the multiple devices.

[0181] Although the control device according to one or more aspects has been described based on the embodiments, the present invention is not limited to these embodiments. As long as it does not deviate from the spirit of the present invention, various modifications conceivable by a person skilled in the art to the present embodiments, or configurations constructed by combining components of different embodiments, may also be included within the scope of one or more aspects. [Industrial Applicability]

[0182] The present invention can be used in devices that constitute a distributed ledger system. [Explanation of symbols]

[0183] 1. Blockchain system 20 blocks 21 Transaction Section 22 Header section 23 Signature section 100a, 100b, 100c, 110 nodes 101, 111 Near Field Communication Department 102 Encryption processing unit 103 Client Section 104 Storage section 105 Communications Department 107 Judgment section 112 Control section 211, 212 Transaction Data 221 hash value 222 Block Number 223, 224 Identification information 225 Creation Date 226 Parameters 231, 232 Signatures N Network

Claims

1. A control method executed by a first device of a distributed ledger system having a plurality of devices each holding a distributed ledger, comprising: receiving, from a second device among the plurality of devices that is different from the first device, second identification information of the second device via short-range wireless communication; generating a block including transaction data selected from a transaction pool held by the first device, the second identification information, and the first identification information of the first device; Execute a storage process to store the generated block in the distributed ledger held by the plurality of devices. Control methods.

2. In the storage process, the smaller the number of blocks generated based on near-field wireless communication between the first device and the second device among the blocks stored in the distributed ledger, the higher the probability that the generated block will be stored in the distributed ledger. The control method according to claim 1 .

3. In the storing process, when the number of blocks generated based on the near-field wireless communication between the first device and the second device among the blocks stored in the distributed ledger is equal to or less than a predetermined number, the generated blocks are stored in the distributed ledger. The control method according to claim 1 or 2.

4. In the storage process, the smaller the number of blocks generated based on near-field wireless communication between the first device and the second device among the latest predetermined number of blocks stored in the distributed ledger, the higher the probability that the generated blocks will be stored in the distributed ledger. The control method according to claim 1 or 2.

5. In the storage process, when the number of blocks generated based on the near-field wireless communication between the first device and the second device among a predetermined number of latest blocks among the blocks stored in the distributed ledger is equal to or less than a predetermined number, the generated blocks are stored in the distributed ledger. The control method according to claim 1 or 4.

6. In the storage process, if a newest block among the blocks stored in the distributed ledger is a block generated based on near-field wireless communication between the first device and the second device, the newest block is prohibited from being stored in the distributed ledger. The control method according to any one of claims 1 to 5.

7. In the storage process, When storing the generated block in the distributed ledger, the generated block is stored in the distributed ledger held by the multiple devices by transmitting the generated block to the multiple devices; If the generated block is not to be stored in the distributed ledger, the generated block is not transmitted to the plurality of devices. The control method according to any one of claims 1 to 6.

8. In the storage process, when the generated block is stored in the distributed ledger, Transmitting the generated block to the second device, thereby causing the second device to add a digital signature to the transmitted block; receiving the block with the digital signature of the second device; Adding a digital signature of the first device to the received block; The block to which the electronic signatures of the first device and the second device are attached is stored in the distributed ledger held by the plurality of devices. The control method according to any one of claims 1 to 7.

9. the second identification information includes authentication information generated using a private key of the second device; When the second identification information is received, Verify the authentication information included in the second identification information using the public key of the second device, and generate the block only if the verification is successful. The control method according to any one of claims 1 to 8.

10. In a distributed ledger system having a plurality of devices each holding a distributed ledger, a control device is a first device among the plurality of devices, a short-range communication unit that receives second identification information of a second device, which is different from the first device, from the second device among the plurality of devices via short-range wireless communication; (a) generating a block including transaction data selected from a transaction pool held by the first device, the second identification information, and the first identification information of the first device; (b) a control unit that executes a storage process to store the generated blocks in the distributed ledger held by the plurality of devices. Control device.

11. A program for causing a computer to execute the control method according to any one of claims 1 to 9.

Images