Information sharing system

Abstract

Provided is an information sharing system in which is used a blockchain network that suppresses shortages in supply of new blocks. An information sharing system comprises a blockchain network that stores information. The blockchain network is configured by connecting a plurality of nodes. The plurality of nodes include a client node that generates a transaction, and a first node that functions as a validator node for generating a block. The first node generates a block including the transaction, randomly selects a second node other than the first node from among the plurality of nodes after generating the block, and causes the second node to function as a new validator node.

Description

Information sharing system

[0001] The present disclosure relates to an information sharing system using a blockchain network.

[0002] Conventionally, a method for managing data using distributed ledger technology has been studied. As one of the distributed ledger technologies, blockchain technology is known. In blockchain technology, each node (terminal) constituting the blockchain network records the same blockchain, so that data can be safely stored while preventing data tampering. A blockchain is data in which blocks including a plurality of transactions are linked in a chain. Among the nodes constituting the blockchain network, a miner node generates a new block and links the block to an existing blockchain, thereby updating the blockchain. Since a system is constructed in which a miner can obtain a reward for generating a new block in the blockchain network, new blocks are continuously generated. The blockchain network ensures security because the validity of blocks and the validity of transactions included in the blocks are verified by each node. Blockchain technology has been proposed for application not only to virtual currencies but also, for example, to electronic medical records and electronic prescription systems (see, for example, Patent Document 1).

[0003] Japanese Patent Application Laid-Open No. 2019-185642

[0004] The electronic prescription management system disclosed in Patent Document 1 manages personal information of patients, and it is difficult to construct a system in which a node serving as a miner in the blockchain network obtains a reward. Therefore, when generating a new block, there is no incentive for the miner to find the nonce required for generating a new block, the speed of generating new blocks becomes slow, and the normal operation of the blockchain network constituting the electronic prescription management system may become difficult.

[0005] Therefore, the present disclosure provides an information sharing system using a blockchain network that suppresses a shortage of supply of new blocks.

[0006] The information sharing system disclosed herein comprises a blockchain network for storing information, the blockchain network being composed of multiple connected nodes, the multiple nodes including client nodes that generate transactions and a first node that functions as a validator node that generates blocks, the first node generating the block containing the transaction, and after generating the block, randomly selecting a second node other than the first node from the multiple nodes and making it function as a new validator node.

[0007] By using the method described above, the blockchain network continues to generate new blocks even when validator nodes are not profiting from it, thus ensuring the stable operation of the information sharing system.

[0008] This figure shows an example of the system configuration of the medical information sharing system 100 according to Embodiment 1. This is an example of the structure of the blockchain 20 on which medical information is stored in the medical information sharing system 100 according to Embodiment 1. This is an example of the structure of a transaction 23 included in a block 21 in the medical information sharing system 100 according to Embodiment 1. This is a schematic diagram showing the movement of information when the first node A generates a block 21a and then verifies the block 21a in the blockchain network 10 according to Embodiment 1. This is a processing flow diagram of a terminal that has become a validator node in the blockchain network 10 according to Embodiment 1.

[0009] Preferred embodiments of the information sharing system of the present disclosure are described in detail below with reference to the drawings. The embodiments described below are preferred examples and are subject to various technically preferred limitations; however, the scope of the present disclosure is not limited to these embodiments unless otherwise specified in the following description. In the embodiments, a "medical information sharing system 100" is described as an example, but the system is not limited to systems that handle medical information.

[0010] Embodiment 1. <Configuration of Medical Information Sharing System 100> Figure 1 is a diagram showing an example of the system configuration of the medical information sharing system 100 according to Embodiment 1. As shown in Figure 1, the medical information sharing system 100 has a network 10 that connects a plurality of terminals 1 to 6 owned by medical facilities 11 to 14. The network 10 is a blockchain network with the plurality of terminals 1 to 6 as nodes, and the medical information sharing system 100 stores medical information using blockchain. The terminals 1 to 6 are connected so as to be able to communicate data via a communication network such as the Internet. In Figure 1, the network 10 is configured by connecting six terminals 1 to 6 to each other, but this is just an example, and the number of terminals n (number of nodes n) can be changed as appropriate.

[0011] The medical information sharing system 100 uses blockchain technology to store information and allows users to view and modify an individual's medical information as needed. Blockchain technology is used to prevent data tampering and enhance security. Data stored on each terminal (node) is encrypted, and data consistency is maintained due to the properties of blockchain. Furthermore, terminals 1-6 at each medical facility (11-14) are interconnected via network 10, allowing data to be managed without relying on a centralized server. This also improves the overall fault tolerance of the system.

[0012] Strict access controls are in place to ensure that only authorized healthcare professionals and related parties can access individual medical information. Access rights are managed on a blockchain and updated as needed. Because each terminal can update and share data in real time, the latest medical information is always available. This ensures that information necessary for diagnosis and treatment is reflected immediately. Patient personal information is strictly protected, and privacy protection is thoroughly ensured even when sharing medical information. Blockchain technology reduces the risk of unauthorized access to patient information. By utilizing the characteristics of blockchain, all data change history and access history are recorded, making it possible to track who accessed which information and when. This enables highly transparent data management. With these features, the medical information sharing system 100 streamlines information management in the medical field, ensuring patient safety and privacy while contributing to the improvement of the quality of medical care.

[0013] <Structure of Blockchain 20> Figure 2 shows an example of the structure of a blockchain 20 in which medical information is stored in the medical information sharing system 100 according to Embodiment 1. In Figure 2, only two blocks 21a and 21b are shown as an example, but it may be composed of many more blocks 21. Also, Figure 2 shows the case where there is a block 21 preceding block 21a. As shown in Figure 2, each block 21 of the blockchain 20 contains a transaction list 22, and each transaction 23 contained in the transaction list 22 contains medical information. Medical information may include, for example, in a system intended to record the prescription history of a patient, an ID to identify the patient, the name of the prescribing medical institution, an ID to identify the prescribing physician, and prescription details (drug name, dosage form, number prescribed, method of administration, etc.). Medical information may include all information related to medical care, such as the contents of medical records created by doctors, information on medical expenses, and insurance information. Medical information created at each of the multiple nodes included in the network 10 may be referred to as first information, second information, third information, etc. Furthermore, transactions 23 containing medical information generated at each node in the network 10 may be distinguished by the node (client node) where they were generated and the timing of their generation, and referred to as the first transaction, second transaction, third transaction, etc. Figure 2 shows a blockchain 20 consisting of two blocks 21a and 21b. The blockchain 20 is composed of multiple blocks 21 connected together, and new information is stored when a new block 21 is generated and added. Note that blocks 21 generated consecutively, such as block 21a and block 21b which is generated after block 21a, may be referred to as the first block and the second block, respectively. In other words, in Figure 2, block 21a may be called the first block and block 21b may be called the second block. The detailed structure of transaction 23 will be explained in Figure 3.

[0014] Block 21 also has a block header 24. The block header 24 contains the hash 25 of the previous block, the Merkle root 26, a timestamp 27, and a block creation key 29 generated by the validator node that created block 21. The validator node that creates block 21 is called the first node A (see Figure 1). Note that at least some of the elements other than the block creation key 29 generated by the first node may not be included in the block header 24.

[0015] The hash 25 of the previous block is used to connect each block 21 as a sequence and to clarify the order in which each block 21 was generated. The Merkle root 26 is a collection of hash values ​​of all transactions 23 within block 21 and is used to efficiently verify whether a particular transaction 23 is included in block 21. The timestamp 27 represents the time when each block 21 was generated.

[0016] The block creation key 29 is generated by each node that becomes a validator node, and may be, for example, a random number n, or a numerical value generated according to a predetermined rule. The block creation key 29 is possessed by the first node that generated it, and is added to the block header 24 and then transmitted to the next node that becomes a validator node. The node that becomes a validator node after the first node A is called the second node B. In Figure 2, if the first node A generates block 21a, then the second node B will generate block 21b. The node that receives the block creation key 29 from the first node A becomes the next validator node and generates a new block 21. Furthermore, the medical information sharing system 100 of this disclosure is characterized in that the first node A (current validator node) that created block 21 creates block 21, and the node that receives the block creation key 29 and the data constituting block 21 (or the data of block 21 including the block creation key 29) from the first node A broadcasts block 21 (requests verification of the block).

[0017] Furthermore, the medical information sharing system 100 allows terminals 1 to 6 connected to the network 10 to view and modify the information contained in the blockchain 20. However, users of terminals 1 to 6 are not unconditionally able to view and modify all the information contained in the blockchain 20; the system can be configured so that viewing and modification are only possible if permission has been granted. For example, transaction 23 may include not only medical information but also a personal identification code 34 of an individual related to the medical information, and the system can be configured so that viewing or modifying an individual's medical information 35 requires that individual's personal identification code 34.

[0018] <Information Processing by the Medical Information Sharing System 100> Next, we will explain how the medical information sharing system 100 can change (add or delete) medical information about a patient P. As an example, we will explain how a doctor can add prescription information as medical information about a patient using terminal 1 installed in the medical facility 11 (Clinic 1) shown in Figure 1(a).

[0019] Terminal 1 creates data related to the prescription. Terminal 1 is also called a client node. This data, as medical information 35, is included as part of transaction 23 in a new block 21 that will later be added to the blockchain 20.

[0020] <Configuration of Transaction 23> Figure 3 shows an example of the structure of transaction 23 included in block 21 in the medical information sharing system 100 according to Embodiment 1. Transaction 23 includes transaction ID 31, sender signature 32, public key 33, personal identification code 34, and medical information 35. Data related to prescriptions is included in the medical information 35. The personal identification code 34 indicates that the medical information 35 pertains to a patient. The personal identification code 34 is different for each patient and is, for example, a character, number, symbol, or other code assigned to the individual.

[0021] Transaction ID 31 is unique to each transaction and is, for example, a hash of all data other than Transaction ID 31 contained in Transaction 23. In the example in Figure 3, Transaction ID 31 is the hash of all of the sender signature 32, public key 33, personal identification code 34, and medical information 35.

[0022] The sender signature 32 is created using a private key 36. The private key 36 is unique to the person (for example, a specific doctor) who creates the medical information 35 using terminal 1, which is the sender node. The private key 36 is created in pair with the public key 33 and is not made public. The value "S" of the sender signature 32 is expressed by the following formula, where the value "K" is the private key 36, "H" is the hash value of at least some of the data included in transaction 23, and the operation is represented by "•": S = H•K ... (1)

[0023] As described above, the public key 33 is created in pair with the private key 36 and is included in transaction 23, which is sent from the sending node (in this case, terminal 1) to the receiving node. The receiving node is any of terminals 2 to 6 other than terminal 1, and there may be one or more receiving nodes. Note that sending transaction 23 from the sending node to a node within the blockchain network 10 is sometimes called broadcasting transaction 23.

[0024] <Verification of Transaction 23> The prescription data created on terminal 1 is included in transaction 23 as medical information 35 and broadcast to the blockchain network 10. Transaction 23 received by the receiving node is verified by the receiving node.

[0025] At the receiving node, the hash value "H" is obtained from the data contained in transaction 23, similar to how the sender signature 32 was generated as described above. The receiving node also extracts the sender signature 32 and the public key 33, and verifies whether the value obtained by calculating the sender signature 32 and the public key 33 matches the hash value "H". In other words, the value of the public key 33 is "K －１When this is done, the receiving node checks whether the following equation (2) is true. S.K. －１ = H ... (2) If the above equation is true, it is verified that the sender signature 32 of transaction 23 is valid and that the data in transaction 23 has not been tampered with. This verification is also performed on other nodes to which transaction 23 was sent. Transactions 23 whose legitimacy cannot be confirmed are discarded. Transactions 23 whose legitimacy has been confirmed are pooled in the blockchain network 10 as unconfirmed transactions. Also, verified transactions 23 will be incorporated into a newly created block 21 later.

[0026] <Generation of a New Block 21> Any node in the blockchain network 10 shown in Figure 1 (any of terminals 1 to 6 in Figure 1) functions as a validator node and generates a new block 21 to be added to the blockchain 20. The validator node selects an unconfirmed transaction from its memory pool. Also, as shown in Figure 2, the validator node creates a block header 24 that includes the hash 25 of the previous block, the Merkle root 26, the timestamp 27, and the key 29 generated by the previous validator node. Here, in Figure 2, block 21a is described as block 21 generated by the current validator node, Node 1 A, and block 21b is described as block 21 generated by Node 2 B, the new validator node selected by the current validator node, which has become Node 1 A. In Figure 1(a), Node 1 A is terminal 1, and Node 2 B is terminal 5. Block 21a generated by Node 1 A includes the key 29a generated by Node 1 A as the content of the block header 24.

[0027] The hash 25 of the previous block included in the block header 24 is the hash of the previous block 21. For example, in block 21b, it is the hash of the entire data of the previous block 21a.

[0028] Merkle root 26 is the hash of the entire set of unacknowledged transactions 23 selected to be included in the new block 21. This is used to prove that all transactions 23 within the block have not been tampered with.

[0029] The timestamp 27 indicates the time when block 21 was generated, which could be, for example, the time when the block header 24 was created, or the time when the key 29 was created. The timestamp 27 is used to establish the order of each block 21 that make up the blockchain 20.

[0030] Key 29a is, for example, a random number n generated by the current validator node that generated block 21a. Key 29a is incorporated into block 21a and is generated at the first node A that generated block 21a when block 21a is created.

[0031] Figure 4 is a schematic diagram illustrating the movement of information when verifying block 21a after the first node A has generated block 21a in the blockchain network 10 according to Embodiment 1. The first node A transmits the generated key 29a and the data constituting the created block 21a (or the entire data of block 21a including key 29) to the second node B, which is a new validator node that will next generate block 21b. The first node A also transmits the hash value h1 of the block 21a created by the first node A to nodes other than the second node B (broadcasting the hash value h1), but does not transmit block 21a itself or the data contained in block 21a.

[0032] Second node B broadcasts block 21a, which it received from first node A, to other nodes in the blockchain network 10 and requests verification of block 21a.

[0033] Another node (verification node C) that receives a verification request hashs the block 21a received from the second node B and checks if it matches the hash value h1 already received from the first node A. If verification node C confirms that the hash value h1 matches the value obtained by hashing block 21a at the verification node, it approves block 21a as a valid block 21 and broadcasts the verification result. This verification and approval is also performed by other nodes in the blockchain network 10. Each verification node C in the blockchain network 10 receives the verification results of other verification nodes C, and if it determines that there is a consensus within the blockchain network 10 that block 21a is a valid block, each node formally adds block 21a to the blockchain.

[0034] Key 29 (29z, 29a, 29b) is, for example, a random number n generated by one of terminals 1 to 6, which function as validator nodes. The random number n is a number of any number of digits and is randomly generated at the validator node. Key 29 (29a, 29b) is also called the block creation key 29.

[0035] Key 29a is sent to one node randomly selected by the first node A, which is the current validator node, after the first node A has generated block 21. For example, in the example in Figure 1(a), terminal 1, which is functioning as the first node A, generates key 29a and sends key 29a only to terminal 5, which is selected as the next second node B. Terminal 1, which is functioning as the first node A, also sends the data of block 21a only to terminal 5, which is selected as the second node B. In addition, terminal 1, which is the first node A, sends the hash value h1 of block 21a to terminals 2, 3, 4, and 6 other than terminal 5, which is selected as the second node B, but does not send block 21a itself or the data contained in block 21a. In other words, the key 29a and block 21a generated by terminal 1 are not sent to any node other than the second node B. Note that the hash value h1 of block 21a may also be sent to terminal 5.

[0036] Figure 5 is a processing flow diagram for a terminal that has become a validator node in the blockchain network 10 according to Embodiment 1. Here, we will explain the information processing that takes place when the current validator node generates block 21a in Figure 2.

[0037] First, the first node A collects the transactions 23 to be included in block 21a (step S1). Transactions 23 are generated by each client node and are unconfirmed transactions pooled within the blockchain network 10. In the example shown in Figure 2, transactions 23a1, 23a2, 23a3, and so on are collected.

[0038] Next, the validator node generates a block creation key 29a (step S2). The block creation key 29a is added as content to block 21a.

[0039] Next, block 21a is generated based on the collected transactions 23 (step S3). Here, the collected transactions 23a1, 23a2, 23a3, etc. are added to the transaction list 22a. The step of generating block 21a also includes the step of creating a block header 24a. As an example, the hash 25a of the previous block 21, the Merkle root 26a, and the timestamp 27a are added to the block header 24a.

[0040] Next, the first node A calculates the hash value h1 of the created block 21a (step S4). The hash value h1 is sent to a sendable node in the blockchain network 10 and used to verify block 21a (step S6). Step S6 can be performed at any time after the hash value h1 is generated by the first node A and before the verification of block 21a by the verification node (step S10).

[0041] When step S4 is completed, the first node A selects a second node (step S5). The selection of the second node B is randomly selected from any of the communicable nodes in the blockchain network 10 as an example. This random selection is implemented, for example, by generating a random number within a predetermined numerical value in each terminal. For example, each terminal has information on a list or array of terminals participating in the blockchain network 10, and selects the terminal corresponding to the generated random number as the next validator node.

[0042] When step S5 is completed, the first node A transmits the block creation key 29a generated by the first node A to the selected second node B (step S7). Steps S5 and S7 are processes for setting the second node B as the next new validator node, and when this process is completed, the process for setting the new validator node (the node that will function as the first node A next) is completed. When steps S5 and S7 are completed, the second node B can perform the processes from step S1 as the new first node A. That is, the second node B can execute the processes from step S1 as the new first node A. Note that the new validator node may be configured such that the processes from S1 can be performed after the block 21a generated by the previous validator node is approved.

[0043] When step S7 is completed, the second node B transmits (broadcasts) the data of the block 21a into the blockchain network 10 (step S9). Nodes other than the first node A and the second node B become verification nodes, and each verification node receives the data of the block 21a transmitted by the second node B.

[0044] When steps S6 and step S9 are completed, the node (verification node; Verification Node) that has received the hash value h1 transmitted from the first node A and the data of the block 21a from the second node B performs a process for verifying the block 21a (step S10).

[0045] If the verification node fails to verify block 21a (No in step S11), the verification node discards block 21a as invalid (step S12). Also, at this time, the verification node broadcasts within the blockchain network 10 that block 21a is invalid. Note that the verification node does not necessarily have to discard the block 21a for which verification has failed, and in some cases, it may be configured to perform other processes such as temporarily isolating it or re-verifying it.

[0046] If the verification node succeeds in verification (Yes in step S11), the verification node approves block 21a as being official (step S13) and broadcasts the result within the blockchain network 10.

[0047] If the verification node approves block 21a as being official and consensus is reached within the blockchain network 10, the verification node adds block 21a to the blockchain (step S14). The formation of consensus within the blockchain network 10 is determined by whether the number of nodes that approve block 21a as being legitimate within the blockchain network 10 is the majority. For example, consensus is formed when the number of approved nodes is equal to or more than a certain percentage of all nodes.

[0048] As described above, block 21a generated by the first node A is added to the blockchain. Once block 21a is added to the blockchain, the second node B functions as the first node A and generates a new block 21b. The node that now functions as the first node A then executes the process from step S1 again. In the example shown in Figure 1, terminal 1, which was the first node A initially, selects the second node B and makes terminal 5 function as the second node B. Terminal 5, the second node B, requests verification of block 21a, and once block 21a is deemed valid and added to the blockchain, it functions as the first node A again. Each node in the blockchain network 10 sequentially takes over the roles of the first node A and the second node B, and sequentially generates new blocks 21. Since the roles of the first node A and the second node B are sequentially taken over by each node in the blockchain network 10, new blocks 21 are generated one after another without the need for a centralized management device or anything similar.

[0049] The above describes the basic processes of generating, verifying, approving, and adding blocks 21 within the blockchain network 10, but these processes may also include the following:

[0050] After step S4 is completed, the first node A may digitally sign the hash value h1 calculated in S4 using the first node A's private key. The digital signature is used for verification at the verification node to which the hash value h1 is sent, together with the public key sent from the first node A. For example, the verification node may be configured to decrypt the digital signature using the public key to obtain the hash value h1. The public key may be sent from the first node A to the second node B, and then sent by the second node B to the verification node.

[0051] The verification node may verify the contents of block 21a in step S10. For example, it may verify the block header 24a included in block 21a, verify the transaction 23 included in the transaction list 22a, and verify the integrity of block 21a.

[0052] Verification of the block header 24 includes checking the hash 25a of the previous block and verifying the timestamp 27a. Checking the hash 25a of the previous block verifies whether the hash 25a of the previous block contained in block 21a matches the one obtained by hashing the previous block 21 (although not shown in Figure 2, this is block 21 that was generated before block 21a). Verification of the timestamp 27a verifies that the timestamp 27a of block 21a is at least later than the timestamp 27 of the previous block 21 and within the acceptable range of the current network time.

[0053] Verification of transactions 23 included in transaction list 22a verifies, for example, that each transaction 23 in block 21a is in the correct format and that the sender signature 32 (see Figure 3) is valid. Signature verification may also use the sender's public key 33 to verify the authenticity of the signature. It also checks whether the same transaction 23 is included twice in the transaction list 22 of block 21a.

[0054] The integrity of block 21a is verified, for example, by calculating whether the Merkle root 26 matches the hash value of the actual transaction 23 contained in block 21a. Alternatively, the size of block 21 may be checked to ensure it is appropriate.

[0055] As described above, the medical information sharing system 100 can add a new block 21 to the blockchain 20 and store new information. However, in the medical information sharing system 100, there is no incentive for each node to generate a new block 21, so it is conceivable that the rate at which new blocks 21 are generated will decrease, which may hinder the storage of medical information. Therefore, in the medical information sharing system 100 according to Embodiment 1, each node of the network 10 generates a new block 21 in the following manner.

[0056] <Determination of Validator Nodes in Network 10> The blockchain network 10 first selects an arbitrary node to be the first node A. After a predetermined time Δt has elapsed, the first node A generates a new block 21a and randomly selects one node from the other nodes. The selected node becomes the second node B and eventually functions as a new first node A. After a predetermined time Δt has elapsed, the new first node A generates a new block 21 and randomly selects one node from the other nodes. By repeating the above process, the medical information sharing system 100 will have a new block 21 added to the blockchain 20 at predetermined time intervals Δt.

[0057] In the blockchain network 10, the first node A, which generated block 21a, sets up the second node B by sending the block creation key 29a to the node that will generate the next block 21b. As shown in Figures 1(a) and 2, the first node A generates the block creation key 29a, selects the second node B, and sends the block creation key 29a. The second node B becomes the next new first node A and generates a new block 21b using the newly generated block creation key 29b. In the blockchain network 10, the first node A that first generates block 21 may be given arbitrary data instead of the block creation key 29 generated by the previous validator node, or it may be configured to generate a new block 21 without the block creation key 29 generated by the previous validator node.

[0058] The predetermined time interval Δt can be set appropriately according to the storage capacity per unit time required by the medical information sharing system 100. For example, during times when a large amount of information is generated, Δt should be set to the shortest possible interval.

[0059] <Operation of the Medical Information Sharing System 100> The medical information sharing system 100 according to Embodiment 1 includes a blockchain network 10, which is configured with multiple nodes connected in a communicative manner. The multiple nodes include client nodes that generate transactions 23 and a first node A that functions as a validator node that generates blocks 21a. The first node A generates a block 21a containing transactions 23, and after generating the block 21a, randomly selects a second node B other than the first node A from the multiple nodes and makes it function as a new validator node. In other words, in Figure 2, the first node A is a node that generates block 21a, and the second node B is a node that generates block 21b. In the example in Figure 1, the first node A can be any terminal from terminals 1 to 6, and the second node B can be any terminal other than the first node from terminals 1 to 6. In this way, by having the first node A, which functions as the current validator node, select the second node B, and having the second node B function as the new validator node, the blockchain network 10 can stably generate new blocks 21 that record medical information 35 without requiring so-called mining. In conventional blockchain networks, where new blocks are generated by so-called mining, it is necessary to set a nonce so that the hash value satisfies the difficulty target. This task of finding the hash value requires high computing power and is costly to find a suitable nonce, so it can function effectively in systems where rewards (fees) are obtained, such as cryptocurrency networks. However, in systems where economic benefits are unlikely to be generated, such as the medical information sharing system 100 according to Embodiment 1, each node in the blockchain network 10 has no incentive to expend high computing power and energy, so if the system is to be operated by generating blocks through mining as in the past, the speed of generating new blocks 21 may be slow.Therefore, in the medical information sharing system 100 according to Embodiment 1, the validator node that generated block 21 designates the next validator node, so that the generation of new blocks 21 continues even without a reward, thereby suppressing a shortage of new blocks 21. In addition, since each node is randomly assigned to generate block 21 as the first node A, it becomes difficult for an attacker to target a specific node and carry out malicious acts, thus improving security.

[0060] In addition to the above, in the medical information sharing system 100 according to Embodiment 1, the multiple nodes (terminals 1 to 6) in the blockchain network 10 include a verification node other than the first node A and the second node B, which verifies whether block 21 is valid. The first node A generates a block creation key 29, adds the block creation key 29 as content to block 21, generates a hash value h1 of block 21, sends the data constituting block 21 including the block creation key 29 (which may be the data of the entire block 21) to the second node B, and sends the hash value h1 to the verification node. In addition to the above, in the medical information sharing system 100 according to Embodiment 1, the second node B sends the block 21 received from the first node A to the verification node. In this way, since the first node A sends the block creation key 29, the data of block 21, and the hash value h1 of the block separately to the second node B and the verification node, respectively, there is no need to broadcast block 21 to many verification nodes in the blockchain network 10, and the load is reduced. Furthermore, since the broadcasting of hash value h1 and the broadcasting of block 21 are divided between the first node A and the second node B, there is an advantage that, if an attacker is present, it is difficult for them to interfere with the block generation and verification process. In addition, since the broadcasting of hash value h1 and the broadcasting of block 21 are executed by two nodes, the verification process can also be sped up. Moreover, if block 21 is generated and verified by a single node, fraudulent activity by that single node may affect the entire blockchain network 10, but by dividing the generation and verification of block 21 among multiple nodes, the possibility of fraud is reduced.

[0061] In addition to the above, in the medical information sharing system 100 according to Embodiment 1, the verification node verifies that block 21 is valid by hashing block 21 received from the second node B and obtaining a value that matches the hash value h1 transmitted from the first node. In this way, since the verification node performs verification based on information from two nodes, the reliability of the verification and agreement regarding the validity of block 21 is increased.

[0062] In addition to the above, in the medical information sharing system 100 according to Embodiment 1, the second node B functions as the first node A after transmitting block 21 to the verification node. In this way, since the second node B has already received the data of block 21 from the first node A, it is ready to generate the next new block 21. Therefore, by the second node B becoming the next first node A, the generation of the next new block 21 can be carried out smoothly. Furthermore, since the function of the first node A is successively transferred to different nodes in this way, each node in the blockchain network 10 equally bears the role of generating block 21, and the distribution of resources within the blockchain network 10 becomes fair.

[0063] <Authentication using personal identification codes> The medical information sharing system 100 identifies that the information contained in each transaction 23 belongs to a specific individual using a personal identification code. In other words, when transactions 23 associated with a particular personal identification code are collected, it becomes the medical information of that particular individual. In the medical information sharing system 100, when generating or modifying the medical information of a specific individual, it is necessary to generate a new transaction 23 using the personal identification code of that specific individual.

[0064] To view, create, or modify medical information concerning a specific individual, the user enters a personal identification code using the input device provided on terminals 1 to 6, thereby granting the user the authority to view, create, or modify medical information concerning that individual.

[0065] The medical information sharing system 100 can store biometric authentication information associated with a personal identification code 34 in a transaction 23. Examples of biometric authentication include fingerprint authentication, facial recognition, iris recognition, voice recognition, vein authentication, retinal authentication, palm authentication, and behavioral authentication. For example, for a specific individual, the personal identification code 34 and fingerprint information can be stored as a transaction 23 on the blockchain. In this case, the personal identification code 34 can be obtained by reading the specific individual's fingerprint with a reader, allowing access to and modification of medical information related to that individual.

[0066] Furthermore, the medical information sharing system 100 has the following advantages due to its ability to store biometric authentication information. For example, if a patient is brought to the hospital in an emergency and is unconscious, the emergency physician may need to refer to the patient's past medical data for treatment. In this case, the emergency physician can refer to the patient's medical data in the medical information sharing system 100 by, for example, using the unconscious patient's finger for fingerprint authentication. Therefore, if a terminal belonging to the blockchain network 10 of the medical information sharing system 100 is equipped, the patient's medical information can be accessed in the same way regardless of which hospital the patient is brought to.

[0067] In this embodiment, a medical information sharing system 100 was described as an example of the information sharing system 100, but it is not limited to this. In other words, the information sharing system can be applied to fields other than medicine.

[0068] For example, it can be applied to an inventory management system in a retailer. Terminals 1 to 6 are installed, for example, in each store or central warehouse of the retailer, and each functions as a node in the blockchain network. Inventory receiving and dispatch operations performed at each store, and inventory movement and replenishment operations at the central warehouse are recorded as transactions on the blockchain. As a result, records of ordering operations and inventory updates are shared among each node, making it possible to understand when, who, and how inventory management was performed across all stores and warehouses. In conventional systems, inventory management information is aggregated on a central server, which leads to update delays and risks of tampering. However, by using the information sharing system 100, inventory management that is difficult to tamper with and highly transparent can be achieved.

[0069] Furthermore, it can be applied to tracking distribution. Terminals 1-6 are installed in various locations, such as manufacturing companies, transportation companies, wholesalers, retailers, and medical facilities, and these function as nodes in a blockchain network. In recording distribution, it is crucial to accurately record "when," "who," "where," "what," "how much," and "to whom it was delivered." For example, in the field of pharmaceutical distribution, some substances, particularly medical narcotics, require strict management, and even the loss or unknown destination of just 1 mL during the distribution process is unacceptable. In this case, this system allows a series of records, such as the time and quantity shipped by the manufacturing company, where and to whom the transportation company's representative delivered the goods, and the contents and time of receipt by wholesalers and retailers, to be stored on the blockchain in a tamper-proof manner. Moreover, transactions at the specific person level, such as "Person B from Company A delivered it to Person D from Company C," can also be recorded as transactions, clarifying responsibility. In conventional distribution management, errors and inconsistencies were prone to occur due to differing record formats among businesses and the difficulty in keeping individual transaction records. However, by using the information sharing system 100, inventory fluctuations and transaction history are linked, enabling highly transparent and consistent distribution history management that clearly identifies individuals, organizations, locations, and times. In other words, the above-mentioned inventory information, trading companies, transaction personnel, locations, and times are equivalent to "patient personal information" in the medical information management system 100.

[0070] Furthermore, in the real estate sector, it can be applied to the management of registration information. Terminals 1 to 6 are installed, for example, in legal affairs bureaus, financial institutions, real estate companies, judicial scrivener offices, local governments, and user terminals (such as property owners), and each functions as a node in the blockchain network. Records of ownership transfers accompanying the buying and selling of land and buildings, records of mortgage establishment by financial institutions, records of registration applications by judicial scriveners, and records related to fixed asset taxes by local governments are each registered as transactions on the blockchain. As a result, a series of information related to real estate registration is stored in a form that is difficult to tamper with and is shared among the relevant parties, thereby preventing fraud and errors in entries and realizing accurate and transparent real estate management.

[0071] Furthermore, it can also be applied to the management of address information. Terminals 1 to 6 are installed in places such as municipal offices, prefectural offices, national administrative agencies, the terminals of residents themselves, financial institutions that use resident registration, and educational institutions, and each functions as a node in the blockchain network. When a resident moves, records of the resident registration change procedure at the municipal office, records of information updates in prefectural and national systems, and records of references to resident registration information at financial institutions and educational institutions are stored as transactions on the blockchain. This allows for accurate tracking of migration history, enabling each institution to conduct its business based on consistent information. Previously, each institution managed data individually, which could lead to delays and inconsistencies in information updates, but by using the information sharing system 100, efficient and reliable address management becomes possible.

[0072] As described above, the information sharing system 100 of this embodiment includes a mechanism that, after the first node A generates a block, randomly selects the second node B to function as a new validator node. Furthermore, the first node A transmits the hash value h1 of the block it generates to the verification node C, and the second node B transmits the block body to the verification node C, thus sharing their respective roles. In addition, the system is configured to generate a new block and select the next node at predetermined time intervals Δt. This eliminates the need for nonce searching to match the difficulty target achieved through mining, as in the conventional method, and enables continuous block generation without relying on reward incentives. As a result, the next generating entity is always determined, and the verification process is distributed and converges quickly, thus suppressing block generation stagnation. In addition, while maintaining tamper-proofness and transparency, the risks of inconsistencies due to centralized management and reliance on a single point of failure are reduced. The information sharing system 100 is particularly useful for sharing medical information and can be applied to a variety of fields that require a highly reliable information sharing infrastructure, such as inventory management, distribution management, real estate management, and address management.

[0073] Although the present disclosure has been described above based on various embodiments, the present disclosure is not limited to the configurations of the embodiments described above. In each of the embodiments described above, the information sharing system 100 is realized by connecting terminals 1 to 6, such as personal computers, as a blockchain network 10. However, the terminals 1 to 6 constituting the blockchain network 10 can also include various computers, mobile terminals, tablets, and other communication terminals / mobile information terminals to realize the same functions. Furthermore, the present disclosure also includes programs for making each terminal function as a node in the blockchain network 10. In addition, the above embodiments and variations may be implemented in combination as appropriate. For the sake of clarity, it should be noted that the scope of various modifications, applications, and uses that a person skilled in the art may make as needed is also included in the gist (technical scope) of this disclosure.

[0074] Furthermore, the information sharing system 100 described above may also include combinations of the features shown in the following appendices 1 to 5. These combinations are shown below.

[0075] [Note 1] An information sharing system comprising a blockchain network for storing information, wherein the blockchain network is configured by connecting a plurality of nodes, the plurality of nodes include a client node that generates transactions, and a first node that functions as a validator node that generates blocks, the first node generates the block containing the transactions, and after generating the block, randomly selects a second node other than the first node from the plurality of nodes and makes it function as a new validator node. [Note 2] An information sharing system according to Note 1, wherein the plurality of nodes include a verification node other than the first node and the second node that verifies whether the block is valid, the first node generates a block creation key, adds the block creation key as content to the block, generates a hash value h1 of the block, transmits the data constituting the block including the block creation key to the second node, and transmits the hash value h1 to the verification node. [Note 3] An information sharing system as described in Note 2, wherein the second node transmits the block received from the first node to the verification node. [Note 4] An information sharing system as described in Note 3, wherein the verification node verifies that the block is valid by having the value obtained by hashing the block received from the second node match the hash value h1 transmitted from the first node. [Note 5] An information sharing system as described in Note 3 or 4, wherein the second node functions as the first node after transmitting the block to the verification node.

[0076] 1: Terminal 2: Terminal 3: Terminal 4: Terminal 5: Terminal 6: Terminal 10: Blockchain network 11: Medical facility 12: Medical facility 13: Medical facility 14: Medical facility 20: Blockchain 21: Block 21a: Block 21b: Block 22: Transaction list 22a: Transaction list 23: Transaction 23a1: Transaction 23a2: Transaction 23a3: Transaction 24: Block header 24a: Block header 25: Hash 25a: Hash 26: Merkle root 26a: Merkle root 27: Timestamp 27a: Timestamp 29: (Block creation) key 29a: (Block creation) key 29b: Block creation key 31: Transaction ID 32: Sender signature 33 : Public key 34: Personal identification code 35: Medical information 36: Private key 100: Medical information sharing system A: First node B: Second node C: Verification node h1: Hash value

Claims

1. An information sharing system comprising a blockchain network for storing information, wherein the blockchain network is composed of multiple connected nodes, and the multiple nodes include client nodes that generate transactions and a first node that functions as a validator node that generates blocks, wherein the first node generates the block containing the transactions, and after generating the block, randomly selects a second node other than the first node from the multiple nodes and makes it function as a new validator node.

2. An information sharing system according to claim 1, wherein the plurality of nodes include a verification node other than the first node and the second node that verifies whether the block is valid, and the first node generates a block creation key, adds the block creation key as content to the block, generates a hash value h1 of the block, transmits the data constituting the block including the block creation key to the second node, and transmits the hash value h1 to the verification node.

3. An information sharing system according to claim 2, wherein the second node transmits the block received from the first node to the verification node.

4. An information sharing system according to claim 3, wherein the verification node verifies that a block is valid by having the value obtained by hashing the block received from the second node match the hash value h1 transmitted from the first node.

5. An information sharing system according to claim 3 or 4, wherein the second node functions as the first node after transmitting the block to the verification node.

Images