Information processing method, information processing device, and program

Abstract

An information processing method executed by an information processing device which functions as a node belonging to a first group in a block chain network in which at least one group having at least one node exists and a process is carried out by group, wherein the information processing device executes a first function of a program in the first group so as to call a second function, which is a function of a program in a second group different from the first group, in a prepare phase or a commit phase of a two-phase commit, and receives execution results of the second function from the second group.

Description

Information processing method, information processing device, and program

[0001] The present invention relates to a technology for executing cross-shard transactions, which are transactions that span multiple shards that make up a blockchain network.

[0002] Blockchain is a database that stores data by generating encrypted data units called blocks and linking the blocks together like a chain. Blockchain technology is widely used as a platform for trading NFTs (Non-fungible Tokens) such as digital art, as typified by Ethereum (registered trademark).

[0003] In addition, in Ethereum (registered trademark), it is being considered to speed up processing by dividing many nodes into multiple shards (sets of nodes) and processing transactions on a shard-by-shard basis.

[0004] Mustafa Al-Bassam, Alberto Sonnino, Shehar Bano, Dave Hrycyszyn, and George Danezis, "Chainspace: A Sharded Smart Contracts Platform," Cornell University, Aug. 2017.

[0005] Non-Patent Document 1 discloses a technology called ChainSpace as a conventional technology for processing cross-shard transactions, which are transactions that span multiple shards. However, this conventional technology has the problem of increasing the processing load on the nodes that make up the blockchain.

[0006] The above issue is not limited to Ethereum (registered trademark), which uses a shard configuration, but can occur in any blockchain network in which multiple nodes are divided into groups and processing is performed for each group.

[0007] The present invention has been made in consideration of the above points, and aims to provide a technology for reducing the processing load on nodes involved in processing across multiple groups in a blockchain network in which multiple nodes are divided into groups and processing is performed for each group.

[0008] According to the disclosed technology, there is provided an information processing method executed by an information processing device that functions as a node belonging to a first group in a blockchain network in which there is one or more groups, each having one or more nodes, and processing is performed for each group, the information processing method comprising: executing a first function of a program in the first group, calling a second function, which is a function of a program in a second group different from the first group, in the preparation phase or the commit phase of a two-phase commit; and receiving the execution result of the second function from the second group.

[0009] According to the disclosed technology, in a blockchain network in which multiple nodes are divided into groups and processing is performed for each group, it is possible to reduce the processing load on nodes involved in processing across multiple groups.

[0010] FIG. 1 is a configuration diagram of a system according to the present embodiment. FIG. 2 is a diagram illustrating a sharding framework on Ethereum (registered trademark). FIG. 3 is a diagram illustrating an example of creating a shard in an admin node and an example of replacing shard members. FIG. 4 is a diagram for explaining an example of executing a cross-shard transaction in ChainSpace. FIG. 5 is a diagram illustrating a processing configuration of a cross-shard transaction in an embodiment. FIG. 6 is a diagram illustrating an example of a function of a cross-shard transaction. FIG. 7 is a diagram illustrating a configuration of a node 10 (information processing device). FIG. 8 is a diagram illustrating an example of the hardware configuration of a device.

[0011] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. The embodiment described below is merely an example, and the embodiment to which the present invention is applied is not limited to the following embodiment.

[0012] Furthermore, while the following mainly describes issues related to Ethereum (registered trademark), which employs a sharded structure, and how to solve them, the application of the technology according to the present invention is not limited to this. The technology according to the present invention can be applied to any blockchain network that divides nodes into groups and performs processing for each group.

[0013] Furthermore, in this embodiment, the program executed by each node is called a "smart contract," but the name of the program is not limited to "smart contract."

[0014] (Example of Overall System Configuration) Fig. 1 shows an example of the overall configuration of a system in this embodiment. As shown in Fig. 1, this system has a plurality of nodes provided on an IP network. Any two nodes can communicate with each other via the IP network. Note that in this embodiment, an IP network is used as the network, but a network other than an IP network may also be used.

[0015] Each node is a computer (which may be called an information processing device) with a communication function. The computer may be a physical machine or a virtual machine built on the cloud.

[0016] Each node manages a blockchain. In the technology according to this embodiment, the blockchain may be of any type, but the following description will be given using the Ethereum (registered trademark) blockchain as an example. Note that a node may also be called a "blockchain node." Also, as shown in FIG. 1, a network including multiple nodes may also be called a blockchain network.

[0017] (Regarding the Blockchain Assumed in the Present Embodiment) As mentioned above, a blockchain is a database that stores data by generating encrypted data units called blocks and linking the blocks like a chain. Blockchain technology is widely used as a platform for trading NFTs (Non-fungible Tokens) such as digital art, as typified by Ethereum (registered trademark).

[0018] In Ethereum (registered trademark), it is being considered to speed up each Tx processing by dividing many nodes into multiple shards (sets of nodes) and processing Tx (or blocks) in parallel for each shard.

[0019] The shard structure of Ethereum (registered trademark) is shown in Figure 2. Note that Figure 2 is based on the diagram found at "https: / / hashhub-research.com / articles / 2019-08-01-ethereum2-overview."

[0020] As shown in Figure 2, the blockchain (main chain) created when PoW (Proof of Work), which was used before PoS (Proof of Stake), was adopted, remains linked to the beacon chain. The beacon chain links to multiple shard chains and manages the shard blockchains.

[0021] Each shard runs its own blockchain, the shard chain. Shards propose blocks to the beacon chain, and the proposed blocks are incorporated into the beacon chain after being approved by the validation nodes in the admin nodes that manage the beacon chain.

[0022] In Figure 2, the State root associated with each block is the hash value of the Root value that summarizes all account states in a Merkle-Patricia tree after all transactions in that block have been executed. If the Tx of this block is tampered with, the value of the State root will change, so the State root is used to prevent tampering of each block.

[0023] The beacon chain is managed by admin nodes, which are a subset of blockchain nodes. The membership of validator nodes in each shard, which execute smart contracts and process / approve transactions from users, is decided by consensus among multiple admin nodes belonging to the beacon chain. In addition, the validator nodes belonging to each shard are periodically replaced at the discretion of the admin nodes to prevent malicious attacks such as Sybil attacks.

[0024] Figure 3 shows an example of creating a shard by an admin node and replacing its member nodes. Figure 3 is based on the reference 1 "Tennakoon Deepal and Gramoli Vincent, "Dynamic Blockchain Sharding", 5 th Based on "International Symposium on Foundations and Applications of Blockchain 2022 (FAB 2022), 2022. https: / / drops.dagstuhl.de / opus / volltexte / 2022 / 16273."

[0025] The left side of Figure 3 shows the set of admin nodes (25 admin nodes) of the beacon chain. The admin nodes manage the movement of validator nodes in each shard and notify each shard of the placement of validator nodes.

[0026] Epoch indicates the interval (in seconds) at which shard members are replaced. In this way, the nodes to which each shard belongs change over time (Epoch). In Figure 3, "Create" means initial placement, and "replace" means notification of new placement. Also, the circle in each shard indicates a validator node.

[0027] In the example shown in Figure 3, three shards are created in Epoch 1, and the admin node sets the number of node members in each shard to nine. In addition, nine nodes are randomly assigned to each shard as validator nodes from among the nodes that have expressed their desire to join the shard (nodes that have sent the Join function to the beacon chain's smart contract). These nodes are selected based on the consensus of the admin nodes.

[0028] Each node receives the shard tag in which it participates and a list of IP addresses of all nodes participating in that shard from the beacon chain smart contract, allowing each node to exchange Tx and blocks with other nodes belonging to its own shard.

[0029] Also, in Epoch 2 of Figure 3, there is a possibility that the participating nodes of each shard will change, so the nodes of each shard will receive a list of IP addresses of new member nodes from the beacon chain smart contract and will be able to exchange Tx and blocks with shard members by recognizing the new shard members.

[0030] As shown in Reference 1, it is known that assigning shards to each DApp (Decentralized Application) application unit makes it more effective because it reduces the occurrence of cross-shard transactions between shards.

[0031] However, how to deal with cross-shard transactions, where smart contracts on multiple shards must be invoked in a single transaction, is an important issue. The following explains the issue in more detail.

[0032] (Regarding the Issues) Non-Patent Document 1 discloses a smart contract platform using shards called ChainSpace. In cross-shards in ChainSpace, it is assumed that smart contracts of multiple shards are invoked by a transaction (T) requested by a single user. In this embodiment, "user" specifically refers to a user terminal (user's computer).

[0033] An example of cross-shard transaction processing in ChainSpace is shown with reference to Figure 4. Figure 4 shows an example where there is a user, Shard_1, Shard_2, and Shard_3.

[0034] In the example of Figure 4, after the user recognizes that Input_1 and Input_2, which are required as inputs in T, will be generated by the smart contracts Shard_1 and Shard_2, respectively, the user sends a Prepare(T) request to the validator node of Shard_1 and the validator node of Shard_2 (S1).

[0035] Each validator node broadcasts T to all validator nodes in the shard to which it belongs, and verifies the processing results (Input_1 / Input_2) of the smart contract in that shard using the BFT (Byzantine Fault-Tolerant) consensus algorithm (S2).

[0036] In addition, since it is necessary to verify the processing in the two shards related to the input of T, the processing results are exchanged between the validator nodes in the two shards, and it is confirmed whether the processing results of both shards are successful (S3).

[0037] In addition, the processing results of the smart contract within each shard are locked, preventing other users from accessing Input_1 and Input_2 (S4).

[0038] If the validator nodes of both shards confirm that the inputs have been generated successfully by the smart contracts of both shards, Shard_1 sends Input_1 to the validator node of Shard_3, and Shard_2 sends Input_2 to the validator node of Shard_3 (S5).

[0039] The validator node of Shard_3 uses the inputs sent from Shard_1 and Shard_2 to generate an output using the smart contract of that shard (Shard_3) (S6), verifies the processing result using the BFT algorithm, and then notifies the validators of Shard_1 and Shard_2 of the processing result.

[0040] Shard_1 and Shard_2 unlock Input_1 and Input_2, respectively, and notify the user that the transaction processing was successful (S7). Conversely, if any processing failure occurs in the processing of Shard_1 to Shard_3, the processing of Input_1 and Input_2 is rolled back and the user is notified that processing of T failed.

[0041] As described above, the ChainSpace method makes it possible to process cross-shard transactions. However, the ChainSpace process shown in Figure 4 has the following issues:

[0042] First, the user must identify all shards that are inputs to T and send a Prepare(T) request message to all of those shards. In addition, the user must specify the related shards in the message (specifying multiple input shards and the output shard).

[0043] Furthermore, validator nodes in each related shard must exchange processing results with validator nodes in other shards, which increases the load on each shard's validator node. Furthermore, since each validator node must transfer processing results within its own shard to other shards, it is not possible to limit neighboring nodes to its own shard. Therefore, as shown in Reference 2 (Matsuura, Fujii, "Proposal of a Method for Selecting Neighboring Nodes for Each Shard Participating Node in a Blockchain Network," IEICE Technical Report NS2023-13, 2023), the transfer process of transactions / blocks within its own shard also takes time.

[0044] (Technology According to the Present Embodiment) A technology according to the present embodiment for solving the above-mentioned problems will be described. In this embodiment, it is assumed that a configuration is used in which smart contracts are divided and assigned to multiple shards in a blockchain network, and transaction requests from users are processed in parallel by the multiple shards. An example of this configuration is the configuration described with reference to FIG. 2.

[0045] The following processing is performed when processing a request (request from a user) for a cross-shard transaction, which is a transaction that requires processing across multiple shards. Processing examples 1 to 6 are described below. Processing example 1 is the basic processing, and processing examples 2 to 6 are functions added to processing example 1. More specifically, processing examples 2 and onward describe the processing examples that are prerequisites. However, this is not limited to this, and processing examples 1 to 6 can be executed in any combination.

[0046] In the following explanation, for the sake of convenience, "a node (specifically, a computer) executes function A, causing the node to execute process A described in function A" may be expressed as "function A executes process A." Process A is, for example, a process of calling a function described in function A to another node.

[0047] <Processing Example 1> When a function of a smart contract distributed to a certain shard receives a call from a function of a smart contract in another shard different from the shard in question, a symbol indicating whether the call is in the prepare phase or the commit phase of two-phase commit is used as an argument to the function receiving the call. For example, the symbol indicating the prepare phase may be prepare. Also, the symbol indicating the commit phase may be accept or abort. The validator node that receives a call with this symbol attached can use this symbol to identify whether it should perform processing in the prepare phase or the commit phase.

[0048] Two-phase commit is a method for ensuring atomicity in distributed transactions by dividing the transaction commit process into two phases. In the prepare phase, it is confirmed whether the transaction is ready to commit, and in the commit phase, a commit instruction is issued.

[0049] When a function of a smart contract distributed to a shard is called in the prepare phase, the validator node of that shard executes the function and then locks the resulting data.

[0050] When the function is called in the Commit phase, if the function processing (e.g., cross-shard transaction processing) is successful, the validator node of the shard will reflect (confirm) the locked data within the shard. On the other hand, if the function processing fails, the validator node of the shard will roll back the locked intra-shard transaction (data within the shard) and return it to its original state.

[0051] <Processing Example 2> Processing Example 2 is based on Processing Example 1. In Processing Example 2, in a "smart contract function in a certain shard" that accepts two-phase commit, it is possible to set a deadline for replying to a call to the prepare phase from another shard as an argument to the function. Furthermore, the deadline can be specified in time units, such as seconds.

[0052] <Processing Example 3> Processing Example 3 is based on Processing Example 1 or 2. In Processing Example 3, a "smart contract function in a shard" that accepts a transaction request from a user manages two-phase commit of a smart contract function outside the shard (referred to as a second function) that is called by the function (referred to as a first function).

[0053] Specifically, when the first function calls the second function for the first time in the Prepare phase, it issues a Lock instruction to the data that will be changed by the execution of the second function, and if it determines that the processing of the second function (e.g., a cross-shard transaction) is successful, it calls the same function (the second function) again in the Commit phase. At that time, the first function instructs the called node to reflect the locked contents within the shard.

[0054] If the first function determines that the processing of the second function (e.g., a cross-shard transaction) has failed, it calls the same function (the second function) in the Commit phase, instructing the called node to roll back the transaction.

[0055] Furthermore, if a reply deadline can be set for the second function called in the prepare phase, the reply deadline may be set.

[0056] <Processing Example 4> Processing Example 4 is premised on Processing Example 3. In Processing Example 4, when a "smart contract function in a shard" that accepts a transaction request from a user (referred to as a first function) calls multiple smart contract functions (referred to as second functions) in other shards, the first function requests all of the second functions to execute the second functions and lock related data in the prepare phase.

[0057] If there is even one second function among all the second functions that did not execute successfully in the prepare phase, the first function requests the rollback of the locked data in the commit phase for all the second functions.Only when the first function detects that the execution in the prepare phase for all the second functions was successful, does the first function instruct all the second functions to reflect the locked data in the shards in the commit phase.

[0058] <Processing Example 5> Processing Example 5 is based on Processing Example 4. In Processing Example 5, a function (referred to as the second function) of a smart contract that is called by two-phase commit can recursively call functions (referred to as the third function) in smart contracts of one or more other shards by two-phase commit. The return value of the recursively called third function is managed by the second function that called it.

[0059] The recursively called second function / third function replies to the function in the smart contract of the shard that directly received the transaction request from the user with a return value indicating whether the prepare process under that function (under its own function) was successful or failed.

[0060] In addition, a request in the Commit phase from a smart contract function (called the first function) that directly receives a transaction request from a user is recursively forwarded from the second function to the third function.

[0061] If a function in a recursive process is successful in processing a cross-shard transaction, it sends an instruction to all functions it recursively calls to update the lock contents to the shards. If a function in a recursive process is unsuccessful in processing a cross-shard transaction, it sends an instruction to all functions it recursively calls to roll back the lock contents.

[0062] This allows for the atomicity of cross-shards to be realized hierarchically.

[0063] <Processing Example 6> Processing Example 6 is premised on Processing Example 5. In Processing Example 6, not only can "a function one layer below a smart contract function (called the first function) that directly receives a transaction request from a user send a two-phase commit request to another shard," but it is also possible for a function k (k>1) layers below the first function to send a two-phase commit request to a function in another shard.

[0064] This not only enables hierarchical invocation of smart contracts across shards in a cross-shard system at any level, but also enables the atomicity of the cross-shard system to be realized by the "smart contract function called directly by the user," which is the top of the hierarchy.

[0065] (Example) As a detailed example of the technology according to the present embodiment, an example will be described below. The system in this example (e.g., FIG. 1) basically employs the shard configuration described with reference to FIGS. 2 and 3.

[0066] FIG. 5 shows an example configuration for processing cross-shard transactions in this embodiment. In the example of FIG. 5, there are Shard_1 to Shard_6. Each shard consists of a set of validator nodes (nine nodes in the example of FIG. 5). FIG. 5 also shows an image of the smart contract (denoted as SC) executed by the validator nodes in each shard. Each smart contract has one or more functions. Note that the operation using the step numbers (S11, etc.) shown in FIG. 5 will be explained later.

[0067] In the configuration of Figure 5, a user simply calls "Function_11 of Smart Contract (SC)_1 of Shard_1" corresponding to the service they desire. When calling, the user does not need to specify the shard involved in the transaction or its input. In addition, a two-phase commit (prepare, commit) is performed when calling any of the functions.

[0068] Function_11 calls function_21 of SC_2, function_31 of SC_3, and function_41 of SC_4 to obtain the three pieces of information required by the function, and uses this information to provide output to the user.

[0069] As a specific example, we will explain a case where SC_1 is a smart contract for a tour company, and function_11 is a function that returns to the user whether the tour can be realized on the date specified by the user.

[0070] In this example, SC_2 is a smart contract for booking flights, and Function_21 is a function that checks whether a flight can be reserved on a specified date and returns the result. Also, assuming that shards are divided into Shard_5 and Shard_6 by airline, Function_51 in SC_5 for airline A and Function_61 in SC_6 for airline B are functions that check the availability of flights on a specified date for each airline.

[0071] If the result of checking the reservation against each airline's smart contract using function_21 is that there are seats available on both airlines, the validator node of Shard_2 will perform a conditional comparison using function_21 of SC_2, reserve one of the aircraft, and return the reservation details to function_11.

[0072] SC_3 is a smart contract that manages events (concerts, etc.) at the user's desired travel destination, and function_31 is a function that reserves tickets for a specified date. SC_4 is a smart contract that manages hotel reservations at the travel destination, and function_41 is a function that reserves hotels for a specified date.

[0073] Examples of important points in the above-mentioned configuration are that "users do not need to be aware of the shard configuration at all" and that "since a hierarchical two-phase commit (prepare, commit) is performed, each function (called the first function) can determine the success or failure of the transaction of the first function based solely on the return values ​​from each function one level below."

[0074] For example, function_11 checks whether the flight reservation was successful in the Prepare phase for function_21, whether the local event reservation was successful in the Prepare phase for function_31, and whether the hotel reservation was successful in the Prepare phase for function_41. Each function called in the Prepare phase locks its processing content (reservation content).

[0075] In the prepare phase for function_21, function_21 determines which airline has better conditions using the airline reservation application system of function_51 and the airline reservation application system of function_61, and decides on the airline based on that determination.

[0076] If any of the results of function_21, function_31, and function_41 result in a reservation not being possible, function_11 sends Commit(abort) in the Commit phase of the two-phase commit to the three functions (function_21, function_31, and function_41) directly one level below function_11, causing those three functions to roll back the contents (reservation contents) that had been locked since receiving the request in the Prepare phase. At this time, function_21 sends Commit(abort) to the function of the airline that made the reservation one level below, canceling the reservation.

[0077] Conversely to the above case, if function_21, function_31, and function_41 all return a reservation success message to function_11, function_11 will send Commit(accept) in the Commit phase of the two-phase commit to the three functions (function_21, function_31, function_41) directly one level below function_11, causing those three functions to confirm the contents (reservation contents) made in the Prepare phase and release the lock state of the reservation.

[0078] <Processing within a shard> In the configuration shown in Figure 5, a smart contract is deployed to each validator node in each shard. One validator node determined by the PoS (Proof of State) or BFT consensus algorithm executes a function and approves the transaction by broadcasting the results of the transaction to other validator nodes within the shard.

[0079] In this embodiment, the cross-shard transaction processing sequence is already determined between smart contract functions, and processing results of related shards are also transmitted and received at the function level. Therefore, in this embodiment, there is no need for a validator node of one shard to communicate with a validator node of another shard, as in ChainSpace described with reference to FIG. 4. Therefore, in this embodiment, the neighboring nodes of each validator node can be limited to nodes within its own shard, as shown in Reference 2, for example.

[0080] (Implementation Example) FIGS. 6 and 7 show examples of the implementation of the function_11 and the function_21 in the configuration example shown in FIG.

[0081] <Function_11> As shown in Figure 6, function_11 has function_21, function_31, and function_41. "Function_21 (tour schedule, processing time constraint, prepare)" means that the tour schedule and processing time constraint are specified and function_21 is called in the prepare phase. The same applies to other functions. The processing time deadline is an example of a processing time constraint.

[0082] That is, in the Prepare phase, Function_11 first calls Function_21, Function_31, and Function_41, which are one level below it in Figure 5, in the Prepare phase, in order to attempt to make a reservation for the date specified by the user. At this time, a processing time limit can be specified as an argument to the function, and when this limit expires, the reservation request made by that function is canceled. These processing time limits can be set differently for each called function, and the time unit (days, hours, minutes, seconds, etc.) can also be determined by the creator of SC_1.

[0083] In addition, function_11, which receives replies from "function_21, function_31, and function_41" one level below, can determine whether the reservation was successfully made by each function, and sends a message in the commit phase depending on the success or failure of the three functions.

[0084] That is, as shown in function_11 in FIG. 6 as "IF (all successful) THEN {...", if reservations are successfully made in all functions, function_11 issues an accept request in the Commit phase to "function_21, function_31, and function_41" one level below, instructing them to finalize the processing data (reservation data) that was locked in the Prepare phase. For example, function_21(accept) means that it issues an accept request to function_21 in the Commit phase. The same applies to function_31(accept) and function_41(accept).

[0085] In function_11 in FIG. 6, as shown by "IF (all accepts completed successfully) Return reservation details; / / Notify user of success", if it can be confirmed from the return value from the function one level lower that the accept requests for all functions were successful, function_11 notifies the user that the reservation was successfully made along with the reservation details.

[0086] In function_11 in Figure 6, as shown by "ELSE THEN {...", if the processing does not end normally in any of "function_21, function_31, function_41" one level below function_11 and a reservation cannot be made, function_11 calls these three functions with an abort request in the Commit phase, causes the three functions to roll back all locked reservation processing, and sends a reply to the user along with the reason why the reservation could not be made.

[0087] For example, function_21(abort) means that function_21 is called with an abort request in the Commit phase. The same applies to function_31(abort) and function_41(abort).

[0088] <Function_21> Next, we will explain function_21 shown in Fig. 7. As shown in Fig. 7 as "IF(prepare){...", when function_21 is called in the Prepare phase, it calls function_51 and function_61, which are one level lower in Fig. 5, in the Prepare phase, receives the presence or absence of reservations and conditions for each airline from those functions, and performs a comparison.

[0089] As a result, one of the airlines will be selected, and an abort request in the Commit phase will be sent to the function of the airline that was not selected, causing the reservation to be cancelled. This is shown in Figure 7 as "IF (select 51) function_61(abort) ELSE function_51(abort)".

[0090] 7, function_21 returns the reservation details of the determined airline to function_11. Also, although not shown in FIG. 7, if a reservation cannot be made with either airline, function_21 notifies function_11 that the reservation was not successful and the reason for it.

[0091] In Figure 7, as shown as "IF(commit:accept){....", when function_21 receives a call from function_11 with an accept request in the Commit phase, it issues an accept request to the function of the airline that made the reservation in the Commit phase to complete the reservation.

[0092] Also, as shown as "IF(commit: abort){....", if function_21 receives an abort request, it issues an abort request in the Commit phase to the function of the airline that made the reservation, causing the reservation to be rolled back.

[0093] (Operation Example) An operation example will be explained with reference to Figure 5. The validator node that executes the functions explained below is the validator node determined by the PoS (Proof of State) or BFT consensus algorithm in the relevant shard. The order of processing the functions below is an example. The following shows an example in which all reservations are successful. If any reservation fails, a rollback and failure notification will be performed as described above.

[0094] In S11, a user specifies the tour schedule and applies for a tour by calling function_11. In S12 to S14, the validator node of Shard_1 executes function_11 to call function_21 of SC_2, function_31 of SC_3, and function_41 of SC_4 in the Prepare phase.

[0095] In S15-S16, the validator node of Shard_2 executes function_21 to call function_51 of SC_5 and function_61 of SC_6 in the Prepare phase, respectively.

[0096] In S17, the validator node of Shard_5 executes the reservation process by executing function_51, and returns a response indicating that the reservation was successful to function_21 of the validator node of Shard_2.

[0097] In S18, the validator node of Shard_6 executes the reservation process by executing function_61, and returns a response indicating that the reservation was successful to function_21 of the validator node of Shard_2.

[0098] In S19, the validator node of Shard_2 determines the flight reservation details as processing by function_21, and returns the determined reservation details to function_11 of the validator node of Shard_1.

[0099] In S20, the validator node of Shard_3 determines the reservation details for the event as processing by function_31, and returns the determined reservation details to function_11 of the validator node of Shard_1.

[0100] In S21, the validator node of Shard_4 determines the hotel reservation details as processing by function_41, and returns the determined reservation details to function_11 of the validator node of Shard_1.

[0101] Next, in steps S22 to S24, the validator node of Shard_1 processes function_11 by issuing an accept request in the Commit phase to function_21, function_31, and function_41, instructing them to confirm the processing data (reserved data) that was locked in the Prepare phase.

[0102] In S25 or S26, the validator node of Shard_2 completes the reservation by issuing an accept request in the Commit phase to the function of the airline that made the reservation as processing of function_21.

[0103] In S27, the validator node of Shard_2 returns a response to the accept request for the airline reservation details to function_11 of the validator node of Shard_1 as processing by function_21.

[0104] In S28, the validator node of Shard_3 returns a response to the accept request regarding the event reservation details to function_11 of the validator node of Shard_1 as processing by function_31.

[0105] In S29, the validator node of Shard_4 returns a response to the accept request for the hotel reservation details to function_11 of the validator node of Shard_1 as processing by function_41.

[0106] In S30, the validator node of Shard_1 notifies the user of all reservation details as processing by function_11.

[0107] (Device Configuration Example) Fig. 8 shows an example of the functional configuration of the node 10. The node 10 may also be called an information processing device. The node 10 is one of multiple nodes that make up a blockchain network in which multiple nodes are divided into multiple shards and blocks are processed in parallel for each shard. The node corresponds to a validator node.

[0108] 8, the node 10 includes a communication unit 11, a management unit 12, an execution unit 13, and a data storage unit 14. The communication unit 11 communicates with other nodes (e.g., function calls, return value reception).

[0109] The management unit 12 performs processes related to the blockchain (block generation, Tx processing, event processing, etc.) and manages the blockchain. Processing by the management units 12 of multiple nodes realizes the blockchain configuration shown in FIG. 2, for example. The processing content of the management unit 12 itself is existing technology. The data that constitutes the blockchain is stored in the data storage unit 14. The data that constitutes the blockchain includes smart contracts.

[0110] The execution unit 13 executes a program (specifically, a smart contract) based on the two-phase commit described as a technology for solving the problem. The execution unit 13 can call a function to a shard other than the shard to which the node 10 belongs, and can also receive a function from another shard and execute the called function. The execution unit 13 calls a function to another shard and receives a return value via the communication unit 11.

[0111] For example, the execution unit 13 executes a first function of a smart contract in the shard to which the node 10 belongs, thereby calling a second function, which is a function of a smart contract in another shard, in the preparation phase or the commit phase of a two-phase commit, and receives the execution result of the second function from the other shard.

[0112] (Hardware Configuration Example) The nodes 10 (information processing devices) constituting the blockchain network described in this embodiment can be realized, for example, by causing a computer to execute a program. This computer may be a physical computer or a virtual machine on the cloud.

[0113] That is, the device can be realized by executing a program corresponding to the processing performed by the device using hardware resources such as a CPU and memory built into a computer. The program can be recorded on a computer-readable recording medium (such as a portable memory) and stored or distributed. The program can also be provided via a network such as the Internet or email.

[0114] Fig. 9 is a diagram showing an example of the hardware configuration of the computer. The computer in Fig. 9 includes a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, and the like, all of which are interconnected via a bus B. The computer may further include a GPU.

[0115] The program that realizes the processing on the computer is provided by a recording medium 1001, such as a CD-ROM or a memory card. When the recording medium 1001 storing the program is set in the drive device 1000, the program is installed from the recording medium 1001 to the auxiliary storage device 1002 via the drive device 1000. However, the program does not necessarily have to be installed from the recording medium 1001, but may be downloaded from another computer via a network. The auxiliary storage device 1002 stores the installed program as well as necessary files, data, etc.

[0116] The memory device 1003 reads and stores the program from the auxiliary storage device 1002 when an instruction to start the program is received. The CPU 1004 realizes functions related to the node 10 in accordance with the program stored in the memory device 1003. The interface device 1005 is used as an interface for connecting to a network, etc. The display device 1006 displays a GUI (Graphical User Interface) or the like according to the program. The input device 1007 is composed of a keyboard, mouse, buttons, a touch panel, etc., and is used to input various operation instructions. The output device 1008 outputs the results of calculations.

[0117] (Summary, Effects, etc. of the Embodiment) As described above, in the technology described in this embodiment, all cross-shard transaction processing is controlled by functions called by the user, so the user does not need to specify the relationship between shards in the Prepare function. This reduces the load on the user.

[0118] In addition, the function called by the user (called the first function) can receive success / failure notifications for all functions of other shards that it called "directly or indirectly." Therefore, the validator node of each shard does not need to exchange related processing information with the validator nodes of other shards, and can concentrate on function processing and evaluation within its own shard. This reduces the processing load on each validator node.

[0119] Furthermore, as mentioned above, since each shard's validator node does not need to exchange information with the validator nodes of other shards, neighboring nodes can be limited to the nodes of its own shard, which increases the propagation speed of transactions / blocks within the shard.

[0120] The following additional notes are provided regarding the above-described embodiments.

[0121] <Additional Notes> (Additional Item 1) In a blockchain network in which there is one or more groups, each having one or more nodes, and processing is performed for each group, an information processing method is executed by an information processing device that functions as a node belonging to a first group, the information processing method comprising: executing a first function of a program in the first group to call a second function, which is a function of a program in a second group different from the first group, in a preparation phase or a commit phase of a two-phase commit; and receiving an execution result of the second function from the second group. (Additional Item 2) The information processing method described in Additional Item 1, in which, when the second function is called in the preparation phase, data of the execution result of the second function is locked in a node that executes the second function in the second group. (Supplementary Item 3) When the second function is called in the commit phase, in the node that executes the second function in the second group, if the processing of the cross-shard transaction is successful, the locked data is committed, and if the processing of the cross-shard transaction fails, the locked data is rolled back and the state is returned to its original state. This is the information processing method described in Supplementary Item 2.

[0122] Note that "when the cross-shard transaction processing is successful" may be more specific, for example, "when all cross-shard transactions are successful and the first function requests a commit in ACCEPT mode." (Supplementary Item 4) The information processing method described in any one of Supplementary Items 1 to 3, in which, when calling the second function, the information processing device specifies a symbol indicating that the call is in the preparation phase or a symbol indicating that the call is in the commit phase as an argument of the second function. (Supplementary Item 5) The information processing method described in any one of Supplementary Items 1 to 4, in which, when calling the second function, the information processing device specifies a processing time limit as an argument of the second function. (Supplementary Item 6) In a blockchain network in which there is one or more groups, each having one or more nodes, and processing is performed for each group, an information processing device that functions as a node belonging to a first group, comprising: a memory; and at least one processor connected to the memory, wherein the processor executes a first function of a program in the first group, thereby calling a second function that is a function of a program in a second group different from the first group, in a preparation phase or a commit phase of a two-phase commit, and receiving a result of execution of the second function from the second group. (Supplementary Item 7) A non-transitory storage medium that stores a program for causing a computer to execute each process in the information processing method recited in any one of Supplementary Items 1 to 5.

[0123] Although the present embodiment has been described above, the present invention is not limited to such a specific embodiment, and various modifications and changes are possible within the scope of the gist of the present invention described in the claims.

[0124] REFERENCE SIGNS LIST 10 Node 11 Communication unit 12 Management unit 13 Execution unit 14 Data storage unit 1000 Drive device 1001 Recording medium 1002 Auxiliary storage device 1003 Memory device 1004 CPU 1005 Interface device 1006 Display device 1007 Input device 1008 Output device

Claims

1. An information processing method executed by an information processing device that functions as a node belonging to a first group in a blockchain network in which there is one or more groups, each having one or more nodes, and processing is performed for each group, the information processing method comprising: executing a first function of a program in the first group, calling a second function, which is a function of a program in a second group different from the first group, in the preparation phase or commit phase of a two-phase commit; and receiving a result of the execution of the second function from the second group.

2. The information processing method according to claim 1, wherein when the second function is called in the preparation phase, data resulting from the execution of the second function is locked in a node in the second group that executes the second function.

3. The information processing method of claim 2, wherein when the second function is called in the commit phase, in a node that executes the second function in the second group, if the cross-shard transaction is successfully processed, the locked data is committed, and if the cross-shard transaction is unsuccessful, the locked data is rolled back and the state is returned to its original state.

4. The information processing method according to claim 1, wherein when the information processing device calls the second function, the information processing device specifies a symbol indicating that the call is in the preparation phase or a symbol indicating that the call is in the commit phase as an argument of the second function.

5. The information processing method according to claim 1, wherein the information processing device specifies a processing time limit as an argument of the second function when calling the second function.

6. In a blockchain network in which there is one or more groups, each having one or more nodes, and processing is performed for each group, an information processing device that functions as a node belonging to a first group, comprising: an execution unit that executes a first function of a program in the first group, calls a second function, which is a function of a program in a second group different from the first group, in the preparation phase or commit phase of a two-phase commit, and receives the execution result of the second function from the second group.

7. A program for causing a computer to execute each process in the information processing method according to any one of claims 1 to 5.

Images