JP7628289B2 - Transaction delegation method and transaction delegation system - Google Patents

Description

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.

The present invention relates to a transaction delegation method and a transaction delegation system in a blockchain.

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.).

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.

In systems that use blockchain, in addition to the fee tokens mentioned above, there are also smart contracts that require the payment of utility tokens when using the system.

JP 2020-080061 A

To use services based on blockchain technology, users need to manage fee tokens and utility tokens, which can be cumbersome, making it unlikely that blockchain systems will see explosive widespread adoption.

The present invention was made in consideration of these circumstances, and aims to provide a transaction delegation method and transaction delegation system that will support the spread of blockchain systems.

In one embodiment of the transaction delegation method disclosed herein, 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, delegating the execution of a transaction desired by the user in the blockchain system, creates 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 transmitted from the first device, and broadcasts the delegation transaction to the blockchain system based on the account data.

According to the present disclosure, users who receive 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.

FIG. 1 is a schematic diagram of a system of the present disclosure. FIG. 2 is a schematic diagram of a transaction delegation process in the system of the present disclosure. FIG. 2 is a block diagram showing a configuration of a first device. FIG. 2 is a block diagram showing a configuration of a second device of a relay. A block diagram showing the configuration of a node in a blockchain system. FIG. 2 is an overview of the processing in the system. FIG. 13 is a sequence diagram illustrating an example of a delegation transaction creation process. FIG. 13 is a sequence diagram illustrating an example of a procedure for delegating execution of a transaction. FIG. 13 is a sequence diagram illustrating an example of a transaction delegation process according to the first embodiment. FIG. 13 is a sequence diagram illustrating an example of a transaction delegation process according to the third embodiment. FIG. 13 is a sequence diagram illustrating an example of a transaction delegation process in the fourth embodiment. FIG. 23 is a sequence diagram illustrating an example of a transaction delegation process in the fifth embodiment. FIG. 23 is a sequence diagram illustrating an example of a transaction delegation process in the sixth embodiment.

This disclosure will be specifically described with reference to drawings showing embodiments thereof.

In this disclosure, a "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 content of the requested transaction is captured in the blockchain.

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

For example, in a Bitcoin (registered trademark)-based blockchain system, when a user requests a transaction to move assets (register a buy/sell), a difference is set between the input and output of the transaction, and a fee in BTC 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 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.

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.

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 must manage tokens by purchasing and sending the necessary tokens (fee tokens or utility tokens) via an exchange using their blockchain system account. Some services issue and distribute special tokens, but even if these special tokens are available, they may still need to be traded for fee tokens or utility tokens. Managing these various tokens requires highly specialized knowledge, making it a high hurdle for general users. The situation in which users who are unfamiliar with blockchain technology do not use blockchain-based services is a major challenge to the mass adoption of blockchain.

The transaction delegation method disclosed herein involves a first device used by a user, a second device that stores account data in a blockchain system, receiving delegation data from the first device used by the user via communication outside the blockchain system, delegating the execution of the user's desired transaction in the blockchain system, 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 transmitted from the first device, and broadcasting the delegation transaction, which involves the payment of a fee token or utility token required to execute the transaction, to the blockchain system based on the account data.

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, hereafter 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).

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 the authority as a delegation fee token, or they are not required to pay a delegation fee.

Transaction delegation (tx delegation) is done outside of the blockchain and can take any form. However, delegation from a user to an intermediary must contain enough data for the intermediary to execute the transaction the user wishes to execute (user tx).

A special transaction (nested tx) having a nested structure may be adopted for delegating a transaction. The special transaction sent 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 execute 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).

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

The second device, which is the relay, creates a delegation transaction (hereinafter, referred to as a delegation transaction (delegation tx)) in the form of a special transaction that includes 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).

The second device of the relayer requests a delegation transaction to the blockchain system based on the account (Relayer Account) for which the relay user has authority. The delegation transaction is executed against the 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 from the Account Caller Contract, but also directly from the Executor Account Contract of the blockchain account that is the executor of the transaction. Fee tokens or utility tokens, etc. required to request the execution of the transaction to the blockchain system at this time are executed from the relayer's account.

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 also performs the payment of the delegation fee token from the user to the intermediary.

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.

Figure 1 is a schematic diagram of a system 100 of the present disclosure. The system includes a first device 1 of a user outside the 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 this disclosure, a "blockchain system" refers to a system that includes multiple computers that can be connected to each other and a network that connects the multiple computers, and creates a blockchain through distributed processing of the multiple computers.

In the system 100 of the present disclosure, the user's first device 1 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 blockchain-based services. 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 send and receive data to and from the second device 2.

The second device 2 is managed by a relayer who has an account in the blockchain system 300 through which fee tokens and utility tokens can be transferred. The second device 2 can send and receive data with 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.

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 (made executable) to accounts. In the following example, the blockchain system 300 is described as using Ethereum blockchain technology, but is not limited to this. The blockchain system 300 may also be based on EOS.

In the blockchain system 300, instances of an account call contract 301 and an executor account contract 302 are generated. As described below (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, the blockchain system generates a delegation fee token management contract 304 that manages delegation fee tokens.

Of the smart contracts 303 corresponding to various applications present in the blockchain system 300, to request a process from a target contract 303 that executes the process desired by the user, a transaction execution process by an account with administrative authority to pay a fee token or utility token is required. However, to trade various tokens including fee tokens or utility tokens in the blockchain system 300, the user needs knowledge of blockchain technology, etc.

In the system 100 of the present disclosure, the user device (first device) 1 that actually receives the service delegates the transaction (user tx) that the user wishes to execute to the relay device (second device) 2 that owns 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 executing a transaction in the blockchain system 300 even if he or she cannot manage the tokens.

Figure 2 is an overview of the transaction delegation processing procedure in the system 100 of the present disclosure.

(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.

At step (1), the 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.

If the service is, for example, a game, the user may wish to execute a transaction to generate or transfer an item in the game, which is realized by a distributed application of the blockchain system 300 (of course, 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. Furthermore, 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 identifying the item, data identifying the transferee, etc.

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.

(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.

(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.

(4) By transmitting the broadcast, the transaction (user tx) that the user wishes to execute is executed by the blockchain account (executor account) corresponding to the user in the blockchain system 300. The fee tokens or utility tokens required to execute this transaction (user tx) are paid from the account (the relay's account or another account) specified by the relay when broadcasting the delegation transaction.

In this way, the device (first device) 1 used by the user who actually receives the service delegates the transaction (user tx) that the user wishes to execute to the relay device (second device) 2 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.

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.

The specific configuration of the system to achieve this processing will be explained below.

Figure 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 memory unit 11, a communication unit 12, a display unit 13, and an operation unit 14.

The processing unit 10 uses a processor such as a CPU (Central Processing Unit) or a GPU (Graphics Processing Unit), and 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, memory, and further the storage unit 11 and communication unit 12.

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 in the storage unit 11 in a non-rewritable manner (a wallet on a chip).

The first program 1P stored in the memory 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 memory unit 11.

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.

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 input voice using a microphone and accept the operation in an interactive format with the voice output from a speaker.

Figure 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 memory unit 21, and a communication unit 22.

The processing unit 20 uses a processor such as a CPU or a GPU, and a memory, etc. Based on the second program 2P stored in the memory unit 21, the processing unit 20 acquires data sent from the first device 1, creates a delegation transaction, and executes the transaction. The memory unit 21 uses a hard disk or flash memory, and stores programs and data referenced by the processing unit 20, including the second program 2P.

The second program 2P stored in the memory 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 memory unit 11.

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

Figure 5 is a block diagram showing the 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 memory unit 32, and a communication unit 33. Furthermore, as long as the node 30 is a device that includes at least the processing unit 31 and the communication unit 33, a part of the processing unit 31 can constitute part or all of the node.

The processing unit 31 uses a processor such as a CPU or GPU, and a memory, etc. The processing unit 31 may be configured as a single piece of hardware that integrates a processor, a memory, and further a storage unit 32 and a communication unit 33. The memory of the processing unit 31 may store a private key that is 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.

The storage unit 32 uses a hard disk or flash memory and stores programs and data referenced by the processing unit 31, including the node program. The storage unit 32 stores the 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 private key described above 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.

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

Figure 6 is an overview of the processing in the system 100. The user's first device 1 creates data addressed to the intermediary, including data required to create the transaction (user tx) that the user wishes to execute, and the blockchain account (executor account) that will execute the transaction, for the purpose of delegating the transaction (corresponding to (1) in Figure 2). In the example shown in Figure 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 verification method (sig), are created and sent to the intermediary's second device 2 (corresponding to (2) in Figure 2).

The second device 2, which acts as a 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 that the user wishes to execute (user tx), a delegation condition (cond), and a signature (sig) in a nested structure.

The second device 2 possesses a fee token or utility token that can execute a transaction in 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 against an account call contract 301 in the blockchain.

The account call contract 301 requests the execution of a transaction (user tx) to the executor account contract 302 acting as a user's account based on a delegation transaction (delegation tx). The executor account contract 302 executes the requested transaction (user tx) in the 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.

Figure 7 is a sequence diagram showing an example of a delegation transaction creation process. The process shown in the sequence diagram of Figure 7 corresponds to the details of the process up to (2) in Figure 2 or Figure 6.

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 the address corresponding to the user's private key and data necessary 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 necessary to determine the fee.

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, etc. The displayed delegation conditions may also be output in text form, or may be output using an icon.

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 processing of step S103 is skipped.

The processing unit 10 accepts confirmation of the content of the transaction (user tx) to be executed and the delegation conditions (cond) (step S104).

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.

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.

The processing unit 20 of the second device 2 receives the contents of the transaction (user tx) and the delegation conditions (cond) with an electronic 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 respond to the user's first device.

The processing unit 20 creates a delegation transaction (delegation tx) that embeds the content 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) that has a nested structure.

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

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.

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 string (so-called salt) when using a virtual account contract. The delegation conditions further include conditions regarding the delegation fee. The delegation fee is different from the fee token or utility token. The conditions regarding the delegation fee include 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 it, and data necessary for determining the delegation fee. The data necessary for determining the delegation fee is, for example, 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.

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, i.e., a token that can be circulated.

Figure 8 is a sequence diagram showing an example of a transaction delegation execution processing procedure. The processing procedure shown in the sequence diagram of Figure 8 includes the processing procedures (3) to (4) in Figure 2 or Figure 6.

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

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.

The instance of the account call contract 301 (hereinafter simply referred to as the account call contract) executes the call function to determine the address based on the data required to determine the address of the executor account contract 302 included in the delegation transaction (step S301).

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

If the verification in step S302 is successful in determining that the signature is valid, the account call contract 301 executes the next process. If the verification in step S302 determines that the signature is not valid, the account call contract 301 ends the process.

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 to the executor account contract the address of the target contract 303 of the transaction the user wishes to execute, the identifier of the target function, and the data to be input to the target function.

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

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). Execution of the specified processing results in the result of the transaction that the user wishes to execute (moving assets, storing data, or computing).

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

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, together with the instruction, the address of the delegation fee token management contract 304 and the address to which the delegation fee is to be paid.

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

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 specified payment destination address (step S601). The amount of the delegation fee may be zero. This ends the execution process of the delegation transaction.

The processing shown in the sequence diagrams of Figures 7 and 8 allows a user to enjoy the results of the execution of 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.

The process shown in the sequence diagram in Figure 8 is an atomic process in which calling a function of a contract 302 calls other functions, and other than signature verification, there is no decision made by each contract 301, 302, 303, 304, and it is executed as a series of processes. This is because the delegation transaction (delegation tx) 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.

In the above explanation, 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 delegation fees from users: collecting them using delegation fee tokens, and not collecting delegation fees. Below, several examples based on these variations will be explained.

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

The advantage of using a virtual account contract is that, first, a 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 deployment fee is required. 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 deployment fee is small. By executing deployment within a series of processes of transaction delegation (tx delegation), it is possible for the intermediary to shoulder the deployment fee.

The second benefit of using a virtual account contract is the high level of asset integrity. Since a virtual account contract before materialization is not materialized, the possibility of it being attacked is extremely low. Even if it were necessary to store the public key of the virtual account contract holder on the blockchain, it would be possible to conceal it by hashing, making attacks against the holder virtually impossible. This property is the same even when a virtual account contract is used alone.

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 separate, 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 are given below and explained. 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 same symbols as those in the above configuration are used to explain the detailed processing procedure.

[Example 1]
In the first embodiment, the account call contract 301 and the executor account contract 302 are separate 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 a user in a blockchain account of the blockchain system 300, and is not a fee token or a utility token.

In Example 1, the delegation transaction creation process shown in the sequence diagram of FIG. 7 is executed between the user's first device 1 and the relay's second device 2, and the transaction delegation process shown below is executed. FIG. 9 is a sequence diagram showing an example of the transaction delegation process in Example 1. Of the process steps shown in the sequence diagram of FIG. 9, the process steps shown in the sequence diagram of FIG. 8 are given the same step numbers and detailed descriptions are omitted.

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, it deploys the executor account contract 302 of the address determined in step S302 (step S312).

The account call contract 301 instructs the deployed executor account contract 302 to execute the target function in the target contract 303 (S303). The processing from step S304 onwards is the same as the processing with reference to the sequence diagram in Figure 8.

Note that the process shown in the sequence diagram in Figure 9 is executed only the first time the executor account contract 302 is called, and from the second time onwards, the process shown in the sequence diagram in Figure 8 is executed.

As described above, because a virtual account contract is used, no deployment fee needs to be paid until the first activation and deployment of the performer account contract 302.

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

The processing contents of each contract in Example 2 are the same as the processing procedures shown in the sequence diagrams of Figures 7 and 8, so they are not illustrated.

In Example 2, 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.

[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 an arbitrary token.

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 user's first device 1 and the relay's second device 2, but at that time, the data required to determine the address of the executor account contract 302 in the delegation conditions is not required.

Figure 10 is a sequence diagram showing an example of transaction delegation processing in Example 3. Among the processing steps shown in the sequence diagram of Figure 10, the processing steps common to the processing steps shown in the sequence diagram of Figure 8 are assigned the same step numbers and detailed descriptions are omitted.

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

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).

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 the input data as an argument to the target function of the target contract 303 and executes it (step S333).

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). The execution of the specified processing results in the result of the transaction that the user wishes to execute (moving assets, storing data, or computing).

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 delegation fee to the payment destination address in the amount determined in step S304, based on the address included in the delegation transaction (step S335). The executor account contract 302 ends the execution process of the delegation transaction.

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

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

In Example 4, the delegation transaction creation process shown in the sequence diagram of FIG. 7 is executed between the user's first device 1 and the relay's second device 2, but no delegation fee is collected. Therefore, the delegation transaction (delegation tx) that is 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 to determine the delegation fee, as delegation conditions.

Figure 11 is a sequence diagram showing an example of transaction delegation processing in Example 4. Among the processing steps shown in the sequence diagram of Figure 11, the steps common to the processing steps shown in the sequence diagram of Figure 8 are assigned the same step numbers and detailed descriptions are omitted.

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, it deploys the executor account contract 302 of the address determined in step S302 (step S342).

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

The executor account contract 302 inputs the passed data as an argument to the target function of the target contract 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 Figure 8 is not executed.

By the processing of step S401, the target contract 303 of the transaction that the user wishes to execute executes the processing specified by executing the target function (S501). By executing the specified processing, the result of the transaction that the user wishes to execute (moving assets, storing data, or computing) is obtained.

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

In Example 5, the delegation transaction creation process shown in the sequence diagram of FIG. 7 is executed between the user's first device 1 and the relay's second device 2, but no delegation fee is collected. Therefore, the delegation transaction (delegation tx) that is created does not require the address of the delegation fee token management contract 304, the address of the delegation fee payment destination, and the data required to determine the delegation fee, as delegation conditions.

Figure 12 is a sequence diagram showing an example of transaction delegation processing in Example 5. Among the processing steps shown in the sequence diagram of Figure 12, the steps common to the processing steps shown in the sequence diagram of Figure 8 are assigned the same step numbers and detailed descriptions are omitted.

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 electronic signature of the transaction (user tx) (S302).

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

The executor account contract 302 that receives the instruction 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 Figure 8 is not executed.

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

In Example 6, the delegation transaction creation process shown in the sequence diagram of FIG. 7 is executed between the user's first device 1 and the intermediary's second device 2, 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, or data required to determine the delegation fee. In Example 6, it is sufficient for the delegation conditions to include the address corresponding to the user's private key.

Figure 13 is a sequence diagram showing an example of transaction delegation processing in Example 6. Among the processing steps shown in the sequence diagram of Figure 13, the processing steps common to the processing steps shown in the sequence diagram of Figure 8 are assigned the same step numbers and detailed descriptions are omitted.

In Example 6, the account call contract 301 and the executor account contract 302 are the same. Therefore, step S301 of determining the address of the executor account contract 302 for the broadcasted delegation transaction (delegation tx) is omitted.

In Example 6, 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).

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 call 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 the 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 Figure 8 are not executed.

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 any blockchain account in the blockchain system 300. Therefore, the executor account contract 302 should be configured to accept instructions only from the account call contract 301, and the account call contract 301 should store accounts (relays) 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 (relays) that have the authority to issue execution instructions in a whitelist format so that it can reject delegated transactions from accounts that do not have the authority.

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 content is verified by an electronic signature for the content of the transaction (user tx) that the user wishes to execute and the delegation conditions. However, this 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 with 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.

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 allows a user to log in and manages the user's wallet (private key) in a centralized manner, it is also possible to handle advance and after-payment in legal tender when collecting the delegation fee. When collecting the delegation fee by after-payment, the assets held by the user may be used 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. If the asset is circulatable in the blockchain system 300, the contract regarding deferred payment and collateral can be made into a smart contract, which has a major advantage in that it can be executed without the risk of an intermediary or contract abandonment.

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 standards 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 transaction delegation fees from users. Of course, it is also possible to completely take over the delegation fee, and in that case, the burden is significantly reduced.

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

The system 100 disclosed herein 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 the private key stored in the user's first device 1). The user can protect his or 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 the private key stored in the user's first device 1), but it is possible to delegate the private information to the third party while keeping it secret.

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-backed stablecoins 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.

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 also 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 the transaction processing that executes the distribution of the fee token or utility token to the user, and it takes a certain amount of time to approve the transaction. It is expensive financially and time-wise to continuously perform this distribution to all customers. 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 necessary, and therefore financial and time costs can be reduced. There are also great benefits for the intermediary company.

The delegated intermediary 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), and therefore had to make the customer bear the burden of work and fees, but by bearing 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.

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 paying 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, if an operator distributes specific tokens issued as part of a marketing campaign to users free of charge, there are exchanges where fee tokens are required when users try to trade these specific tokens on the blockchain system 300. In such cases, the application of the system 100 of the present disclosure can promote service use for users and operators.

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 widespread use 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. Even in such use cases in the enterprise area, the use of fiat-backed stable coins will be very effective.

If transaction delegation (tx delegation) using the system 100 (method) disclosed herein is interpreted as "a transaction between a fee token or utility token and a delegation fee token that can be collected from users," a trading market will be created. Although there are still challenges to widespread adoption when transaction matching is taken into account, the requirements of a trading market will be met simply by forming an open transaction pool. With a functioning trading market, it will also be possible to operate as a business by becoming an intermediary.

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.

REFERENCE SIGNS LIST 1 First device 10 Processing unit 11 Memory unit 13 Display unit 14 Operation unit 1P First program 2 Second device 20 Processing unit 21 Memory unit 2P Second program 300 Blockchain system 30 Node 301 Account call contract 302 Executor account contract 303 Target contract 304 Delegation fee management contract

Claims (14)

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. The method of claim 1 , wherein the first device of the user has account data that does not have associated therewith a fee token or utility token required for requesting a transaction in the blockchain system. 2. The transaction delegation method of claim 1, wherein the delegation data includes an address in the blockchain system of a target contract that is the subject 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 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 method of claim 3 , further comprising: an address of the executing smart contract that will be the executor of the user-requested transaction, or data for determining the address. the delegation transaction includes a function that invokes a particular invocation smart contract when the delegation transaction is stored as a blockchain;
5. The method of claim 1, wherein the calling smart contract instructs the executing smart contract to execute the desired transaction based on the delegation transaction. 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;
6. The method of claim 5 , further comprising: requesting a transaction to pay the determined delegation fee to a delegation fee smart contract that effectuates the payment from the user's account to an intermediary. The method of claim 6 , wherein the delegation fee is different from a fee token or a utility token. 8. The method of claim 5, wherein the invocation smart contract allows invocation based on a delegation transaction only from a second device having account data from a pre-stored account list. the delegation transaction includes a function that invokes the execute smart contract when the delegation transaction is stored as a blockchain;
5. The method of claim 1 , wherein the execute smart contract, when invoked, executes the desired transaction input with the invocation of the function. 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;
10. The method of claim 9 , further comprising: requesting a transaction to pay the determined delegation fee to a delegation fee smart contract that effectuates the payment from the user's account to an intermediary. The method of claim 10 , wherein the delegation fee is different from a fee token or a utility token. 12. The method of claim 10 or 11 , wherein the executing smart contract allows invocation based on the delegated transaction only from a second device having account data of a pre-stored account list. a first device used by a user;
a second device having account data in the blockchain system;
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. 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