WO2021166528A1

WO2021166528A1 - Fraud testing device and fraud detection system

Info

Publication number: WO2021166528A1
Application number: PCT/JP2021/001809
Authority: WO
Inventors: 彰深田
Original assignee: Ｎｅｃソリューションイノベータ株式会社
Priority date: 2020-02-21
Filing date: 2021-01-20
Publication date: 2021-08-26

Abstract

A confirmation block acquisition unit 81 acquires, from a second block chain, a block confirmation transaction which is a transaction including a first Merkle root hash calculated from a block header of a block within a target range in a first block chain and a block number indicating the block within the range. A fraudulent operation testing unit 82 identifies the block in the first block chain from the block number included in the acquired confirmation transaction, calculates a second Merkle root hash from the block header of the identified block, compares the first and second Merkle root hashes with each other to determine whether there is a match, and detects a fraudulent operation with respect to the identified block.

Description

Fraud verification device and fraud detection system

The present invention relates to a fraud verification device, a confirmation generator, a fraud detection system, a fraud verification method, a fraud detection method, and a fraud verification program used for fraud verification and detection performed on a blockchain.

In recent years, blockchain is widely known as one of the distributed ledger technology (DLT: Distributed Ledger Technology). Blockchain is a technology that stores data by generating units of data called blocks and connecting each block.

The header of each block stores a hash value calculated from the transaction history (transaction) in the block, which enables verification of the correct combination of transaction history. In addition, the hash value calculated from the previous block header is also stored, which allows the validity of the logical connection with the previous block to be verified.

Blockchains are roughly classified into three types depending on how to select block approvers and differences in the mechanism (that is, validators when consensus is reached).

The first is a form called a public blockchain. In the public blockchain, there is no centralized authority, and the risk of fraud is eliminated by preparing a consensus algorithm such as PoW (Proof of Work). Due to these characteristics, public blockchains generally have no restrictions on participation, and are therefore large-scale networks in which an unspecified number of nodes exist.

The second is a form called a private blockchain. A private blockchain is a small network in which participation is restricted and only specific nodes can participate. Since the number of participating nodes is smaller than that of the public blockchain, the transaction (approval) time is generally short.

The third is a form called a consortium type blockchain. Like the private blockchain, the consortium blockchain has fewer nodes to participate in than the public blockchain, so the transaction time is generally shorter. Furthermore, since the consortium type blockchain is consensus-building by multiple organizations, it can be said that it is a highly reliable network compared to the private type blockchain.

Further, Patent Document 1 describes a system for detecting tampering in the blockchain. In the system described in Patent Document 1, the existence proof of the terminal object is stored in an external system. Therefore, when the history of a certain object is recreated or the end object is replaced, the alteration can be detected by using the existence proof in the external system.

Japanese Patent No. 6618138

As mentioned above, the private blockchain and the consortium blockchain are smaller than the public blockchain in that the nodes that make up the chain are about several tens of nodes. Therefore, if a plurality of malicious participants collude and falsify the data, there is a possibility that such fraud cannot be detected.

In the system described in Patent Document 1, in the first place, it is not considered that the participants of the blockchain collude and falsify the data, and such fraud cannot be detected.

Therefore, in the present invention, a fraud verification device that can detect fraudulent operations of data performed on the blockchain, a fraud detection system, a fraud verification method, a fraud detection method, a fraud verification program, and a confirmation generation that generates confirmation used for the detection. The purpose is to provide the device.

The fraud verification device according to the present invention is a transaction including the first Merkle root hash calculated from the block header of the block of the target range in the first blockchain and the block number indicating the block in the range. A confirmation block acquisition unit that acquires a block confirmation transaction from a second blockchain that is a blockchain in which the block confirmation transaction is registered and is different from the first blockchain, and a block included in the acquired confirmation transaction. The block in the first blockchain is identified from the number, the second Merkle root hash is calculated from the block header in the identified block, and the first Merkle root hash and the second Merkle root hash match. It is characterized by having an illicit operation verification unit that detects illicit operations on the specified block by comparing with each other.

The confirmation generator according to the present invention calculates a Merkle root hash from the block headers of blocks in the target range in the first blockchain, and calculates a block number indicating the blocks in the range and the calculated Merkle root hash. It is provided with a confirmation block generation unit that generates a block confirmation transaction that is a including transaction, and a registration request unit that transmits a transaction requesting registration of a block confirmation transaction to a second blockchain different from the first blockchain. It is characterized by that.

The fraud detection system according to the present invention calculates the first Merkle root hash from the block header of the block of the target range in the first block chain, and calculates the block number indicating the block in the range and the calculated first. A confirmation block generator that generates a block confirmation transaction that is a transaction including a Merkle root hash, and a registration that sends a transaction that requests registration of a block confirmation transaction to a second blockchain that is different from the first blockchain. The request unit, the confirmation block acquisition unit that acquires the block confirmation transaction from the second blockchain, and the block number in the acquired confirmation transaction identify the block in the first blockchain, and the block in the specified block. Fraud operation verification that calculates the second Merkle root hash from the header, compares whether the first Merkle root hash and the second Merkle root hash match, and detects tampering with the identified block. It is characterized by having a part.

The fraud verification method according to the present invention is a transaction including the first Merkle root hash calculated from the block header of the block of the target range in the first blockchain and the block number indicating the block in the range. A block confirmation transaction is acquired from a second blockchain that is a blockchain in which the block confirmation transaction is registered and is different from the first blockchain, and is first from the block number included in the acquired confirmation transaction. Identify the block in the blockchain, calculate the second Merkle root hash from the block header in the identified block, and compare whether the first Merkle root hash and the second Merkle root hash match. , It is characterized by detecting an unauthorized operation on the specified block.

In the fraud detection method according to the present invention, the first Merkle root hash is calculated from the block header of the block in the target range in the first block chain, and the block number indicating the block in the range is calculated as the first. A block confirmation transaction, which is a transaction including a Merkle root hash, is generated, a transaction requesting registration of the block confirmation transaction is sent to a second blockchain different from the first blockchain, and the block confirmation transaction is transmitted. Obtained from the second blockchain, identify the block in the first blockchain from the block number included in the acquired confirmation transaction, calculate the second Merkle root hash from the block header in the identified block, and calculate the second Merkle root hash. It is characterized in that an illicit operation on a specified block is detected by comparing whether the first Merkle root hash and the second Merkle root hash match.

The fraud verification program according to the present invention includes, in the computer, a first Merkle root hash calculated from the block header of a block of interest in the first blockchain, and a block number indicating the block in that range. A confirmation block acquisition process for acquiring a block confirmation transaction, which is a transaction, from a second blockchain that is a blockchain in which the block confirmation transaction is registered and is different from the first blockchain, and an acquired confirmation transaction. The block in the first blockchain is identified from the block number included in, the second Merkle root hash is calculated from the block header in the identified block, and the first Merkle root hash and the second Merkle root are. It is characterized in that an illicit operation verification process for detecting an illicit operation on a specified block is executed by comparing whether or not the hash matches.

According to the present invention, it is possible to detect unauthorized manipulation of data performed on the blockchain.

It is explanatory drawing which shows the structural example of the 1st Embodiment of the fraud detection system by this invention. It is explanatory drawing which shows the example of the process which generates the block confirmation transaction. It is explanatory drawing which shows the operation example of the fraud detection system of 1st Embodiment. It is explanatory drawing which shows the structural example of the 2nd Embodiment of the fraud detection system by this invention. It is explanatory drawing which shows the example of block verification. It is explanatory drawing which shows the operation example of the fraud detection system of the 2nd Embodiment. It is explanatory drawing which shows the structural example of the 3rd Embodiment of the fraud detection system by this invention. It is explanatory drawing which shows the specific example of the process of registering confirmation. It is explanatory drawing which shows the specific example which verifies tampering. It is a block diagram which shows the outline of the fraud verification apparatus by this invention. It is a block diagram which shows the outline of the confirmation generator by this invention. It is a block diagram which shows the outline of the fraud detection system by this invention.

Hereinafter, embodiments of the present invention will be described with reference to the drawings.

Embodiment 1.
In the first embodiment, a process of registering a confirmation for detecting an unauthorized operation will be described. FIG. 1 is an explanatory diagram showing a configuration example of a first embodiment of the fraud detection system according to the present invention. The fraud detection system 100 of the present embodiment includes a client device 1, a plurality of nodes 10, a transaction management unit 20, and an intermediary client 30.

The client device 1, the plurality of nodes 10, and the transaction management unit 20 operate as components of the blockchain 110. Hereinafter, the blockchain 110 including the client device 1, the plurality of nodes 10, the transaction management unit 20, and the intermediary client 30 will be referred to as a first blockchain.

In the present embodiment, the first blockchain is assumed to be a small-scale network having several tens of nodes constituting the chain, such as a private blockchain or a consortium type blockchain. Examples of such a blockchain include Hyperldger Fabric, Corda, and Quorum. In the following description, Hyperldger Fabric will be used as a specific example of the first blockchain, but the mode of the first blockchain is not limited to Hyperldger Fabric.

The intermediary client 30, which will be described later, also operates as a component of a large-scale blockchain 120 such as a public blockchain. Hereinafter, the blockchain 120 including the intermediary client 30 will be referred to as a second blockchain. The second blockchain is a blockchain different from the first blockchain. Examples of such a blockchain include Ethereum, NEM, EOS, and the like. In the following description, Ethereum will be used as a specific example of the second blockchain, but the mode of the second blockchain is not limited to Ethereum. The details of the second blockchain will be described later.

The client device 1 is a device that creates a transaction request (transaction) in the blockchain 110 and transmits the created transaction request to any of a plurality of nodes 10. The client device 1 is a device called a client, a node, a wallet, or the like, although various names exist depending on the participating blockchain. For example, in the case of Hyperldger Fabric, the client device 1 corresponds to the client. The client device 1 may create a transaction request according to the participating blockchain.

The node 10 is composed of a plurality of units in the blockchain 110, receives the received transaction request, performs processing, and holds the blockchain data generated as a result of the processing. For example, in the case of Hyperldger Fabric, node 10 corresponds to peer. Although FIG. 1 illustrates the case where the number of nodes 10 is two, the number of nodes is not limited to two and may be three or more.

The node 10 includes a control unit 11 and a storage unit 12.

The control unit 11 verifies and executes the received transaction request. Each process executed by the control unit 11 is determined according to the blockchain 110, and the control unit 11 executes each process according to the blockchain 110 to be used and the received transaction request, and the processing result. Should be notified to the client device 1. For example, in the case of Hyperldger Fabric, the control unit 11 may execute processing for a transaction request according to a chain code (program) in which business logic is implemented.

The storage unit 12 holds blockchain data generally called a ledger. For example, in the case of Hyperldger Fabric, the ledger includes World State and a plurality of blocks (block chains). Each block has a block header that contains metadata about the block as well as multiple transaction requests. The block header contains the hash value of the immediately preceding block, the hash value of the transaction group (Merkle root), and the nonce. In addition to these, the block header includes a time stamp and bits.

The transaction management unit 20 collectively creates a block for transaction requests. Specifically, the transaction management unit 20 creates a block in which transaction requests are ordered and put together, and broadcasts the generated block to each node 10. For example, in the case of Hyperldger Fabric, the transaction management unit 20 corresponds to the orderer. Each process executed by the transaction management unit 20 is also defined according to the blockchain 110, and the transaction management unit 20 may execute each process according to the blockchain 110 to be used.

Further, the transaction management unit 20 of the present embodiment includes the block management unit 21. The block management unit 21 calculates the Merkle root hash from the block header of the block in the target range. Specifically, the block management unit 21 aggregates the hash values of the block headers in the blocks in the target range in a Merkle tree and calculates one Merkle root hash. Further, the block management unit 21 generates a transaction (hereinafter, referred to as a block confirmation transaction) including a block number indicating a block in the aggregated range and a Merkle root hash.

The target range is determined according to the block generation timing in the first blockchain and the block generation timing in the second blockchain. In this embodiment, the first blockchain is a small network such as a private blockchain or a consortium blockchain, and the second blockchain is a large blockchain such as a private blockchain. It is assumed that. Therefore, the target range may be the number of blocks generated in the first blockchain at intervals at which blocks are generated in the second blockchain.

For example, if the second blockchain is Ethereum, the block generation interval is 15 seconds. Here, when blocks are generated at 1-second intervals in the first blockchain, the target range of blocks may be 15 blocks.

FIG. 2 is an explanatory diagram showing an example of a process for generating a block confirmation transaction. The block management unit 21 collects the hash values of the block headers calculated at the time of block generation for the number of blocks to be aggregated. In the example shown in FIG. 2, it is shown that the hash values of the block headers from the block n-1 to the block n + 2 have been collected.

Next, the block management unit 21 calculates the hash value again from the hash value of the block header in the adjacent blocks. Further, the block management unit 21 repeats the process of calculating the hash value again from the calculated adjacent hash values, and repeats the process until one hash value is obtained. If adjacent hash values do not exist by the time they become one hash value, the block management unit 21 may calculate the hash value again using the same hash value. Then, the block management unit 21 uses the hash value calculated until it becomes one as the Merkle root hash.

In the example shown in FIG. 2, the hash value (block n-1 + n) is calculated from the hash value of the block header of block n-1 and the hash value of the block header of block n, and the hash value of the block header of block n + 1 is used. , Indicates that the hash value (block n + 1 + n + 2) has been calculated from the hash value of the block header of block n + 2. Further, in the example shown in FIG. 2, the hash value (blocks n-1 to n + 2) is calculated again from the hash value (block n-1 + n) and the hash value (block n + 1 + n + 2), and this hash value is the Merkle root hash. It is shown that it is used as.

Further, in the example shown in FIG. 2, the block number (block n-1 to n + 2) of the block from which the Merkle root hash is calculated becomes the block number of the block in the aggregated range. This block number is used in the hash value verification process described later.

In this way, the block management unit 21 calculates one Merkle root hash from the block header in the block of the target range, so that the hash value is changed when the transaction registered later is tampered with. Since it does not match, it becomes possible to detect tampering.

The block management unit 21 transmits the generated block confirmation transaction to the intermediary client 30.

Although the case where the block management unit 21 is configured as a part of the transaction management unit 20 has been described in the present embodiment, the block management unit 21 may be provided separately from the transaction management unit 20. In that case, the block management unit 21 may receive the output from the transaction management unit 20 and execute each of the above-described processes.

The intermediary client 30 is a device that creates a transaction request in the blockchain 120 and transmits the created transaction request to a node (not shown) of the blockchain 120. That is, the intermediary client 30 is a device that operates as a client (node, wallet) in the blockchain 120.

In particular, the intermediary client 30 of the present embodiment transmits a transaction requesting registration of the block confirmation transaction to the blockchain 120 (specifically, a node of the blockchain 120). After that, the transaction request is processed according to the specifications of the blockchain 120, and the intermediary client 30 receives the processing result for the transaction request.

It takes time for the block including the transaction history to be generated in the blockchain. For example, in the case of Ethereum, it takes about 15 seconds to generate a block. Therefore, the intermediary client 30 may receive a notification that the registration has been completed as a processing result.

If the blockchain is a blockchain that can include a block confirmation transaction in a transaction request, and it is difficult to tamper with this block confirmation transaction, such as a public blockchain, the mode of the second blockchain is optional. be. By registering a block confirmation transaction in such a large-scale blockchain 120, it is possible to suppress tampering with the transaction itself.

As described above, in the present embodiment, the block management unit 21 generates the block confirmation transaction, and the intermediary client 30 transmits the generated block confirmation transaction to the second block chain. Therefore, the block management unit 21 and the intermediary client An apparatus including 30 can be referred to as a confirmation generator.

The transaction management unit 20 (more specifically, the block management unit 21) and the intermediary client 30 are computer processors (for example, CPU (Central Processing Unit), GPU (Graphics Processing Unit)) that operate according to a program (confirmation generation program). ). For example, the program may be stored in the storage unit 12, and the processor may read the program and operate as the transaction management unit 20 (more specifically, the block management unit 21) and the intermediary client 30 according to the program. Further, the function of the confirmation generator may be provided in the SaaS (Software as a Service) format.

Further, the transaction management unit 20 (more specifically, the block management unit 21) and the intermediary client 30 may each be realized by dedicated hardware. Further, a part or all of each component of each device may be realized by a general-purpose or dedicated circuit (circuitry), a processor, or a combination thereof. These may be composed of a single chip or may be composed of a plurality of chips connected via a bus. A part or all of each component of each device may be realized by a combination of the above-mentioned circuit or the like and a program.

Further, when a part or all of each component of the confirmation generator is realized by a plurality of information processing devices and circuits, the plurality of information processing devices and circuits may be centrally arranged or distributed. It may be arranged. For example, the information processing device, the circuit, and the like may be realized as a form in which each of the client-server system, the cloud computing system, and the like is connected via a communication network.

Next, the operation of the fraud detection system of this embodiment will be described. FIG. 3 is an explanatory diagram showing an operation example of the fraud detection system 100 of the present embodiment. The client device 1 creates a transaction request and sends it to the node 10 (step S11). The control unit 11 of the node 10 verifies and executes the received transaction request, and requests the transaction management unit 20 to block the transaction request (step S12). The transaction management unit 20 blocks the transaction request (step S13). Further, the block management unit 21 generates a block confirmation transaction (step S14), and transmits the generated block confirmation transaction to the intermediary client 30 (step S15).

The intermediary client 30 transmits a transaction request requesting registration of the block confirmation transaction to the blockchain 120 (step S16). When the intermediary client 30 transmits the processing result from the blockchain 120 to the transaction management unit 20 (step S17), the transaction management unit 20 transmits the blocked information to each node 10 (step S18). Each node 10 connects the received block to the block chain held by itself (step S19), and transmits the processing result to the client device 1 (step S20).

Note that the processes of steps S14 and S15 illustrated in FIG. 3 correspond to the processes (confirmation generation processes) performed by the above-mentioned confirmation generator.

As described above, in the present embodiment, the block management unit 21 calculates the Merkle root hash from the block header of the block in the target range in the first blockchain, and sets the block number indicating the block in the range. Generate a block verification transaction containing the calculated Merkle root hash. Then, the intermediary client 30 transmits a transaction requesting registration of the block confirmation transaction to the second blockchain. Therefore, even if the data is tampered with in the first blockchain, the tampering can be detected by the block confirmation transaction registered in the second blockchain.

Further, by determining the range of the target block for which the Merkle root hash is generated according to the block generation timing in the first blockchain and the block generation timing in the second blockchain, two blockchains are generated. It becomes possible to adjust the speed difference of block generation in.

Also, in general, the fee increases according to the number of transaction requests sent to the blockchain. In the present embodiment, since one Merkle root hash is generated from the hash values of the block headers of a plurality of blocks to generate a block confirmation transaction, it is possible to suppress the fee in the second block chain.

Embodiment 2.
Next, a second embodiment of the present invention will be described. In the second embodiment, the process of detecting an unauthorized operation based on the confirmation registered in the first embodiment will be described. FIG. 4 is an explanatory diagram showing a configuration example of a second embodiment of the fraud detection system according to the present invention. The fraud detection system 200 of the present embodiment includes a client device 1, a plurality of nodes 10, a transaction management unit 40, and an intermediary client 50.

That is, the fraud detection system 200 of the second embodiment is provided with the transaction management unit 40 instead of the transaction management unit 20 as compared with the fraud detection system 100 of the first embodiment, and the mediation client is replaced with the mediation client 30. It differs in that it has 50. Since the other configurations of the client device 1 and the plurality of nodes 10 are the same as those of the first embodiment, the description thereof will be omitted.

The transaction management unit 40 creates a block by collecting transaction requests as in the first embodiment. Further, the transaction management unit 40 of the present embodiment includes the block management unit 41. Similar to the first embodiment, the block management unit 41 may be provided separately from the transaction management unit 40. The function of the block management unit 41 will be described later.

The intermediary client 50 acquires a block confirmation transaction from the blockchain 120 (that is, the second blockchain) based on an instruction from the transaction management unit 40 (more specifically, the block management unit 41) described later. Specifically, the intermediary client 50 identifies a block verification transaction that includes a Merkle root hash calculated based on the block header of the block from the block number of the designated block. The intermediary client 50 may acquire the block confirmation transaction based on the specifications of the second blockchain.

Then, the intermediary client 50 transmits the information of the specified block confirmation transaction to the transaction management unit 40 (more specifically, the block management unit 41). The intermediary client 50 may transmit the block number and the Merkle root hash of the aggregated range of the specified block confirmation transaction information to the transaction management unit 40.

The block management unit 41 identifies the block number of the block used for verification from the transaction request, and gives an instruction to acquire the block confirmation transaction to the intermediary client 50. Then, the block management unit 41 extracts the range of the block to be verified from the acquired block confirmation transaction information (more specifically, the block number of the block in the aggregated range), and in the first block chain. Identify the block.

Next, the block management unit 41 calculates the Merkle root hash again from the block header of the block in the specified range. The method of calculating the Merkle root hash is the same as the method calculated by the block management unit 21 in the first embodiment. Then, the block management unit 41 compares the newly calculated Merkle root hash with the Merkle root hash acquired from the block confirmation transaction, and detects an unauthorized operation.

FIG. 5 is an explanatory diagram showing an example of block verification. In the example shown in FIG. 5, it is shown that the block numbers (blocks n-1 to n + 2) are specified as the range of the blocks to be verified. The block management unit 41 identifies the blocks in the range indicated by the block number, aggregates the hash values of the block headers of the specified blocks in a Merkle tree, and generates one Merkle root hash. Then, the block management unit 41 compares the newly calculated Merkle root hash with the Merkle root hash acquired from the block confirmation transaction. If the hash values do not match, the block management unit 41 determines that an illegal operation (tampering) is performed in a transaction in any of the blocks.

If the hash values do not match, the transaction management unit 40 determines that an illegal operation has been performed and notifies the node 10 of the error. At this time, the node 10 that has received the transaction request from the client device 1 notifies the client device 1 of the error.

As described above, in the present embodiment, since the intermediary client 50 acquires the block confirmation transaction from the second blockchain and verifies the unauthorized operation based on the block confirmation transaction acquired by the block management unit 41, the block management unit A device including 41 and an intermediary client 50 can be called a fraud verification device.

The transaction management unit 40 (more specifically, the block management unit 41) and the intermediary client 50 are realized by a computer processor that operates according to a program (fraud verification program).

Next, the operation of the fraud detection system of this embodiment will be described. FIG. 6 is an explanatory diagram showing an operation example of the fraud detection system 200 of the present embodiment. The process of receiving the transaction request by the client device 1 and blocking it is the same as the process from step S11 to step S13 illustrated in FIG.

The block management unit 41 identifies the block number of the block used for verification (step S21), and gives an instruction to acquire the block confirmation transaction to the intermediary client 50 (step S22). Based on the instruction from the block management unit 41, the intermediary client 50 acquires the block confirmation transaction from the second blockchain (step S23) and returns it to the block management unit 41 (step S24).

The block management unit 41 specifies the range of the block to be verified from the range of the acquired block numbers (step S25). Then, the block management unit 41 calculates the Merkle root hash again from the block header of the block in the specified range (step S26), and compares it with the Merkle root hash obtained from the block confirmation transaction (step S27). ).

If the hash values match (Yes in step S27), the block management unit 41 determines that no unauthorized operation has been performed (step S28). On the other hand, if the hash values do not match (No in step S27), the block management unit 41 determines that an illegal operation has been performed, and the node 10 notifies the client device 1 of an error (step S29).

Note that the processes from step S21 to step S29 illustrated in FIG. 6 correspond to the processes (fraud verification process) performed by the above-mentioned fraud verification device.

As described above, in the present embodiment, the intermediary client 50 acquires the block confirmation transaction from the second blockchain, and the block management unit 41 obtains the block in the first blockchain from the block number included in the confirmation transaction. Identify and calculate the mark root hash from the block header in the identified block. Then, the mark root hash included in the block confirmation transaction and the calculated mark root hash are compared to see if they match, and an unauthorized operation on the specified block is detected. Therefore, it is possible to detect unauthorized manipulation of data performed on the blockchain.

Embodiment 3.
Next, a third embodiment of the present invention will be described. In the first embodiment, the fraud detection system 100 generates a confirmation (block confirmation transaction) used for verification, and in the second embodiment, the fraud detection system 200 verifies the fraudulent operation of data by using the confirmation. Was explained. It should be noted that the process of generating confirmation and the process of verifying unauthorized operation may be realized in one system.

FIG. 7 is an explanatory diagram showing a configuration example of a third embodiment of the fraud detection system according to the present invention. The fraud detection system 300 of the present embodiment includes a client device 1, a plurality of nodes 10, a transaction management unit 60, and an intermediary client 70.

The transaction management unit 60 includes the block management unit 21 of the first embodiment and the block management unit 41 of the second embodiment. Further, the intermediary client 70 also has the functions of the intermediary client 30 of the first embodiment and the intermediary client 50 of the second embodiment. The block management unit 21 and the block management unit 41 may be provided separately from the transaction management unit 60, as in the first embodiment and the second embodiment.

With such a configuration, even if data is tampered with in the first blockchain, the tampering can be detected by the block confirmation transaction registered in the second blockchain.

Next, a specific configuration example of the fraud detection system of the above embodiment will be described. In the following description, a case where Hyperldger Fabric is used for the first blockchain and Ethereum is used for the second blockchain will be illustrated.

FIG. 8 is an explanatory diagram showing a specific example of the process of registering confirmation. In the example shown in FIG. 8, the client 201 is described outside the Hyperldger Fabric network 310, but the client 201 may be included in the Hyperldger Fabric network 310.

Client201 creates a transaction request and sends it to the first blockchain (Hyperldger Fabric network 310) (step S201). The peer 210 requests the orderer 220 for the blocking process after executing the process according to the transaction request (step S202). The orderer 220 generates a block confirmation transaction together with the blocking process and transmits it to the Ethereum client 230 (step S203). The Ethereum client 230 records the block confirmation transaction in the second blockchain (Ethereum network 320) (step S204), and returns the result to the orderer 220 (step S205). The orderer 220 transmits the block information to each peer 210 (step S206). The peer connects the block to its own blockchain and returns the result to client201 (step S207).

FIG. 9 is an explanatory diagram showing a specific example of verifying unauthorized operation. In the example shown in FIG. 9, the client 201 is described outside the Hyperldger Fabric network 310, but the client 201 may be included in the Hyperldger Fabric network 310. Here, it is assumed that a malicious user colludes and rewrites the block 202 (step S301).

Client201 creates a transaction request and sends it to the first blockchain (Hyperldger Fabric network 310) (step S302). The peer 210 requests the orderer 240 for the blocking process after executing the process according to the transaction request (step S303). The Ethereum client 250 reads the block confirmation transaction from the second blockchain (Ethereum network 320) (step S304). The orderer 240 generates a hash value of the target block based on the block confirmation transaction (step S305).

Since the block 202 has been rewritten, the generated hash value and the value of the block confirmation transaction do not match (step S306). Therefore, the orderer 240 returns an error to the peer 210 (step S307), and the peer 210 returns an error to the client 201 (step S308).

Next, a specific process for detecting falsification of a document using the fraud detection system of the present embodiment will be described. Here, the first blockchain is a consortium type blockchain, and the second blockchain is a public type blockchain.

For example, suppose that transaction A of the first blockchain contains data that can prove that a certain document has not been tampered with. When it is found that the transaction A is in the block 10, the intermediary client 50 acquires the block confirmation transaction that generated the hash value based on the block 10 from the public blockchain (second blockchain). do.

Here, when it is found that the data of the block No. 10 is included in the block No. 1100 of the public blockchain, the intermediary client 50 marks from the block confirmation transaction included in the block No. 1100 of the public blockchain. Extract the ruroot hash. On the other hand, the block management unit 41 calculates the Merkle root hash again from the block numbers of the aggregated range of blocks. If these two hash values match, it can be determined that the document has not been tampered with. As described above, since the determination process is performed on the first blockchain, the client device 1 basically does not need to be aware of the internal process.

Next, the outline of the present invention will be described. FIG. 10 is a block diagram showing an outline of the fraud verification device according to the present invention. The fraud verification device 80 according to the present invention (for example, the fraud verification device of the second embodiment described above) is calculated from the block headers of the blocks in the target range in the first blockchain (for example, the blockchain 110). A block confirmation transaction that is a transaction including a first Merkle root hash and a block number indicating a block in the range is a blockchain in which the block confirmation transaction is registered, and the first blockchain is The block in the first blockchain is specified from the confirmation block acquisition unit 81 (for example, the intermediary client 50) acquired from a different second blockchain (for example, blockchain 120) and the block number included in the acquired confirmation transaction. , Calculates the second Merkle root hash from the block header in the identified block, compares whether the first Merkle root hash and the second Merkle root hash match, and is invalid for the identified block. It includes an unauthorized operation verification unit 82 (for example, a block management unit 41) that detects an operation (for example, falsification of data).

With such a configuration, it is possible to detect unauthorized manipulation of data performed on the blockchain.

Further, the target range in the first blockchain may be determined according to the block generation timing in the first blockchain and the block generation timing in the second blockchain.

Specifically, the range targeted by the first blockchain is the range of the number of blocks in the first blockchain generated within the period in which one block is generated in the second blockchain. May be good.

Further, the first blockchain may be a consortium type blockchain or a public type blockchain, and the second blockchain may be a public type blockchain.

Specifically, the first Merkle root hash and the second Merkle root hash are calculated by the same method.

FIG. 11 is a block diagram showing an outline of the confirmation generator according to the present invention. The confirmation generator 90 according to the present invention (for example, the confirmation generator of the first embodiment described above) is a Merkle from the block header of the block of the target range in the first blockchain (for example, the blockchain 110). A confirmation block generation unit 91 (for example, a block management unit 21) that calculates a root hash and generates a block confirmation transaction that is a transaction including a block number indicating a block in the range and a calculated Merkle root hash, and a block confirmation. It includes a registration requesting unit 92 (for example, an intermediary client 30) that transmits a transaction for requesting transaction registration to a second blockchain (for example, blockchain 120) different from the first blockchain.

FIG. 12 is a block diagram showing an outline of the fraud detection system according to the present invention. The fraud detection system 170 (for example, the fraud detection system 300) according to the present invention calculates the first Merkle root hash from the block header of the block of the target range in the first blockchain (for example, the blockchain 110). Then, the confirmation block generation unit 71 (for example, the block management unit 21) that generates the block confirmation transaction, which is a transaction including the block number indicating the block in the range and the calculated first Merkle root hash, and the block confirmation transaction. A registration requesting unit 72 (for example, an intermediary client 30) that transmits a transaction requesting registration of the above to a second blockchain (for example, blockchain 120) different from the first blockchain, and a block confirmation transaction. The block in the first blockchain is specified from the confirmation block acquisition unit 73 (for example, the intermediary client 50) acquired from the second blockchain and the block number included in the acquired confirmation transaction, and from the block header in the specified block. A second Merkle root hash is calculated, the first Merkle root hash and the second Merkle root hash are compared to see if they match, and tampering with the identified block (eg, data tampering) is performed. It is provided with an unauthorized operation verification unit 74 (for example, a block management unit 41) for detecting.

Part or all of the above embodiments may be described as in the following appendix, but are not limited to the following.

(Appendix 1) A block confirmation transaction that is a transaction including the first Merkle root hash calculated from the block header of the block of the target range in the first blockchain and the block number indicating the block of the range. , From the blockchain in which the block confirmation transaction is registered, the confirmation block acquisition unit acquired from the second blockchain different from the first blockchain, and the block number included in the acquired confirmation transaction. The block in the first blockchain is specified, the second Merkle root hash is calculated from the block header in the specified block, and the first Merkle root hash and the second Merkle root hash are A fraud verification device including a fraud verification unit that detects fraudulent operations on the specified block by comparing whether they match or not.

(Appendix 2) The target range in the first blockchain is the fraud verification described in Appendix 1 which is determined according to the block generation timing in the first blockchain and the block generation timing in the second blockchain. Device.

(Appendix 3) The range covered by the first blockchain is the range of the number of blocks in the first blockchain generated within the period in which one block is generated in the second blockchain. Alternatively, the fraud verification device described in Appendix 2.

(Appendix 4) The first blockchain is a consortium type blockchain or a public type blockchain, and the second blockchain is described in any one of Appendix 1 to Appendix 3 which is a public type blockchain. Fraud verification device.

(Supplementary note 5) The fraud verification device according to any one of Supplementary note 1 to Supplementary note 4, wherein the first Merkle root hash and the second Merkle root hash are calculated by the same method.

(Appendix 6) In a transaction that calculates a Merkle root hash from the block header of a block in the target range in the first blockchain, and includes the block number indicating the block in the range and the calculated Merkle root hash. It is provided with a confirmation block generation unit that generates a certain block confirmation transaction and a registration request unit that transmits a transaction requesting registration of the block confirmation transaction to a second blockchain different from the first blockchain. A confirmation generator characterized by.

(Appendix 7) The target range in the first blockchain is the confirmation generation according to Appendix 6, which is determined according to the block generation timing in the first blockchain and the block generation timing in the second blockchain. Device.

(Appendix 8) The first Merkle root hash is calculated from the block header of the block of the target range in the first block chain, and the block number indicating the block of the range and the calculated first Merkle root are calculated. A registration request for transmitting a confirmation block generator that generates a block confirmation transaction, which is a transaction including a hash, and a transaction requesting registration of the block confirmation transaction to a second block chain different from the first block chain. The block in the first block chain is specified from the block number included in the confirmation block acquisition unit and the acquired confirmation transaction for acquiring the block confirmation transaction from the second block chain, and the specified block. A second Merkle root hash is calculated from the block header in the above, and the first Merkle root hash and the second Merkle root hash are compared to see if they match, and an illegal operation on the specified block is performed. A fraud detection system characterized by having a fraudulent operation verification unit that detects fraudulent operations.

(Appendix 9) The target range in the first blockchain is the fraud detection described in Appendix 8 which is determined according to the block generation timing in the first blockchain and the block generation timing in the second blockchain. system.

(Appendix 10) A block confirmation transaction that is a transaction including the first Merkle root hash calculated from the block header of the block of the target range in the first blockchain and the block number indicating the block of the range. , The block chain in which the block confirmation transaction is registered, acquired from a second block chain different from the first block chain, and the first block from the block number included in the acquired confirmation transaction. Identify the block in the chain, calculate the second Merkle root hash from the block header in the identified block, and compare whether the first Merkle root hash and the second Merkle root hash match. A fraud verification method comprising detecting a fraudulent operation on the specified block.

(Appendix 11) The scope of the first blockchain is determined according to the block generation timing in the first blockchain and the block generation timing in the second blockchain. Method.

(Appendix 12) The first Merkle root hash is calculated from the block header of the block of the target range in the first block chain, and the block number indicating the block of the range and the calculated first Merkle root are calculated. A block confirmation transaction, which is a transaction including a hash, is generated, a transaction requesting registration of the block confirmation transaction is transmitted to a second blockchain different from the first blockchain, and the block confirmation transaction is transmitted. The block in the first blockchain is specified from the block number acquired from the second blockchain and included in the acquired confirmation transaction, and the second Merkle root hash is calculated from the block header in the specified block. A fraud detection method, characterized in that a fraud detection method for detecting a fraudulent operation on the specified block is performed by comparing whether or not the first Merkle root hash and the second Merkle root hash match.

(Appendix 13) The range targeted by the first blockchain is the fraud detection according to Appendix 12, which is determined according to the block generation timing in the first blockchain and the block generation timing in the second blockchain. Method.

(Appendix 14) A block that is a transaction in which a computer includes a first Merkle root hash calculated from a block header of a block of the target range in the first block chain and a block number indicating the block of the range. The confirmation transaction is included in the confirmation block acquisition process of acquiring the block confirmation transaction from a second blockchain which is a blockchain in which the block confirmation transaction is registered and different from the first blockchain, and the acquired confirmation transaction. The block in the first block chain is specified from the block number to be obtained, the second Merkle root hash is calculated from the block header in the specified block, and the first Merkle root hash and the second Merkle root hash are calculated. A fraud verification program for executing a fraud verification process that detects a fraudulent operation on the specified block by comparing whether it matches the root hash.

(Appendix 15) The scope of interest in the first blockchain is determined according to the block generation timing in the first blockchain and the block generation timing in the second blockchain. program.

(Appendix 16) A Merkle root hash is calculated from the block headers of blocks in the target range in the first block chain, and the block number indicating the block in the range and the calculated Merkle root hash are input to the computer. A confirmation block generation process for generating a block confirmation transaction which is a including transaction, and a registration request process for transmitting a transaction requesting registration of the block confirmation transaction to a second blockchain different from the first blockchain. A confirmation generator to run.

Although the invention of the present application has been described above with reference to the embodiments and examples, the invention of the present application is not limited to the above embodiments and examples. Various changes that can be understood by those skilled in the art can be made within the scope of the present invention in terms of the structure and details of the present invention.

This application claims priority based on Japanese patent application 2020-28430 filed on February 21, 2020, and incorporates all of its disclosures herein.

1 Client device 10 Nodes 11 Control unit 12

Storage unit

20, 40, 60

Transaction management unit

21, 41

Block management unit

30, 50, 70

Mediation client

100, 200, 300 Fraud detection system 110 Blockchain 120 Blockchain

Claims

The block confirmation transaction, which is a transaction including the first Merkle root hash calculated from the block header of the block of the target range in the first blockchain and the block number indicating the block of the range, is the block confirmation transaction. A blockchain in which a transaction is registered, and a confirmation block acquisition means acquired from a second blockchain different from the first blockchain.
The block in the first blockchain is specified from the block number included in the acquired confirmation transaction, the second Merkle root hash is calculated from the block header in the specified block, and the first Merkle root hash is calculated. A fraud verification device comprising: a fraud verification means for detecting fraudulent operations on the specified block by comparing whether and the second Merkle root hash match.
The fraud verification device according to claim 1, wherein the target range in the first blockchain is determined according to the block generation timing in the first blockchain and the block generation timing in the second blockchain.
Claim 1 or claim that the range covered by the first blockchain is the range of the number of blocks of the first blockchain generated within the period in which one block is generated in the second blockchain. 2. The fraud verification device described.
The first blockchain is a consortium type blockchain or a public type blockchain, and the second blockchain is a public type blockchain.
The fraud verification device according to any one of claims 1 to 3.
The fraud verification device according to any one of claims 1 to 4, wherein the first Merkle root hash and the second Merkle root hash are calculated by the same method.
A block confirmation transaction that calculates a Merkle root hash from the block headers of blocks in the target range in the first blockchain, and includes the block number indicating the block in the range and the calculated Merkle root hash. Confirmation block generation means to generate
A confirmation generation device including a registration requesting means for transmitting a transaction requesting registration of the block confirmation transaction to a second blockchain different from the first blockchain.
The confirmation generation device according to claim 6, wherein the target range in the first blockchain is determined according to the block generation timing in the first blockchain and the block generation timing in the second blockchain.
The first Merkle root hash is calculated from the block header of the block of the target range in the first blockchain, and the block number indicating the block in the range and the calculated first Merkle root hash are included. Block confirmation that is a transaction Confirmation block generation means that generates a transaction, and
A registration requesting means for transmitting a transaction requesting registration of the block confirmation transaction to a second blockchain different from the first blockchain, and
A confirmation block acquisition means for acquiring the block confirmation transaction from the second blockchain, and
The block in the first blockchain is specified from the block number included in the acquired confirmation transaction, the second Merkle root hash is calculated from the block header in the specified block, and the first Merkle root hash is used. A fraud detection system comprising: a fraudulent operation verification means for detecting a fraudulent operation on the specified block by comparing whether or not the second Merkle root hash matches.
The fraud detection system according to claim 8, wherein the target range in the first blockchain is determined according to the block generation timing in the first blockchain and the block generation timing in the second blockchain.
The block confirmation transaction, which is a transaction including the first Merkle root hash calculated from the block header of the block of the target range in the first blockchain and the block number indicating the block of the range, is the block confirmation transaction. A blockchain in which a transaction is registered, which is acquired from a second blockchain different from the first blockchain.
The block in the first blockchain is specified from the block number included in the acquired confirmation transaction, the second Merkle root hash is calculated from the block header in the specified block, and the first Merkle root hash is calculated. A fraud verification method characterized by detecting a fraudulent operation on the specified block by comparing whether and the second Merkle root hash match.
The fraud verification method according to claim 10, wherein the target range in the first blockchain is determined according to the block generation timing in the first blockchain and the block generation timing in the second blockchain.
The first Merkle root hash is calculated from the block header of the block of the target range in the first blockchain, and the block number indicating the block in the range and the calculated first Merkle root hash are included. Generate a block verification transaction that is a transaction and
A transaction requesting registration of the block confirmation transaction is transmitted to a second blockchain different from the first blockchain, and the transaction is transmitted.
Obtaining the block confirmation transaction from the second blockchain,
The block in the first blockchain is specified from the block number included in the acquired confirmation transaction, the second Merkle root hash is calculated from the block header in the specified block, and the first Merkle root hash is used. A fraud detection method characterized in that a fraudulent operation on the specified block is detected by comparing whether or not the second Merkle root hash matches.
The fraud detection method according to claim 12, wherein the target range in the first blockchain is determined according to the block generation timing in the first blockchain and the block generation timing in the second blockchain.
On the computer
The block confirmation transaction, which is a transaction including the first Merkle root hash calculated from the block header of the block of the target range in the first blockchain and the block number indicating the block of the range, is the block confirmation transaction. A confirmation block acquisition process that is a blockchain in which a transaction is registered and is acquired from a second blockchain different from the first blockchain, and a confirmation block acquisition process.
The block in the first blockchain is specified from the block number included in the acquired confirmation transaction, the second Merkle root hash is calculated from the block header in the specified block, and the first Merkle root hash is calculated. A program storage medium for storing a fraud verification program for executing a fraud verification process for detecting a fraudulent operation on the specified block by comparing whether and the second Merkle root hash match.
A fraud verification program characterized in that the target range in the first blockchain is determined according to the block generation timing in the first blockchain and the block generation timing in the second blockchain is stored. 14. The program storage medium according to claim 14.
On the computer
A block confirmation transaction that calculates a Merkle root hash from the block headers of blocks in the target range in the first blockchain, and includes the block number indicating the block in the range and the calculated Merkle root hash. Confirmation block generation process to generate, and
A program storage medium that stores a confirmation generation program in order to execute a registration request process for transmitting a transaction requesting registration of the block confirmation transaction to a second blockchain different from the first blockchain.