JP7478240B2 - Escrow transaction method and system using smart contract on blockchain - Google Patents

Description

The following description relates to an escrow transaction method and system that uses smart contracts on a blockchain.

Blockchain is a distributed data storage technology that manages data in blocks, links them like a chain, and copies and stores them simultaneously on multiple computers. It is also called a distributed ledger. Instead of storing transaction records on a centralized server, transaction details are sent to all users participating in the transaction, and all transaction participants share and compare information each time a transaction is made, thereby preventing data forgery and alteration. For example, Korean Patent Publication No. 10-2019-0133573 relates to a blockchain transaction system and method using a smart contract, and provides an interface to enable transactions and services to be used through smart contracts while utilizing the unique characteristics of blockchain. In this system, a support requester posts support request information in a network ecosystem, a service provider posts a transaction or contract, and a person who wishes to provide support selects a button (action) such as providing support on related information or a service user agrees to a transaction (signature), and the reward system for each activity is divided into grades so that the ``participation and sharing'' activity is continuously activated through one mobile app in the network ecosystem, and a method thereof is disclosed.

In such traditional blockchain transactions, if the sender and receiver's wallet addresses are specified and a transaction is requested, the transaction is completed the moment the block containing the transaction is confirmed. For this reason, it is not suitable when the trust relationship between the sender and receiver is unclear or when certain conditions must be met to complete the transaction.

By clearly indicating the conditions for a transaction to be concluded in a smart contract, we provide an escrow transaction method and system that allows for the transfer of funds to the recipient when certain conditions are met after depositing the funds, rather than the immediate transfer.

The present invention provides an escrow transaction method for a blockchain system, the method including the steps of depositing a currency corresponding to a remittance of the sender in an escrow contract included in the blockchain system for an escrow transaction from a sender to a receiver, transferring the currency deposited in the escrow contract to the receiver if a predefined condition for the remittance of the sender is satisfied, and returning the currency deposited in the escrow contract to the sender if the predefined condition for the remittance is not satisfied.

According to one aspect, the step of depositing the currency may include a step of requesting a token contract of the blockchain system that has received an approval request from the sender to transfer the currency, and a step of receiving from the token contract a transfer of tokens that belong to the token contract and have been approved in accordance with the sender's request, and depositing the tokens in the escrow contract in the currency corresponding to the sender's transfer.

In another aspect, the depositing of the currency may include receiving an escrow token transfer request from a token contract of the blockchain system that has received an escrow transfer request from the sender, requesting a transfer from the token contract in response to the escrow token transfer request, and depositing the tokens transferred in accordance with the request to the token contract in the escrow contract in a currency corresponding to the sender's transfer.

In another aspect, the escrow transaction method may further include a step of installing the escrow contract according to a request from an owner of the escrow contract, a step of setting the escrow contract in the token contract according to a request from the escrow contract owner, and a step of setting the token contract in the escrow contract according to control of the token contract.

In another aspect, the depositing of the currency may include receiving a token fallback request including meta-information related to an escrow transaction from a token contract of the blockchain system that has received a remittance request from the sender, and receiving a remittance of tokens belonging to the token contract from the sender in a currency corresponding to the remittance of the sender based on information regarding the escrow transaction obtained by analyzing the meta-information, and depositing the tokens in the escrow contract.

In another aspect, the escrow transaction method may further include installing the escrow contract in accordance with a request from an owner of the escrow contract, and linking the escrow contract with the token contract using an address of the token contract included in the request from the escrow contract owner.

In another aspect, the step of transferring the deposited currency to the recipient may be characterized by requesting a token contract of the blockchain system to transfer the currency from the escrow contract to the recipient in accordance with an escrow receipt request made by a caller specified in the escrow contract when a predefined condition for the sender's transfer is met.

In another aspect, the step of returning the deposited currency to the sender may be characterized by requesting a token contract of the blockchain system to transfer the currency from the escrow contract to the sender in accordance with an escrow cancellation request made by a caller specified in the escrow contract if a predefined condition for the sender's remittance is not met.

In another aspect, the caller may be the owner of the escrow contract or the sender.

In another aspect, the currency corresponding to the sender's remittance may include the base currency of the blockchain system.

According to yet another aspect, the currency may be characterized as including a token belonging to a token contract further included in the blockchain system.

A computer program recorded on a computer-readable recording medium is provided for combining with a computer device to cause the computer device to execute the method.

A computer-readable recording medium is provided on which a program for causing a computer device to execute the method is recorded.

A computer device is provided that includes at least one processor that is implemented to execute computer-readable instructions, and is characterized in that, for an escrow transaction from a sender to a receiver, the at least one processor deposits currency corresponding to the sender's remittance in an escrow contract included in the blockchain system, transfers the currency deposited in the escrow contract to the receiver if predefined conditions for the sender's remittance are met, and returns the currency deposited in the escrow contract to the sender if predefined conditions for the remittance are not met.

By clearly stating the conditions for a transaction to be completed in a smart contract, the transfer will not be instantaneous, but rather the money can be held in escrow and then transferred to the recipient when certain conditions are met.

The sender can cancel a transfer if certain conditions are met.

Since the source code of smart contracts is published on the blockchain network, it is possible to ensure transparency about the logic by which the escrow function operates.

FIG. 1 illustrates an example of a network environment in accordance with an embodiment of the present invention. FIG. 2 is a block diagram illustrating an example computing device according to an embodiment of the present invention. FIG. 2 illustrates an example of a base currency escrow transaction in accordance with one embodiment of the present invention. FIG. 2 illustrates an example of a base currency escrow transaction in accordance with one embodiment of the present invention. FIG. 2 illustrates an example of a base currency escrow transaction in accordance with one embodiment of the present invention. FIG. 1 illustrates a first example escrow transaction for a token in accordance with an embodiment of the present invention. FIG. 1 illustrates a first example escrow transaction for a token in accordance with an embodiment of the present invention. FIG. 1 illustrates a first example escrow transaction for a token in accordance with an embodiment of the present invention. FIG. 13 illustrates a second example escrow transaction for a token in accordance with an embodiment of the present invention. FIG. 13 illustrates a second example escrow transaction for a token in accordance with an embodiment of the present invention. FIG. 13 illustrates a second example escrow transaction for a token in accordance with an embodiment of the present invention. FIG. 13 illustrates a second example escrow transaction for a token in accordance with an embodiment of the present invention. FIG. 13 illustrates a third example escrow transaction for a token in accordance with an embodiment of the present invention. FIG. 13 illustrates a third example escrow transaction for a token in accordance with an embodiment of the present invention. FIG. 13 illustrates a third example escrow transaction for a token in accordance with an embodiment of the present invention. FIG. 13 illustrates a third example escrow transaction for a token in accordance with an embodiment of the present invention. 4 is a flow chart illustrating an example method for an escrow transaction in accordance with one embodiment of the present invention.

The following describes the embodiments in detail with reference to the attached drawings.

The escrow transaction system according to an embodiment of the present invention may be a blockchain system realized by at least one computer device, and the escrow transaction method according to an embodiment of the present invention may be executed by at least one computer device included in the escrow transaction system. In the computer device, a computer program according to an embodiment of the present invention may be installed and executed, and the computer device may execute the escrow transaction method according to an embodiment of the present invention according to the control of the executed computer program. The above-mentioned computer program may be recorded on a computer-readable recording medium in combination with the computer device to cause the computer to execute the escrow transaction method.

Figure 1 is a diagram showing an example of a network environment in one embodiment of the present invention. The network environment in Figure 1 shows an example including multiple electronic devices 110, 120, 130, 140, multiple servers 150, 160, and a network 170. Figure 1 is merely an example for explaining the invention, and the number of electronic devices and the number of servers are not limited to those shown in Figure 1. Furthermore, the network environment in Figure 1 is merely an example of an environment applicable to this embodiment, and the environment applicable to this embodiment is not limited to the network environment in Figure 1.

The electronic devices 110, 120, 130, and 140 may be fixed terminals or mobile terminals realized by computer devices. Examples of the electronic devices 110, 120, 130, and 140 include smartphones, mobile phones, navigation systems, personal computers (PCs), notebook PCs, digital broadcasting terminals, personal digital assistants (PDAs), portable multimedia players (PMPs), and tablet PCs. As an example, FIG. 1 shows a smartphone as an example of the electronic device 110, but in an embodiment of the present invention, the electronic device 110 may refer to one of various physical computer devices that can communicate with other electronic devices 120, 130, and 140 and/or servers 150 and 160 via a network 170 using a substantially wireless or wired communication method.

The communication method is not limited, and may include not only a communication method using a communication network that the network 170 can include (for example, a mobile communication network, a wired Internet, a wireless Internet, or a broadcasting network), but also short-range wireless communication between devices. For example, the network 170 may include any one or more of the following networks: a personal area network (PAN), a local area network (LAN), a campus area network (CAN), a metropolitan area network (MAN), a wide area network (WAN), a broadband network (BBN), and the Internet. Furthermore, the network 170 may include any one or more of the following network topologies, including, but not limited to, a bus network, a star network, a ring network, a mesh network, a star-bus network, a tree or hierarchical network, and the like.

Each of the servers 150, 160 may be implemented by one or more computing devices that communicate with the multiple electronic devices 110, 120, 130, 140 via the network 170 to provide instructions, code, files, content, services, etc. For example, the server 150 may be a system that provides services (e.g., content provision services, group calling services (or audio conferencing services), messaging services, email services, social networking services, map services, translation services, financial services, payment services, search services, location-based services, etc.) to the multiple electronic devices 110, 120, 130, 140 connected via the network 170.

Figure 2 is a block diagram showing an example of a computer device in one embodiment of the present invention. Each of the multiple electronic devices 110, 120, 130, and 140 and each of the servers 150 and 160 described above may be realized by the computer device 200 shown in Figure 2.

Such a computer device 200 may include a memory 210, a processor 220, a communication interface 230, and an input/output interface 240, as shown in FIG. 2. The memory 210 is a computer-readable recording medium and may include a RAM (Random Access Memory), a ROM (Read Only Memory), and a permanent mass storage device such as a disk drive. Here, a permanent mass storage device such as a ROM or a disk drive may be included in the computer device 200 as a separate permanent storage device separate from the memory 210. In addition, the memory 210 may store an operating system and at least one program code. Such software components may be loaded into the memory 210 from a computer-readable recording medium separate from the memory 210. Such a separate computer-readable recording medium may include a computer-readable recording medium such as a floppy drive, a disk, a tape, a DVD/CD-ROM drive, or a memory card. In other embodiments, the software components may be loaded into the memory 210 through the communication interface 230 rather than through a computer-readable recording medium. For example, the software components may be loaded into the memory 210 of the computer device 200 based on a computer program that is installed by a file received via the network 170.

The processor 220 may be configured to process computer program instructions by performing basic arithmetic, logic, and input/output operations. The instructions may be provided to the processor 220 by the memory 210 or the communication interface 230. For example, the processor 220 may be configured to execute instructions received according to program code recorded in a recording device such as the memory 210.

The communication interface 230 may provide a function for the computer device 200 to communicate with other devices (for example, the above-mentioned recording device) via the network 170. As an example, requests, commands, data, files, etc. generated by the processor 220 of the computer device 200 according to program code recorded in a recording device such as the memory 210 may be transmitted to other devices via the network 170 under the control of the communication interface 230. Conversely, signals, commands, data, files, etc. from other devices may be received by the computer device 200 through the communication interface 230 of the computer device 200 via the network 170. The signals, commands, data, etc. received through the communication interface 230 may be transmitted to the processor 220 or the memory 210, and the files, etc. may be recorded on a recording medium (the above-mentioned permanent recording device) that the computer device 200 may further include.

The input/output interface 240 may be a means for interfacing with the input/output device 250. For example, the input device may include devices such as a microphone, keyboard, or mouse, and the output device may include devices such as a display and a speaker. As another example, the input/output interface 240 may be a means for interfacing with a device in which functions for input and output are integrated into one, such as a touch screen. The input/output device 250 may be configured as a single device together with the computer device 200.

Also, in other embodiments, computer device 200 may include fewer or more components than those of FIG. 2. However, most prior art components need not be explicitly shown in the figures. For example, computer device 200 may be implemented to include at least some of the input/output devices 250 described above, and may further include other components such as a transceiver, a database, etc.

In a blockchain network according to an embodiment of the present invention, a base coin defined in a protocol and a token defined by a smart contract may be used for transactions. In this case, since the base currency does not depend on a specific smart contract, escrow transactions are possible by defining three functions, deposit, receive, and cancel, in a smart contract for escrow (hereinafter, "escrow contract"). The terms "sender," "receiver," and "third party" described below may essentially refer to electronic devices used by the sender, receiver, or third party for remittance processing.

Figures 3 to 5 show an example of an escrow transaction of a base currency in one embodiment of the present invention. A smart contract 310 for escrow is installed in the blockchain system 300, and the escrow transaction may be processed by calling three functions for depositing, receiving, and canceling money, which is the base currency.

Figure 3 shows an example in which sender A 320 deposits money, which is a base currency, in the escrow contract 310 by calling an escrow transfer function ("escrowTransfer()") defined in the escrow contract 310. In this case, the first parameter "B" of the escrow transfer function may be an identifier of receiver B 330, who is the recipient of the corresponding transfer, and the second parameter "value" may indicate the amount of the corresponding transfer. "Coin Transfer" may indicate the process of transferring the base currency from sender A 320 to the escrow contract 310.

Figure 4 shows an example in which an escrow receive function ("escrowReceive()") defined in the escrow contract 310 is called to transfer the deposited money to the recipient B 330 specified in the escrow contract 310. As an example, the escrow receive function may include a parameter for identifying the relevant transfer. A caller that can call the escrow receive function may be specified in the escrow contract 310. Such a caller may be the recipient himself or a trusted third party. The embodiment of Figure 4 shows an example in which the caller is specified as the escrow contract owner 410, who is the owner or developer of the escrow contract 310, which is a trusted third party. The escrow contract owner 410 may call an escrow receive function in the escrow contract 310 when predefined conditions for the transfer are met, which may result in the money deposited in the escrow contract 310 being transferred to the recipient B 330 specified in the escrow contract 310. The function "baseCoinTransfer(B, value)" shown in FIG. 4 is a function for transferring base currency, and may refer to a function in which the escrow contract 310 transfers money, which is the base currency corresponding to the second parameter "value", to the recipient B 330 identified from the first parameter "B".

5 shows an example in which an escrow cancel function ("escrowCancel()") is called to return the amount deposited by sender A320 in the escrow contract 310 if predefined conditions are not met for the corresponding transfer. As an example, the escrow cancel function may include a parameter for identifying the corresponding transfer. A caller that can call the escrow cancel function may be specified in the escrow contract 310. Such a caller may be the sender himself or a trusted third party. The embodiment of FIG. 5 shows an example in which the escrow contract owner 410, who is a trusted third party, is specified as the caller. The escrow contract owner 410 may call an escrow cancel function in the escrow contract 310 if predefined conditions are not met for the corresponding transfer, thereby allowing the money deposited in the escrow contract 310 to be transferred to sender A320. The function "baseCoinTransfer(A, value)" shown in FIG. 5 may refer to a function for transferring a base currency, in which the escrow contract 310 transfers money, which is the base currency corresponding to the second parameter "value", to the sender A 320 identified from the first parameter "A".

Escrow transactions for tokens are conducted in a similar manner to the escrow transactions for base currencies described above with reference to Figures 3-5. However, because tokens belong to a specific smart contract, functions in the token contract must be called in addition to functions in the escrow contract to transfer tokens. Below, we explain three methods for performing escrow transactions for tokens.

Figures 6-8 show a first example of an escrow transaction for a token in one embodiment of the present invention. A Decentralized Application (DApp) 600 installed and executed in the blockchain system 300 is an application that utilizes blockchain technology to distribute, store, and execute information on a network without going through a central server. The DApp 600 may include an escrow contract 610 and a specific smart contract to which the token belongs (hereinafter, "token contract 620").

Figure 6 shows an example of a process in which sender A 320 first deposits money in an escrow contract 610 in order to transfer money, which is a token, to receiver B 320. At this time, sender A 320 may request approval of the transfer from the token contract 620 to which the token belongs using an approval function ("approve()"), and may also request the transfer from the escrow contract 610 using an escrow transfer function ("escrowTransfer()").

The first parameter of the approval function may represent the recipient of the remittance. At this time, money must be deposited in the escrow contract 610. In other words, the first parameter "escrowContractAddress" of the approval function of the token contract 620 called by the sender A320 may represent an address by which the token contract 620 identifies the escrow contract 610 so that money can be transferred from the token contract 620 to the escrow contract 610. The second parameter "value" of the approval function may indicate the amount of the remittance, and the third parameter "currentAllowance" may represent the amount of money currently approved for remittance.

On the other hand, the first parameter "B" of the escrow transfer function may indicate the recipient B320 who is the actual recipient of the transfer, and the second parameter "value" may indicate the amount of the transfer. In response to the invocation of the escrow transfer function, the escrow contract 610 may request the token contract 620 to transfer the money. In the function "transferFrom()", the first parameter "A" may represent the sender A320, the second parameter "escrowContractAddress" may represent the escrow contract 610, and the third parameter "value" may represent the amount of the transfer. In other words, the escrow contract 610 may request the token contract 620 to transfer the money of the sender A320 from the token contract 620 to the escrow contract 610. In this case, the token contract 620 may transfer the amount requested by the function "transferFrom()" to the escrow contract 610 within the amount approved by the sender A320 using the approval function (the amount requested by the escrow contract 610 to transfer) (effectively changing the owner of the corresponding token from the sender A320 to the escrow contract 610), thereby depositing the money of the sender A320 in the escrow contract 610. In FIG. 6, "Token Transfer" may indicate the process in which the token contract 620 transfers the token to the escrow contract 610.

FIG. 7 illustrates an example in which the escrow contract owner 630 , a trusted third party, calls an escrow receive function ("escrowReceive()") defined in the escrow contract 610 when a predefined condition for the corresponding remittance is satisfied. In this case, the escrow receive function may include a parameter for identifying the corresponding remittance. In this case, the escrow contract 610 may call a transfer function ("transfer()") in the token contract 620 to transfer the deposited money to the recipient B 330. In this case, the first parameter "B" of the transfer function may be an identifier of the recipient B 330 to which the remittance is to be made, and the second parameter "value" may mean the amount of the remittance. In this case, the token contract 620 may transfer the money deposited in the escrow contract 610 to the recipient B 330 by changing the owner of the token deposited in the escrow contract 610 to the recipient B 330. In FIG. 7, “Token Transfer” may indicate the process in which sender A 320 transfers the deposited money to receiver B 330 through an escrow contract 610 .

FIG. 8 illustrates an example in which, if a predefined condition for the corresponding transfer is not met, an escrow cancel function ("escrowCancel()") is called, and the sender A 320 receives a refund of the amount deposited in the escrow contract 610. As an example, the escrow cancel function may include a parameter for identifying the corresponding transfer. A caller that can call the escrow cancel function may be specified in the escrow contract 610. Such a caller may be the sender himself or a trusted third party. In the embodiment of FIG. 8, an example is illustrated in which the escrow contract owner 6 3 0, which is a trusted third party, is specified as the caller. If the escrow contract owner 6 3 0 calls the escrow cancel function for the corresponding transfer, the escrow contract 610 may call a transfer function ("transfer()") defined in the token contract 620. In this case, the first parameter "A" of the remittance function may be an identifier of the sender A 320 to be remitted, and the second parameter "value" may mean the amount of the remittance. Thus, the token contract 620 may process the remittance from the escrow contract 610 to the sender A 320 by changing the token deposited in the escrow contract 610 to the ownership of the sender A 320. In FIG. 8, "Token Transfer" indicates the process in which the escrow contract 610 returns the money deposited by the sender A 320 to the sender A 320.

In the embodiment of Figures 6-8, the escrow contract 610 and the token contract 620 may be maintained as separate interfaces because the escrow contract 610 acts as a separate entity that receives and transmits token transfers from the token contract 620.

Figures 9-12 show a second example of an escrow transaction for a token in one embodiment of the present invention. The DApp 900 according to this embodiment may be installed and executed in the blockchain system 300 and may include a token contract 910 and an escrow contract 920.

9 illustrates an example of a process in which the escrow contract owner 930 installs the token contract 910 and the escrow contract 920 in the DApp 900. At this time, the escrow contract owner 930 may directly install the escrow contract 920 in the DApp 900, or may control the token contract 910 to set the escrow contract 920 using a function defined to be executed when installing a contract in the token contract 910 already installed in the DApp 900. In this case, the token contract 910 may install the escrow contract 920 and install the address of the token contract 910 in the escrow contract 920. For example, the token contract 910 may install the escrow contract 920 using an escrow contract setting function ("setEscrowContract(escrow_contract_address=contractAddress1)"), and may set the address of the token contract in the escrow contract 920 using a token contract address setting function ("TokenContract(token_contract_address=contractAddress2)"). Here, "contractAddress1" may mean the address of the escrow contract 920, and "contractAddress2" may mean the address of the token contract 910.

Figure 10 shows an example of a process in which a sender A 320 requests an escrow transaction and deposits a token in an escrow contract 920. First, when the sender A 320 requests the token contract 910 to transfer to the receiver B 330 using an escrow transfer function ("escrowTransfer()") defined in the token contract 910, the token contract 910 may first approve the transfer using an approval function ("approve()"), and then transmit the sender A 320's request for transfer to the receiver B 330 to the escrow contract 920 using an escrow token transfer function ("escrowTokenTransfer()"). The approval function may use the address of the escrow contract 920 and the amount of the transfer as parameters to approve the transfer of the amount of the transfer to the escrow contract 920. In this case, the escrow contract 920 may use the function "transferFrom()" to request the token contract 910 to transfer to the escrow contract 920. The first parameter "ES" of the function "transferFrom()" may indicate the address of the escrow contract 920, and the second parameter "value" may indicate the amount of transfer. In FIG. 10, "Token Transfer" may mean that the token that the sender A320 intends to transfer to the receiver B330 is transferred to the escrow contract 920 (effectively, the owner of the token in the token contract 910 is changed from the sender A320 to the escrow contract 920) and deposited in the escrow contract 920.

Figure 11 shows an example in which the escrow contract owner 930, a trusted third party, calls the escrow receive function ("escrowReceive()") defined in the escrow contract 920 when predefined conditions for the relevant remittance are met. At this time, the escrow receive function may include a parameter for identifying the relevant remittance. In this case, the escrow contract 920 may call the transfer function ("transfer()") defined in the token contract 910. At this time, the first parameter "B" of the transfer function may be an identifier of the recipient B330 who is the target of the remittance, and the second parameter "value" may mean the amount of the remittance. Therefore, the token contract 910 may transfer the money deposited from the escrow contract 920 to the recipient B330 by changing the owner of the token of the escrow contract 920 to the recipient B330. In FIG. 11, "Token Transfer" may indicate the process in which sender A320 transfers the deposited money to receiver B330 through escrow contract 920.

FIG. 12 illustrates an example in which the sender A 320 returns the amount deposited in the escrow contract 920 by calling the escrow cancel function ("escrowCancel()") when a predefined condition is not met for the corresponding transfer. As an example, the escrow cancel function may include a parameter for identifying the corresponding transfer. A caller that can call the escrow cancel function may be specified in the escrow contract 920. Such a caller may be the sender himself or a trusted third party. In the embodiment of FIG. 12, an example is illustrated in which the escrow contract owner 930, who is a trusted third party, is specified as the caller. If the escrow contract owner 930 calls the escrow cancel function for the corresponding transfer, the escrow contract 920 may call the transfer function ("transfer()") defined in the token contract 910. In this case, the first parameter "A" of the remittance function may be an identifier of the sender A320 to be remitted, and the second parameter "value" may indicate the amount of the remittance. In this case, the token contract 910 may return the deposited amount by changing the owner of the token of the escrow contract 920 to the sender A320. In FIG. 12, "Token Transfer" may indicate a process in which the escrow contract 920 returns the money deposited by the sender A320 to the sender A320.

In the embodiment of Figures 9-12, a token contract 910 supporting an escrow contract 920 is used to process the process for sender A320 to deposit the money to be sent using a single transaction.

Figures 13-16 show a third example of an escrow transaction for a token in one embodiment of the present invention. The DApp 1300 according to this embodiment may be installed and executed in the blockchain system 300 and may include a token contract 1310 and an escrow contract 1320.

The embodiment of FIG. 13 illustrates an example of a process in which the escrow contract owner 930 installs the escrow contract 1320 in the DApp 1300. At this time, the escrow contract owner 1330 may link the escrow contract 1320 and the token contract 1310 using a function defined to be executed when installing the contract in the escrow contract 1320.

Figure 14 shows an example of a process in which a sender A320 requests an escrow transaction and deposits a token in the escrow contract 1320. First, the sender A320 may request the token contract 1310 to transfer money to the escrow contract 1320 using a transfer function ('transfer()') defined in the token contract 1310. Here, the first parameter of the transfer function may be the address of the escrow contract 1320, such as 'escrow_token_addr = contractAddress1'. The second parameter of the transfer function may be the amount to be transferred, such as 'value'. The third parameter of the transfer function may indicate meta information (recipient, memo) related to the escrow, such as '0x+'transferid:toAddress:memo'. If the recipient is a Contract Address (CA) that is not an Externally Owned Wallet (EOA), the token contract 1310 may call a token fallback function ("tokenFallback()") defined in a contract (the escrow contract 1320 in this embodiment) corresponding to the CA, and the above-mentioned meta-information may be included in the data field of the token fallback function in the form of bytes. In this case, the escrow contract 1320 may deposit the money transferred from the sender A 320 by analyzing the meta-information and executing the escrow logic. Here, "Token Transfer" may mean that the token that the sender A 320 intends to transfer to the recipient B 330 is transferred to the escrow contract 920 and deposited. The function "escrow_token_transfer()" may be a function that is called within the token fallback function to record the recipient of the transfer in the escrow contract 920 and to handle post-processing such as data validation.

Figure 15 shows an example in which the escrow contract owner 1330, a trusted third party, calls the escrow receive function ("escrowReceive()") defined in the escrow contract 1320 when predefined conditions for the relevant transfer are met. At this time, the escrow receive function may include a parameter for identifying the relevant transfer. In this case, the escrow contract 1320 may call the transfer function ("transfer()") defined in the token contract 1310. At this time, the first parameter "B" of the transfer function may be an identifier of the recipient B330 to whom the transfer is to be made, and the second parameter "value" may mean the amount of the transfer. Therefore, the token contract 1310 may process the money deposited in the escrow contract 920 to be transferred to the recipient B330 by changing the owner of the token of the escrow contract 920 to the recipient B330. In FIG. 15, "Token Transfer" may indicate the process in which sender A320 transfers the deposited money to receiver B330 through escrow contract 1320.

FIG. 16 illustrates an example in which the sender A 320 returns the amount deposited in the escrow contract 920 by invoking the escrow cancel function ("escrowCancel()") when a predefined condition for the corresponding transfer is not met. As an example, the escrow cancel function may include a parameter for identifying the corresponding transfer. A caller that can call the escrow cancel function may be specified in the escrow contract 1320. Such a caller may be the sender himself or a trusted third party. In the embodiment of FIG. 16, an example is illustrated in which the escrow contract owner 1330, who is a trusted third party, is specified as the caller. If the escrow contract owner 1330 invokes the escrow cancel function for the corresponding transfer, the escrow contract 1320 may invoke the transfer function ("transfer()") defined in the token contract 1310. In this case, the first parameter "A" of the remittance function may be an identifier of the sender A320 to be remitted, and the second parameter "value" may mean the amount of the remittance. Therefore, the token contract 1310 may return the money deposited in the escrow contract 1320 to the sender A320 by changing the owner of the token of the escrow contract 1320 to the sender A320. In FIG. 16, "Token Transfer" may indicate a process in which the escrow contract 1320 returns the money deposited by the sender A320 to the sender A320.

In the embodiment of Figures 13 to 16, the specifications of the token contract 1310 are not changed, and escrow transactions can be processed simply by adding the escrow contract 1320. For example, there is no need for the token contract 1310 to individually recognize the escrow contract 1320. In addition, it becomes possible for sender A320 to process the process of depositing the money to be remitted using a single transaction.

Conditions for remittance may be defined in various ways depending on the person setting the condition and the circumstances. For example, the sender's request to remit may be considered to satisfy the condition, and the sender's request to cancel the remittance may be considered to not satisfy the condition. In addition, conditions may be defined in various ways, such as making the remittance after a certain amount of time has passed or on a specific date.

The functions such as approve(), transfer(), transferFrom(), and fallback() described above may be based on the ERC-20 (Ethereum Request for Comments-20) interface, which is the basic token standard for Ethereum.

FIG. 17 is a flowchart showing an example of an escrow transaction method according to an embodiment of the present invention. The escrow transaction method according to this embodiment may be executed by an escrow contract included in the blockchain system 300, and may be substantially executed by the processor 220 of the computer device 200 executing the code of such an escrow contract. In this case, the processor 220 of the computer device 200 may be realized to execute control instructions from the operating system code and at least one computer program code (for example, the code of the escrow contract) included in the memory 210. Here, the processor 220 may control the computer device 200 so that the computer device 200 executes steps 1710 to 1740 included in the method of FIG. 17 according to the control instructions provided by the code recorded in the computer device 200.

At step 1710, the computing device 200 may deposit currency corresponding to the sender's transfer in an escrow contract included in the blockchain system for an escrow transaction from the sender to the receiver.

As described above, in a blockchain system, the currency corresponding to the sender's remittance may include the base currency of the blockchain system or a token belonging to a token contract further included in the blockchain system. In this case, if the currency corresponding to the sender's remittance is the base currency of the blockchain system, the computer device 200 may directly deposit the base currency corresponding to the sender's remittance in an escrow contract. On the other hand, if the currency corresponding to the sender's remittance is a token belonging to a specific token contract, the token corresponding to the sender's remittance may be deposited in an escrow contract using the token contract, as in the following embodiment.

In one embodiment, in step 1710, the computer device 200 may request a currency transfer to a token contract of a blockchain system that has received an approval request from the sender, receive a transfer of tokens that belong to the token contract and have been approved according to the sender's request from the token contract, and deposit the tokens in an escrow contract in the currency corresponding to the sender's transfer. The deposit method according to the embodiment has been described in detail with reference to FIG. 6.

In another embodiment, the computer device 200 may receive an escrow token remittance request from a token contract of a blockchain system that has received an escrow remittance request from a sender in step 1710, request a remittance to the token contract in response to the escrow token remittance request, and deposit the remitted token in the escrow contract in a currency corresponding to the remittance of the sender according to the request to the token contract. The depositing method according to this embodiment has been described in detail with reference to FIG. 10. Meanwhile, in the installation process of the escrow contract for this embodiment, the computer device 200 may install the escrow contract according to a request from the owner of the escrow contract, set the escrow contract in the token contract according to a request from the escrow contract owner, and set the token contract in the escrow contract according to the control of the token contract. In this case, the escrow contract and the token contract are linked to each other, and the token contract can recognize the escrow contract.

In another embodiment, the computer device 200 may receive a token fallback request including meta information related to an escrow transaction from a token contract of the blockchain system that has received a remittance request from a sender in step 1710, and may receive a remittance of tokens belonging to the token contract in a currency corresponding to the remittance of the sender from the sender based on information about the escrow transaction obtained by analyzing the meta information, and deposit the tokens in the escrow contract. The deposit method according to this embodiment has been described in detail with reference to FIG. 14. In this case, in the process of installing the escrow contract for this embodiment, the computer device 200 may install the escrow contract according to a request from the owner of the escrow contract, and may link the escrow contract and the token contract according to the address of the token contract included in the request from the escrow contract owner. In this case, since the specifications of the token contract are not changed, it is not necessary to go through a process of individually recognizing the escrow contract.

In step 1720, the computer device 200 may determine whether a predefined condition is met for the sender's remittance. If the predefined condition is met, the computer device 200 may execute step 1730, and if the predefined condition is not met, the computer device 200 may execute step 1740. In effect, whether the predefined condition is met may be determined by a caller specified in the escrow contract, and the caller may call an escrow receive function if the predefined condition is met, and an escrow cancel function if the predefined condition is not met. In other words, the computer device 200 may determine that the predefined condition is met if the escrow receive function is called, and may determine that the predefined condition is not met if the escrow cancel function is called.

At step 1730, the computer device 200 may transfer the currency deposited in the escrow contract to the recipient. As an example, when a predefined condition for the sender's transfer is met, the computer device 200 may request a token contract of the blockchain system to transfer the currency from the escrow contract to the recipient in accordance with an escrow receipt request made by a caller specified in the escrow contract. Such transfers to the recipient have been described in detail with reference to Figures 7, 11, and 15.

At step 1740, the computer device 200 may return the currency deposited in the escrow contract to the sender. As an example, if a predefined condition for the sender's remittance is not met, the computer device 200 may request a token contract in the blockchain system to transfer the currency from the escrow contract to the sender in accordance with an escrow cancellation request made by a caller specified in the escrow contract. The return of the deposited currency to the sender has been described in detail with reference to Figures 8, 12, and 16.

On the other hand, in steps 1730 and 1740, the caller may be the owner or sender of the escrow contract.

In this way, according to an embodiment of the present invention, by clearly indicating the conditions for a transaction to be concluded in a smart contract, the remittance is not made immediately, but rather the money can be deposited and then processed for remittance to the recipient when certain conditions are met. Also, the remitter can cancel the remittance depending on whether or not certain conditions are met. Furthermore, since the source code of the smart contract is published on the blockchain network, transparency can be ensured as to the logic by which the escrow function operates.

The above-described systems or devices may be realized by hardware components or a combination of hardware and software components. For example, the devices and components described in the embodiments may be realized using one or more general-purpose or special-purpose computers, such as, for example, a processor, a controller, an ALU (arithmetic logic unit), a digital signal processor, a microcomputer, an FPGA (field programmable gate array), a PLU (programmable logic unit), a microprocessor, or various devices capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications that run on the OS. The processing device may also respond to the execution of the software and access, record, manipulate, process, and generate data. For ease of understanding, the description may be given as if one processing device is used, but one skilled in the art will understand that the processing device may include multiple processing elements and/or multiple types of processing elements. For example, a processing unit may include multiple processors or one processor and one controller. Other processing configurations, such as parallel processors, are also possible.

The software may include computer programs, codes, instructions, or a combination of one or more of these, and may configure or instruct a processing device to perform a desired operation, either individually or collectively. The software and/or data may be embodied in any type of machine, component, physical device, virtual device, computer storage medium, or device to be interpreted based on the processing device or to provide instructions or data to the processing device. The software may be distributed and stored or executed in a distributed manner on computer systems connected by a network. The software and data may be stored on one or more computer-readable storage media.

The method according to the embodiment may be realized in the form of program instructions executable by various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc., alone or in combination. The medium may be one that continuously records a computer-executable program, or one that temporarily records it for execution or download. The medium may be one that is a recording or storage means in the form of a single or multiple hardware devices, and is not limited to a medium that is directly connected to a certain computer system, but may be one that is distributed over a network. Examples of the medium include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs and DVDs, magneto-optical media such as floptical disks, and ROMs, RAMs, flash memories, etc., configured to record program instructions. Other examples of the medium include recording media or storage media managed by application stores that distribute applications, or sites, servers, etc. that supply or distribute various other software. Examples of program instructions include not only machine code, such as that produced by a compiler, but also high-level language code that is executed by a computer using an interpreter or the like.

Although the embodiments have been described above based on limited embodiments and drawings, those skilled in the art will appreciate that various modifications and variations may be made from the above description. For example, the described techniques may be performed in an order different from that described, and/or the components of the described systems, structures, devices, circuits, etc. may be combined or combined in a manner different from that described, or may be replaced or substituted by other components or equivalents, and still achieve suitable results.

Therefore, different embodiments that are equivalent to the scope of the claims are within the scope of the attached claims.

Claims (19)

For an escrow transaction from a sender to a receiver, depositing currency corresponding to the sender's remittance in an escrow contract included in the blockchain system;
A computer program product that causes a computer device to execute the steps of: transferring the currency deposited in the escrow contract to the recipient if a predefined condition for the sender's transfer is met; and returning the currency deposited in the escrow contract to the sender upon request by a trusted third party that is a caller specified in the escrow contract if the predefined condition for the transfer is not met. The step of depositing the currency includes:
2. The computer program of claim 1, further comprising: a step of requesting a token contract of the blockchain system that has received an approval request from the sender to remit the currency; and a step of receiving, from the token contract, a remittance of the token that belongs to the token contract and has been approved according to the request of the sender, and depositing the token in the escrow contract in the currency corresponding to the remittance of the sender. The step of depositing the currency includes:
receiving an escrow token remittance request from a token contract of the blockchain system that has received an escrow token remittance request from the sender;
2. The computer program product of claim 1, further comprising: requesting the token contract to remit in response to the escrow token remittance request; and depositing the tokens remitted in accordance with the request to the token contract in the escrow contract in a currency corresponding to the remittance of the sender. installing the escrow contract pursuant to a request from an owner of the escrow contract;
4. The computer program product of claim 3, configured to cause a computer device to execute the steps of: setting the escrow contract in the token contract according to a request from an owner of the escrow contract; and setting the token contract in the escrow contract according to control of the token contract. The step of depositing the currency includes:
2. The computer program product of claim 1, further comprising: receiving a token fallback request including meta information related to an escrow transaction from a token contract of the blockchain system that has received a remittance request from the sender; and receiving a remittance of tokens belonging to the token contract from the sender in a currency corresponding to the remittance of the sender based on information regarding the escrow transaction obtained by analyzing the meta information, and depositing the tokens in the escrow contract. 6. The computer program product of claim 5, configured to cause a computer device to execute the steps of: installing the escrow contract in accordance with a request from an owner of the escrow contract; and linking the escrow contract and the token contract using an address of the token contract included in the request from the owner of the escrow contract. The step of transferring the deposited currency to the recipient includes:
2. The computer program of claim 1, further comprising: a computer program for requesting a token contract of the blockchain system to transfer money from the escrow contract to the receiver in accordance with an escrow receipt request made by a caller specified in the escrow contract when a predefined condition for the sender's remittance is met. The step of returning the deposited currency to the sender includes:
2. The computer program of claim 1, further comprising: a computer program for requesting a token contract of the blockchain system to transfer money from the escrow contract to the sender in accordance with an escrow cancellation request made by a caller specified in the escrow contract when a predefined condition for the sender's remittance is not met. The computer program of claim 7 or 8, wherein the caller is the owner of the escrow contract or the sender. The computer program of claim 1, characterized in that the currency corresponding to the sender's remittance includes the base currency of the blockchain system. The computer program of claim 1, wherein the currency includes a token belonging to a token contract further included in the blockchain system. For an escrow transaction from a sender to a receiver, depositing currency corresponding to the sender's remittance in an escrow contract included in the blockchain system;
transferring the currency deposited in the escrow contract to the receiver if a predefined condition for the sender's transfer is met; and
and returning the currency deposited in the escrow contract to the sender upon request by a trusted third party that is a caller as specified in the escrow contract if a predefined condition for the transfer is not met.
The escrow transaction method includes causing a computer device to execute the steps described above. A computer-readable recording medium on which the computer program according to any one of claims 1 to 11 is recorded. at least one processor implemented to execute computer readable instructions;
by said at least one processor,
For an escrow transaction from a sender to a receiver, depositing currency corresponding to the sender's remittance in an escrow contract included in the blockchain system;
If a predefined condition for the sender's transfer is met, then transfer the currency deposited in the escrow contract to the receiver;
and returning the currency deposited in the escrow contract to the sender upon request by a trusted third party that is a caller specified in the escrow contract if a predefined condition for the transfer is not met. by said at least one processor,
Requesting a token contract of the blockchain system that has received an approval request from the sender to remit the currency;
The computer device of claim 14, further comprising: receiving from the token contract a transfer of tokens that belong to the token contract and are approved according to the request of the sender, and depositing the tokens in the escrow contract in a currency corresponding to the transfer of the sender. by said at least one processor,
receiving an escrow token remittance request from a token contract of the blockchain system that has received an escrow remittance request from the sender;
In response to the escrow token transfer request, request the token contract to transfer the escrow token;
15. The computer device of claim 14, further comprising: depositing tokens transferred in accordance with a request to the token contract in the escrow contract in a currency corresponding to the sender's transfer. by said at least one processor,
receiving a token fallback request including meta information related to an escrow transaction from a token contract of the blockchain system that has received a remittance request from the sender;
The computer device according to claim 14, further comprising: receiving a remittance of tokens belonging to the token contract in a currency corresponding to the remittance of the sender from the sender based on information regarding an escrow transaction obtained by analyzing the meta-information, and depositing the tokens in the escrow contract. by said at least one processor,
The computer device of claim 14, further comprising: a computer device that requests a token contract of the blockchain system to transfer money from the escrow contract to the receiver in accordance with an escrow receipt request made by a caller specified in the escrow contract when a predefined condition for the sender's transfer is met. by said at least one processor,
The computer device of claim 14, further comprising: a computer device that requests a token contract of the blockchain system to transfer funds from the escrow contract to the sender in accordance with an escrow cancellation request made by a caller specified in the escrow contract when a predefined condition for the sender's transfer is not met.

Images