Information processing method, program, and information processing apparatus

Abstract

The present invention provides an information processing method, etc., that can suitably select meta-transactions that bear the fees. [Solution] The information processing method is a meta-transaction for trading digital tokens issued on a blockchain, wherein the sender obtains a signed meta-transaction, determines whether the conditions for bearing the fees necessary to execute the processing related to the meta-transaction are met based on the transfer history of the digital tokens or the transaction details of the digital tokens in the obtained meta-transaction, and if it is determined that the conditions for bearing the fees are met, the computer executes a process to store the data of the meta-transaction, generate a transaction to pay the fees to the verifier, and output the generated transaction to the blockchain network.

Description

Technical Field

[0001] The present invention relates to an information processing method, a program, and an information processing apparatus.

Background Art

[0002] Non-Patent Document 1 discloses a technique for changing the bearer of a fee (so-called gas fee) that occurs when processing data in a blockchain, called a meta transaction.

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In one aspect, an object is to provide an information processing method or the like that can suitably select a meta transaction that bears a fee.

Means for Solving the Problems

[0005] The information processing method is a meta-transaction for trading digital tokens issued on a blockchain, in which a computer obtains a meta-transaction signed by the sender, determines whether the conditions for bearing the fees necessary to execute the processing related to the meta-transaction are met based on the transfer history of the digital tokens or the transaction details of the digital tokens in the obtained meta-transaction, and if it is determined that the conditions for bearing the fees are met, the computer executes a process to store the data of the meta-transaction, generate a transaction to pay the fees to the verifier, and output the generated transaction to the blockchain network. [Effects of the Invention]

[0006] In one respect, it allows for the selection of meta-transactions that bear the fees. [Brief explanation of the drawing]

[0007] [Figure 1] This is an explanatory diagram showing an example configuration of a gas bill reimbursement system. [Figure 2] This is a block diagram showing an example server configuration. [Figure 3] This diagram shows an example of the record layout for the issuer database, user database, business database, and transfer history database. [Figure 4] This is a diagram illustrating the overview of Embodiment 1. [Figure 5] This is a table showing the conditions for bearing gas costs. [Figure 6] This diagram shows how metatransactions are processed in a blockchain network. [Figure 7] This flowchart shows an example of the processing steps performed by the server. [Figure 8] This is a diagram illustrating the overview of Embodiment 2. [Modes for carrying out the invention]

[0008] The present invention will be described in detail below with reference to the drawings illustrating its embodiments. (Embodiment 1) Figure 1 is an explanatory diagram showing an example configuration of a gas fee burden system. This embodiment describes a gas fee burden system in which the system operator bears the gas fees (transaction charges) incurred when trading NFTs (Non-Fungible Tokens) on the blockchain, provided that predetermined gas fee burden conditions are met. The gas fee burden system includes an information processing device 1, a blockchain network 2, a user terminal 3, a business terminal 4, and an explorer server 5. Each device is connected to the others via a network N such as the Internet.

[0009] In this embodiment, NFTs are used as an example of the token to be traded, but the target token can be any digital token issued on the blockchain, such as a fungible token.

[0010] Blockchain Network 2 is a network composed of numerous nodes (20, 20, 20...) that records the transfer history of digital tokens, including NFTs, on the blockchain. Each node (20) functions as a miner that verifies digital token transactions, and records the transaction on the blockchain if it is deemed legitimate. Miners are paid gas fees as a reward for their verification work.

[0011] User terminal 3 is a terminal device used by users of this system, such as a personal computer, smartphone, or tablet. In this embodiment, as an example of a use case for the gas bill reimbursement system, we will describe a case in which NFTs are distributed to users as coupons that can be used for a designated business (e.g., a restaurant). The business distributes NFTs to users (customers), and the user can receive a designated service (e.g., a discount on product prices) by using the NFT (sending it to the business's wallet address). When using NFTs in this way, normally the user who sends the NFT would have to bear the gas bill, but in this system, the system operator bears the gas bill.

[0012] The service provider terminal 4 is a terminal device of the service provider that provides the coupon distribution service, such as a personal computer, smartphone, or tablet device. As described below, the service provider receives an NFT from the user when the coupon is used, and after use, destroys (burns) the NFT (coupon) to make it unusable.

[0013] Information processing device 1 is an information processing device capable of various information processing and information transmission and reception, such as a server computer or a personal computer. In this embodiment, information processing device 1 is assumed to be a server computer, and for simplicity, it will be read as server 1 below. Server 1 functions as a relayer that bears the gas fee on behalf of the NFT sender using the metatransaction technology described in Non-Patent Literature 1. Specifically, server 1 receives a metatransaction for trading an NFT from the sender and determines whether the predetermined gas fee bearing conditions are met. If it is determined that the bearing conditions are met, server 1 stores the metatransaction data, generates a legitimate transaction (the first transaction described later) that pays the gas fee to the miner (verifier), and outputs it to the blockchain network 2.

[0014] The explorer server 5 is a server computer that provides an explorer service for outputting NFT transaction information (transfer history). The explorer server 5 collects the transaction information of each NFT and stores it in the transfer history DB 501. When determining whether the gas fee burden condition is satisfied, the server 1 acquires the transfer history of the NFT from the explorer server 5. The server 1 determines whether the burden condition is satisfied based on the transfer history acquired from the explorer server 5.

[0015] Figure 2 is a block diagram showing a configuration example of the server 1. The server 1 includes a control unit 11, a main memory unit 12, a communication unit 13, and an auxiliary storage unit 14. The control unit 11 is a processor such as one or more CPUs (Central Processing Units), MPUs (Micro-Processing Units), GPUs (Graphics Processing Units), etc. By reading and executing the program P stored in the auxiliary storage unit 14, it performs various information processes. The main memory unit 12 is a temporary storage area such as SRAM (Static Random Access Memory), DRAM (Dynamic Random Access Memory), etc., and temporarily stores the data necessary for the control unit 11 to execute arithmetic processing. The communication unit 13 is a communication module for performing communication-related processes, and transmits and receives information to and from the outside.

[0016] The auxiliary storage unit 14 is a non-volatile storage area such as a hard disk, a large-capacity memory, etc., and stores the program P (program product) and other data necessary for the control unit 11 to execute processing. In addition, the auxiliary storage unit 14 stores an issuer DB 141, a user DB 142, and a merchant DB 143. The issuer DB 141 is a database that stores information (wallet address) of the issuer of the NFT. The user DB 142 is a database that stores information (wallet address) of each user. The merchant DB 143 is a database that stores information (wallet address) of each merchant.

[0017] Note that the auxiliary storage unit 14 may be an external storage device connected to the server 1. Also, the server 1 may be a multi-computer composed of a plurality of computers, or may be a virtual machine virtually constructed by software.

[0018] Also, in this embodiment, the server 1 is not limited to the above configuration. For example, it may include an input unit for receiving operation inputs, a display unit for displaying images, etc. Also, the server 1 may be provided with a reading unit for reading a portable storage medium 1a such as a CD (Compact Disk)-ROM or a DVD (Digital Versatile Disc)-ROM, and may read and execute the program P from the portable storage medium 1a.

[0019] FIG. 3 is a diagram showing an example of the record layout of the issuer DB 141, user DB 142, operator DB 143, and transfer history DB 501.

[0020] The issuer DB 141 includes an issuer name column and an address column. The issuer name column stores the names of the issuers registered as the legitimate issuers of NFTs in this system. The address column stores the wallet addresses of the issuers in association with the issuer names.

[0021] Note that the issuer of NFTs may be the same as the operator who provides the coupon distribution service to users, or may be different.

[0022] The user DB 142 includes a user name column and an address column. The user name column stores the user names. The address column stores the wallet addresses of the users in association with the user names.

[0023] The operator DB 143 includes an operator name column and an address column. The operator name column stores the operator names. The address column stores the wallet addresses of the operators in association with the operator names.

[0024] The transfer history DB501 includes columns for date and time, contract address, token ID, sender address, recipient address, and method. The date and time column stores the date and time of the NFT transaction. The contract address, token ID, sender address, recipient address, and method columns each store, in association with the transaction date and time, the contract address of the smart contract called for the NFT transaction, the NFT token ID, the NFT sender's wallet address, the recipient's wallet address, and the function (method) called for the NFT transaction.

[0025] Figure 4 is a diagram illustrating the overview of Embodiment 1. Figure 4 conceptually illustrates the process of transferring NFTα from wallet address A to wallet address B. Based on Figure 4, the overview of this embodiment will be explained.

[0026] As described above, Server 1 functions as a relayer for metatransactions and bears the gas charges that the NFT sender (user or business operator) should pay. First, Server 1, as a relayer, generates a metatransaction in response to a request from the NFT sender (user terminal 3 or business operator terminal 4) and sends (outputs) it to the sender.

[0027] Note that the metatransaction may be generated by the sender (user terminal 3 or carrier terminal 4) rather than the relayer (server 1).

[0028] A metatransaction is a pseudo-transaction that describes the details of an NFT transaction (in Figure 4, this is data indicating the transfer of ownership of NFTα from wallet address A to wallet address B). A metatransaction includes the wallet address of the sender of the metatransaction (from), the contract address of the management contract to which the metatransaction will be sent (to), the amount of cryptocurrency to be sent to the management contract set as the recipient (value, which can be 0), the gas fee required to execute the management contract set as the recipient (gas), the expiration date of the metatransaction (deadline), and the call data for the function executed in the management contract set as the recipient (data, in Figure 4, this is data indicating the transfer of NFTα from wallet address A to wallet address B).

[0029] The sender digitally signs the metatransaction using their private key. Specifically, the sender takes the hash value of the metatransaction data and digitally signs that hash value with their private key. The sender then sends the digitally signed metatransaction to Server 1.

[0030] When a signed metatransaction is obtained, Server 1 obtains the transfer history of the NFT to be traded (transferred) by the metatransaction. In this embodiment, Server 1 obtains the NFT transfer history using the Explorer service provided by Explorer Server 5. Based on the token ID of the NFT to be traded in the metatransaction, Server 1 requests Explorer Server 5 to output the transfer history. When the request for output of the transfer history is received, Explorer Server 5 outputs the NFT transfer history to Server 1. The transfer history is data that shows past transactions for the NFT and data that shows the history of the NFT holder (and their wallet address).

[0031] In this embodiment, Server 1 determines whether the following gas fee burden conditions are met, based on the NFT transfer history up to that point and / or the transaction details of the current NFT indicated by the metatransaction.

[0032] First, Server 1 identifies the wallet address of the NFT issuer (the original holder of the NFT) based on the NFT transfer history and determines whether the issuer is registered in the whitelist. In this embodiment, the issuer of the NFT to be subject to gas charges is registered in the issuer database 141, and gas charges are borne for NFTs issued by legitimate issuers registered in the issuer database 141. Server 1 determines whether the wallet address of the NFT issuer is registered in the issuer database 141.

[0033] Next, Server 1 determines, based on the NFT transfer history and the transaction details of the NFT indicated by the metatransaction, whether the wallet address of the current holder of the NFT matches the wallet address of the sender of the NFT indicated by the metatransaction. In other words, Server 1 determines whether the current holder of the NFT is the sender of the metatransaction.

[0034] Furthermore, Server 1 determines whether the transaction performed by the meta-transaction falls under any of the following actions (1) to (4) that are subject to gas charges. (1) Transfer of NFTs by a specific user up to the Xth time (2) Destruction of NFTs by the business operator (invalidation of used coupons) (3) Transfer of NFTs to businesses (use of coupons) (4) Transfer of NFTs (1 time)

[0035] Figure 5 is a table showing the conditions for bearing gas charges. The table in Figure 5 shows the conditions such as the sender address (from), recipient address (to), and function to be executed (method) for a metatransaction to fall under (1) to (4).

[0036] (1) This provision allows a specific user to transfer NFTs (coupons) free of charge up to X times. The "specific user" referred to here is a user registered in User DB142. The destination of the NFT transfer is irrelevant. For example, Server 1 counts the number of NFT transfers (number of transfer function executions) for each user, with each user's wallet address as the source (from), based on the NFT transfer history obtained from Explorer Server 5. When Server 1 obtains a meta-transaction transferring an NFT from a user's wallet address registered in User DB142, Server 1 determines whether the number of NFT transfers from the user's wallet address is less than or equal to a predetermined number (X times).

[0037] (2) The service provider bears the gas fee when it destroys (burns) used NFTs (coupons). Server 1 determines whether a metatransaction is a transaction to destroy an NFT based on the transaction details indicated by the metatransaction. Specifically, Server 1 determines whether the wallet address of the sender (from) in the metatransaction is a wallet address of a service provider registered in the service provider DB143, and whether the function to be executed is a burn function (a function that sends tokens to a wallet address for token invalidation).

[0038] (3) The use of NFTs (coupons) is always free. Server 1 determines, based on the transaction details indicated by the metatransaction, whether the metatransaction is a transaction that transfers an NFT to the wallet address of a specific recipient (business). Specifically, Server 1 determines whether the recipient's (to) wallet address in the metatransaction is a wallet address of a business registered in the business DB143, and whether the function to be executed is the transfer function.

[0039] (4) allows the transfer of an NFT to an unspecified person to be free of charge only once. For example, Server 1 counts the number of transfers (number of times the transfer function is executed) for each NFT based on the NFT transfer history obtained from Explorer Server 5. When Server 1 obtains a metatransaction for transferring an NFT, it determines whether the previous number of NFT transfers is 0. In other words, Server 1 determines whether the obtained metatransaction is the first transaction to transfer the NFT.

[0040] Server 1 determines that the gas fee payment conditions are met if the issuer of the NFT is on the whitelist, the current holder of the NFT is the sender of the metatransaction, and any of the above conditions (1) to (4) are met. The above conditions (1) to (4) are applied in this order. Furthermore, the above payment conditions (1) to (4) are just examples, and it is also possible to determine whether the conditions are met for only one of (1) to (4) (for example, only (2) or (3)), or to set payment conditions other than (1) to (4).

[0041] Returning to Figure 4, let's continue the explanation. If Server 1 determines that the conditions for paying gas charges are met, it stores the meta-transaction data and generates a legitimate transaction to pay the gas charges to the miner. To distinguish it from the "second transaction" described later, this transaction will be called the "first transaction."

[0042] The first transaction is a transaction that describes the contract address of the forwarder contract to which the first transaction is sent (described later), the gas fee to be paid to the miner, and other data. The first transaction contains the data of the meta-transaction described above. Server 1 inputs the relayer's digital signature into the first transaction using the relayer's private key and outputs it to the blockchain network 2.

[0043] In this embodiment, the blockchain network 2 is provided with two smart contracts: a forwarder contract and an NFT management contract (recipient). The forwarder contract is a smart contract that verifies the contents of the meta-transaction stored in the first transaction. The management contract is a smart contract that executes processing related to the meta-transaction (the second transaction described later).

[0044] Figure 6 illustrates the processing of metatransactions in a blockchain network. Figure 6 shows the processing details in forwarder contracts and management contracts.

[0045] The forwarder contract extracts metatransaction data from the first transaction and verifies the validity of the metatransaction. Specifically, the forwarder contract determines whether the NFT management contract allows execution from the forwarder contract. The forwarder contract also determines whether the metatransaction is within its expiration period. Furthermore, the forwarder contract extracts the wallet address from the digital signature described in the metatransaction and determines whether it matches the wallet address of the sender of the metatransaction.

[0046] If the validity of the metatransaction can be verified, the forwarder contract generates a transaction that describes the same content as the metatransaction so that it can be processed on the blockchain. In the following explanation, this transaction will be referred to as the "second transaction".

[0047] The second transaction contains data that reflects the same transaction details as the meta-transaction (in the example in Figures 4 and 6, this data indicates the transfer of ownership of NFTα from wallet address A to wallet address B). However, due to blockchain specifications, the sender address of the second transaction (msg.sender) is set to the contract address of the forwarder contract. The forwarder contract then sends the second transaction to the management contract.

[0048] The managed contract has the following additional or overridden functions compared to the standard standard (e.g., ERC721). Specifically, the managed contract includes a function to register permission (trust) for execution from a particular forwarder contract, and a function to retrieve that registration. Furthermore, if the sender address of the second transaction (msg.sender) is the contract address of a registered forward contract, the managed contract, instead of calling the function to retrieve the sender address of the second transaction, rewrites the sender address of the second transaction to the sender's wallet address (address A) of the metatransaction. This sends the NFT from the sender's wallet address (address A) specified in the metatransaction to the recipient's wallet address (address B).

[0049] As described above, according to this embodiment, when a signed meta-transaction is received from the sender, the server 1 determines whether the conditions for bearing gas fees are met. If it determines that the conditions are met, it generates a first transaction to bear the gas fees and outputs it to the blockchain network 2 (forwarder contract). This makes it possible to suitably select a meta-transaction to bear the gas fees while reducing the burden of gas fees on the NFT sender (user or business).

[0050] Figure 7 is a flowchart illustrating an example of the processing procedure performed by Server 1. Based on Figure 7, the processing details performed by Server 1 will be explained. The control unit 11 of server 1 generates a metatransaction for trading NFTs in response to a request from user terminal 3 or business terminal 4 and outputs it to the requesting user terminal 3 or business terminal 4 (step S11). The control unit 11 obtains the metatransaction, which has been digitally signed with the sender's (user or business) private key, from user terminal 3 or business terminal 4 (step S12). If a signed metatransaction is obtained, the control unit 11 obtains the transfer history of the NFT to be traded in that metatransaction from the explorer server 5 (step S13).

[0051] The control unit 11 determines, based on the NFT transfer history, whether the NFT issuer (the original holder of the NFT) is registered in the whitelist (step S14). That is, the control unit 11 determines whether the NFT issuer's wallet address is registered in the issuer DB 141, which defines legitimate issuers.

[0052] If the issuer is determined to be registered on the whitelist (S14:YES), the control unit 11 determines, based on the NFT transfer history, whether the wallet address of the NFT sender indicated by the metatransaction matches the wallet address of the current holder of the NFT (step S15).

[0053] If it is determined that the wallet address matches (S15: YES), the control unit 11 determines whether the number of NFT transfers from the user's wallet address is less than or equal to a predetermined number, if the NFT sender is a user registered in the user DB 142 (step S16). In other words, the control unit 11 determines whether the number of coupon transfers by the user is less than or equal to a predetermined number.

[0054] If it is determined that the number of times is not less than the predetermined number (S16: NO), the control unit 11 determines whether the metatransaction is a transaction that discards the NFT if the sender of the NFT is a business operator (step S17).

[0055] If it is determined that the transaction is not one that destroys the NFT (S17: NO), the control unit 11 determines whether the metatransaction is one that transfers the NFT to the service provider's wallet address (step S18). In other words, the control unit 11 determines whether or not it is a coupon usage.

[0056] If it is determined that the transaction is not one that transfers to the service provider's wallet address (S18: NO), the control unit 11 determines, based on the NFT transfer history, whether the metatransaction is the first transaction to transfer the NFT (step S19).

[0057] If the answer in steps S16, S17, S18, or S19 is YES, the control unit 11 generates a first transaction that stores the meta-transaction data and pays the gas fee (transaction fee) to the miner (validator) (step S20). The control unit 11 outputs the generated first transaction to the blockchain network 2 (step S21) and terminates the series of processes.

[0058] If the answer in step S14, S15, or S19 is NO, the control unit 11 discards the meta-transaction (step S22) and terminates the series of processes.

[0059] Based on the above, according to this embodiment 1, it is possible to suitably select a meta-transaction that bears the fee.

[0060] (Embodiment 2) Embodiment 1 described a method of obtaining the NFT transfer history from an external service such as the Explorer Server 5. This embodiment describes a method of obtaining the transfer history from a smart contract that records the execution history of meta-transactions (second transactions) on the blockchain network 2. Note that the same reference numerals are used for parts that overlap with Embodiment 1, and their explanation is omitted.

[0061] Figure 8 is a diagram illustrating the overview of Embodiment 2. This embodiment will be described based on Figure 8.

[0062] Figure 8, like Figure 6, shows the processing details of meta-transactions in blockchain network 2. The difference from Embodiment 1 is that, in addition to the forwarder contract and management contract, a smart contract is added that records the execution history of meta-transactions (second transactions). In the following explanation, this smart contract will be referred to as the "reputation contract".

[0063] A reputation contract is a smart contract that records the execution history of meta-transactions when they are performed in the management contract. The reputation contract records the execution history of meta-transactions, i.e., the number of times meta-transactions were used, for each sender's wallet address.

[0064] The management contract in this embodiment includes a function to record the execution history of meta-transactions in the reputation contract. Each time the management contract receives and executes a second transaction from the forwarder contract, it records the execution history in the reputation contract.

[0065] When Server 1, acting as a relayer, receives a metatransaction from the sender, it retrieves the transfer history of the NFTs to be traded in that metatransaction from the reputation contract. Based on the retrieved transfer history, Server 1 determines whether or not the conditions for bearing gas charges described in Embodiment 1 are met.

[0066] This embodiment is the same as Embodiment 1 described above, except that the NFT transfer history is obtained from the reputation contract; therefore, flowcharts and other detailed explanations are omitted in this embodiment.

[0067] Based on the above, according to this embodiment 2, the transfer history of NFTs can be suitably obtained by recording the execution history of metatransactions in the reputation contract.

[0068] The embodiments disclosed herein should be considered in all respects to be illustrative and not restrictive. The scope of the present invention is indicated by the claims, not in the sense described above, and all modifications within the sense and scope equivalent to the claims are intended.

[0069] The matters described in each embodiment can be combined with each other. Furthermore, the independent and dependent claims described in the claims can be combined with each other in any combination, regardless of the form of reference. In addition, the claims use a form in which claims referencing two or more other claims (multi-claim form), but are not limited to this. A form in which multi-claims referencing at least one multi-claim (multi-multi-claim) may also be used. [Explanation of Symbols]

[0070] 1. Server (Information Processing Device) 11 Control Unit 12 Main memory 13 Communications Department 14 Auxiliary storage P Program 141 Publisher Database 142 UserDB 143 Operator DB 2 Blockchain Network 20 nodes 3. User terminals 4. Carrier terminals 5. Explorer Server 501 Transfer History Database

Claims

1. A meta-transaction for trading digital tokens issued on the blockchain, where the sender obtains a signed meta-transaction. Based on the transfer history of the digital token or the transaction details of the digital token in the acquired meta-transaction, it is determined whether the conditions for bearing the fees necessary for executing the processing related to the meta-transaction are met. If it is determined that the aforementioned burden conditions are met, the system stores the data of the meta-transaction and generates a transaction to pay the fee to the verifier. Output the generated transaction to the blockchain network. An information processing method in which a computer performs the processing.

2. When the processing related to the meta-transaction is executed in the aforementioned blockchain network, the transfer history is obtained from a smart contract that records the execution history. The information processing method according to claim 1.

3. Based on the aforementioned transfer history, it is determined whether the number of digital token transfers from the sender's wallet address is less than or equal to a predetermined number. The information processing method according to claim 1.

4. Based on the transaction details, determine whether the meta-transaction is a transaction that destroys the digital token. The information processing method according to claim 1.

5. Based on the transaction details, determine whether the meta-transaction is a transaction that transfers the digital token to the wallet address of a specific recipient. The information processing method according to claim 1.

6. Based on the transfer history and transaction details, it is determined whether the meta-transaction is the first transaction to transfer the digital token. The information processing method according to claim 1.

7. A meta-transaction for trading digital tokens issued on the blockchain, where the sender obtains a signed meta-transaction. Based on the transfer history of the digital token or the transaction details of the digital token in the acquired meta-transaction, it is determined whether the conditions for bearing the fees necessary for executing the processing related to the meta-transaction are met. If it is determined that the aforementioned burden conditions are met, the system stores the data of the meta-transaction and generates a transaction to pay the fee to the verifier. Output the generated transaction to the blockchain network. A program that instructs a computer to perform a process.

8. An information processing device comprising a control unit, The control unit, A meta-transaction for trading digital tokens issued on the blockchain, where the sender obtains a signed meta-transaction. Based on the transfer history of the digital token or the transaction details of the digital token in the acquired meta-transaction, it is determined whether the conditions for bearing the fees necessary for executing the processing related to the meta-transaction are met. If it is determined that the aforementioned burden conditions are met, the system stores the data of the meta-transaction and generates a transaction to pay the fee to the verifier. Output the generated transaction to the blockchain network. Information processing device.

Images