JP7190404B2 - Computer system and request processing method - Google Patents

Description

TECHNICAL FIELD The present invention relates to a blockchain for sharing various data among multiple institutions, and more particularly to an authentication method between blockchains.

Blockchain has the characteristics of making it difficult to falsify data and enabling direct transactions without intermediaries, and in recent years, in addition to being used in systems that realize virtual currency, it has been attracting attention as a platform for corporate activities. are gathering.

In addition to public blockchains that publish data widely, there are private blockchains where only members within the same community share data. As various organizations build their own blockchains, there may be cases where corporate activities are conducted within each blockchain. There is a possibility that efficiency can be improved.

On the other hand, regarding different blockchains, especially private blockchains, the basic idea is not to disclose data to anyone other than the relevant parties. and the contents of the request must be validated correctly.

Patent Document 1 discloses a known technology related to system cooperation using blockchain. Patent Literature 1 describes "a ledger management unit that manages the ownership of the thing 4, and an object storage 3 that can physically store the thing 4 with a key 31 that is opened and closed by electronic processing. , a key manager capable of opening or closing the key 31, a user who, upon receiving a request to unlock the key 31, makes the request, and a user whose ownership is recorded in the ledger manager. a determination unit for determining whether the key management unit matches the user who made the request and the user who has the ownership recorded in the ledger management unit; 31 is opened to make it possible to take out the object 4 from the object storage device 3, and to notify the ledger management unit that the key 31 has been opened."

JP 2019-016342 A

In the technique described in Patent Literature 1, a server that receives a request from a user can determine the validity of the requested operation for products and users managed by itself, but does not accept requests for products and users managed by other systems. cannot determine the legitimacy of Therefore, in a use case of cooperation between blockchains, the conventional technology cannot correctly determine the validity of a request to a cooperation destination blockchain.

The present invention is a system that realizes blockchain cooperation, and even if the cooperation source blockchain does not know the information of the user managed by the cooperation destination blockchain, the user is appropriately authenticated, and the cooperation destination block Provide techniques to prevent sending or executing illegitimate requests to the chain.

A representative example of the present invention is as follows. That is, a computer system comprising a plurality of computers constituting a block chain, the plurality of computers including a plurality of computers constituting a first block chain and a plurality of computers constituting a second block chain, When the plurality of computers constituting the first blockchain receives a request for executing a transaction including the signature for the first blockchain, first verification using the signature for the first blockchain performing processing, and if the result of the first verification processing is verification success, determining whether the request is a request for executing a transaction related to the second blockchain; determining whether the request includes a signature for the second blockchain, if the request is determined to be a request to perform a transaction related to a second blockchain; If the request is determined to contain the signature for the request, the request is transmitted to a plurality of computers constituting the second blockchain.

Advantageous Effects of Invention According to the present invention, in a system that realizes blockchain cooperation, it is possible to prevent transmission or execution of an unauthorized request to a cooperation destination blockchain. Problems, configurations and effects other than those described above will be clarified by the following description of the embodiments.

1 is a block diagram showing an example of a hardware configuration and a software configuration of a computer system of Example 1; FIG. 4 is an explanatory diagram showing an example of the data structure of program management information held by the computer of Example 1; FIG. 4 is an explanatory diagram illustrating an example of the data structure of cooperation destination information held by the computer of Example 1; FIG. 4 is an explanatory diagram showing an example of the data structure of a ledger held by the computer of Example 1; FIG. 4 is an explanatory diagram showing an example of the data structure of a ledger held by the computer of Example 1; FIG. 4 is an explanatory diagram showing an example of the data structure of cooperation control information held by the computer of Example 1; FIG. 4 is an explanatory diagram showing an example of the data structure of cooperation control information held by the computer of Example 1; FIG. 4 is an explanatory diagram showing an example of the data structure of state management information held by the computer of Example 1; FIG. 4 is a flowchart for explaining an example of inter-BC cooperation processing executed in the computer system of Example 1; 4 is a flowchart for explaining an example of inter-BC cooperation processing executed in the computer system of Example 1; 7 is a flowchart illustrating an example of processing executed by the client terminal in the inter-BC cooperation processing according to the first embodiment; FIG. 11 is a flowchart illustrating an example of inter-BC cooperation processing executed in the computer system of Example 2; FIG. FIG. 11 is a flowchart illustrating an example of inter-BC cooperation processing executed in the computer system of Example 2; FIG. FIG. 11 is a flowchart illustrating an example of inter-BC cooperation processing executed in the computer system of Example 2; FIG. FIG. 11 is a flowchart illustrating an example of inter-BC cooperation processing executed in the computer system of Example 2; FIG. FIG. 11 is a flow chart showing an example of processing executed when a computer belonging to a cooperation destination BC receives a request from a computer belonging to a cooperation source BC according to the third embodiment; FIG.

Hereinafter, embodiments of the present invention will be described with reference to the drawings. However, the present invention should not be construed as being limited to the contents of the examples described below. Those skilled in the art will easily understand that the specific configuration can be changed without departing from the idea or gist of the present invention.

In the configurations of the invention described below, the same or similar configurations or functions are denoted by the same reference numerals, and overlapping descriptions are omitted.

FIG. 1 is a block diagram showing an example of the hardware configuration and software configuration of the computer system of the first embodiment.

A computer system that realizes cooperation of a plurality of blockchains (hereinafter referred to as BC) includes one or more cooperation source computers 101, one or more cooperation destination computers 102, and one or more client terminals 103. and one or more BC authority servers 104 .

The BC certification authority server 104 registers information such as IDs and certificates for identifying each BC in each of a plurality of independently existing BCs. The BC certification authority server 104 is intended to be used, for example, by a cooperation destination computer belonging to a certain BC to identify the BC of the cooperation source computer.

Computers 101 and 102 and client terminal 103 are connected to network 105 via I/Fs 112 and 182, respectively. The computer 101 receives operation requests and responds with operation results to external devices such as the client terminal 103 via the I/F 112 .

Computers 101 and 102 are computers that configure BC, and include CPU 111 , I/F 112 , memory 113 , and HDD (Hard Disk Drive) 114 . CPU 111, I/F 112, memory 113, and HDD 114 are connected to each other via an internal bus or the like.

The CPU 111 receives an operation request from an external device such as the client terminal 103 via the I/F 112, executes an operation based on the operation request, and communicates with the external device by executing processing according to a program stored in the memory 113. Executes transmission of processing results, etc.

The I/F 112 is an interface for connecting with an external device. I/F 112 is, for example, a network interface.

Memory 113 stores programs executed by CPU 111 and information used by the programs.

HDD 114 permanently stores data. Note that the computer 101 may have an SSD (Solid State Drive) instead of the HDD 114 . Also, the computer 101 may include both the HDD 114 and SSD.

The client terminal 103 has a CPU 181 , an I/F 182 and a memory 183 . CPU 181, I/F 182, and memory 183 are connected to each other via an internal bus or the like. The client terminal 103 may include an input device such as a keyboard, mouse, and touch panel, and an output device such as a display.

The CPU 181 executes processing according to a program stored in the memory 183, thereby transmitting operation requests to the computers 101 and 102 via the I/F 182, receiving processing results from the computers 101 and 102, and the like. .

The I/F 182 is an interface for connecting with external equipment. I/F 182 is, for example, a network interface.

Memory 183 stores programs executed by CPU 181 and information used by the programs.

In the following description, when a process is described with a functional unit as the subject, it means that the CPU 111 or 181 is executing a program that implements the functional unit.

The memory 113 of the computer 101 stores programs that implement the cooperation unit 121 , the transaction management unit 122 , the consensus building unit 123 , and the authentication unit 124 , and also stores program management information 131 and cooperation destination information 132 . The HDD 114 of the computer 101 also stores a ledger (ledger information) 141 .

The program management information 131 is a transaction that the computer 101 requests from the client terminal 103 or the like is a transaction that is closed within its own BC, such as updating the ledger 141 within its own BC and exchanging with other computers 101 within its own BC. It is information used to determine whether there is a transaction (transaction related to other BC) in cooperation with other BC, such as sending a request to another BC. Details of the data structure of the program management information 131 will be described with reference to FIG.

The cooperation destination information 132 is information for managing information about cooperation destinations such as BCs that cooperate with the BC to which the computer 102 belongs. The details of the data structure of the cooperation destination information 132 will be described with reference to FIG.

The ledger 141 is information for managing transaction data (transaction data) such as transactions performed on the BC. Details of the data structure of the ledger 141 will be described with reference to FIG. 4A.

The cooperation unit 121 transmits and receives data to and from a computer belonging to its own BC, a computer belonging to another BC, the client terminal 103, and the like.

The transaction management unit 122 executes processing such as entering data into the ledger 141 and referring to the ledger 141 as a transaction based on a request transmitted from the client terminal 103 or the like. to manage.

For example, when a request for updating the ledger 141 is received, the consensus building unit 123 pre-verifies the request before updating, and considers the pre-verification results of other computers 101 in its own BC, It determines whether or not to update the ledger 141, and executes processing based on the determination result.

When receiving a request from the client terminal 103 or the like, the authentication unit 124 performs authentication of the client terminal 103 and verification of a signature attached to data.

The memory 113 of the computer 102 stores programs for implementing the cooperation unit 151 , the transaction management unit 152 , the consensus building unit 153 and the authentication unit 154 , and also stores cooperation control information 161 and state management information 162 . Also, the HDD 114 of the computer 102 stores a ledger 171 .

The cooperation control information 161 is information for managing a method for restricting a request transmission source and restrictions imposed on a request transmission source when a request is received from a computer or the like belonging to another BC. Details of the data structure of the cooperation control information 161 will be described with reference to FIGS. 5A and 5B.

The status management information 162 is information for managing the execution status of transactions held in the cooperation destination BC for ensuring consistency in cooperation between BCs. Details of the data structure of the state management information 162 will be described with reference to FIG. Note that processing using the state management information 162 will be described in a second embodiment.

The cooperation unit 151 , the transaction management unit 152 , the consensus formation unit 153 and the authentication unit 154 have the same functions as the cooperation unit 121 , the transaction management unit 122 , the consensus formation unit 123 and the authentication unit 124 .

The memory 183 of the client terminal 103 stores a program that implements the transaction request section 191 , the signature generation section 192 and the cooperation management section 193 .

The transaction request unit 191 cooperates with external computers, such as the computer 101 belonging to the cooperation source BC and the computer 102 belonging to the cooperation destination BC, and transmits requests instructing execution of transactions to the external computers. The transaction requesting unit 191 also receives responses from external computers.

When transmitting a transaction request, the signature generation unit 192 generates a signature for assuring the validity of the transaction and the validity of the sender of the request.

The cooperation management unit 193 communicates with a computer belonging to a cooperation source BC and a computer belonging to a cooperation destination BC, etc., in cooperation between BCs, and ensures consistency of transactions managed by both BCs.

Note that the computer 101 may hold the cooperation control information 161 and the state management information 162 . Also, the computer 102 may hold the program management information 131 and the cooperation destination information 132 .

Next, the data structure of information held by the computer system of the first embodiment will be described.

First, the program management information 131 and cooperation destination information 132 stored in the memory 113 of the computer 101 and the ledger 141 stored in the HDD 114 will be described.

FIG. 2 is an explanatory diagram showing an example of the data structure of the program management information 131 held by the computer 101 of the first embodiment.

The program management information 131 stores an entry consisting of five fields: ID 201 , program name 202 , collaboration presence/absence 203 , designation method 204 , and collaboration destination 205 .

The ID 201 is a field that stores identification information for identifying programs managed by the computer 101 . A program name 202 is a field that stores the name of the program.

The presence/absence of cooperation 203 is a field for storing information indicating whether or not the program corresponding to the entry performs processing in cooperation with an external system such as another BC. The cooperation presence/absence 203 stores either "no" indicating that processing in cooperation with an external system is not performed or "yes" indicating that processing in cooperation with an external system is performed.

The specifying method 204 is a field for storing information indicating whether the external system to be linked is a fixed one that is unchangeable or can be specified by an argument or the like from the client terminal 103 . When the presence/absence of cooperation 203 is "no", the specifying method 204 is blank.

A collaboration destination 205 is a field for storing information for specifying a collaboration destination. In the example shown in FIG. 2, "1001" indicates a collaboration destination whose ID 301 in the collaboration destination information 132 described in FIG. , means to indicate the cooperation destination.

FIG. 3 is an explanatory diagram showing an example of the data structure of the cooperation destination information 132 held by the computer 101 of the first embodiment.

The cooperation destination information 132 stores an entry composed of three fields of ID 301 , name 302 and destination information 303 .

The ID 301 is a field that stores identification information for identifying a cooperation destination. A name 302 is a field for storing the name of the cooperation destination. Destination information 303 is a field for storing detailed information about destinations of cooperation destinations. The destination information 303 stores URLs, IP addresses, and the like.

FIG. 4A is an explanatory diagram showing an example of the data structure of the ledger 141 held by the computer 101 of the first embodiment.

FIG. 4A shows, as an example, a ledger 141 that manages data related to transactions related to commodity trading. The ledger 141 stores entries consisting of eight fields of ID 401 , purchaser 402 , seller 403 , product name 404 , quantity 405 , price 406 , date and time 407 and tx_ID 408 . One data corresponds to one transaction data.

The ID 401 is a field that stores identification information for identifying transaction data recorded in the ledger 141 . Purchaser 402 is a field that stores purchaser information in the transaction corresponding to the entry. A seller 403 is a field that stores information about the seller in the transaction corresponding to the entry. A product name 404 is a field that stores the name of the product purchased in the transaction corresponding to the entry. A quantity 405 is a field that stores the quantity of the purchased product. A price 406 is a field that stores the price of the product purchased. The date and time 407 is a field that stores the date and time when the transaction corresponding to the entry was performed. A tx_ID 408 is a field that stores identification information (transaction ID) for identifying a transaction corresponding to an entry.

Next, the cooperation control information 161 and state management information 162 stored in the memory 113 of the computer 102 and the ledger 171 stored in the HDD 114 will be described.

5A and 5B are explanatory diagrams showing an example of the data structure of the cooperation control information 161 held by the computer 102 of the first embodiment.

The cooperation control information 161 includes control definition information 500 and constraint information 510 .

The control definition information 500 stores an entry composed of five fields: control type 501, authentication granularity 502, authentication method 503, constraint information ID 504, and application destination BC_ID 505. FIG.

The control type 501 is a field that stores identification information for identifying the type of cooperative control method.

The authentication granularity 502 is a field that stores information indicating the granularity of the authentication process of the sender of the request. For example, when the authentication granularity 502 is "device", the request sender is authenticated on a device-by-device basis using an IP address, etc., and when the authentication granularity 502 is "user", a user name is used on a user-by-user basis. When the request sender is authenticated and the authentication granularity 502 is "BC", the request sender is authenticated for each BC using the identification information of the BC to which the request sender belongs.

Note that the authentication granularity 502 can also be set to a value obtained by combining a plurality of authentication granularities. For example, in the case of "equipment, BC", authentication is performed in units of equipment and in units of BC. In this case, in addition to device-by-device authentication, authentication is performed in consideration of information on the BC to which the request sender belongs.

The authentication method 503 is a field for storing information indicating the details of the authentication method of the sender of the request. For example, when the authentication method 503 is "password", ID/password authentication is performed, and when the authentication method 503 is "signature (device)", authentication is performed using the signature of the device. In the case of "signature (user)", authentication is performed using the user's signature, and in the case of the authentication method 503 being "BC identification", authentication is performed using information on the BC to which the request sender belongs.

The restriction information ID 504 is a field that stores information for specifying restrictions imposed on the sender of the request. The constraint information ID 504 stores the identification information (constraint ID 510) of the entry of the constraint information 510 described later. For example, when the restriction information ID 504 is "2, 3, 4", three restrictions of "2", "3", and "4" are imposed as the restriction IDs 511 to authenticate the sender of the request.

The destination BC_ID 505 is a field that stores the identification information of the BC to which the control corresponding to the entry is applied. For example, for computers belonging to "BC1", cooperative control is performed based on the cooperative control method whose control type 501 is "1".

Constraint information 510 stores an entry consisting of two fields, constraint ID 511 and score 512 .

A constraint ID 511 is a field that stores identification information for identifying a constraint. A score 512 is a field that stores information indicating the details of the constraint.

Here, the constraints defined in the first embodiment will be explained.

Under the constraint that the constraint ID 511 is "1", the computer accepts the request and executes the transaction based on the request only when the signature executor and the subject of the request content match.

For example, if user A signs and requests that user A pay user B, the request is accepted. On the other hand, a request for user A to sign and payment from user B to user A is not accepted because the person who signed the signature does not match the subject of the request.

In the constraint where the constraint ID 511 is "2", a computer accepts a request and executes a transaction based on the request only when it receives requests containing the same transaction ID from a plurality of different computers (request senders). .

Depending on the BC, multiple computers verify the same processing when updating the ledger, etc., and as a result, multiple duplicate requests are sent to the computers belonging to the collaborating BC. be.

In addition to simply determining that a plurality of requests have been received, the fact that the requests have been sent from a predetermined address may be added to the restriction. Receipt of multiple requests serves to ensure that a computer belonging to a certain BC did not send requests independently.

In the constraint with the constraint ID 511 of "3", the computer provides only information that can be viewed by anyone in response to the received request.

When the constraint ID 511 is "4", the computer provides information if the received request is related to information on the BC to which the computer that sent the request belongs, but does not provide information otherwise.

For example, when the computer that sends the request belongs to multiple BCs (BC1, BC2), and information (for example, payment information) related to transactions on these BCs is managed by the linked BC (BC3), BC2 contains an organization different from BC1. In such a case, it is believed that information regarding transactions on BC2 should not be made public to members of BC1. Therefore, when a request is received from a computer in an organization belonging to both BC1 and BC2, the computer belonging to the cooperating BC provides only information related to BC1 in response to the request as a computer belonging to BC1, You need to provide control that otherwise would not provide. The constraint with the constraint ID 511 of "4" is for realizing the control described above.

Control based on the constraint with the constraint ID 511 of "4" can prevent information that should not be made public from being erroneously provided to computers belonging to the BC of the cooperation destination or the BC of the cooperation source.

As a method of determining whether or not a computer belongs to a plurality of BCs, a method in which a computer belonging to a cooperation destination BC manages such association information and makes a determination based on the information is conceivable. In addition, identification information of computers such as IP addresses is recorded, and transaction data recorded in the ledger of the linked BC is referenced to determine whether or not transaction data related to different BCs involving one computer is recorded. A method of determination is conceivable.

The above is the description of the cooperation control information 161 .

FIG. 6 is an explanatory diagram showing an example of the data structure of the state management information 162 held by the computer 102 of the first embodiment.

The state management information 162 stores an entry consisting of seven fields: tx_ID 601 , entity 602 , state 603 , external tx_ID 604 , start time 605 , end time 606 and execution time limit 607 .

A tx_ID 601 is a field that stores identification information for identifying a transaction.

Principal 602 is a field that stores information about the performer of the transaction.

A state 603 is a field that stores information indicating the execution status of a transaction. The status 603 includes "completed" indicating that the transaction has ended, "waiting" indicating that the transaction is waiting without starting, and "executing" indicating that the transaction is being executed. Stored.

An external tx_ID 604 is a field for storing an external tx_ID transmitted from a computer belonging to the cooperation source BC. The external tx_ID 604 is information for specifying that the transaction of the cooperation destination BC is being executed in association with the transaction of the cooperation source BC. If the external tx_ID 604 is blank, it indicates that the transaction is not caused by a request from an external BC, but is generated within its own BC.

A start time 605 is a field that stores the start time of the transaction. A blank start time 605 indicates that the transaction has not yet started.

The end time 606 is a field that stores the end time of the transaction. A blank end time 606 indicates that the transaction is in progress.

The execution deadline 607 is a field that stores the transaction execution deadline. For example, in a transaction corresponding to an entry whose status 603 is "standby", if the time set in the execution time limit 607 has passed, the request corresponding to the transaction is deleted.

FIG. 4B is an explanatory diagram showing an example of the data structure of the ledger 171 held by the computer 102 of the first embodiment.

FIG. 4B shows, as an example, a ledger 171 that manages data on transactions related to product payment. Ledger 171 stores entries consisting of eight fields: ID 411 , payer 412 , payee 413 , amount 414 , date 415 , BC_ID 416 , external tx_ID 417 and tx_ID 418 .

The ID 411 is a field that stores identification information for identifying transaction data recorded in the ledger 171 . Payer 412 is a field that stores the information of the payer in the transaction corresponding to the entry. A payee 413 is a field for storing payee information in the transaction corresponding to the entry. Amount 414 is a field that stores the amount paid in the transaction corresponding to the entry. The date and time 415 is a field for storing the execution date and time of the transaction corresponding to the entry. BC_ID 416 is a field that stores identification information of the BC that sent the request for executing the transaction corresponding to the entry. This makes it possible to specify which BC the request is from the computer belonging to. The external tx_ID 417 is a field for storing transaction identification information in the cooperation source BC, which is transmitted from a computer belonging to the cooperation source BC. The tx_ID 418 is a field for storing identification information of transactions recorded in the BC of the cooperation destination.

Based on the external tx_ID 417 and tx_ID 418, it is possible to identify the transaction of the cooperation destination BC linked to the transaction of the cooperation source BC.

The above is the description of the data structure of the information held by the computer system of the first embodiment.

Next, the inter-BC cooperation processing executed by the computers belonging to the BCs of the first embodiment will be described. The inter-BC cooperation processing is executed in cooperation with the cooperation source BC and the cooperation destination BC.

7A and 7B are flowcharts illustrating an example of inter-BC cooperation processing executed in the computer system of the first embodiment. Here, the BC to which the computer 101 belongs is assumed to be the cooperation source BC, and the BC to which the computer 102 belongs is assumed to be the cooperation destination BC.

<Processing of Computers Belonging to Collaborating Source BC>
FIG. 7A is a flowchart showing an example of processing executed by the computer 101 belonging to the cooperation source BC.

The computer 101 receives a request for executing any transaction from the client terminal 103 (step S701).

For example, when a user transmits a request for executing a transaction such as purchase of a product, the request includes operational information such as referencing and updating a ledger related to purchase procedures.

The operation information includes information for specifying a program to call, a program to execute processing, and the like. One request may be issued for a transaction involving one program, or one request may be issued for a transaction involving multiple programs. In this case, information for specifying the program involved in each request may be managed separately.

The client terminal 103 generates a signature using the key for the collaboration source BC, and transmits the request with the signature to the computer 101 belonging to the collaboration source BC. Upon receiving the request, the authentication unit 124 of the computer 101 executes authentication processing for verifying the validity of the signature included in the request. If the signature is valid, computer 101 accepts the request as a request to be executed. In the following explanation, the processing will be explained assuming that the result of the authentication processing described above is authentication success.

Next, the computer 101 identifies a program to be called when executing a transaction corresponding to the request (step S702), and determines whether or not the identified program includes a program for inter-BC cooperation. Determine (step S703). That is, it is determined whether or not the request is for executing a transaction related to another BC.

Specifically, the linking unit 121 searches for an entry whose name of the specified program matches the program name 202, and among the searched entries, there are at least entries whose link presence/absence 203 is set to “Yes”. Determine whether or not there is one or more. When there is at least one or more entries for which “Yes” is set in the cooperation presence/absence 203, the cooperation unit 121 determines that the identified programs include a program that performs inter-BC cooperation.

If it is determined that the program that performs inter-BC collaboration is not included, the computer 101 determines that the request is not a request linked with another BC, but a request to close the local BC, and executes a normal transaction in the BC (step S704). ). Furthermore, the computer 101 transmits the execution result of the transaction to the client terminal 103 (step S709), and then terminates the process.

When it is determined that the program for inter-BC collaboration is included, the computer 101 determines whether the received request includes a signature for the collaboration destination BC (step S705).

For example, the cooperation unit 121 checks whether the request includes a signature different from the local BC signature. Note that the cooperation unit 121 may determine whether or not the signature included in the request is the signature for the cooperation destination BC by, for example, obtaining the certificate of the certification authority for the cooperation destination BC in advance.

If it is determined that the received request does not contain the signature for the cooperation destination BC, the computer 101 generates a hash based on the data of the request to be transmitted to the cooperation destination BC, and includes the hash in the client terminal 103. A request to resend the request is sent (step S706), and then the process ends.

When receiving the request, the client terminal 103 generates a signature using the hash and the key for the collaboration destination BC, and transmits the request including the signature again to the computer 101 belonging to the collaboration source BC. This enables the request to be sent to the cooperation destination BC. That is, it is possible to realize request processing in which BC cooperates.

If it is determined that the received request includes the signature for the cooperation destination BC, the computer 101 transmits the request including the signature to the computer 102 belonging to the cooperation destination BC (step S707).

At this time, the cooperation unit 121 transmits the identification information of the transaction in the cooperation source BC to the computers belonging to the cooperation destination BC. Specifically, the computer 101 transmits the value of the tx_ID 408 of the ledger 141 managed by the collaboration source BC as transaction identification information to the computer 102 belonging to the collaboration destination BC. As a result, it is possible to link and manage the transactions executed in the cooperation destination BC and the transactions executed in the cooperation source BC.

The computer 102 belonging to the cooperation destination BC adds an entry to the ledger 171 along with the execution of the transaction, sets the received transaction identification information to the external tx_ID 417 of the added entry, and sets the tx_ID 418 to the tx_ID 418 of the transaction in the cooperation destination BC. Set identification information.

When the computer 101 receives a response from the computer 102 belonging to the cooperation destination BC (step S708), the computer 101 transmits the execution result of the transaction included in the response to the client terminal 103 (step S709), and then terminates the process.

At this time, the computer 101 may add the execution result of the transaction received from the computer 102 to the ledger 141 .

<Processing of computer belonging to cooperation destination BC>
FIG. 7B is a flowchart showing an example of processing executed when the computer 102 belonging to the cooperation destination BC receives a request from the computer 101 belonging to the cooperation source BC.

The computer 102 receives the request including the signature for the collaboration destination BC from the computer 101 belonging to the collaboration source BC (step S721), and verifies the validity of the received request based on the signature for the collaboration destination BC and the request content. (step S722).

In this embodiment, the validity of the request is verified based on the cooperation control information 161. FIG.

Verification of validity of the signature is performed using a certificate issued by a certification authority used by the partner BC. For example, when a request is received from a computer belonging to a BC to which the constraint ID 511 of "1" is applied, the computer 102 determines whether or not the signature executor and the subject of the request match. In this case, a request for user A to sign and user A to pay user B is allowed, but a request for user A to sign and user B to pay user A is not allowed. This is because the signature executor and the subject of the request do not match.

In the computer 102 belonging to the collaboration destination BC, the name of the subject included in the public key certificate used by the collaboration destination BC is set as account information in the collaboration destination BC, and the signature executor and the request subject match. You may make it determine whether it is.

The computer 102 determines whether the verification is successful based on the verification result (step S723).

If it is determined that the verification has succeeded, the computer 102 executes the transaction based on the received request and transmits a response including the transaction execution result to the computer 101 belonging to the cooperation source BC (step S724). After that, computer 102 terminates the process.

If it is determined that the verification has failed, the computer 102 does not execute the transaction, and transmits a response including an execution result indicating verification failure or the like to the computer 101 belonging to the cooperation source BC (step S725). After that, computer 102 terminates the process.

According to the first embodiment, even if the cooperation source BC does not know the user information or the like in the cooperation destination BC, appropriate user authentication can be realized. This makes it possible to prevent transmission and execution of unauthorized requests to the cooperation destination BC.

(Modification)
Next, a modified example of inter-BC cooperation processing will be described. In a modified example, the client terminal 103 determines whether there is cooperation between BCs. Therefore, the client terminal 103 holds the program management information 131 and the cooperation destination information 132 . In this case, the computer 101 does not have to hold the program management information 131 and the cooperation destination information 132 .

FIG. 8 is a flowchart illustrating an example of processing executed by the client terminal in the inter-BC cooperation processing according to the first embodiment.

The client terminal 103 generates a request for causing the cooperation source BC to execute a transaction (step S801). Specifically, the transaction request unit 191 generates a request. The request contains a signature for the collaborating BC.

Next, the client terminal 103 identifies a program to be called when executing a transaction corresponding to the generated request (step S802), and the identified program includes a program for inter-BC cooperation. It is determined whether or not (step S803).

Specifically, the cooperation management unit 193 executes the same processing as steps S702 and S703.

If it is determined that the identified programs do not include a program for inter-BC cooperation, the client terminal 103 transmits the generated request to the computer 101 belonging to the cooperation source BC (step S804). After that, the client terminal 103 ends the processing.

When it is determined that the specified program includes a program that performs inter-BC cooperation, the client terminal 103 generates a hash based on the data of the request to be sent to the cooperation destination BC, and uses the hash A signature is generated using the key for the partner BC (step S805).

Next, the client terminal 103 transmits a request including the signature for the collaboration source BC and the signature for the collaboration destination BC to the computer 101 belonging to the collaboration source BC (step S806). After that, the client terminal 103 ends the processing.

When the processing shown in FIG. 8 is executed, the computer 101 belonging to the cooperation source BC executes the processing from step S701 to step S706 and the processing of steps S708 and S709. There is no particular change in the processing executed by the computer 101 belonging to the cooperation destination BC.

According to the modified example of the first embodiment, the client terminal 103 can reduce interaction with the computers 101 and 102 belonging to the BC by determining in advance whether or not a signature for the cooperation destination BC is required.

The above is the description of the modification.

Next, Example 2 of the present invention will be described. In the second embodiment, in inter-BC cooperation, it is possible to prevent state inconsistency such that only one BC's ledger is updated and other BC's ledgers are not updated.

Specifically, the computer belonging to the cooperation destination BC waits for the transaction requested by the computer belonging to the cooperation source BC instead of immediately executing it, and then accepts the waiting transaction request from the client terminal 103 again. If so, execute the transaction. The second embodiment will be described below, focusing on the differences from the first embodiment.

The configuration of the computer system of the second embodiment is the same as that of the first embodiment. The hardware configuration and software configuration of the computers 101 and 102 belonging to the BC of the second embodiment are the same as those of the first embodiment. Also, the hardware configuration and software configuration of the client terminal 103 of the second embodiment are the same as those of the first embodiment.

In the inter-BC cooperation processing of the second embodiment, the processing related to whether or not a signature is required, which is executed by the computer belonging to the cooperation source BC, is the same as that of the first embodiment. However, in the second embodiment, a computer belonging to the cooperation source BC executes processing different from that in the first embodiment. In the second embodiment, the processes executed by the computers belonging to the cooperation destination BC are different. Also, in the second embodiment, the client terminal 103 executes processing different from that in the first embodiment.

9A, 9B, 9C, and 9D are flowcharts illustrating an example of inter-BC cooperation processing executed in the computer system of the second embodiment. Here, the BC to which the computer 101 belongs is assumed to be the cooperation source BC, and the BC to which the computer 102 belongs is assumed to be the cooperation destination BC.

<Processing of Computers Belonging to Collaborating Source BC>
9A and 9B are flowcharts showing an example of processing executed by the computer 101 belonging to the cooperation source BC.

The processing from step S701 to step S707 and step S709 is the same as in the first embodiment.

After the process of step S707, the computer 101 receives a response from the computer 102 belonging to the cooperation destination BC (step S901).

The computer 101 determines whether or not the cooperation is successful based on the verification result included in the response (step S902). If the verification result indicates verification success, the computer 101 determines that the cooperation has succeeded.

If it is determined that the cooperation has failed, the computer 101 transmits a response indicating that the cooperation has failed to the client terminal 103 (step S903), and terminates the process.

If it is determined that the cooperation has succeeded, the computer 101 executes the transaction (S904) and determines whether the transaction has succeeded (step S905).

In executing a transaction, the computer 101 executes processing such as updating or referencing the ledger 141 . For example, the computer 101 adds the commercial transaction information corresponding to the processing in the cooperation source BC to the ledger 141 upon receiving successful verification of payment processing in the cooperation destination BC.

If it is determined that the transaction has succeeded, the computer 101 transmits to the client terminal 103 a response indicating the success of the transaction together with the identification information of the transaction corresponding to the request and the destination information of the computer 102 belonging to the cooperation destination BC ( step S906). After that, the computer 101 terminates the processing.

The transaction identification information included in the response sent to the client terminal 103 is the identification information (tx_ID 408) managed by the computer 101 side.

If it is determined that the transaction has failed, the computer 101 transmits a response indicating failure of the request to the client terminal 103 (step S907), and terminates the process. In this case, the cooperation destination BC does not execute the transaction and deletes the request after the execution time limit has passed.

<Processing of computer belonging to cooperation destination BC>
FIG. 9C is a flowchart showing an example of processing executed when the computer 102 belonging to the cooperation destination BC receives a request from the computer 101 belonging to the cooperation source BC.

The computer 102 receives a request including a signature for the collaboration destination BC from the computer 101 belonging to the collaboration source BC (step S721).

At this time, the computer 102 updates the state management information 162 . Specifically, the computer 102 adds an entry to the state management information 162, sets the tx_ID 601 of the added entry to the identification information of the collaboration destination BC, and sets the external tx_ID 604 to the identification information included in the request. The computer 102 sets the status 603 of the added entry to "standby". Also, the computer 102 sets the values included in the request to the subject 602 and execution deadline 607 of the added entry.

For example, it can be seen that the transaction with the tx_ID 601 of "dk34kfa" is on standby and is associated with the transaction with the identification information of the cooperation source BC of "AAA1".

Next, computer 102 verifies the legitimacy of the received request based on the signature for cooperation destination BC and the content of the request (step S722).

The computer 102 determines whether the verification is successful based on the verification result (step S723).

If it is determined that the verification has succeeded, the computer 102 puts the transaction on standby and transmits a response including the verification result and the like to the computer 101 belonging to the cooperation source BC (step S911). After that, the computer 102 proceeds to step S913.

If it is determined that the verification has failed, the computer 102 does not execute the transaction, and transmits a response including an execution result indicating verification failure or the like to the computer 101 belonging to the cooperation source BC (step S912). After that, the computer 102 proceeds to step S913.

In step S913, the computer 102 receives a request corresponding to the pending transaction from the client terminal 103 (step S913). The request includes transaction identification information (tx_ID 408) on the collaborating BC side. Computer 102 can identify the transaction to be executed by searching for an entry whose external tx_ID 604 matches the transaction identification information included in the request.

The computer 102 verifies the validity of the received request based on the signature etc. included in the received request (step S914).

The computer 102 determines whether the verification is successful based on the verification result (step S915).

If it is determined that the verification has failed, the computer 102 does not accept the request and terminates the process.

If the verification is determined to be successful, computer 102 executes the transaction (step S916) and ends the process. In addition, in the second embodiment, it is assumed that the request is always transmitted from the valid client terminal 103 . Therefore, inconsistencies in the state of the ledger do not occur.

At this time, the computer 102 updates the state management information 162 . Specifically, the computer 102 updates the state 603 of the entry corresponding to the transaction to be executed to “executing” and sets the start time 605 to the time. When the transaction is completed, the computer 102 sets the entry status 603 to "completed" and sets the end time 606 to the time.

<Processing of Client Terminal 103>
FIG. 9D is a flowchart showing an example of processing executed when the client terminal 103 receives a response from the computer 101 belonging to the cooperation source BC.

The client terminal 103 receives a response from the computer 101 belonging to the cooperation source BC (step S921).

The client terminal 103 determines whether or not the received response indicates successful cooperation (step S922).

If it is determined that the received response does not indicate successful cooperation, the client terminal 103 terminates the process. The received response is one of a response indicating cooperation failure, a response indicating transaction success, and a response indicating transaction failure.

If the received response is determined to be a response indicating successful collaboration, the client terminal 103 transmits a transaction request including transaction identification information included in the response to the computer 102 belonging to the collaboration destination BC (step S923), and then the process ends.

According to the second embodiment, it is possible to prevent inconsistency of ledger states in cooperation between BCs.

Next, Example 3 of the present invention will be described. In the first embodiment, processing related to authentication of the client terminal 103 requesting cooperation is mainly executed. In the third embodiment, when a transaction result is transmitted from a computer belonging to a cooperation destination BC to a computer belonging to a cooperation source BC, it is possible to prevent information unrelated to the cooperation source BC from being mistakenly transmitted.

Specifically, the computer belonging to the cooperation destination BC controls the content of the response in addition to verifying the content of the request for cooperation. The third embodiment will be described below, focusing on the differences from the first embodiment.

The configuration of the computer system of the third embodiment is the same as that of the first embodiment. The hardware configuration and software configuration of the computers 101 and 102 belonging to the BC of the third embodiment are the same as those of the first embodiment. Also, the hardware configuration and software configuration of the client terminal 103 of the third embodiment are the same as those of the first embodiment.

In the inter-BC cooperation processing of the third embodiment, the processing regarding whether or not a signature is required, which is executed by the computer belonging to the cooperation source BC, is the same as that of the first embodiment. However, in step S707, the computer belonging to the collaborating source BC transmits the request together with the signature and the identification information of the collaborating source BC. In Example 3, the processing executed by the computers belonging to the cooperation destination BC is different.

<Processing of computer belonging to cooperation destination BC>
FIG. 10 is a flowchart showing an example of processing executed when the computer 102 belonging to the cooperation destination BC according to the third embodiment receives a request from the computer 101 belonging to the cooperation source BC.

The processing from step S721 to step S725 is the same as in the first embodiment.

If it is determined in step S723 that the verification has succeeded, the computer 102 uses the identification information of the collaborating BC and the identification information of the client terminal 103 such as the signature of the client terminal 103 to become the transmission destination of the execution result of the transaction. The validity of BC is verified (step S1001). As for the identification information of the collaborating BC, for example, there is a method of using identification information issued/signed to each BC by a certification authority such as the BC certification authority server 104, or a value determined in advance between each BC. Conceivable.

For example, the computer 102 determines whether or not the BC_ID 416 of the ledger 171 matches the BC identification information included in the request. If the BC_ID 416 of the ledger 171 matches the BC identification information included in the request, it is determined that the verification has succeeded.

The computer 102 determines whether the verification is successful based on the verification result (step S1002).

If the verification is determined to be successful, computer 102 proceeds to step S724. If it is determined that the verification has failed, computer 102 proceeds to step S725.

For example, in the case of transaction data whose ID 411 in FIG. 4B is "1", BC_ID 416 is "BC1". If the identification information of the BC sent together with the request from the computer belonging to the collaborating BC is "BC1", the verification is successful, and the transaction data is permitted to be provided to the collaborating BC. On the other hand, if the BC identification information included in the request sent from the computer belonging to the cooperating BC is not "BC1", the verification fails and the transaction data is not permitted to be provided to the cooperating BC.

According to the third embodiment, when a transaction result is transmitted from a computer belonging to a collaboration destination BC to a computer belonging to a collaboration source BC, erroneous transmission of information unrelated to the collaboration source BC can be prevented.

In addition, the present invention is not limited to the above-described embodiments, and includes various modifications. Further, for example, the above-described embodiments are detailed descriptions of the configurations for easy understanding of the present invention, and are not necessarily limited to those having all the described configurations. Moreover, it is possible to add, delete, or replace a part of the configuration of each embodiment with another configuration.

Further, each of the above configurations, functions, processing units, processing means, and the like may be realized by hardware, for example, by designing them in an integrated circuit. The present invention can also be implemented by software program code that implements the functions of the embodiments. In this case, a computer is provided with a storage medium recording the program code, and a processor included in the computer reads the program code stored in the storage medium. In this case, the program code itself read from the storage medium implements the functions of the above-described embodiments, and the program code itself and the storage medium storing it constitute the present invention. Examples of storage media for supplying such program code include flexible disks, CD-ROMs, DVD-ROMs, hard disks, SSDs (Solid State Drives), optical disks, magneto-optical disks, CD-Rs, magnetic tapes, A nonvolatile memory card, ROM, or the like is used.

Also, the program code that implements the functions described in this embodiment can be implemented in a wide range of programs or scripting languages, such as assembler, C/C++, perl, Shell, PHP, Python, and Java (registered trademark).

Furthermore, by distributing the program code of the software that realizes the functions of the embodiment via a network, it can be stored in storage means such as a hard disk or memory of a computer or in a storage medium such as a CD-RW or CD-R. Alternatively, a processor provided in the computer may read and execute the program code stored in the storage means or the storage medium.

In the above-described embodiments, the control lines and information lines indicate those considered necessary for explanation, and not all control lines and information lines are necessarily indicated on the product. All configurations may be interconnected.

101, 102 computer 103 client terminal 104 BC certification authority server 105 network 111, 181 CPU
112, 182 interface
113, 183 memory 114 HDD
121, 151 Collaborating Units 122, 152 Transaction Management Units 123, 153 Consensus Building Units 124, 154 Authentication Unit 131 Program Management Information 132 Collaboration Destination Information 141, 171 Ledger 161 Cooperation Control Information 162 State Management Information 191 Transaction Request Unit 192 Signature Generation Unit 193 Coordination Management Department

Claims (12)

A computer system comprising a plurality of computers forming a blockchain,
The plurality of computers includes a plurality of computers forming a first block chain and a plurality of computers forming a second block chain,
The plurality of computers that constitute the first blockchain,
Upon receiving a request to execute a transaction that includes a signature for the first blockchain, performing a first verification process using the signature for the first blockchain;
if the result of the first verification process is verification success, determining whether the request is a request to execute a transaction related to the second blockchain;
If the request is determined to be a request to perform a transaction associated with the second blockchain, determine whether the request includes a signature for the second blockchain;
A computer system, wherein when the request is determined to include the signature for the second blockchain, the request is transmitted to a plurality of computers forming the second blockchain. A computer system according to claim 1,
When it is determined that the request does not include the signature for the second blockchain, the plurality of computers configuring the first blockchain add the signature for the second blockchain to the source of the request. Send a request to resend the request instructing the generation,
The plurality of computers that make up the second blockchain,
When the request is received from a plurality of computers constituting the first blockchain, performing a second verification process of verifying the validity of the request using a signature for the second blockchain included in the request,
A computer system, wherein a transaction corresponding to the request is executed when the result of the second verification process is verification success. A computer system according to claim 2,
In the second verification process, the plurality of computers constituting the second blockchain verify that the signature for the second blockchain is valid and that the user who is the subject of the transaction in the request and the second blockchain A computer system characterized by determining that verification is successful if the user who has signed for the certificate matches the user. A computer system according to claim 2,
When it is determined that the request includes the signature for the second blockchain, the plurality of computers that configure the first blockchain provide the plurality of computers that configure the second blockchain with the signature for the first blockchain. sending said request with identifying information;
The plurality of computers that make up the second blockchain,
If the result of the second verification process is verification success, the identification information of the first blockchain transmitted together with the request is used to verify the validity of the destination blockchain of the execution result of the transaction corresponding to the request. Execute a third verification process to verify the
A computer system, wherein a transaction corresponding to the request is executed when the result of the third verification process is verification success. A computer system according to claim 1,
The plurality of computers that make up the second blockchain,
executing a second verification process of verifying the validity of the request by using the signature for the second block chain included in the request when the request is received from a plurality of computers constituting the first blockchain; ,
If the result of the second verification process is verification success, transmitting a response including the result of the second verification process to a plurality of computers constituting the first blockchain;
The plurality of computers that constitute the first blockchain,
If the response is received, execute a transaction corresponding to the request;
When the execution of the transaction corresponding to the request is successful, by notifying the sender of the request of the success of the transaction, the sender of the request can send the request to the plurality of computers constituting the second blockchain. control to send,
A computer system, wherein the plurality of computers constituting the second block chain execute a transaction corresponding to the request when receiving the request from the source of the request. A computer system according to claim 1,
A plurality of computers forming the first block chain and a plurality of computers forming the second block chain process transactions corresponding to requests transmitted and received between the first block chain and the second block chain in their own blocks. A computer system that associates and manages identification information in a chain with identification information in other blockchains. A request processing method executed by a computer system having a plurality of computers forming a blockchain,
The plurality of computers includes a plurality of computers forming a first block chain and a plurality of computers forming a second block chain,
The request processing method includes:
When a plurality of computers constituting the first blockchain receive a request for executing a transaction including the signature for the first blockchain, first verification using the signature for the first blockchain a first step of performing a process;
If the result of the first verification process is successful, the plurality of computers configuring the first blockchain determine whether the request is a request for executing a transaction related to the second blockchain. a second step of determining
When the plurality of computers constituting the first blockchain determine that the request is a request for executing a transaction related to the second blockchain, the request is signed for the second blockchain. a third step of determining whether it contains
a plurality of computers configuring the first blockchain, when it is determined that the request includes a signature for the second blockchain, transmitting the request to a plurality of computers configuring the second blockchain; 4. A request processing method, comprising: The request processing method according to claim 7,
When the plurality of computers constituting the first blockchain determine that the request does not include the signature for the second blockchain, the sender of the request must include the signature for the second blockchain. a fifth step of sending a request to resend the request instructing generation;
When the plurality of computers configuring the second blockchain receive the request from the plurality of computers configuring the first blockchain, the signature for the second blockchain included in the request is used to send the request. a sixth step of performing a second verification process for verifying correctness;
and a seventh step of executing a transaction corresponding to the request by a plurality of computers constituting the second blockchain when the result of the second verification process is verification success. Processing method. The request processing method according to claim 8,
In the sixth step, a plurality of computers constituting the second blockchain are authenticated by a user whose signature for the second blockchain is valid and who is the subject of the transaction in the request and the second blockchain. A request processing method, comprising a step of determining that verification is successful if the user who signed the request matches the user who signed the request. The request processing method according to claim 8,
The fourth step includes a step in which the plurality of computers forming the first block chain transmit the request together with the identification information of the first block chain to the plurality of computers forming the second block chain. ,
The seventh step is
A plurality of computers constituting the second blockchain use the identification information of the first blockchain transmitted together with the request to verify the validity of the destination blockchain of the execution result of the transaction corresponding to the request. a step of performing a third verification process to verify;
A request processing method, comprising a step of executing a transaction corresponding to the request by a plurality of computers constituting the second blockchain when the result of the third verification process is verification success. The request processing method according to claim 7,
When the plurality of computers constituting the second blockchain receives the request from the plurality of computers constituting the first blockchain, the request is processed using the signature for the second blockchain included in the request. a step of performing a second verification process for verifying the correctness of
When the result of the second verification process is successful, the plurality of computers constituting the second blockchain send a response including the result of the second verification process to the plurality of computers constituting the first blockchain. and sending
a step of executing a transaction corresponding to the request when the plurality of computers constituting the first blockchain receives the response;
When the plurality of computers constituting the first blockchain succeed in executing the transaction corresponding to the request, the request sender notifies the request sender of the success of the transaction. a step of controlling to transmit the request to a plurality of computers constituting 2 blockchains;
A request processing method, comprising: when a plurality of computers constituting the second blockchain receive the request from the source of the request, executing a transaction corresponding to the request. The request processing method according to claim 7,
A plurality of computers forming the first block chain and a plurality of computers forming the second block chain process transactions corresponding to requests transmitted and received between the first block chain and the second block chain in their own blocks. A request processing method characterized by managing identification information in a chain and identification information in another blockchain in association with each other.

Images