Information processing device

Abstract

This information processing device is used in a configuration in which a transaction request from a user is processed in parallel in a blockchain network in which a plurality of shards are present. The information processing device comprises a communication unit that has a fixed address, is provided to each shard, and, in a shard that executes a transaction process desired by the user, receives the transaction request from the user.

Description

Information processing device

[0001] The present invention relates to a technology for executing transaction processing in a multi-shard environment that constitutes 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 (groups of nodes) and processing transactions on a shard-by-shard basis.

[0004] Tennakoon Deepal and Gramoli Vincent, "Dynamic Blockchain Sharding," 5th International Symposium on Foundations and Applications of Blockchain 2022 (FAB 2022), 2022. https: / / drops.dagstuhl.de / opus / volltexte / 2022 / 16273 Matsuura and Fujii, "Proposal of a Hierarchical Cross-Shard Transaction Management Method Using Smart Contracts," IEICE Technical Report, vol. 123, no. 397, NS2023-201, pp. 172-177, March 2024. "Danksharding," Ethereum. https: / / ethereum.org / en / roadmap / danksharding /

[0005] Regarding cross-shard transactions, which require the calling of smart contracts of multiple shards in one transaction, Non-Patent Document 2 discloses a technique for executing cross-shard transactions hierarchically by adding prepare and commit (accept, abort) arguments to a function.

[0006] However, since the node to which a shard belongs changes on an Epoch-by-Epoch basis, users must always know the IP address or other address of the node to which the shard belongs on an Epoch-by-Epoch basis. Also, when communicating between shards in a cross-shard transaction, the sender must know the node to which the shard belongs on an Epoch-by-Epoch basis before sending.

[0007] The present invention has been made in consideration of the above points, and aims to provide a technology that enables users or nodes to send information in a configuration where cross-shard transactions are performed without being aware of address changes on an Epoch-by-Epoch basis.

[0008] According to the disclosed technology, there is provided an information processing device used in a configuration for processing transaction requests from users in parallel in a blockchain network having a plurality of shards, the information processing device having a fixed address and provided in each shard, and comprising a communication unit that receives transaction requests from the user in the shard that executes the transaction processing desired by the user.

[0009] The disclosed technology provides a technology that enables users or nodes to send information in a configuration where cross-shard transactions are performed without being aware of address changes on an Epoch-by-Epoch basis.

[0010] FIG. 1 is a configuration diagram of a system according to an embodiment. FIG. 1 is a diagram illustrating a sharding framework on Ethereum (registered trademark). FIG. 2 is a diagram illustrating an example of shard creation in an admin node and an example of shard member replacement. FIG. 3 is a diagram illustrating an example of a cross-shard transaction in a conventional method. FIG. 4 is a diagram illustrating an example of an application of a transaction server (TS). FIG. 5 is a diagram illustrating an example of a smart contract function of a TS. FIG. 6 is a diagram illustrating an example of outbound adjacent node setting of a TS. FIG. 7 is a diagram illustrating an example of transaction synchronization between a TS and a validator node. FIG. 8 is a diagram illustrating an example of Danksharding application of a TS. FIG. 9 is a diagram illustrating an example of cooperation between layers 1 / 2 by a TS. FIG. 10 is a diagram illustrating an example of the functional configuration of an information processing device 10. FIG. 11 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] In addition, the following mainly describes issues related to Ethereum (registered trademark), which employs a shard structure, and how to solve them, but the application of the technology according to the present invention is not limited to this.

[0013] Furthermore, in this embodiment, the program executed by each node or transaction server 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 process by dividing many nodes into multiple shards (sets of nodes) and processing Tx (or blocks) in parallel for each shard. Note that Tx is an abbreviation for transaction. For the sake of convenience, the following explanation will mainly use "Tx."

[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 Txs of 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 Tx 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] An example of creating a shard by an admin node and replacing its member nodes is shown in Figure 3. Note that Figure 3 is based on Non-Patent Document 1.

[0025] The upper part of Figure 3 shows the set of admin nodes (15 admin nodes) of the beacon chain. The admin nodes assign validator nodes to each shard on an epoch-by-epoch basis. The admin nodes also manage the movement of validator nodes in each shard and notify each shard of the placement of validator nodes.

[0026] Epoch indicates the interval (for example, in seconds) at which shard members are replaced. In this way, the nodes to which each shard belongs change over time (Epoch).

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

[0028] Each shard 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, so each node can 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 Non-Patent Document 1, it is known that assigning shards to each application unit of DApps (Decentralized Applications) makes it more effective because it makes it less likely that cross-shard Tx will occur between shards.

[0031] However, how to deal with cross-shards, which require invoking smart contracts of multiple shards in one Tx, is an important issue. Below, we first explain a conventional method that addresses this issue (specifically, the technology disclosed in Non-Patent Document 2) and the issues with the conventional method, and then explain the technology related to this embodiment.

[0032] (Regarding Conventional Methods) Non-Patent Document 2 discloses a technique for executing cross-shard Tx hierarchically by adding arguments prepare and commit (accept, abort) to a function.

[0033] In the conventional method disclosed in Non-Patent Document 2, when a function of a smart contract distributed to a certain shard is called 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 a 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.

[0034] Two-phase commit is a method for ensuring atomicity in distributed Tx by dividing the commit process of Tx into two phases. In the Prepare phase, it is confirmed whether the state is ready for commit, and in the Commit phase, a commit instruction is issued.

[0035] 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.

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

[0037] The "smart contract function in the shard" that accepts Tx requests from users manages the two-phase commit of the smart contract function outside the shard (called the second function) that is called by that function (called the first function).

[0038] 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 changed by the execution of the second function, and if it determines that the processing of the second function (e.g., cross-shard Tx) is successful, it calls the same function (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.

[0039] If the first function determines that the processing of the second function (e.g., cross-shard Tx) has failed, it calls the same function (second function) in the Commit phase. In this case, the first function instructs the called node to roll back the Tx.

[0040] A function in a smart contract (called the second function) that is called using two-phase commit can recursively call functions in smart contracts in one or more other shards (called the third function) using two-phase commit. The return value of the recursively called third function is managed by the second function that called it.

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

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

[0043] In a function in recursive processing, if the cross-shard Tx processing is successful, an instruction is sent to all functions recursively called from that function to reflect the lock contents to the shard. Also, if the cross-shard Tx processing is unsuccessful in a function in recursive processing, an instruction is sent to all functions recursively called from that function to roll back the lock contents.

[0044] An example of the cross-shard Tx processing configuration in the conventional method is shown in Figure 4. When a user wants to receive a desired service, they simply call function_11 of smart contract (SC)_1 of Shard_1 corresponding to the desired service. There is no need to specify the shard involved in the Tx or its input. To obtain the three pieces of information required for the function, function_11 calls function_21 of SC_2, function_31 of SC_3, and function_41 of SC_4, and uses this information to provide the output to the user.

[0045] More specifically, for example, SC_1 in Figure 4 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. In that case, for example, SC_2 is a smart contract for booking an airline ticket, and function_21 is a function that checks whether an airline ticket can be reserved on the specified date and returns the result.

[0046] In this case, the shards are divided into Shard_5 and Shard_6 by airline, and function_51 in SC_5 and function_61 in SC_6 for each company check for available seats on the specified date. If there are available seats on both airlines, function_21 in SC_2 performs a comparison based on the conditions, reserves one of the flights, and returns it to function_11. SC_3 is a smart contract that manages events (concerts, etc.) at the user's desired travel destination; for example, 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; for example, function_41 is a function that reserves hotels for a specified date.

[0047] The important point about this processing configuration is that not only does the user not need to be aware of the shard configuration at all, but also because it performs a hierarchical two-phase commit (Prepare, Commit), each function can determine the success or failure of its Tx based solely on the return value from the function one level below.

[0048] For example, function_11 can check whether an airline reservation was made in the Prepare phase for function_21, whether a local event reservation was made in the Prepare phase for function_31, and whether a hotel reservation was made in the Prepare phase for function_41. In this case, function_21 determines which airline has better conditions using the airline reservation application systems of function_51 and function_61, and the airline is decided based on the judgment of function_21.

[0049] If any of the results of function_21, function_31, or function_41 result in a reservation not being possible, function_11 sends Commit(abort) to the three functions directly below in the Commit phase of the two-phase commit, and rolls back the contents (reservation contents) that were locked after receiving the Prepare phase request.Function_21 sends Commit(abort) to the airline function that made the reservation one level below, canceling the reservation.

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

[0051] In the configuration shown in Figure 4, a smart contract is deployed to each validator node in each shard. Therefore, one validator node determined by a PoS (Proof of State) or BFT consensus algorithm executes a function, and approval is achieved by propagating the Tx results executed within the shard to other validator nodes within the shard via a gossip protocol. Here, the cross-shard Tx processing already follows a two-phase commit processing order between each function in the smart contract. Furthermore, processing results of related shards are also sent and received at the function level, eliminating the need for communication via a gossip protocol between validator nodes in other shards. Therefore, the neighboring nodes of each validator node can be limited to nodes within its own shard, as shown in Non-Patent Document 2.

[0052] (Problems with Conventional Method) However, the conventional method shown in FIG. 4 has the following problems.

[0053] As mentioned above, the node to which a shard belongs changes on an Epoch-by-Epoch basis, so users must always know the IP address or other address of the node to which the shard belongs on an Epoch-by-Epoch basis. Also, when communicating between shards in cross-shard Tx, the sender must know the node to which the shard belongs on an Epoch-by-Epoch basis before transmitting.

[0054] For example, in Figure 4, when function_11 makes a cross-shard Tx request to function_21, the cross-shard Tx request must be made to a node belonging to shard_2 that can execute function_21 at that time.

[0055] In addition, a shard node that receives a cross-shard Tx request from another shard node must return the cross-shard Tx execution results to the shard node that made the cross-shard Tx request. However, if there are a large number of shards, many cross-shard Tx results will be received, and it will take time to select the necessary Tx result from the many Tx execution results received by the shard.

[0056] In addition, when determining whether the Tx requests / results it holds are the latest, each shard node can check with its neighboring nodes to see if they hold the same Tx requests / results. However, it is not always possible to confirm whether the Tx requests / results are accurate information, or it takes time to confirm this.

[0057] (Technology Related to an Embodiment of the Present Invention) In order to solve the above-mentioned problem, in this embodiment, a transaction server with a fixed address is provided for each shard, and Tx requests / results to each shard are managed. Hereinafter, the transaction server will be referred to as TS. TS is an abbreviation for Transaction Server. The transaction server may also be called a transaction server device.

[0058] In contrast to the example of the hierarchical cross-shard processing configuration shown in FIG. 4, an example of a system configuration with a TS for each shard is shown in FIG.

[0059] TS is fixed per shard and does not move between shards. Therefore, users and validator nodes can know where the desired TS is located regardless of the Epoch.

[0060] For example, each TS is configured for each shard before accepting the first Tx, and its IP address and name are registered in DNS. This allows all users and shard nodes to refer to the desired TS. In other words, each user and each smart contract function can obtain the IP address of the TS for each shard by accessing DNS.

[0061] In the example configuration shown in Figure 5, when the TS of Shard_1 receives a Tx request from a user, the TS forwards the Tx request to all shard nodes in the shard using the gossip protocol. As a result, one node belonging to Shard_1 executes function_11 in the prepare phase of function_11. The gossip protocol is an example of a predetermined communication protocol.

[0062] In addition, function_11 sends a Tx request to the TS of each shard that holds function_21, function_31, and function_41. These Tx requests are processed in the same way as the process in Shard_1 described above. That is, in each shard, the Tx request is propagated from the TS to the shard nodes within the same shard using the gossip protocol. As a result, each function is executed in the prepare phase by one node belonging to each shard.

[0063] Furthermore, function_21 sends a Tx request to the TS of each shard that holds function_51 and function_61. These Tx requests are processed in the same way as the processing in Shard_1 to Shard_4 described above. That is, in each shard, the Tx request is propagated from the TS to the shard node using the gossip protocol, and each function is executed in the prepare phase by one node belonging to each shard.

[0064] The Tx results (reservation results for airlines A / B) executed in function_51 and function_61 are sent to the TS of Shard_2 as shown by lines A and B in Figure 5. The TS of Shard_2 propagates these Tx results to nodes belonging to Shard_2 using the gossip protocol. Therefore, the node executing this cross-shard Tx can accept the results, determine which airline is more suitable for the user's request, and send a Commit (Abort) request to the inappropriate airline to cancel the Tx.

[0065] Function_21 determines the airline in the prepare phase, function_31 reserves the user-specified event ticket in the prepare phase, and function_41 reserves the hotel in the prepare phase. Each function then sends the results of its Tx processing to the TS of Shard_1. This transmission is shown by lines C, D, and E in Figure 5.

[0066] The TS of Shard_1 propagates these Tx results to each node of Shard_1 using the gossip protocol. As a result, the node executing function_11 of this cross-shard Tx accepts the result, and if all of functions_21, 31, and 41 are successful, it sends Commit(Accept) to each TS of Shard_2, Shard_3, and Shard_4. However, if a reservation cannot be made in any of the functions, it sends Commit(Abort) and rolls back the Tx. Function_11 also sends the cross-shard Tx result to the user.

[0067] (Regarding representative functions held by the TS smart contract) As described above, the TS plays the role of a gateway for fixing the destination of a Tx request. In this embodiment, the processing within the TS is performed by a smart contract function.

[0068] Figure 6 shows an example of a representative function held by a smart contract executed in a TS. As shown in Figure 6, representative functions held by a TS smart contract include a queue creation function, a Tx addition function, a Tx deletion function, and a Tx set acquisition function. The functions of each function are as follows:

[0069] The queue creation function allows the shard administrator to create a queue by specifying the queue name and queue ID. A queue with the specified name and ID is created. The Tx addition function adds a new Tx request / result to the queue by specifying the queue ID. This function is used when a user or smart contract makes a Tx request to another shard or sends a Tx result.

[0070] Each shard has one queue that accepts Tx requests. However, it is possible to set a queue that accepts Tx results for each shard. For example, the TS for Shard_1 can store the cross-shard Tx results sent to Shard_2, Shard_3, and Shard_4 in separate queues. These queues do not need to be physically separate, but within the TS, queue management is performed using arrays or other methods in memory so that processing can be done on a queue-by-queue basis.

[0071] In addition, Tx requests / results transferred from each TS to nodes in a shard using the gossip protocol can be sent from the TS along with information about which queue they arrived in. Therefore, each node can manage Tx requests / results by pairing them with the queue ID.

[0072] The Tx deletion function is configured by the shard administrator, sets the retention period (number of epochs, etc.) for Tx requests / results for each Tx queue, and deletes Tx requests / results that have passed that retention period from TS. This retention period is set uniformly for all Tx queues. However, it is also possible to specify a queue ID set as an argument to this function and apply the retention period only to queues included in that ID set.

[0073] The Tx set acquisition function is a function that each shard node calls to synchronize the Tx requests / results it holds with the latest Tx requests / results held by the TS. The Tx queue to be synchronized and the synchronization start Epoch can be specified as arguments to the Tx set acquisition function. In addition, since the TS holds a fixed IP address, all shard nodes can call the Tx set acquisition function by specifying the IP address of the TS.

[0074] (TS Outbound Adjacent Node Setting Example) An example of setting an outbound adjacent node of a TS in this embodiment will be described with reference to Fig. 7. Fig. 7 shows an example of setting an outbound adjacent node in a TS having a TS smart contract (TS_SC).

[0075] A TS designates nodes belonging to the same shard as itself as outbound neighboring nodes, and propagates Tx requests / results by sending the Tx requests / results that arrive in each queue to outbound neighboring nodes using a gossip protocol.

[0076] In the example shown in Figure 7, the ShardNodes Event, which is sent from the beacon chain to all shard participating nodes, is configured to be sent to each TS as well, and only nodes belonging to the IP address list of that ShardNodes Event are set as the TS's outbound neighboring nodes. By referencing the ShardNodes Event, each TS can determine the IP addresses of each node belonging to its own shard. Each TS can limit its outbound neighboring nodes to nodes belonging to its own shard.

[0077] The TS sets only the nodes that belong to the IP address list of its own shard, which is notified by the ShardNodes Event, as its outbound neighbor nodes. Therefore, as shown in Figure 7, outbound neighbor nodes are replaced at any time on an Epoch basis.

[0078] 7, an inside adjacent node refers to an adjacent node that belongs to the same region as the region to which the TS belongs, and an outside adjacent node refers to an adjacent node that belongs to a region different from the region to which the TS belongs. As shown in Non-Patent Document 2, the Tx propagation speed is faster when the number of outside adjacent nodes is smaller, so in the setting example shown in Fig. 7, out of a total of eight adjacent nodes, the upper limit of the number of inside adjacent nodes is set to 7, and the upper limit of the number of outside adjacent nodes is set to 1.

[0079] (Example of Synchronization) With reference to FIG. 8, an example of how the validator nodes in each shard synchronize with each Tx request / result receive queue of the shard TS will be described.

[0080] 8 shows an example of a TS on Shard_1 and one validator node on Shard_1. The TS smart contract is running on the TS.

[0081] The Tx requests / results received by the TS via the TS smart contract are stored in the queues shown in Figure 8. Specifically, in the example of Figure 8, the Tx requests are stored in the Tx request receiving queue, and the Tx results received from Shard_2, Shard_3, and Shard_4 are stored in their respective Tx result receiving queues.

[0082] As shown in Figure 8, the TS stores the received Tx request / result in a queue, and at the same time, it propagates the received Tx request / result along with the queue ID of the queue storing it to all validator nodes in the shard using the gossip protocol.

[0083] A validator node that receives each Tx request / result can store the Tx request / result in a queue within its own node that corresponds to the queue ID. That is, in the example of Figure 8, the validator node stores the Tx request in a Tx request receiving queue, and stores the Tx results received by the TS from each of Shard_2, Shard_3, and Shard_4 in their respective Tx result receiving queues.

[0084] Furthermore, due to traffic congestion within a shard, Tx requests / results may not be synchronized among all validator nodes when propagated via the gossip protocol. In such cases, if a validator node wishes to synchronize with the Tx requests / results held by the TS, it can use the Tx set acquisition function described with reference to Figure 6 to specify the queue ID and synchronization start Epoch and acquire the Tx requests / results of the specified queue after that Epoch. In this case, the validator node acquires the Tx requests / results by calling the function and specifying the IP address of the TS.

[0085] In the example of Fig. 8, each of the TS and validator node has only one queue for receiving Tx requests. However, this is just an example, and the system is not limited to having only one queue for receiving Tx requests. Multiple queues may be set depending on the request source, or queues may be divided depending on whether the request is a prepare request or a commit request.

[0086] (Example of Layer 2 rollup) In the Danksharding framework shown in Non-Patent Document 3, Layer 2 rollup, which does not exist on the main chain, performs Tx processing. In addition, the prover verifies the data and returns the results to the main chain, so that only data verification is performed on the main chain.

[0087] In the above framework, by allowing the rollup and prover to access the Tx set acquisition function, Tx processing can be performed by ZK (zero-knowledge) rollup in Layer 2, and when the prover verifies it, it can also use the latest Tx request / results from TS. In other words, TS can also be used to realize Danksharding. ZK rollup is a method of performing contract calculations and Tx execution off-chain. A more specific example is explained below.

[0088] (Example of application of TS to Danksharding) With reference to Figure 9, an example will be described in which hierarchical cross-shard Tx is applied to tour reservations using a TS with a fixed address for each shard, similar to the example in Figure 5. The processing flow is basically the same as that described with reference to Figure 5, with a function at a higher level in the hierarchy first calling the shard function immediately below it. When all reservation processing related to the tour (flight (A / B), event tickets, hotel) has been completed, the cross-shard shard is committed at the discretion of the function at the highest level. If any of the reservation processing cannot be completed, the cross-shard Tx is aborted. This type of processing makes it possible to maintain the atomicity of the cross-shard Tx.

[0089] In this embodiment, in each shard, the ZK rollup in layer 2 (a node in Layer 2 in FIG. 9) processes Tx requests received through the TS. The ZK rollup processes multiple Txs approved within the shard to which it belongs by rolling them up, and sends the results as a blob (Non-Patent Document 3) to the shard committee in layer 1 via the TS. For example, in Shard_1, the line indicated by A in FIG. 9 shows the transmission of the blob to the shard committee in layer 1.

[0090] In this embodiment, in which TS is applied to Danksharding, layer 1 only verifies the blob (processing results of multiple Tx), and the actual Tx processing of each shard is performed in layer 2. This reduces the load on layer 1. By using TS, it is possible to link layer 1 and layer 2, as shown in FIG. 9.

[0091] (Regarding the role of TS in Danksharding) Figure 10 shows the relationship between TS and the Layer 1 / 2 blockchain in Shard_1. Figure 10 also shows Tx synchronization between TS and Layer 2 nodes.

[0092] TS not only acts as a gateway for Tx between shards, but also acts as a gateway between Layer 2 and Layer 1 blockchains within the same shard.

[0093] First, for the ZK rollup of Layer 2 (Layer 2 node in Figure 10), a Tx request receiving queue and a Tx result receiving queue for each shard are provided as logical queues. In the example of Figure 10, a Tx request receiving queue and three Tx result receiving queues are provided in the Layer 2 node.

[0094] As in the examples described above, these queues are managed by the TS smart contract. Also, as shown by line A in Fig. 10, the TS propagates the Tx request / result information of each TS queue along with the queue ID to the layer 2 node using a gossip protocol.

[0095] The layer 2 node generates a blob, which is Tx aggregate information, based on the Tx information and transmits the blob to the TS as shown by line B in FIG.

[0096] Furthermore, as shown by line C in FIG. 10, if a layer 2 node wants the latest Tx information, it can specify a queue directly for the TS and synchronize with its own queue.

[0097] Since TS also maintains an adjacent relationship with the validator nodes in layer 1, it can propagate the blob to the validator nodes in layer 1 using the gossip protocol, as shown by line D in Figure 10. This allows each validator node to verify the Tx processing in layer 2 from the Tx aggregate information.

[0098] Furthermore, as shown by line E in FIG. 10, if necessary, a validator node can synchronize its own blob with the latest blob held by the TS on a queue-by-queue basis.

[0099] As described above, TS acts as a gateway between blockchains in different layers, and can provide Tx to Layer 2 on a queue-by-queue basis and provide a blob of Tx rollup information to Layer 1.

[0100] (Device Configuration Example) Fig. 11 shows a functional configuration example of an information processing device 10 functioning as a TS. The information processing device 10 has the TS functions described above. That is, in a blockchain network having multiple shards, the information processing device 10 is provided for each shard and has a fixed address.

[0101] 11, the information processing device 10 includes a communication unit 11, a management unit 12, and a data storage unit 13. The communication unit 11 transmits and receives Tx requests and Tx results. The data storage unit 13 has a data storage area used as a queue. The management unit 12 manages the queue.

[0102] It is assumed that the communication unit 11, management unit 12, and data storage unit 13 are realized by a smart contract executed by the information processing device 10, but this is not limited to this.

[0103] (Hardware Configuration Example) Any of the devices described in this embodiment (information processing device, TS, shard node, layer 2 node, layer 1 node, etc.) 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 a cloud.

[0104] 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.

[0105] Fig. 12 is a diagram showing an example of the hardware configuration of the computer. The computer in Fig. 12 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.

[0106] 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.

[0107] The memory device 1003 reads and stores a program from the auxiliary storage device 1002 when an instruction to start the program is received. The CPU 1004 realizes functions related to the device 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.

[0108] (Summary of the embodiment) As described above, the TS (herein referred to as a transaction server device) described in this embodiment has at least the following features 1 to 7. Note that the shard node may also be called a transaction management device.

[0109] <Feature 1> A transaction server device is a device used in a configuration (called a transaction processing system) in a blockchain network that divides smart contracts into multiple shards and processes transaction requests from users in parallel. A transaction server device has a fixed address and is installed in each shard. A user sends a transaction request to the transaction server device of the shard that executes the transaction processing. The transaction server device receives the transaction request.

[0110] <Feature 2> Feature 2 is premised on Feature 1. In each shard, a transaction server device processes cross-shard transaction requests from users across multiple shards. The transaction server device is equipped with a smart contract for accepting transaction requests. The transaction server device also uses the smart contract to manage a transaction request reception queue that receives transaction requests from users / other shards. Furthermore, the transaction server device manages a cross-shard transaction result reception queue for each shard that receives cross-shard transaction results from other shards.

[0111] <Feature 3> Feature 3 is based on Feature 2. The transaction server device propagates transaction requests received in a transaction request receiving queue from users / other shards, and transaction results processed by other shards received in each cross-shard transaction result receiving queue, to all shard nodes in the shard to which the transaction server device belongs, using a communication protocol such as a gossip protocol.

[0112] <Feature 4> Feature 4 is based on Feature 3. A shard node that receives a transaction request / result from a transaction server device stores the transaction request in a transaction request receiving queue within that node, and stores the transaction result from the shard in a transaction result receiving queue set for each shard.

[0113] <Feature 5> Feature 5 is based on Feature 4. A shard node can update the transaction requests / results in each of its queues by accessing the transaction server device of the shard to which it belongs, as needed.

[0114] <Feature 6> Feature 6 is based on Feature 5. When a shard node of a certain shard needs to send a cross-shard transaction request to another shard, it stores the cross-shard transaction request in the transaction request receiving queue of the transaction server device of the other shard via a smart contract of the transaction server device of the other shard.

[0115] <Feature 7> Feature 7 is based on Feature 6. A shard node that receives a cross-shard transaction request from another shard via a transaction request receiving queue invokes a smart contract of a transaction server device in the shard that originated the cross-shard transaction request, and requests that the transaction result be stored in the transaction result receiving queue of that shard.

[0116] (Effects of the Technology According to the Embodiments) The TS of each shard has a fixed address regardless of the Epoch. Therefore, users can recognize the destination address of a Tx request regardless of the Epoch. Also, in cross-shard Tx, when communicating between shards, all nodes can recognize the destination address.

[0117] In addition, TS stores Tx requests / results in different queues for each Tx request and Tx result for each shard, and sends the Tx requests / results to the validator node within the shard along with the Tx request / result queue ID. This allows each validator node to manage Tx requests / results for each queue, allowing for faster search results when referencing Tx requests / results in cross-shard Tx processing.

[0118] Furthermore, since the latest Tx requests / results for each shard are managed by TS, each validator can directly address and obtain the latest data, allowing each node to obtain accurate Tx requests / results within the shard.

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

[0120] <Additional Notes> (Additional Item 1) An information processing device used in a configuration for processing transaction requests from users in parallel in a blockchain network having a plurality of shards, wherein the information processing device has a fixed address and is provided in each shard, and comprises: a communication unit that receives the transaction request from the user in the shard that executes the transaction processing desired by the user. (Additional Item 2) The information processing device according to Additional Item 1, comprising: a management unit that manages a transaction request receiving queue that receives transaction requests from users or transaction requests from other shards different from the shard to which the information processing device belongs, and that manages a cross-shard transaction result receiving queue for receiving cross-shard transaction results from other shards for each other shard. (Additional Item 3) The information processing device according to Additional Item 2, wherein the communication unit propagates the transaction request received in the transaction request receiving queue and the cross-shard transaction result received in the cross-shard transaction result receiving queue to a node of the shard to which the information processing device belongs, using a predetermined communication protocol. (Supplementary Item 4) The information processing device according to Supplementary Item 3, wherein the communication unit receives a request to update the transaction request and the cross-shard transaction result from a node of a shard to which the information processing device belongs, and transmits the latest transaction request and the cross-shard transaction result to the node.

[0121] 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.

[0122] REFERENCE SIGNS LIST 10 Information processing device 11 Communication unit 12 Management unit 13 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 device used in a configuration that processes transaction requests from users in parallel in a blockchain network that has multiple shards, the information processing device having a fixed address and provided in each shard, and comprising a communication unit that receives transaction requests from the user in the shard that executes the transaction processing desired by the user.

2. The information processing device according to claim 1, further comprising a management unit that manages a transaction request receiving queue that receives transaction requests from users or transaction requests from other shards other than the shard to which the information processing device belongs, and that manages a cross-shard transaction result receiving queue that receives cross-shard transaction results from other shards for each other shard.

3. The information processing device described in claim 2, wherein the communication unit propagates the transaction request received in the transaction request receiving queue and the cross-shard transaction result received in the cross-shard transaction result receiving queue to the node of the shard to which the information processing device belongs using a predetermined communication protocol.

4. The information processing device described in claim 3, wherein the communication unit receives a request to update the transaction request and the cross-shard transaction result from a node of the shard to which the information processing device belongs, and transmits the latest transaction request and the cross-shard transaction result to the node.

Images