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

Abstract

An escrow transaction method and system using smart contracts on a blockchain are disclosed. An escrow transaction method according to one embodiment, for an escrow transaction from a sender to a receiver, depositing a currency corresponding to the remittance of the sender in an escrow contract included in the blockchain system; transferring currency deposited in said escrow contract to said recipient if predefined conditions for a sender's transfer are met; and if predefined conditions for said transfer are not met, Returning currency deposited in the escrow contract to the sender may be included.

Description

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

Blockchain is a distributed data storage technology that manages data in blocks, connects it like a chain, and copies and stores it simultaneously on many computers.It is also called a distributed ledger. Instead of storing transaction records on a centralized server, we send transaction details to all users who participate in the transaction, and all participants share and compare information each time a transaction is made, thereby improving data storage. It is implemented to prevent forgery and alteration. For example, Korean Patent Publication No. 10-2019-0133573 relates to a blockchain trading system and method using smart contracts, which utilizes the unique characteristics of blockchains to utilize transactions and services through smart contracts. By providing an interface so that support requesters can post support request information in the network ecosystem, service providers can post transactions or contracts, and those who want to provide support can provide related information. Or, when service users select buttons (actions) such as transaction consent (signature), their own activities so that 'participation and sharing' activities are continuously activated by one mobile application in the network ecosystem We have disclosed a system and method in which the reward system is divided into grades and the cryptocurrency that is an incentive is paid as a reward.

In such conventional blockchain transactions, if a transaction is requested by specifying the wallet addresses of the sender and receiver, the transaction will be completed the moment the block containing the transaction is confirmed. Therefore, it is not suitable when the trust relationship between the sender and the receiver is not clear, or when certain conditions must be met in order to complete the transaction.

By specifying the conditions for transaction completion in the smart contract, the remittance is not done immediately, and after depositing, the remittance can be processed to the recipient when specific conditions are met. Provide an escrow transaction method and system.

An escrow transaction method for a blockchain system, comprising depositing a currency corresponding to the remittance of the sender in an escrow contract included in the blockchain system for an escrow transaction from a sender to a receiver; transferring currency deposited in said escrow contract to said recipient if a predefined condition for the transfer is met; and if a predefined condition for the transfer is not met, the escrow contract. providing a method of escrow transactions including the step of returning to said sender currency deposited with.

According to one aspect, depositing the currency includes requesting transfer of the currency to a token contract of the blockchain system that has received an approval request from the sender; Receiving an approved token transfer upon request from the token contract and depositing in the escrow contract in a currency corresponding to the sender's transfer.

According to another aspect, depositing the currency includes receiving an escrow token remittance request from a token contract of the blockchain system that received an escrow remittance request from the sender, and responding to the escrow token remittance request. The method may include requesting the token contract for remittance, and depositing the remitted tokens according to the request to the token contract in the escrow contract in a currency corresponding to the sender's remittance.

According to another aspect, the escrow transaction method includes: installing the escrow contract according to a request from an owner of the escrow contract; and setting the token contract to the escrow contract under control of the token contract.

According to another aspect, the step of escrowing the currency receives a token fallback request containing meta information related to an escrow transaction from a token contract of the blockchain system that received a remittance request from the sender. receiving remittance of tokens belonging to the token contract from the sender in a currency corresponding to the remittance of the sender based on the information about the escrow transaction obtained by analyzing the meta information and sending the token to the escrow contract; It may be characterized by including the step of depositing.

According to yet another aspect, the escrow transaction method includes installing the escrow contract according to a request from the escrow contract owner, and using an address of the token contract included in a request from the escrow contract owner. The method may further include linking the escrow contract and the token contract using a method.

According to yet another aspect, transferring the escrowed currency to the recipient includes: from a caller specified in the escrow contract if predefined conditions for the sender's transfer are met; It may be characterized by requesting the token contract of the blockchain system to transfer money from the escrow contract to the recipient according to the requested escrow reception request.

According to yet another aspect, the step of returning the deposited currency to the sender from a caller specified in the escrow contract if a predefined condition for the sender's remittance is not met. It may be characterized by requesting the token contract of the blockchain system to transfer money from the escrow contract to the sender according to the requested escrow cancellation request.

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

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

According to yet another aspect, the currency may include tokens belonging to token contracts further included in the blockchain system.

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

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

at least one processor implemented to execute computer readable instructions, said at least one processor for sending to an escrow contract included by said blockchain system for an escrow transaction from a sender to a recipient; deposit currency corresponding to the remittance of a party, and if predefined conditions for said sender's remittance are met, remit currency deposited in said escrow contract to said recipient; A computer device is provided that returns currency deposited in the escrow contract to the sender if a defined condition is not met.

By specifying the conditions for transaction completion in the smart contract, the remittance is not done immediately, but after depositing, it is possible to process the remittance to the recipient when specific conditions are met.

The transfer can be reversed by the sender depending on whether certain conditions are met.

Since the source code of the smart contract is published on the blockchain network, it is possible to ensure the transparency of what kind of logic the escrow function operates.

1 is a diagram showing an example of a network environment in one embodiment of the present invention; FIG. 1 is a block diagram illustrating an example of a computing device, in accordance with one embodiment of the present invention; FIG. FIG. 4 illustrates an example of a base currency escrow transaction in one embodiment of the present invention; FIG. 4 illustrates an example of a base currency escrow transaction in one embodiment of the present invention; FIG. 4 illustrates an example of a base currency escrow transaction in one embodiment of the present invention; FIG. 4 is a diagram showing a first example of escrow transactions for tokens in one embodiment of the present invention; FIG. 4 is a diagram showing a first example of escrow transactions for tokens in one embodiment of the present invention; FIG. 4 is a diagram showing a first example of escrow transactions for tokens in one embodiment of the present invention; FIG. 10 is a diagram showing a second example of escrow transactions for tokens in one embodiment of the present invention; FIG. 10 is a diagram showing a second example of escrow transactions for tokens in one embodiment of the present invention; FIG. 10 is a diagram showing a second example of escrow transactions for tokens in one embodiment of the present invention; FIG. 10 is a diagram showing a second example of escrow transactions for tokens in one embodiment of the present invention; FIG. 10 is a diagram showing a third example of escrow transactions for tokens in one embodiment of the present invention; FIG. 10 is a diagram showing a third example of escrow transactions for tokens in one embodiment of the present invention; FIG. 10 is a diagram showing a third example of escrow transactions for tokens in one embodiment of the present invention; FIG. 10 is a diagram showing a third example of escrow transactions for tokens in one embodiment of the present invention; 1 is a flowchart illustrating an example of an escrow transaction method, in accordance with one embodiment of the present invention;

Embodiments will be described in detail below with reference to the accompanying drawings.

An escrow trading system according to an embodiment of the present invention may be a blockchain system implemented by at least one computer device, and an escrow trading method according to an embodiment of the present invention comprises at least one It may be performed by a computing device. A computer program according to an embodiment of the present invention may be installed and executed in the computer device, and the computer device executes the escrow transaction method according to the embodiment of the present invention under the control of the executed computer program. you can The computer program described above may be recorded in a computer-readable recording medium in order to combine with a computer device and cause the computer to execute the escrow transaction method.

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

The plurality of electronic devices 110, 120, 130, 140 may be fixed terminals or mobile terminals implemented by computing devices. Examples of the plurality of electronic devices 110, 120, 130, and 140 include smartphones, mobile phones, navigation systems, PCs (personal computers), notebook PCs, digital broadcasting terminals, PDAs (Personal Digital Assistants), and PMPs (Portable Multimedia Players). ), and tablet PCs. As an example, FIG. 1 shows a smart phone as an example of the electronic device 110, but in embodiments of the present invention, the electronic device 110 substantially utilizes a wireless or wired communication scheme and communicates with other devices via the network 170. may refer to one of a wide variety of physical computing devices capable of communicating with the electronic devices 120, 130, 140 and/or the servers 150, 160.

The communication method is not limited, and not only the communication method using the communication network that can be included in the network 170 (eg, mobile communication network, wired Internet, wireless Internet, broadcasting network), but also the short distance between devices. Wireless communication may be included. For example, the network 170 includes a PAN (Personal Area Network), a LAN (Local Area Network), a CAN (Campus Area Network), a MAN (Metropolitan Area Network), a WAN (Wide Area Network), a BBN (Broadband Network, etc.), and the Internet. Any one or more of the networks may be included. Additionally, network 170 may include any one or more of network topologies including, but not limited to, bus networks, star networks, ring networks, mesh networks, star-bus networks, tree or hierarchical networks, and the like. will not be

Each of servers 150, 160 is implemented by one or more computing devices that communicate with a plurality of electronic devices 110, 120, 130, 140 over network 170 to provide instructions, code, files, content, services, etc. good. For example, the server 150 provides services (for example, content providing service, group call service (or audio conference service), messaging service, mail service, social network services, map services, translation services, financial services, payment services, search services, location-based services, etc.).

FIG. 2 is a block diagram illustrating an example computing device, in accordance with one embodiment of the present invention. Each of the plurality of 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 FIG.

Such a computing device 200 may include memory 210, processor 220, communication interface 230, and input/output interface 240, as shown in FIG. The memory 210 is a computer-readable storage medium and may include random access memory (RAM), read only memory (ROM), and permanent mass storage devices such as disk drives. Here, a permanent mass storage device such as a ROM or disk drive may be included in computer device 200 as a separate permanent storage device separate from memory 210 . Also stored in memory 210 may be an operating system and at least one program code. Such software components may be loaded into memory 210 from a computer-readable medium separate from memory 210 . Such other computer-readable recording media may include computer-readable recording media such as floppy drives, disks, tapes, DVD/CD-ROM drives, memory cards, and the like. In other embodiments, software components may be loaded into memory 210 through communication interface 230 rather than a computer-readable medium. For example, software components may be loaded into memory 210 of computing device 200 based on computer programs installed by files received over network 170 .

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

Communication interface 230 may provide functionality for computer device 200 to communicate with other devices (eg, the recording device described above) via network 170 . As an example, processor 220 of computing device 200 can transmit requests, commands, data, files, etc. generated according to program code recorded in a recording device such as memory 210 to other devices via network 170 under the control of communication interface 230 . device. Conversely, signals, instructions, data, files, etc. from other devices may be received by computing device 200 through communication interface 230 of computing device 200 over network 170 . Signals, instructions, data, etc. received through the communication interface 230 may be transmitted to the processor 220 and the memory 210, and files may be stored in a recording medium (the permanent recording device described above) that the computing device 200 may further include. may be recorded.

Input/output interface 240 may be a means for interfacing with input/output device 250 . For example, input devices may include devices such as a microphone, keyboard, or mouse, and output devices may include devices such as displays, speakers, and the like. As another example, input/output interface 240 may be a means for interfacing with a device that integrates functionality for input and output, such as a touch screen. Input/output device 250 may be one device with computing device 200 .

Also, in other embodiments, computing device 200 may include fewer or more components than the components of FIG. However, most prior art components need not be explicitly shown in the figures. For example, computing device 200 may be implemented to include at least some of the input/output devices 250 described above, and may also include other components such as transceivers, databases, and the like.

In a blockchain network according to an embodiment of the present invention, a base coin defined by a protocol and a token defined by a smart contract may be used for transactions. At this time, since the base currency has no dependency on a specific smart contract, by defining three functions of deposit, receipt, and cancellation in the smart contract for escrow (hereinafter, “escrow contract”), Escrow transactions are possible. "Sender," "recipient," and "third party," etc., described below, may substantially refer to any electronic device used by the sender, recipient, or third party to process money transfers. .

3-5 are diagrams illustrating examples of base currency escrow transactions in accordance with one embodiment of the present invention. A smart contract 310 for escrow is installed in the blockchain system 300, and escrow transactions may be processed by calling three functions of depositing, receiving, and canceling money, which is the base currency.

FIG. 3 shows an example in which sender A 320 deposits money, which is the base currency, in escrow contract 310 by calling an escrow transfer function (“escrowTransfer( )”) defined in escrow contract 310 . At this time, the first parameter 'B' of the escrow remittance function may be the identifier of the recipient B 330 of the remittance, and the second parameter 'value' is the amount of the remittance. can be shown. “Coin Transfer” may indicate the process by which the base currency is transferred from Sender A 320 to Escrow Contract 310 .

FIG. 4 shows an example in which the 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. there is As an example, an escrow receive function may include a parameter to identify the transfer in question. The callers 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 FIG. 4 shows an example in which a trusted third party, escrow contract owner 410, who is the owner or developer of escrow contract 310, is specified as the caller. The escrow contract owner 410 may call an escrow receive function on the escrow contract 310 if the pre-defined conditions for that transfer are met, causing the money deposited in the escrow contract 310 to be transferred to the escrow contract 310. may be sent to Recipient B330 specified in . The function "baseCoinTransfer(B, value)" shown in FIG. 4 is a function for transferring the base currency, where the escrow contract 310 transfers two It may mean a function for transferring money, which is the base currency corresponding to the first parameter 'value'.

FIG. 5 shows that if the pre-defined conditions for the remittance are not met, the escrow cancellation function (“escrowCancel( )”) is invoked to return the amount deposited by Sender A 320 in the escrow contract 310. example. As an example, the escrow cancellation function may include a parameter to identify the transfer in question. The callers that can call the escrow undo function may be specified in the escrow contract 310 . Such callers may be the original sender or a trusted third party. The embodiment of FIG. 5 shows an example in which a trusted third party, escrow contract owner 410, is specified as the caller. Escrow contract owner 410 may invoke an escrow cancel function on escrow contract 310 if the pre-defined conditions for that transfer are not met, causing money deposited in escrow contract 310 to be returned to Sender A 320. may be remitted. The function "baseCoinTransfer(A, value)" shown in FIG. 5 is a function for transferring the base currency from the escrow contract 310 to the sender A 320 identified from the first parameter "A". may mean a function that transfers money, which is the base currency corresponding to the parameter 'value' of .

Escrow transactions for tokens also proceed in a similar fashion to escrow transactions for the base currency described with reference to FIGS. 3-5 above. However, since the token belongs to a specific smart contract, the function of the token contract must be called in addition to the function of the escrow contract in order to transfer the token. Three methods for executing escrow transactions for tokens are described below.

6-8 are diagrams showing a first example of an escrow transaction for tokens in one embodiment of the present invention. A DApp (Decentralized Application) 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 particular smart contract to which the token belongs (hereinafter "token contract 620").

FIG. 6 shows an example of a process in which sender A 320 first deposits money in escrow contract 610 in order to transfer money, which is a token, to recipient B 320 . At this time, the sender A 320 requests the token contract 620 to which the token belongs to approve the transfer using the approval function (“approve( )”), and the escrow contract 610 also uses the escrow transfer function (“escrowTransfer( )”). You may request a deposit by

A 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 authorization function of token contract 620 called by Sender A 320 is specified by token contract 620 to escrow contract 610 so that money can be transferred from token contract 620 to escrow contract 610 . It may mean an address for identification. A second parameter of the authorization function, 'value', may indicate the amount of money to be transferred, and a third parameter, 'currentAllowance', may mean the amount of money authorized to be transferred to date.

On the other hand, the first parameter "B" of the escrow remittance function may indicate the actual recipient of the remittance in question, Recipient B 320, and the second parameter "value" indicates the amount of the remittance. good. Escrow contract 610 may request a transfer from token contract 620 in response to a call to an escrow transfer function. In the function "transferFrom( )", the first parameter "A" is the sender A 320, the second parameter "escrowContractAddress" is the escrow contract 610, the third parameter "value" is the amount of the transfer, each can mean In other words, escrow contract 610 may ask token contract 620 to transfer Sender A 320's money from token contract 620 to escrow contract 610 . In this case, the token contract 620 remits (substantially Specifically, by changing the owner of the corresponding token from sender A 320 to escrow contract 610 , sender A 320's money may be deposited in escrow contract 610 . In FIG. 6, “Token Transfer” may indicate the process by which token contract 620 transfers tokens to escrow contract 610 .

FIG. 7 shows that the escrow contract owner 620, a trusted third party, receives the escrow receive function defined in the escrow contract 610 ("escrowReceive() ”) is shown. At this time, the escrow receiving function may include a parameter for identifying the relevant remittance. In this case, the escrow contract 610 may cause the escrowed money to be transferred to the recipient B 330 by calling a transfer function (“transfer( )”) on the token contract 620 . At this time, the first parameter "B" of the remittance function may be the identifier of the recipient B330 who is the target of remittance, and the second parameter "value" may mean the amount of remittance. At this time, the token contract 620 may transfer the money deposited in the escrow contract 610 to the recipient B330 by changing the owner of the token deposited in the escrow contract 610 to the recipient B330. In FIG. 7 , “Token Transfer” may indicate the process of transferring money deposited by sender A 320 to recipient B 330 by escrow contract 610 .

FIG. 8 shows that an escrow cancellation function (“escrowCancel( )”) is invoked to return the amount deposited by Sender A 320 in the escrow contract 610 if the pre-defined conditions for the remittance are not met. It shows an example of receiving. As an example, the escrow cancellation function may include a parameter to identify the transfer in question. The callers that can call the escrow undo function may be specified in the escrow contract 610 . Such callers may be the original sender or a trusted third party. The embodiment of FIG. 8 shows an example in which a trusted third party, escrow contract owner 620, is specified as the caller. Escrow contract 610 may call the transfer function (“transfer( )”) defined in token contract 620 if escrow contract owner 620 calls the escrow cancel function for that transfer. At this time, the first parameter "A" of the remittance function may be the identifier of the recipient A320 who is the target of remittance, and the second parameter "value" may mean the amount of remittance. Accordingly, token contract 620 may handle transfers from escrow contract 610 to sender A 320 by transferring tokens escrowed with escrow contract 610 into the possession of sender A 320 . In FIG. 8, “Token Transfer” indicates the process of returning money deposited by sender A320 to sender A320 by escrow contract 610 .

In the embodiments of FIGS. 6-8, escrow contract 610 operates as a separate entity receiving and sending token transfers of token contract 620, so that escrow contract 610 and token contract 620 are each maintained as separate interfaces. you can

9-12 are diagrams illustrating a second example of an escrow transaction for tokens in one embodiment of the present invention. A DApp 900 according to this embodiment may be installed and run on the blockchain system 300 and may include a token contract 910 and an escrow contract 920 .

The embodiment of FIG. 9 shows an example process of an escrow contract owner 930 installing a token contract 910 and an escrow contract 920 into a DApp 900 . At this time, the escrow contract owner 930 may install the escrow contract 920 directly into the DApp 900, utilizing the functions defined to be executed when installing the contract with the token contract 910 already installed in the DApp 900. may control the token contract 910 to set up the escrow contract 920. In this case, token contract 910 may install escrow contract 920 and install the address of token contract 910 into escrow contract 920 . For example, token contract 910 may install escrow contract 920 using a set escrow contract function (“setEscrowContract(escrow_contract_addr=contractAddress1)”) and a set token contract address function (“TokenContract(token_contract_addr=contractAddress2)”). may be used to set the escrow contract 920 to the address of the token contract. Here, “contractAddress1” may refer to the address of the escrow contract 920 and “contractAddress2” may refer to the address of the token contract 910 .

FIG. 10 shows an example of a process in which a token is deposited in an escrow contract 920 by requesting an escrow transaction from sender A 320 . First, when the sender A320 requests the token contract 910 to transfer money to the recipient B330 using the escrow transfer function ("escrowTransfer()") defined in the token contract 910, the token contract 910 first: After approving the transfer using the approval function (“approve( )”), the escrow contract 920 requests sender A 320 to send the transfer to recipient B 330 using the escrow token transfer function (“escrowTokenTransfer( )”). may be transmitted. The authorization function may use the address of the escrow contract 920 and the amount of the transfer as parameters, respectively, to authorize the transfer of the transfer amount to the escrow contract 920 . In this case, escrow contract 920 may request token contract 910 to transfer money to escrow contract 920 using the function “transferFrom( )”. 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 money to transfer. In FIG. 10, "Token Transfer" indicates that the token that the sender A320 intends to transfer to the receiver B330 is transferred to the escrow contract 920 (substantially, in the token contract 910, the owner of the corresponding token to the escrow contract 920) and deposited in the escrow contract 920.

FIG. 11 shows that the escrow contract owner 930, a trusted third party, receives the escrow receive function defined in the escrow contract 920 ("escrowReceive() ”) is shown. At this time, the escrow receiving function may include a parameter for identifying the relevant remittance. In this case, escrow contract 920 may call the transfer function (“transfer( )”) defined in token contract 910 . At this time, the first parameter "B" of the remittance function may be the identifier of the recipient B330 who is the target of remittance, and the second parameter "value" may mean the amount of remittance. Thus, token contract 910 may transfer money deposited from escrow contract 920 to recipient B330 by changing the owner of the token in escrow contract 920 to recipient B330. In FIG. 11 , “Token Transfer” may indicate the process of transferring money deposited by sender A 320 to receiver B 330 by escrow contract 920 .

FIG. 12 shows that the escrow cancellation function (“escrowCancel( )”) is called so that Sender A 320 returns the amount deposited in the escrow contract 920 if the pre-defined conditions for the remittance are not met. example. As an example, the escrow cancellation function may include a parameter to identify the transfer in question. The callers that can call the escrow undo function may be specified in the escrow contract 920 . Such callers may be the original sender or a trusted third party. The embodiment of FIG. 12 shows an example in which the escrow contract owner 930, who is a trusted third party, is specified as the caller. Escrow contract 920 may call the transfer function (“transfer( )”) defined in token contract 910 if escrow contract owner 930 calls the escrow cancel function for that transfer. At this time, the first parameter "A" of the remittance function may be the identifier of the recipient A320 who is the target of remittance, and the second parameter "value" may mean the amount of remittance. In this case, token contract 910 may change the owner of the token in escrow contract 920 to sender A 320 so that the deposited amount is returned. In FIG. 12 , “Token Transfer” may indicate the process of returning money deposited by sender A320 to sender A320 by means of escrow contract 920 .

In the embodiments of FIGS. 9-12, the token contract 910 in support of the escrow contract 920 can be used to handle the process for depositing money sent by Sender A 320 using a single transaction. become.

13-16 illustrate a third example of an escrow transaction for tokens in one embodiment of the present invention. A DApp 1300 according to this embodiment may be installed and run on the blockchain system 300 and may include a token contract 1310 and an escrow contract 1320 .

The embodiment of FIG. 13 shows an example of the process by which Escrow Contract Owner 930 installs Escrow Contract 1320 in DApp 1300 . Escrow contract owner 1330 may then link escrow contract 1320 and token contract 1310 using functions defined to be executed when the contract is installed in escrow contract 1320 .

FIG. 14 shows an example of a process in which a token is deposited in the escrow contract 1320 by requesting an escrow transaction from the sender A320. First, sender A 320 may request token contract 1310 to transfer money to escrow contract 1320 using a transfer function (“transfer( )”) defined in token contract 1310 . Here, the first parameter of the remittance function may be the address of the escrow contract 1320, such as "escrow_token_addr=contractAddress1". Also, the second parameter of the remittance function may be the amount to be remitted, such as "value". Also, the third parameter of the transfer function may indicate meta information (recipient, memo) associated with the escrow, such as "0x+'transferid:toAddress:memo". Token contract 1310 is a token fallback function defined in the contract (in this embodiment, escrow contract 1320) corresponding to the CA (Contract Address) that the recipient is not EOA (Externally Owned Wallet). ("tokenFallback( )") may be called, where the meta information described above 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 money sent from Sender A 320 by parsing the meta-information and executing escrow logic. Here, 'Token Transfer' may mean that the token that sender A 320 intends to transfer to recipient B 330 is transferred to escrow contract 920 and deposited. The function "escrow_token_transfer()" may be a function that is called in the token fallback function to record the transfer recipient in the escrow contract 920 and for post-processing such as handling data validation. .

FIG. 15 shows that the escrow contract owner 1330, a trusted third party, receives the escrow receive function defined in the escrow contract 1320 (“escrowReceive() ”) is shown. At this time, the escrow receiving function may include a parameter for identifying the relevant remittance. In this case, escrow contract 1320 may call the transfer function (“transfer( )”) defined in token contract 1310 . At this time, the first parameter "B" of the remittance function may be the identifier of the recipient B330 who is the target of remittance, and the second parameter "value" may mean the amount of remittance. Accordingly, token contract 1310 may handle money deposited in escrow contract 920 to be transferred to Recipient B 330 by changing ownership of the tokens in Escrow Contract 920 to Recipient B 330 . In FIG. 15 , “Token Transfer” may indicate the process of transferring money deposited by sender A 320 to receiver B 330 by escrow contract 1320 .

FIG. 16 shows that the escrow cancellation function (“escrowCancel( )”) is called so that Sender A 320 returns the amount deposited in the escrow contract 920 if the pre-defined conditions for the remittance are not met. example. As an example, the escrow cancellation function may include a parameter to identify the transfer in question. The callers that can call the escrow undo function may be specified in the escrow contract 1320 . Such callers may be the original sender or a trusted third party. The embodiment of FIG. 16 shows an example in which the escrow contract owner 1330, who is a trusted third party, is specified as the caller. The escrow contract 1320 may call the transfer function (“transfer( )”) defined in the token contract 1310 if the escrow contract owner 1330 calls the escrow cancel function for that transfer. At this time, the first parameter "A" of the remittance function may be the identifier of the recipient A320 who is the target of remittance, and the second parameter "value" may mean the amount of remittance. Accordingly, token contract 1310 may return the money deposited in escrow contract 1320 to sender A320 by changing ownership of the tokens in escrow contract 1320 to sender A320. In FIG. 16, “Token Transfer” may indicate the process of returning money deposited by sender A320 to sender A320 by escrow contract 1320 .

In the embodiments of FIGS. 13-16, escrow transactions can be processed only by adding an escrow contract 1320 without changing the specifications of the token contract 1310 . For example, there is no need for the token contract 1310 to independently recognize the escrow contract 1320 . It is also possible for sender A 320 to use one transaction to process the process of depositing money to be transferred.

Conditions for remittance may be defined variously depending on the person who sets the conditions and the case. As an example, a sender's request to transfer money may be considered acceptable, or a sender's request to cancel a transfer may be considered unsatisfactory. In addition, various conditions may be defined such as remittance after a certain period of time or remittance on a specific date.

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 of Ethereum.

FIG. 17 is a flowchart illustrating an example of an escrow transaction method in one embodiment of the invention. The escrow transaction method according to this embodiment may be performed by an escrow contract included in the blockchain system 300, and may be substantially performed by the processor 200 of the computer device 200 executing the code of such an escrow contract. . In this case, the processor 220 of the computing device 200 is implemented to execute control instructions by the code of the operating system contained in the memory 210 and the code of at least one computer program (eg, the code of the escrow contract). may be Here, processor 220 may control computing device 200 such that computing device 200 performs steps 1710-1740 included in the method of FIG. 17 according to control instructions provided by code recorded in computing device 200. .

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

As described above, in the blockchain system, the currency corresponding to the sender's remittance may include the reference currency of the blockchain system or a token belonging to a token contract further included in the blockchain system. At this time, if the currency corresponding to the sender's remittance is the reference currency of the blockchain system, the computing device 200 may directly deposit the reference currency corresponding to the sender's remittance to the 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 is deposited in the escrow contract using the token contract as in the following embodiment. You can

As an embodiment, in step 1710, the computer device 200 requests a currency transfer to the token contract of the blockchain system that received the approval request from the sender, and belongs to the token contract and is approved according to the sender's request. Token transfers may be received from a token contract and deposited 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.

As another embodiment, in step 1710, the computer device 200 receives an escrow token remittance request from the token contract of the blockchain system that received the escrow remittance request from the sender, and responds to the escrow token remittance request to the token contract. You may request a transfer and deposit the transferred tokens in an escrow contract in the currency corresponding to the sender's transfer as requested by the token contract. The deposit method according to this embodiment has been described in detail with reference to FIG. Meanwhile, in the escrow contract installation process for the present embodiment, the computer device 200 installs the escrow contract according to a request from the escrow contract owner, and escrows the token contract according to a request from the escrow contract owner. A contract may be established, and an escrow contract may be established with the token contract under 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, in step 1710, the computing device 200 receives a token fallback request including meta information related to an escrow transaction from the token contract of the blockchain system that received the remittance request from the sender. Then, based on the information on the escrow transaction obtained by analyzing the meta information, the remittance of tokens belonging to the token contract in the currency corresponding to the sender's remittance may be received from the sender and deposited in the escrow contract. The deposit method according to this embodiment has been described in detail with reference to FIG. In this case, in the escrow contract installation process for this embodiment, the computer device 200 installs the escrow contract according to the request from the escrow contract owner, and the token contract address included in the request from the escrow contract owner. You may link the escrow contract and the token contract by . In this case, since there is no change in the specification of the token contract, there is no need to go through the process of individually recognizing the escrow contract.

At step 1720, computing device 200 may determine whether predefined conditions are met for the sender's remittance. At this time, the computing device 200 may perform step 1730 if the predefined condition is met, and the computing device 200 may perform step 1740 if the predefined condition is not met. Substantially, whether a predefined condition is met may be made by the caller specified in the escrow contract, the caller calling the escrow receive function if the predefined condition is met, Each escrow undo function may be called if a predefined condition is not met. In other words, computing device 200 may determine that a predefined condition is met if the escrow receive function is called, and that the predefined condition is not met if the escrow cancel function is called. You can decide.

At step 1730, computing device 200 may transfer the currency deposited in the escrow contract to the recipient. As an example, the computer device 200 is configured to execute the token contract of the blockchain system according to the escrow reception request requested from the caller specified in the escrow contract when the predefined conditions for the remittance of the sender are satisfied. Then, you may request that the escrow contract send the money to the recipient. Such remittances to recipients have been described in detail with reference to FIGS.

At step 1740, computing device 200 may return the currency deposited in the escrow contract to the sender. As an example, the computer device 200 may be configured to execute the token contract of the blockchain system according to an escrow cancellation request requested by the caller specified in the escrow contract if a predefined condition for the sender's remittance is not met. You may then request that the escrow contract send the money to the sender. The return of deposited currency to the sender has been described in detail with reference to FIGS. 8, 12 and 16. FIG.

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

As described above, according to the embodiment of the present invention, by specifying the conditions for the transaction establishment in the smart contract, the remittance is not performed immediately, and the specific condition is satisfied after depositing the money. When the remittance can be processed to the recipient. Also, the remittance can be canceled by the remitter depending on whether or not certain conditions are met. Furthermore, since the source code of the smart contract is published on the blockchain network, it is possible to ensure the transparency of what kind of logic the escrow function operates.

The systems or devices described above may be realized by hardware components or a combination of hardware and software components. For example, the devices and components described in the embodiments include, for example, processors, controllers, ALUs (Arithmetic Logic Units), digital signal processors, microcomputers, FPGAs (Field Programmable Gate Arrays), PLUs (Programmable Logic Units), micro It may be implemented using one or more general purpose or special purpose computers, such as a processor or various devices capable of executing instructions and responding to instructions. The processing unit may run an operating system (OS) and one or more software applications that run on the OS. The processor may also access, record, manipulate, process, and generate data in response to executing software. For convenience of understanding, one processing device may be described as being used, but those skilled in the art will appreciate that a processing device may include multiple processing elements and/or multiple types of processing elements. You can understand that. For example, a processing unit may include multiple processors or a processor and a controller. Other processing configurations are also possible, such as parallel processors.

Software may include computer programs, code, instructions, or a combination of one or more of these, to configure or, independently or collectively, to instruct a processor to perform a desired operation. You can Software and/or data may be embodied in any kind of machine, component, physical device, virtual device, computer storage medium or device for interpretation on or for providing instructions or data to a processing device. may be changed. The software may be stored and executed in a distributed fashion over computer systems linked by a network. Software and data may be recorded on one or more computer-readable recording media.

The method according to the embodiments may be embodied in the form of program instructions executable by various computer means and recorded on a computer-readable medium. The computer-readable media may include program instructions, data files, data structures, etc. singly or in combination. The medium may be a continuous recording of the computer-executable program or a temporary recording for execution or download. In addition, the medium may be various recording means or storage means in the form of a combination of single or multiple hardware, and is not limited to a medium that is directly connected to a computer system, but is distributed over a network. It may exist in Examples of media 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 ROM, RAM. , flash memory, etc., configured to store program instructions. Other examples of media include recording media or storage media managed by application stores that distribute applications, sites that supply or distribute various software, and servers. Examples of program instructions include high-level language code that is executed by a computer, such as using an interpreter, as well as machine language code, such as that generated by a compiler.

As described above, the embodiments have been described based on the limited embodiments and drawings, but those skilled in the art will be able to make various modifications and variations based on the above description. For example, the techniques described may be performed in a different order than in the manner described and/or components such as systems, structures, devices, circuits, etc. described may be performed in a manner different from the manner described. Any combination or combination, substitution or replacement by other elements or equivalents may achieve suitable results.

Accordingly, different embodiments that are equivalent to the claims should still fall within the scope of the appended claims.

FIG. 7 shows that a trusted third party, escrow contract owner 630 , receives an escrow receive function defined in escrow contract 610 ("escrowReceive ()") is shown. At this time, the escrow receiving function may include a parameter for identifying the relevant remittance. In this case, the escrow contract 610 may cause the escrowed money to be transferred to the recipient B 330 by calling a transfer function (“transfer( )”) on the token contract 620 . At this time, the first parameter "B" of the remittance function may be the identifier of the recipient B330 who is the target of remittance, and the second parameter "value" may mean the amount of remittance. At this time, the token contract 620 may transfer the money deposited in the escrow contract 610 to the recipient B330 by changing the owner of the token deposited in the escrow contract 610 to the recipient B330. In FIG. 7 , “Token Transfer” may indicate the process of transferring money deposited by sender A 320 to recipient B 330 by escrow contract 610 .

FIG. 8 shows that an escrow cancellation function (“escrowCancel( )”) is invoked to return the amount deposited by Sender A 320 in the escrow contract 610 if the pre-defined conditions for the remittance are not met. It shows an example of receiving. As an example, the escrow cancellation function may include a parameter to identify the transfer in question. The callers that can call the escrow undo function may be specified in the escrow contract 610 . Such callers may be the original sender or a trusted third party. The embodiment of FIG. 8 shows an example in which the escrow contract owner 630 , who is a trusted third party, is specified as the caller. The escrow contract 610 may call the transfer function (“transfer( )”) defined in the token contract 620 if the escrow contract owner 630 calls the escrow cancel function for the transfer in question. At this time, the first parameter "A" of the remittance function may be the identifier of the sender A320 who is the target of remittance, and the second parameter "value" may mean the amount of remittance. Accordingly, token contract 620 may handle transfers from escrow contract 610 to sender A 320 by transferring tokens escrowed with escrow contract 610 into the possession of sender A 320 . In FIG. 8, “Token Transfer” indicates the process of returning money deposited by sender A320 to sender A320 by escrow contract 610 .

FIG. 12 shows that the escrow cancellation function (“escrowCancel( )”) is called so that Sender A 320 returns the amount deposited in the escrow contract 920 if the pre-defined conditions for the remittance are not met. example. As an example, the escrow cancellation function may include a parameter to identify the transfer in question. The callers that can call the escrow undo function may be specified in the escrow contract 920 . Such callers may be the original sender or a trusted third party. The embodiment of FIG. 12 shows an example in which the escrow contract owner 930, who is a trusted third party, is specified as the caller. Escrow contract 920 may call the transfer function (“transfer( )”) defined in token contract 910 if escrow contract owner 930 calls the escrow cancel function for that transfer. At this time, the first parameter "A" of the remittance function may be the identifier of the sender A320 who is the target of remittance, and the second parameter "value" may mean the amount of remittance. In this case, token contract 910 may change the owner of the token in escrow contract 920 to sender A 320 so that the deposited amount is returned. In FIG. 12 , “Token Transfer” may indicate the process of returning money deposited by sender A320 to sender A320 by means of escrow contract 920 .

FIG. 16 shows that the escrow cancellation function (“escrowCancel( )”) is called so that Sender A 320 returns the amount deposited in the escrow contract 920 if the pre-defined conditions for the remittance are not met. example. As an example, the escrow cancellation function may include a parameter to identify the transfer in question. The callers that can call the escrow undo function may be specified in the escrow contract 1320 . Such callers may be the original sender or a trusted third party. The embodiment of FIG. 16 shows an example in which the escrow contract owner 1330, who is a trusted third party, is specified as the caller. The escrow contract 1320 may call the transfer function (“transfer( )”) defined in the token contract 1310 if the escrow contract owner 1330 calls the escrow cancel function for that transfer. At this time, the first parameter "A" of the remittance function may be the identifier of the sender A320 who is the target of remittance, and the second parameter "value" may mean the amount of remittance. Accordingly, token contract 1310 may return the money deposited in escrow contract 1320 to sender A320 by changing ownership of the tokens in escrow contract 1320 to sender A320. In FIG. 16, “Token Transfer” may indicate the process of returning money deposited by sender A320 to sender A320 by escrow contract 1320 .

FIG. 17 is a flowchart illustrating an example of an escrow transaction method in one embodiment of the invention. The escrow transaction method according to the present embodiment may be performed by an escrow contract included in the blockchain system 300, and is substantially performed by the processor 220 of the computer device 200 executing code of such an escrow contract. you can In this case, the processor 220 of the computing device 200 is implemented to execute control instructions by the code of the operating system contained in the memory 210 and the code of at least one computer program (eg, the code of the escrow contract). may be Here, processor 220 may control computing device 200 such that computing device 200 performs steps 1710-1740 included in the method of FIG. 17 according to control instructions provided by code recorded in computing device 200. .

Claims (19)

An escrow transaction method for a blockchain system, comprising:
Depositing currency corresponding to the sender's remittance in an escrow contract included in the blockchain system for an escrow transaction from a sender to a recipient;
transferring currency deposited in said escrow contract to said recipient if predefined conditions for said sender's remittance are met; and if pre-defined conditions for said remittance are not met. , returning currency deposited in said escrow contract to said sender. Depositing the currency comprises:
requesting the token contract of the blockchain system that has received an approval request from the sender to transfer the currency; and depositing with the escrow contract in a currency corresponding to the sender's remittance. Depositing the currency comprises:
receiving an escrow token remittance request from the token contract of the blockchain system that received the escrow remittance request from the sender;
requesting the token contract for remittance in response to the escrow token remittance request; and depositing the tokens remitted according to the request to the token contract in the escrow contract in a currency corresponding to the sender's remittance. The escrow transaction method of claim 1, comprising: installing the escrow contract at the request of an owner of the escrow contract;
4. The method of claim 3, further comprising: setting the escrow contract to the token contract upon request from an owner of the escrow contract; and setting the token contract to the escrow contract under control of the token contract. escrow transaction method. Depositing the currency comprises:
Receiving a token fallback request containing meta information related to an escrow transaction from the token contract of the blockchain system that received the remittance request from the sender; and an escrow transaction obtained by analyzing the meta information. receiving from the sender a remittance of tokens belonging to the token contract in a currency corresponding to the sender's remittance and depositing it in the escrow contract based on information about Escrow transaction method described in . installing the escrow contract in response to a request from the owner of the escrow contract; and linking the escrow contract and the token contract by an address of the token contract contained in a request from the owner of the escrow contract. The escrow transaction method according to claim 5. Transferring the deposited currency to the recipient comprises:
From the escrow contract to the token contract of the blockchain system according to an escrow reception request requested from the caller specified in the escrow contract when a predefined condition for the sender's remittance is met. The escrow transaction method according to claim 1, characterized by requesting remittance to said recipient. Returning the deposited currency to the sender includes:
from said escrow contract to a token contract of said blockchain system according to an escrow cancellation request requested by a caller specified in said escrow contract if a predefined condition for said sender's remittance is not met; The escrow transaction method according to claim 1, characterized by requesting remittance to said sender. The escrow transaction method according to claim 7 or 8, characterized in that said caller is the owner of said escrow contract or said sender. The escrow transaction method according to claim 1, wherein the currency corresponding to the sender's remittance includes the base currency of the blockchain system. The escrow trading method according to claim 1, characterized in that said currency includes tokens belonging to a token contract further included in said blockchain system. Recorded on a computer-readable recording medium for causing a computer device to execute the method according to any one of claims 1 to 8, claim 10, or claim 11 in combination with a computer device, computer program. A computer-readable recording medium on which a computer program for causing a computer device to execute the method according to any one of claims 1 to 8, 10, or 11 is recorded. at least one processor implemented to execute computer readable instructions;
by the at least one processor;
Deposit currency corresponding to the sender's remittance in an escrow contract included in the blockchain system for an escrow transaction from the sender to the receiver;
transferring currency deposited in the escrow contract to the recipient if predefined conditions for the sender's transfer are met;
A computer device, wherein currency deposited in said escrow contract is returned to said sender if predefined conditions for said remittance are not met. by the at least one processor;
Requesting a transfer of the currency to the token contract of the blockchain system that received the approval request from the sender,
receiving a remittance of tokens belonging to said token contract and approved according to said sender's request from said token contract and depositing them in said escrow contract in a currency corresponding to said sender's remittance; 15. The computer device according to 14. by the at least one processor;
receiving an escrow token remittance request from the token contract of the blockchain system that received the escrow remittance request from the sender;
requesting the token contract to transfer money in response to the escrow token transfer request;
15. The computer device according to claim 14, wherein the token transferred according to the request to the token contract is deposited in the escrow contract in a currency corresponding to the sender's transfer. by the at least one processor;
receiving a token fallback request containing meta information related to an escrow transaction from the token contract of the blockchain system that received the remittance request from the sender;
Receiving remittance of tokens belonging to the said token contract in the currency corresponding to the remittance of the said sender from the said sender and depositing them in the said escrow contract based on the information on the escrow transaction obtained by analyzing the said meta information. 15. A computer device as claimed in claim 14, characterized in that. by the at least one processor;
From the escrow contract to the token contract of the blockchain system according to an escrow reception request requested from the caller specified in the escrow contract when a predefined condition for the sender's remittance is met. 15. The computer device of claim 14, requesting remittance to the recipient. by the at least one processor;
from said escrow contract to a token contract of said blockchain system according to an escrow cancellation request requested by a caller specified in said escrow contract if a predefined condition for said sender's remittance is not met; 15. The computer device of claim 14, requesting remittance to the sender.

Images