Transaction delegation method and transaction delegation system

Abstract

To provide a transaction delegation method, a transaction delegation system, and a computer readable medium in a block chain.SOLUTION: In a transaction delegation method: a second device stores account data in a block chain system receives, through communication outside the block chain system, delegation data from a first device used by a user, the delegation data being for delegating execution of a desired transaction of the user in the block chain system; creates a delegation transaction that causes an execution smart contract to execute the desired transaction from an account of the user in the block chain system on the basis of the delegation data transmitted from the first device; and broadcasts the delegation transaction to the block chain system on the basis of the account data.SELECTED DRAWING: Figure 7

Description

[Technical field]

[0001] This application claims the benefit of priority to U.S. Provisional Patent Application No. 62 / 953,734, filed December 26, 2019, which is incorporated by reference in its entirety.

[0002] The present invention relates to a transaction delegation method and a transaction delegation system in a blockchain. [Background technology]

[0003] In a system using blockchain, when a user requests a transaction to a node or smart contract that constitutes the blockchain system, the user is required to pay a fee in the form of a fee token (hereinafter also referred to as a fee token) as consideration for the transaction (Patent Document 1, etc.).

[0004] The transactions required in a blockchain system include not only those aimed at transferring assets (such as cryptocurrencies), but also data storage or calculations performed by smart contracts.

[0005] In systems that use blockchain, in addition to the fee tokens mentioned above, there are smart contracts that require the payment of utility tokens when using the system. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] JP 2020-080061 A Summary of the Invention [Problem to be solved by the invention]

[0007] To use services based on blockchain technology, users need to manage fee tokens and utility tokens, which can be cumbersome, making it difficult for blockchain systems to become explosively widespread.

[0008] The present invention has been made in consideration of the above circumstances, and aims to provide a transaction delegation method and a transaction delegation system that support the spread of blockchain systems. [Means for solving the problem]

[0009] In one embodiment of the transaction delegation method of the present disclosure, a second device that stores account data in a blockchain system receives delegation data from a first device used by a user via communication outside the blockchain system, and based on the delegation data sent from the first device, creates a delegation transaction that causes an execution smart contract to execute the desired transaction from the user's account in the blockchain system, and broadcasts the delegation transaction to the blockchain system based on the account data. Effect of the Invention

[0010] According to the present disclosure, users receiving the service can enjoy the service without being aware of their accounts in the blockchain system on which the service is based, or the operation of tokens circulating in the blockchain system. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 is a schematic diagram of a system of the present disclosure. [Diagram 2] FIG. 2 is a schematic diagram of a transaction delegation process in the system of the present disclosure. [Diagram 3]FIG. 2 is a block diagram showing a configuration of a first device. [Figure 4] FIG. 13 is a block diagram showing a configuration of a second device of a relay. [Diagram 5] A block diagram showing the configuration of a node in a blockchain system. [Figure 6] FIG. 2 is an overview of the processing in the system. [Figure 7] FIG. 13 is a sequence diagram illustrating an example of a delegation transaction creation process. [Figure 8] FIG. 13 is a sequence diagram illustrating an example of a procedure for delegating execution of a transaction. [Figure 9] FIG. 11 is a sequence diagram illustrating an example of a transaction delegation process in the first embodiment. [Figure 10] FIG. 13 is a sequence diagram illustrating an example of a transaction delegation process according to the third embodiment. [Figure 11] FIG. 13 is a sequence diagram illustrating an example of a transaction delegation process in the fourth embodiment. [Figure 12] FIG. 13 is a sequence diagram illustrating an example of a transaction delegation process in the fifth embodiment. [Figure 13] FIG. 23 is a sequence diagram illustrating an example of a transaction delegation process in the sixth embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] The present disclosure will be specifically described with reference to the drawings showing the embodiments thereof.

[0013] In this disclosure, the term "blockchain system" refers to a system that includes multiple computers that can communicate with each other and a network that connects the multiple computers, and creates a blockchain through distributed processing of the multiple computers. The blockchain incorporates the contents of the requested transactions.

[0014] In a system using blockchain, when a user's first device requests a transaction to the blockchain system, the user is required to pay a fee in the form of a specific token (fee token) according to the blockchain technology.

[0015] For example, in a Bitcoin (registered trademark)-based blockchain system, when a user requests a transaction to move assets (register a trade), a difference is set between the input and output of the transaction, and a fee in BTC units equal to the difference is paid to the miner. In an Ethereum (registered trademark)-based blockchain system, when a transaction is executed, a fee in ETH units equivalent to the amount of gas required to include the transaction in the blockchain is paid to the miner according to the specified gas cost. In both Bitcoin and Ethereum, transactions with low fees are less likely to be included in the blockchain.

[0016] In an EOS-based blockchain system, the entity requesting a transaction must secure the storage capacity and computing resources required for the transaction in advance. Specifically, the user requesting the transaction must purchase storage capacity in the blockchain system with EOS tokens via the device they are using, and stake (deposit) the EOS tokens in the blockchain account that will execute the processing.

[0017] In order to continue operating a blockchain-based system, a mechanism for requesting payment of such fees is important in terms of incentive design and improving resistance to DOS attacks. In order to use the service, users need to manage tokens by purchasing and sending the necessary tokens (fee tokens or utility tokens) through an exchange using their blockchain system account. Some services issue and distribute special tokens, but even if these special tokens are available, they may need to be traded for fee tokens or utility tokens. Managing these various tokens requires highly specialized knowledge, which is a high hurdle for general users. The situation in which users who are not familiar with blockchain technology do not use blockchain-based services is a major challenge to the mass adoption of blockchain.

[0018] The transaction delegation method disclosed herein involves a second device that stores account data in a blockchain system receiving delegation data from a first device used by a user via communication outside the blockchain system, delegating the execution of a desired transaction of the user in the blockchain system, and creating a delegation transaction that causes an execution smart contract to execute the desired transaction from the user's account in the blockchain system based on the delegation data sent from the first device, and broadcasting the delegation transaction to the blockchain system, including the payment of a fee token or utility token required to execute the transaction based on the account data.

[0019] In the transaction delegation method disclosed herein, a device (first device) used by a user who actually receives the service can delegate a transaction (user transaction, hereinafter also referred to as user tx) that the user wishes to execute to a relay device (second device) that owns a fee token or utility token in the blockchain system that realizes the service, i.e., transaction delegation (tx delegation).

[0020] This allows users to obtain transaction execution results even if they do not have the authority (account) to manage the fee token or utility token required for the transaction (user tx) they wish to execute. Users do not need to be aware of the operation of fee tokens or utility tokens in the blockchain on which the service is based. They can use any token for which they have authority as a delegation fee token, or they do not need to pay a delegation fee.

[0021] Transaction delegation (tx delegation) is done outside of the blockchain and can take any form, but delegation from a user to an intermediary requires that the intermediary contains enough data to execute the transaction the user wishes to execute (user tx).

[0022] A special transaction (nested tx) having a nested structure may be adopted for delegating a transaction. The special transaction transmitted from the first device to the second device has a nested structure in the sense that it contains a transaction (user tx) that the user wishes to execute. The special transaction includes data necessary to determine the transaction (user tx) that the user wishes to execute, and a blockchain account (hereinafter also referred to as an executer account) that will be the entity that executes the transaction. The special transaction may include multiple transactions (user tx). In this case, the special transaction includes the necessary data and blockchain account data for each transaction (user tx).

[0023] The special transaction sent from the user's first device to the intermediary's second device may include a delegation condition (cond) and a signature (sig).

[0024] The second device of the relay creates a delegation transaction (hereinafter, referred to as a delegation transaction (delegation tx)) in the form of a special transaction including a transaction (user tx) that the user wishes to execute in a nested structure based on the transaction delegation from the user. The delegation transaction may include the transaction (user tx) that the user wishes to execute, a delegation condition (cond), and a signature (sig).

[0025] The second device of the relayer requests a delegation transaction to the blockchain system based on an account (Relayer Account) for which the relay user has authority. The delegation transaction is executed to an Account Caller Contract, which is a smart contract belonging to the blockchain system. As described below, the second device of the relayer may request the execution of the delegation transaction not only to the Account Caller Contract but also directly to the Executor Account Contract of the blockchain account that is the executor of the transaction. Fee tokens or utility tokens, etc. required for requesting the blockchain system to execute the transaction at this time are executed from the account of the relayer.

[0026] The Account Invoke contract requests the Executor Account contract, acting as the user's account, to execute a transaction (user tx) based on the delegation transaction (delegation tx). The Executor Account contract executes the requested transaction (user tx) and pays the delegation fee token from the user to the intermediary.

[0027] This allows users of the service to enjoy the service without being aware of the operation of various tokens in the blockchain system on which the service is based.

[0028] FIG. 1 is a schematic diagram of a system 100 of the present disclosure. The system includes a first device 1 of a user outside a blockchain system 300, and a second device 2 managed by an intermediary that can be accessed from the first device 1. The system 100 includes an instance of an Account Caller Contract 301 and an Executor Account Contract 302 within the blockchain system 300. In the present disclosure, the term "blockchain system" refers to a system that includes multiple computers that can be connected to each other for communication and a network that connects the multiple computers, and creates a blockchain through distributed processing of the multiple computers.

[0029] In the system 100 of the present disclosure, the first device 1 of the user stores a private key corresponding to the blockchain system 300, but does not need to store an account associated with a fee token or utility token of the blockchain system 300. However, the first device 1 can obtain the results of processing in the blockchain system 300 in order to receive a blockchain-based service. For example, the first device 1 can obtain the processing results from the blockchain system 300 on a web basis. The first device 1 can also transmit and receive data to and from the second device 2.

[0030] The second device 2 is managed by a relayer having an account that allows the transfer of fee tokens and utility tokens in the blockchain system 300. The second device 2 can transmit and receive data to and from the user's first device 1, and can execute transactions in the blockchain system 300 based on the relayer's account. In other words, the second device 2 can pay (stake) fee tokens or utility tokens.

[0031] The blockchain system 300 in the system 100 of the present disclosure uses a type of blockchain technology that allows smart contracts to be deployed (executable) to accounts. In the following example, the blockchain system 300 will be described as using Ethereum blockchain technology, but is not limited to this. The blockchain system 300 may be based on EOS.

[0032] In the blockchain system 300, instances of an account call contract 301 and an executor account contract 302 are generated. As described later (Examples 4 and 6), these may be the same instance. The blockchain system 300 includes a variety of multiple contract 303 instances corresponding to multiple applications. In addition, in the blockchain system, delegation fee token management contracts 304 that manage delegation fee tokens are generated.

[0033] In order to request a process from a target contract 303 that executes a process desired by a user among the smart contracts 303 corresponding to various applications existing in the blockchain system 300, the user needs to execute a transaction using an account with administrative authority to pay a fee token or utility token. However, transactions of various tokens including fee tokens or utility tokens in the blockchain system 300 require the user to have knowledge of blockchain technology.

[0034] In the system 100 of the present disclosure, a user device (first device) 1 that actually receives the provision of a service delegates a transaction (user tx) that the user wishes to execute to an intermediary device (second device) 2 that possesses and can transfer fee tokens or utility tokens of the blockchain system 300 that realizes the service. By delegating, the user can enjoy the results of the execution of a transaction in the blockchain system 300 even if he or she cannot manage the tokens.

[0035] FIG. 2 is a schematic diagram of a transaction delegation process in the system 100 of the present disclosure.

[0036] (1) A user (first device 1) who wishes to process a transaction in the service determines or creates data that identifies the blockchain account (executor account) that will be the executor of the transaction (user tx) that the user wishes to execute on the blockchain.

[0037] At step (1), a user (first device 1) determines or creates data for constituting a transaction (user tx) to be executed by the executor account contract in the blockchain system 300.

[0038] If the service is, for example, a game, the user may wish to execute a transaction for generating or transferring an item in the game realized by a distributed application of the blockchain system 300 (obviously, the service is not limited to games). In this case, the blockchain account (executer account) for executing the transaction (user tx) that the user wishes to execute is, for example, the user's account in the blockchain system. Also, if the desired transaction (user tx) is the generation or transfer of an item, the data for constituting the transaction (user tx) may include data for identifying the item, data for identifying the transferee, etc.

[0039] At step (1), the user (first device 1) obtains the data (sig) necessary for this verification using a method (e.g., a digital signature) that can verify that the user has specified the user's blockchain account (executor account) and the transaction (user tx) that he or she wishes to execute.

[0040] (2) The user's first device 1 transmits the user's blockchain account (executor account), the transaction to be executed (user tx), and data required for verification to the intermediary's second device 2 outside the blockchain system 300. This conveys the blockchain account (executor account) and the desired transaction (user tx) to the intermediary.

[0041] (3) The second device 2 of the relay creates a delegation transaction (delegation tx) that embeds the blockchain account (executor account) corresponding to the user and the desired transaction (user tx) based on the data received from the first device 1 of the user. The second device 2 of the relay broadcasts the delegation transaction to the blockchain system 300 with the authority of the relay's account or another account (any account) that the relay can use.

[0042] (4) The transmission of the broadcast realizes the execution of the transaction (user tx) that the user wishes to execute by the blockchain account (executor account) corresponding to the user in the blockchain system 300. The fee token or utility token required to execute this transaction (user tx) is paid from the account (the relay's account or another account) specified by the relay when broadcasting the delegation transaction.

[0043] In this way, the device (first device) 1 used by the user who actually receives the provision of the service delegates the transaction (user tx) that the user wishes to execute to the device (second device) 2 of the intermediary that owns the fee token or utility token in the blockchain system 300. By delegating, it becomes possible to execute a transaction in the blockchain system 300 even if the user does not have the authority to manage the fee token or utility token.

[0044] This allows users receiving the service to execute transactions without being aware of the operation of the fee tokens or utility tokens of the blockchain system 300 on which the service is based.

[0045] A specific configuration of a system for implementing such processing will be described below.

[0046] 3 is a block diagram showing the configuration of the first device 1. The first device 1 is, for example, a smartphone or a tablet terminal. The first device 1 includes a processing unit 10, a storage unit 11, a communication unit 12, a display unit 13, and an operation unit 14.

[0047] The processing unit 10 uses a processor such as a CPU (Central Processing Unit) and a GPU (Graphics Processing Unit), a memory, etc. The processing unit 10 may be configured as a single piece of hardware (SoC: System On a Chip) that integrates the processor, the memory, and further the storage unit 11 and the communication unit 12.

[0048] The storage unit 11 uses a flash memory and stores programs and data referenced by the processing unit 10, including the first program 1P. The first program 1P is a program for causing a computer to function as the first device 1 of the system 100 of the present disclosure. As shown in FIG. 3, the storage unit 11 may store a private key of a user in the blockchain system 300. The private key may be stored in the memory of the processing unit 10 or the storage unit 11 in a non-rewritable manner (a wallet on a chip).

[0049] The first program 1P stored in the storage unit 11 may be a first program 8P stored in a computer-readable storage medium 8 that is read by the processing unit 10 and stored in the storage unit 11.

[0050] The communication unit 12 is a communication module that realizes a communication connection with the second device 2 and other communication devices. The communication unit 12 uses a network card, a wireless communication device, or a carrier communication module.

[0051] The display unit 13 uses a display device such as a liquid crystal panel or an organic EL display. The operation unit 14 is an interface that accepts user operations, and uses physical buttons, a touch panel device built into the display, a speaker, a microphone, etc. The operation unit 14 may accept operations on a screen displayed on the display unit 13 using physical buttons or a touch panel, or may recognize the operation content from an input voice using a microphone and accept the operation in an interactive format using the voice output from a speaker.

[0052] 4 is a block diagram showing the configuration of the second device 2 of the relay. Like the first device 1, the second device 2 is a communication terminal device such as a smartphone or a tablet terminal. The second device 2 may be a second computer, or a desktop or laptop personal computer. The second device 2 includes a processing unit 20, a storage unit 21, and a communication unit 22.

[0053] The processing unit 20 uses a processor such as a CPU or a GPU, a memory, etc. The processing unit 20 acquires data transmitted from the first device 1 based on the second program 2P stored in the storage unit 21, and realizes creation of a delegation transaction and execution of the transaction. The storage unit 21 uses a hard disk or a flash memory, and stores programs and data referenced by the processing unit 20, including the second program 2P.

[0054] The second program 2P stored in the storage unit 21 may be a second program 9P stored in a computer-readable storage medium 9 that is read by the processing unit 10 and stored in the storage unit 11.

[0055] The communication unit 22 is a communication module that realizes a communication connection with the first device 1 or the block chain system 300. The communication unit 22 uses a network card, a wireless communication device, or a carrier communication module.

[0056] 5 is a block diagram showing a configuration of a node 30 in a blockchain system 300. The node 30 may be a server computer, a desktop or laptop personal computer, or a communication terminal device such as a smartphone. The node 30 includes a processing unit 31, a storage unit 32, and a communication unit 33. If the node 30 is a device including at least the processing unit 31 and the communication unit 33, a part of the processing unit 31 can constitute a part or the whole of the node.

[0057] The processing unit 31 uses a processor such as a CPU or a GPU, a memory, etc. The processing unit 31 may be configured as a single piece of hardware that integrates a processor, a memory, a storage unit 32, and a communication unit 33. The memory of the processing unit 31 may store a private key unique to each node 3. The processing unit 31 then executes each process based on the node program stored in the storage unit 32, and causes the general-purpose computer to function as a node in the blockchain system 300.

[0058] The storage unit 32 uses a hard disk or flash memory, and stores programs and data referenced by the processing unit 31, including a node program. The storage unit 32 stores a blockchain. The node program includes a program for functioning as a smart contract (the processing unit 31 that executes predetermined calculation processing for transaction execution), which will be described later. The above-mentioned private key may be stored in the storage unit 32. The storage unit 32 may store a public key and an address based on the private key.

[0059] The communication unit 33 is a communication module that realizes intercommunication between the nodes 30. The communication unit 33 uses a network card, an optical communication device, a wireless communication device, or the like.

[0060] Fig. 6 is a schematic diagram of the process in the system 100. The user's first device 1 creates data addressed to the intermediary, including data required to create a transaction (user tx) that the user wishes to execute, and a blockchain account (executor account) that will execute the transaction, for the purpose of delegating the transaction (corresponding to (1) in Fig. 2). In the example shown in Fig. 6, data including the user's transaction (user tx) and the blockchain account (executor account) corresponding to the user, as well as transaction conditions (cond) and a verification method (sig) are created and transmitted to the intermediary's second device 2 (corresponding to (2) in Fig. 2).

[0061] The second device 2, which is the relay, creates a delegation transaction (delegation tx) based on the contents of the data sent from the first device 1 (corresponding to (3) in Figure 2). The delegation transaction is a special transaction (nested tx) that includes a transaction (user tx) that the user wishes to execute, a delegation condition (cond), and a signature (sig) in a nested structure.

[0062] The second device 2 possesses fee tokens or utility tokens that can execute transactions on the blockchain system 300. The second device 2 executes a delegation transaction based on an account for which the relayer has authority (corresponding to (3) in FIG. 2). The delegation transaction is executed on an account call contract 301 in the blockchain.

[0063] The Account Invoke Contract 301 requests the Executor Account Contract 302, which acts as a user's account, to execute a transaction (user tx) based on a delegation transaction (delegation tx). The Executor Account Contract 302 executes the requested transaction (user tx) in a target contract 303. The Executor Account Contract 302 executes the requested transaction (user tx) and also executes a transaction including the payment (transfer) of the delegation fee to the intermediary to the Delegation Fee Token Management Contract 304. The delegation fee is different from the fee token or utility token.

[0064] 7 is a sequence diagram showing an example of a delegation transaction creation process procedure. The process procedure shown in the sequence diagram of FIG. 7 corresponds to the details of the process procedure up to (2) in FIG.

[0065] The processing unit 10 of the first device 1 creates the contents of the transaction (user tx) that the user wishes to execute and the initial value of the delegation condition (cond) based on the first program 1P stored in the storage unit 11 (step S101). The contents of the transaction (user tx) include the address of the target contract 303 of the transaction, the identifier of the target function in the target contract 303, and the argument data of the target function. The delegation condition of the transaction includes an address corresponding to the user's private key and data required to determine the address of the executor account contract 302. The delegation condition further includes the address of the delegation fee token management contract 304, the address of the payment destination of the delegation fee (token), and data required to determine the fee.

[0066] The processing unit 10 displays the content of the created transaction (user tx) and the initial value of the delegation condition (cond) on the display unit 13 (step S102). The content of the transaction displayed in step S102 may be the address, identifier, and argument data output in text form, or may be output using the name of the contract, an identifying icon, or the like. The displayed delegation condition may also be output in text form, or may be output using an icon.

[0067] The processing unit 10 accepts editing of the contents of the transaction (user tx) and the delegation conditions (cond) by the user (step S103). If there are no changes, the process of step S103 is skipped.

[0068] The processing unit 10 accepts confirmation of the contents of the transaction (user tx) to be executed and the delegation condition (cond) (step S104).

[0069] The processing unit 10 generates an electronic signature based on the user's private key for the content of the confirmed transaction (user tx) and the data of the delegation condition (cond) (step S105). The private key may be securely stored in the storage unit 11 of the first device 1, or may be input by the user.

[0070] The processing unit 10 transmits the content of the confirmed transaction (user tx), the delegation condition (cond), and the electronic signature acquired in step S105 to the second device 2 of the intermediary (step S106). The content of the transaction (user tx) includes the address of the target contract 303 of the transaction, the identifier of the target function, and the argument data of the target function.

[0071] The processing unit 20 of the second device 2 receives the contents of the transaction (user tx) and the delegation conditions (cond) with a digital signature (step S201). In step S201, the processing unit 20 determines whether the delegation can be accepted based on the transmitted contents, and if the delegation cannot be accepted, may return a response to the user's first device.

[0072] The processing unit 20 creates a delegation transaction (delegation tx) by embedding the contents of the received transaction (user tx), the delegation condition (cond), and the electronic signature (step S202). The delegation transaction (delegation tx) created in step S202 is a special transaction (nested tx) having a nested structure.

[0073] The processing unit 20 generates an electronic signature for the delegation transaction created in step S202 using the private key of a relay account in the blockchain system 300 that is associated with the relay that manages the second device 2 (step S203).

[0074] The processing unit 20 embeds the electronic signature generated in step S203 in the delegation transaction (delegation tx) created in step S202 (step S204), and the process of creating the delegation transaction (delegation tx) is completed.

[0075] The delegation transaction created in step S202 includes the address of the account call contract that is the target of the delegation transaction and the identifier of the call function. The delegation transaction includes the contents of the user's transaction (user tx) to be executed as an argument of the call function. The contents of this transaction are the address of the target contract, the identifier of the target function in the contract, and the data to be input to the function. The delegation conditions include an address corresponding to the user's private key and data required to determine the address of the execution account contract. The data required to determine the address of the execution account contract is the address itself, or an arbitrary value or character string (so-called salt) when using a virtual account contract. The delegation conditions further include a condition regarding the delegation fee. The delegation fee is different from the fee token or the utility token. The condition regarding the delegation fee includes the address of the delegation fee token management contract 304 that manages the token to be paid as the delegation fee. The conditions regarding the delegation fee include the payee of the delegation fee, i.e., the address for the relay to receive the delegation fee, and data necessary for determining the delegation fee, such as the rate between the token to be paid as the delegation fee (delegation fee token) and the fee token, and the rate between the token and the utility token.

[0076] Even if the conditions regarding the delegation fee to be included in the delegation transaction (delegation tx) are not specified, or if it is determined that the conditions equivalent to no specification are set, the fee token or utility token required to execute the transaction (user tx) that the user wishes to execute is paid based on the account of the intermediary. The user may not pay the delegation fee. In addition, the token that can be specified as the token to be paid as the delegation fee (delegation fee token) is a token that exists in the same blockchain system 300 as the target contract 303 of the transaction that the user wishes to execute, that is, a circulatable token.

[0077] 8 is a sequence diagram showing an example of a transaction delegation execution processing procedure, which includes the processing procedures (3) to (4) in FIG.

[0078] The second device 2, which is the relay, broadcasts the created delegation transaction (delegation tx) (step S205).

[0079] When the delegation transaction in step S205 is broadcast, the delegation transaction is incorporated into the blockchain by node 30 of the blockchain system 300. Based on the delegation transaction incorporated into the blockchain, the call function of the account call contract 301 of the address included in the delegation transaction is executed, and the following processing proceeds. The following processing is executed atomically and indivisibly unless the verification of the validity of the signature (S302) fails.

[0080] An instance of the account call contract 301 (hereinafter simply referred to as the account call contract) determines an address based on data required for determining the address of the executor account contract 302 included in the delegation transaction by executing a call function (step S301).

[0081] The account call contract 301 verifies the validity of the electronic signature for the contents of the transaction (user tx) that the user wishes to execute, which are included in the delegation transaction, and the delegation conditions (step S302).

[0082] If the verification in step S302 is successful in determining that the signature is valid, the account call contract 301 executes the following process. If the verification in step S302 is successful in determining that the signature is invalid, the account call contract 301 ends the process.

[0083] The account call contract 301 instructs the executor account contract 302 of the address determined in step S301 to execute a target function in the target contract 303 based on the transaction the user wishes to execute (step S303). In step S303, the account call contract passes the address of the target contract 303 of the transaction the user wishes to execute, the identifier of the target function, and data to be input to the target function to the executor account contract.

[0084] Based on the passed address and identifier, the executor account contract 302 inputs the passed data as an argument to the target function of the target contract 303 and executes it (step S401).

[0085] As a result, the processing specified by the execution of the target function is executed in the target contract 303 of the transaction that the user wishes to execute (step S501). The execution of the specified processing results in the result of the transaction that the user wishes to execute (movement of assets, storage of data, or computing).

[0086] The account call contract 301 determines the amount of the delegation fee (delegation fee token) to be paid by the user based on data necessary for determining the delegation fee in the delegation conditions included in the delegation transaction (step S304).

[0087] The account call contract 301 instructs the executor account contract 302 to pay the determined amount of delegation fee (step S305). In step S305, the account call contract 301 specifies the address of the delegation fee token management contract 304 and the address of the payee of the delegation fee together with the instruction.

[0088] The executor account contract 302 instructs the designated delegation fee token management contract 304 to pay the delegation fee to the designated payee address (step S402).

[0089] In response to the instruction in step S402, the delegation fee token management contract 304 executes the payment process of the delegation fee to the designated payee address (step S601). The amount of the delegation fee may be zero. This ends the execution process of the delegation transaction.

[0090] By using the processing shown in the sequence diagrams of Figures 7 and 8, a user can enjoy the results of executing processing in the target contract 303 in the blockchain system 300, even if the user does not possess an account with the authority to move fee tokens or utility tokens in the blockchain system 300.

[0091] The process shown in the sequence diagram of Fig. 8 is an atomically linked process in which calling a function of a contract 302 calls other functions, and is executed as a series of processes without any judgment in each contract 301, 302, 303, 304 except for signature verification. This is realized in the form of a special transaction (nested tx) that includes a transaction desired by the user (user tx) in a nested structure.

[0092] In the above description, the account call contract 301 and the executor account contract 302 are described as separate instances. However, these contracts 301 and 302 may be the same contract. In addition, there are two methods for collecting the delegation fee from the user: collecting it with a delegation fee token, and not collecting the delegation fee. Below, several embodiments will be described based on these variations.

[0093] When the account call contract 301 and the executor account contract 302 exist as separate instances, the executor account contract 302 may be a virtual account contract or not. A virtual account contract is a special contract that does not have any substance until the process of the transaction (user tx) that the user actually wishes to execute and the call function are executed.

[0094] The advantages of using a virtual account contract are, first, that the virtual account contract can hold a token even if the entity does not exist. In other words, no fee is charged to the user before activation. In a typical contract in the blockchain system 300, a contract that holds a token must exist beforehand, so a fee is required for its deployment. In addition, the cost of activation is small. An instance of a virtual account contract is very lightweight, that is, the amount of program data is small, so the fee for deployment is small. By executing deployment in a series of processes of transaction delegation (tx delegation), it is possible for the intermediary to shoulder the fee for deployment.

[0095] The second benefit of using a virtual account contract is the high security of assets. Since a virtual account contract before materialization is not materialized, the possibility of it being attacked is extremely low. Even if it is necessary to store the public key of the virtual account contract holder in the blockchain, it is possible to conceal it by hashing, so attacks on the holder are virtually impossible. This property is the same even when the virtual account contract is used alone.

[0096] There are three ways: whether the account call contract 301 and the executor account contract 302 are the same or not, and if they are different, whether a virtual account contract is used or not. There are also two ways for the delegation fee: one is to collect it, and the other is to have the intermediary shoulder the cost without collecting it. Therefore, six (3 x 2) examples of the execution of transaction delegation will be given below. Since the hardware configurations and basic processing of the blockchain system 300, the user's first device 1, and the intermediary's second device 2 are the same, the detailed processing procedures will be explained by assigning the same symbols as those of the above configuration.

[0097] [Example 1] In the first embodiment, the account call contract 301 and the executor account contract 302 are different instances, the executor account contract is a virtual account contract, and the delegation fee is collected by an arbitrary token, which is a token owned by the user in the blockchain account of the blockchain system 300, and is not a fee token or a utility token.

[0098] In the first embodiment, the creation process of the delegation transaction shown in the sequence diagram of Fig. 7 is executed between the first device 1 of the user and the second device 2 of the intermediary, and the delegation process of the transaction shown below is executed. Fig. 9 is a sequence diagram showing an example of the delegation process of the transaction in the first embodiment. Among the process steps shown in the sequence diagram of Fig. 9, the detailed description of the process steps shown in the sequence diagram of Fig. 8 is omitted by assigning the same step numbers.

[0099] The account call contract 301 verifies the validity of the electronic signature of the transaction that the user wishes to execute based on the imported delegation transaction (S302), and if the verification is successful, deploys the executor account contract 302 of the address determined in step S302 (step S312).

[0100] The account call contract 301 instructs the deployed executer account contract 302 to execute a target function in the target contract 303 (S303). The process from step S304 onwards is similar to the process with reference to the sequence diagram of FIG.

[0101] The process shown in the sequence diagram of FIG. 9 is executed only the first time the performer account contract 302 is called, and from the second time onwards, the process shown in the sequence diagram of FIG. 8 is executed.

[0102] As described above, because a virtual account contract is used, no deployment fees need to be paid until the first activation and deployment of the actor account contract 302.

[0103] [Example 2] In the second embodiment, the account call contract 301 and the executor account contract 302 are different instances, the executor account contract 302 is not a virtual account contract, and the delegation fee is collected in an arbitrary token.

[0104] The processing contents of each contract in the second embodiment are the same as the processing procedures shown in the sequence diagrams of FIGS. 7 and 8, and therefore are not illustrated.

[0105] In the second embodiment, the payment of the delegation fee to the delegation fee token management contract 304 by the executor account contract 302 in step S402 executes the payment process of the non-zero delegation fee to the intermediary.

[0106] [Example 3] In the third embodiment, the account call contract 301 and the executor account contract 302 are the same instance, which is not a virtual account contract, and the delegation fee is collected in any token.

[0107] In the third embodiment, the account call contract 301 and the executor account contract 302 are the same instance. The delegation transaction creation process shown in the sequence diagram of Fig. 7 is executed between the first device 1 of the user and the second device 2 of the intermediary, but at that time, data required for determining the address of the executor account contract 302 in the delegation conditions is not required.

[0108] Fig. 10 is a sequence diagram showing an example of a transaction delegation process in the embodiment 3. Among the process steps shown in the sequence diagram of Fig. 10, the process steps common to the process steps shown in the sequence diagram of Fig. 8 are assigned the same step numbers and detailed descriptions are omitted.

[0109] In the third embodiment, the account call contract 301 and the executor account contract 302 are the same. Therefore, the process of step S301 for determining the address of the executor account contract 302 for the broadcasted delegation transaction (delegation tx) is omitted.

[0110] In the third embodiment, based on the address included in the delegation transaction, the executor account contract 302 (account call contract 301) executes a call function to verify the contents of the transaction (user tx) that the user wishes to execute and the validity of the electronic signature for the delegation conditions (S302).

[0111] If the verification in step S302 is successful in determining that the signature is valid, the executor account contract 302 executes the following process: Based on the address of the target contract 303 and the identifier of the target function included in the transaction that the user wishes to execute, the executor account contract 302 inputs input data as an argument to the target function of the target contract 303 and executes it (step S333).

[0112] As a result, in the target contract 303 of the transaction that the user wishes to execute, the processing specified by the execution of the target function is executed (S501). By executing the specified processing, the result of the transaction that the user wishes to execute (movement of assets, storage of data, or computing) is obtained.

[0113] The executor account contract 302 determines the amount of delegation fee tokens to be paid by the user (S304). The executor account contract 302 instructs the delegation fee token management contract 304 to pay the amount of delegation fee determined in step S304 to the payment destination address based on the address included in the delegation transaction (step S335). The executor account contract 302 ends the execution process of the delegation transaction.

[0114] In response to the instruction in step S335, the delegation fee token management contract 304 executes the payment process of the delegation fee to the specified payee (relay) address.

[0115] [Example 4] In the fourth embodiment, the account call contract 301 and the executor account contract 302 are separate instances, the executor account contract 302 is a virtual account contract, and does not collect delegation fees. In this case, the user does not even need to own an account in the blockchain system 300.

[0116] In the fourth embodiment, the delegation transaction creation process shown in the sequence diagram of Fig. 7 is executed between the first device 1 of the user and the second device 2 of the relay, but the delegation fee is not collected. Therefore, the delegation transaction (delegation tx) to be created does not require the address of the delegation fee management contract (delegation fee token contract), the address of the delegation fee payee, and the data required for determining the delegation fee in the delegation conditions.

[0117] Fig. 11 is a sequence diagram showing an example of a transaction delegation process in the embodiment 4. Among the process steps shown in the sequence diagram of Fig. 11, the same step numbers are assigned to the process steps shown in the sequence diagram of Fig. 8, and detailed descriptions thereof will be omitted.

[0118] The account call contract 301 verifies the validity of the electronic signature of the transaction that the user wishes to execute based on the imported delegation transaction (S302), and if the verification is successful, deploys the executor account contract 302 of the address determined in step S302 (step S342).

[0119] The account call contract 301 instructs the deployed executor account contract 302 to execute a target function in the target contract 303 (S303).

[0120] Based on the passed address and identifier, the executor account contract 302 inputs the passed data as an argument to the target function of the target contract and executes it (S401), and the process ends. The processes after step S304 in the process procedure shown in the sequence diagram of FIG. 8 are not executed.

[0121] By the process of step S401, the target contract 303 of the transaction that the user wishes to execute executes the process specified by executing the target function (S501). By executing the specified process, the result of the transaction that the user wishes to execute (movement of assets, storage of data, or computing) is obtained.

[0122] [Example 5] In the fifth embodiment, the account call contract 301 and the executor account contract 302 are different instances, the executor account contract 302 is not a virtual account contract, and does not collect delegation fees.

[0123] In the fifth embodiment, the delegation transaction creation process shown in the sequence diagram of Fig. 7 is executed between the first device 1 of the user and the second device 2 of the intermediary, but the delegation fee is not collected. Therefore, in the delegation transaction (delegation tx) to be created, the address of the delegation fee token management contract 304, the address of the payee of the delegation fee, and the data required for determining the delegation fee are not required in the delegation conditions.

[0124] Fig. 12 is a sequence diagram showing an example of a transaction delegation process in the embodiment 5. Among the process steps shown in the sequence diagram of Fig. 12, the same step numbers are assigned to the process steps shown in the sequence diagram of Fig. 8, and detailed descriptions thereof will be omitted.

[0125] The account call contract 301 determines the address of the executor account contract 302 based on the imported delegation transaction (S301). The account call contract 301 verifies the validity of the digital signature of the transaction (user tx) (S302).

[0126] The account call contract 301 instructs the executor account contract 302 of the address determined in step S301 to execute a target function in the target contract 303 (S303).

[0127] The instructed executor account contract 302 inputs the passed data as an argument to the target function of the target contract 303 based on the passed address and identifier, executes it (S401), and the process ends. The process from step S304 onwards in the process procedure shown in the sequence diagram of Fig. 8 is not executed.

[0128] [Example 6] In the sixth embodiment, the account call contract 301 and the executor account contract 302 are the same instance, which is not a virtual account contract, and does not collect delegation fees.

[0129] In the sixth embodiment, the delegation transaction creation process shown in the sequence diagram of FIG. 7 is executed between the first device 1 of the user and the second device 2 of the intermediary, but the account call contract 301 and the executor account contract 302 are the same contract, and no delegation fee is collected. Therefore, in the delegation transaction (delegation tx) created, the delegation conditions do not include data required to determine the address of the executor account contract 302. The delegation conditions do not require the address of the delegation fee token management contract 304, the address of the payee (intermediary) of the delegation fee, and data required to determine the delegation fee. In the sixth embodiment, it is sufficient for the delegation conditions to include an address corresponding to the user's private key.

[0130] Fig. 13 is a sequence diagram showing an example of a transaction delegation process in the embodiment 6. Among the process steps shown in the sequence diagram of Fig. 13, the process steps common to the process steps shown in the sequence diagram of Fig. 8 are assigned the same step numbers and detailed descriptions are omitted.

[0131] In the sixth embodiment, the account call contract 301 and the executor account contract 302 are the same. Therefore, the process of step S301 for determining the address of the executor account contract 302 for the broadcasted delegation transaction (delegation tx) is omitted.

[0132] In the sixth embodiment, based on the address included in the delegation transaction, the executor account contract 302 (account call contract 301) executes a call function to verify the content of the transaction (user tx) that the user wishes to execute and the validity of the electronic signature for the delegation conditions (S302).

[0133] If the verification in step S302 is successful in determining that the signature is valid, the executor account contract 302, which is also the account invocation contract 301, executes the following process. Based on the address of the target contract 303 and the identifier of the target function included in the transaction that the user wishes to execute, the executor account contract 302 inputs input data as an argument to the target function of the target contract 303 and executes it (step S363). The delegation process ends. The processes from step S304 onwards in the processing procedure shown in the sequence diagram of FIG. 8 are not executed.

[0134] It is unrealistic for the account call contract 301 and the executor account contract 302 described above to be configured to accept transaction execution instructions from all blockchain accounts in the blockchain system 300. Therefore, the executor account contract 302 should be configured to accept only instructions from the account call contract 301, and the account call contract 301 should store accounts (intermediates) that have the authority to issue execution instructions for its own call function in a whitelist format. As in Examples 3 and 6, when the account call contract 301 and the executor account contract 302 are the same instance, the account call contract 301 (executor account contract 302) should store accounts (intermediates) that have the authority to issue execution instructions in a whitelist format so that it can reject delegation transactions from accounts that do not have the authority.

[0135] In the transaction delegation process shown in the sequence diagrams of Figures 8 to 13, an example was given in which the validity of the delegation contents is verified by an electronic signature for the contents of the transaction (user tx) that the user wishes to execute and the delegation conditions. However, it is not limited to an electronic signature. The transaction that the user wishes to execute may be set in advance to pass some kind of authentication, and the verification process of step S301 may be omitted. Alternatively, instead of the verification process of step S301, another verification contract may be deployed in the blockchain system 300, and the process may proceed after verification by this verification contract. Furthermore, instead of the verification process of step S301, in the delegation transaction creation process procedure of Figure 7, the second device 2 of the intermediary may verify the electronic signature received from the first device 1 outside the blockchain system 300.

[0136] Other variations are also permitted for the method of collecting the delegation fee. In the sequence diagrams of FIG. 8 and FIG. 9, the executor account contract 302 executes the payment process to the delegation fee token management contract 304. However, it may be performed in a form in which another contract authorized by the user, for example, the account call contract 301, executes the withdrawal process in the delegation process of the delegation transaction. In addition, the delegation fee may not be collected in the delegation process, but may be realized in a form in which it is paid in advance or after the execution of the delegation transaction for a certain period of time (tx delegation). In a service that logs in the user and manages the user's wallet (private key) centrally, it is also possible to handle advance or after payment in legal tender when collecting the delegation fee. When collecting the delegation fee after the fact, it may be possible to use the assets held by the user as collateral, taking into account the risk that the payment will not be executed. The assets referred to here may be assets (tokens) that can be circulated in the blockchain system 300. They may also be various assets (cash, securities, real estate, etc.) that exist outside the blockchain system 300. In the case of assets that can be circulated in the blockchain system 300, by making the contracts regarding deferred payment and collateral into smart contracts, it becomes possible to execute the contracts without the need for intermediaries or the risk of contract abandonment, which is a major advantage.

[0137] The above-described system 100 allows users to execute transactions in the blockchain system 300 even if they do not hold a utility token or a fee token. This significantly reduces the burden on users. The intermediary can collect the delegation fee with any token (delegation fee token). In the present disclosure, the delegation fee token management contract 304 can execute the above-described process without modification to accommodate transaction delegation, so it is possible to use a large number of tokens that already exist in the blockchain system 300. For example, in Ethereum, the delegation fee token can be collected with an existing token that complies with a standard specification such as ERC20, ERC721, or ERC1155. In the case of ERC1155, collection is also possible with multiple types of tokens. In other words, it is possible to ease the burden on users by flexibly adjusting the procedure for collecting the delegation fee of a transaction from the user. Of course, it is also possible to completely take over the user's account, and in that case, the burden is significantly reduced.

[0138] Even when verifying the validity of the delegation contents using a digital signature to safely delegate from the user to the intermediary (the person being delegated), the user only needs to perform a process of generating a digital signature for the transaction (user tx) that he / she wishes to execute once at the beginning. As a result, approval processing is not required again in the later processing regarding the delegation of the transaction (user tx), and it is no different from the execution of a normal transaction. Therefore, the delegation of transactions disclosed herein does not increase the user's workload.

[0139] The system 100 of the present disclosure allows the intermediary to execute a specified transaction (user tx) from the user's blockchain account (executor account contract) without knowing the user's private information (such as a private key stored in the user's first device 1). The user can protect his / her own private information while allowing the intermediary to use the authority of the executor account contract 302. If the user wants a third party (the intermediary) to use the user's authority, the user needs to inform the third party of the user's private information (such as a private key stored in the user's first device 1), but the user can delegate the private information to the third party while keeping it secret.

[0140] It is possible to prevent the intermediary from modifying the contents of the transaction (user tx) that the user wishes to execute. For example, the user may add an electronic signature to the contents of the transaction that the user wishes to execute and verify it with a smart contract. It is also possible to execute the transaction (user tx) that the user wishes to execute and collect the delegation fee atomically. It is also possible to reduce the possibility that the user will be disadvantaged due to the fraud of the delegated intermediary. This can greatly contribute to preventing fraud. If a situation occurs in which the delegated delegation transaction (delegation tx) is not executed, it is also possible to deal with it via another intermediary. In order to atomically execute the transaction (user tx) that the user wishes to execute and collect the delegation fee, the user needs to hold some kind of token (delegation fee token) that can be used as a delegation fee in the blockchain system 300. It is also possible to protect the user from the risk of a price drop in the token that can be used as the delegation fee by applying a stable coin to the token that can be used as the delegation fee. In particular, since fiat-collateralized stable coins are tokens with stable prices and no speculative nature, they are assets with low holding risk that are easy to handle even for users who are not familiar with the various tokens circulating in the blockchain system 300, and are highly useful.

[0141] The delegated intermediary may be, for example, a company that has been approved by a central government agency through a formal procedure. This company is responsible for managing the customer's cryptocurrency (private key) and can execute the transaction (user tx) desired by the user. It is also possible to distribute fee tokens or utility tokens in advance to the customer account of the user under the management of the company, and execute the transaction desired by the user based on this. However, a fee token is naturally required for transaction processing that distributes the fee token or utility token to the user, and approval of the transaction also takes a certain amount of time. Continuously performing this distribution to all customers is expensive in terms of money and time. If the system disclosed herein is used to aggregate fee tokens or utility tokens in an account (intermediary, for example, a financial company) that executes the delegation transaction (delegation tx), distribution processing is not required, and therefore financial and time costs can be reduced. There are also great benefits for the company that becomes the intermediary.

[0142] The intermediary to be delegated is not limited to a licensed company as described above. Even small and medium-sized enterprises and individuals can become intermediaries. By applying the system disclosed herein, the intermediary can safely shoulder the burden of the user. Until now, the intermediary was unable to be involved in the asset management of the customer (user), so the intermediary had to make the customer bear the burden of work and fees, but by shouldering this burden, the burden of the customer can be reduced. If the intermediary is unable to completely shoulder the fees, it is also possible to flexibly distribute the burden by collecting from the customer crypto assets that the customer can handle in the blockchain system 300, or a delegation fee outside the blockchain system 300. Some kind of incentive may be set for the payment of the delegation fee in a service that is realized by an app in the blockchain system 300 and enjoyed by the user. This makes it possible to build a scheme in which customers (users) pay each other delegation fees to execute transaction delegation.

[0143] The system 100 (method) of the present disclosure is applicable to, for example, Dapps (distributed application) operators or wallet app developers. For example, game Dapps are expected to attract general users who are not familiar with the blockchain system 300 as users of the game, but the procedures and management for payment of fee tokens are complicated. By applying the system 100 of the present disclosure, even users who cannot manage fee tokens can lower the barrier to becoming a user of the game. In addition, in the case of games, when an operator distributes specific tokens issued as part of a marketing campaign to users free of charge, if the user tries to trade these specific tokens in the blockchain system 300, there are exchanges that require fee tokens. In such cases, the application of the system 100 of the present disclosure can promote service use for users and operators.

[0144] The system 100 (method) of the present disclosure may be applied to B2B billing not only for Dapps operators and wallet app developers, but also for cloud vendors or SI (System Integration) vendors that provide services related to the blockchain system 300. In the spread phase of the blockchain system 300, like Dapps users, most of the customers of each vendor are not familiar with the blockchain system 300 and are unlikely to use a large number of tokens. It is expected that there will be an increasing need for a scheme in which the vendor shoulders the payment of fee tokens or utility tokens in order to operate services built using the blockchain system 300. In such use cases in the enterprise field, the use of fiat-backed stable coins is very effective.

[0145] If transaction delegation (tx delegation) using the system 100 (method) of the present disclosure is interpreted as "a transaction between a fee token or utility token and a delegation fee token that can be collected from a user," a trading market will be created. Although there are still challenges to popularization when transaction matching is taken into account, the requirements of a trading market are met simply by forming an open transaction pool. With a functioning trading market, it will also be possible to become a business by becoming a relay.

[0146] The embodiments disclosed above are illustrative in all respects and are not restrictive. The scope of the present invention is defined by the claims, and includes all modifications within the meaning and scope of the claims. [Explanation of symbols]

[0147] 1 1st device 10 Processing section 11 Storage section 13 Display section 14 Control section 1P 1st Program 2 Second device 20 Processing section 21 Memory section 2P 2nd Program 300 Blockchain System 30 nodes 301 Account Invocation Contract 302 Executor Account Contract 303 Target Contract 304 Delegation Fee Management Contract

Claims

1. A second device that stores account data in a blockchain system receives delegation data delegating execution of a transaction desired by the user in the blockchain system from a first device used by the user through communication outside the blockchain system; Based on the delegation data transmitted from the first device, create a delegation transaction to cause an execution smart contract to execute the desired transaction from the user's account in the blockchain system; broadcasting the delegation transaction to the blockchain system based on the account data; For a certain period of time, payment of fee tokens or utility tokens required for transactions executed based on the delegation transactions broadcast by the second device to the blockchain system is performed based on the account data stored in the second device; The second device collects the assets of the user corresponding to the payment in a lump sum manner, either in a post-payment or pre-payment manner. Transaction delegation method.

2. The first device of the user has account data that is not associated with a fee token or a utility token required for requesting a transaction in the blockchain system. The method of claim 1 .

3. The delegation data includes an address in the blockchain system of a target contract that is the target of the desired transaction, identification data of a target function in the target contract, and argument data to be passed to the target function. The method of claim 1 .

4. The delegation transaction includes a user-desired transaction including the address of the target contract, the identification data, and the argument data in a nested structure; The address of the executing smart contract that will be the executor of the user's desired transaction, or data for determining the address 4. The method of claim 3.

5. the delegation transaction includes a function that invokes a particular invocation smart contract when the delegation transaction is stored as a blockchain; The calling smart contract instructs the executing smart contract to execute the desired transaction based on the delegation transaction. A method for delegating a transaction according to any one of claims 1 to 4.

6. the delegation transaction includes terms of a delegation fee to the second device; The calling smart contract determines a delegation fee based on the delegation transaction; Request a transaction to pay the determined delegation fee to a delegation fee smart contract that effectuates the payment from the user's account to the intermediary.

6. The method of claim 5.

7. The delegation fee is different from the fee token or utility token.

7. The method of claim 6, wherein the transaction is committed.

8. The invocation smart contract allows invocation based on delegation transactions only from a second device having account data from a pre-stored account list. A method for transaction delegation according to any one of claims 5 to 7.

9. the delegation transaction includes a function that invokes the execute smart contract when the delegation transaction is stored as a blockchain; The execute smart contract, when invoked, executes the desired transaction entered with the invocation of the function. A method for delegating a transaction according to any one of claims 1 to 4.

10. the delegation transaction includes terms of a delegation fee to the second device; The execution smart contract determines a delegation fee based on the delegation transaction; Request a transaction to pay the determined delegation fee to a delegation fee smart contract that effectuates the payment from the user's account to the intermediary.

10. The method of claim 9.

11. The delegation fee is different from the fee token or utility token.

11. The method of claim 10.

12. The executing smart contract allows invocation based on the delegation transaction only from a second device having account data from a pre-stored account list. A method for delegating a transaction according to claim 10 or 11.

13. a first device used by a user; a second device having account data in the blockchain system; Including, The first device transmits delegation data delegating the execution of the user's desired transaction in the blockchain system via communication outside the blockchain system; The second device creates a delegation transaction based on the delegation data sent from the first device, the delegation transaction causing an execution smart contract to execute the desired transaction from the user's account in the blockchain system; The first device broadcasts the delegation transaction to the blockchain system based on the account data; For a certain period of time, payment of fee tokens or utility tokens required for transactions executed based on the delegation transactions broadcast by the second device to the blockchain system is performed based on the account data stored in the second device; The second device collects the assets of the user corresponding to the payment in a lump sum manner, either in a post-payment or pre-payment manner. Transaction delegation system.

14. A computer that stores account data in the blockchain system receiving delegation data including content of a user's desired transaction; creating a delegation transaction for executing the desired transaction in an executing smart contract from the user's account in the blockchain system based on the received delegation data; broadcasting the delegation transaction to the blockchain system based on the account data; A process of performing payment of fee tokens or utility tokens required for transactions performed based on the delegation transactions broadcasted to the blockchain system for a certain period of time based on the account data; and A process of collecting the user's assets corresponding to the payment in a lump sum, either in a deferred payment or in advance payment. A computer program that executes the following:

Images