KR20220108302A - Method for exchanging asset between compatible blockchain networks - Google Patents

Abstract

A method for efficiently and safely exchanging assets in a blockchain network is executed by a relay entity relaying the exchange of assets and includes the steps of: (a) obtaining a meta transaction for consignment created for a smart contract for asset exchange transaction between a first entity and a second entity; (b) executing the smart contract through the meta transaction for consignment, withdrawing assets corresponding to the amount of exchange from each blockchain wallet, and depositing the same in the smart contract of each blockchain; and (c) executing a withdrawal transaction to execute a withdrawal so that the assets deposited in the smart contract are transferred to each counterparty as the meta transaction for consignment, which is for confirming that the assets corresponding to the respective exchange volume have been normally deposited, is obtained.

Description

METHOD FOR EXCHANGING ASSET BETWEEN COMPATIBLE BLOCKCHAIN NETWORKS

The present invention relates to an asset exchange method in a blockchain network, and more particularly, to an asset transfer and exchange method using a transaction transfer relay method utilizing meta-transactions (meta-tx) between compatible blockchain networks.

Various types of blockchain tokens have been created and widely distributed to many users, but there are many problems in using them in real life. Among them, the biggest problem is usability and speed, and many developers are working hard to solve this problem.

To solve the above problem, many developers are developing their own dedicated block chains and dedicated software such as wallets. Many block chains improve governance to increase speed based on ethereum, but each developer The method of adding necessary functions is mainly adopted. There is not much difference between the dedicated block chains created in this way. This can be explained by analogy with the fact that when surfing the web, users cannot distinguish whether the Internet service they are accessing is a Google server or an Amazon server.

In other words, as long as the user has a web browser, he/she must be able to access the server hosted through the http protocol regardless of the type of server, and the service provider must also be able to host the web regardless of the type of server, the blockchain service provider also has its own purpose. It is necessary to be able to provide one's own service through general-purpose software rather than blockchain-exclusive software if one chooses a blockchain according to the requirements.

Basically, since the blockchains that hard forked Ethereum and Ethereum have a very high level of compatibility, using this, a technical environment (i.e. , and a high usability service that does not require separate use of block chains) is a situation in which users are increasingly demanding. In addition, there is a need for a method that can make asset transfers and exchanges between such compatible blockchain networks more efficient and more secure.

An object of the present invention is to provide an asset transfer and exchange method using a transaction transfer relay method utilizing meta-transactions (meta-tx) between compatible blockchain networks.

According to one aspect of the present invention, there is provided an asset exchange method in a blockchain network executed by a relay entity that relays asset exchange, (a) a smart for asset exchange transaction between a first entity and a second entity. acquiring a meta-transaction for entrustment created for the contract; (b) executing the smart contract through the consignment meta transaction, withdrawing assets corresponding to each exchange amount from each blockchain wallet and depositing it in the smart contract of each blockchain; (c) As a meta-transaction for approval confirming that the assets corresponding to each exchange amount are normally deposited, executing the withdrawal transaction to execute the withdrawal so that the assets deposited in the smart contract are transferred to each counterparty; An asset exchange method in a blockchain network including ; is provided.

According to the asset exchange method between compatible blockchain networks according to an embodiment of the present invention, there is an effect that can make asset transfer and exchange between compatible blockchain networks more efficient and more secure.

1 and 2 are flowcharts for explaining an asset exchange method between compatible blockchain networks according to an embodiment of the present invention.

Since the present invention can apply various transformations and can have various embodiments, specific embodiments are illustrated in the drawings and described in detail in the detailed description. However, this is not intended to limit the present invention to specific embodiments, and should be understood to include all modifications, equivalents, and substitutes included in the spirit and scope of the present invention.

In describing the present invention, if it is determined that a detailed description of a related known technology may unnecessarily obscure the gist of the present invention, the detailed description thereof will be omitted. In addition, numbers (eg, first, second, etc.) used in the description process of the present specification are merely identification symbols for distinguishing one component from other components.

Also, throughout the specification, when an element is referred to as “connected” or “connected” with another element, the one element may be directly connected to or directly connected to the other element, but in particular Unless there is a description to the contrary, it should be understood that they may be connected or connected through another element in the middle. In addition, throughout the specification, when a part "includes" a certain component, it means that other components may be further included, rather than excluding other components, unless otherwise stated. In addition, terms such as "unit" and "module" described in the specification mean a unit that processes at least one function or operation, which means that it can be implemented as one or more hardware or software or a combination of hardware and software. .

Hereinafter, an embodiment of the present invention will be described in detail with reference to the accompanying drawings, but the technical concept of the present invention will be first described to help the understanding of the present invention.

Compatible blockchains have the same signature scheme, and smart contracts can be executed with the signature scheme. Accordingly, a third party can execute the smart contract by transmitting the command (transaction) of the smart contract that has signed it. In the present invention, assets are transferred between different compatible blockchains (eg, ethereum and compatible ethereum-compatible chains (eg, klaytn blockchain, etc.)) using this method. or implement an exchange method. These are briefly described in order as follows.

1. The party who initiated the transaction (referred to as a maker in this specification, refer to the first entity of 'User 1' in FIGS. 1 and 2) determines the blockchain to be moved and the asset to be moved, and commands the corresponding details. It is created and signed to create an offline transaction that cannot be forged or tampered with. The offline transaction created in this way is published in a public place to find a trader or delivered to a target who wants to trade 1:1. As used herein, maker refers to the user who initially signed the asset exchange or transfer instruction.

2. The counterparty who has agreed to the transaction (referred to as a taker in this specification, refer to the second entity of 'User 2' in FIGS. 1 and 2) adds their signature again using the maker's offline transaction do. In this specification, a taker means a person who wants to make a transaction by adding his or her signature to the maker's transmission command.

3. The final offline transaction signed by the maker and taker entrusts execution to a third party (referred to as a relay entity in this specification, refer to the relay entity of 'service' in FIGS. 1 and 2) for fairness of the transaction. In this specification, the relay means a person who executes the commands signed by the maker and the taker in two blockchains, respectively. Also, in this specification, an offline transaction means that a transaction signed by a maker and a taker is created as a meta transaction so that a relay can execute it.

4. The broker entrusted with the execution of the transaction executes the corresponding offline transaction, withdraws the amount to be transacted on both blockchains from the wallets of the maker and taker, and deposits it in the smart contract.

5. The maker and the taker check whether the right amount is deposited in their wallet of the blockchain they want to transfer to, and if the deposit is correct, they sign the approval.

6. The relayer who has received both the maker and taker approval signatures collects the signatures of the two and executes the smart contract.

7. After confirming that the approval transaction is successful, the relay executes a withdrawal transaction to withdraw the transferred assets to each user.

In the present invention, the reason for separating approval and withdrawal is that either of the approvals may be processed late due to the difference in block generation time between blockchains. In consideration of this point, the approval status and the withdrawal status were separated without direct withdrawal.

As described above, according to the present invention, when a transaction is started, the smart contracts of each block chain move the assets of the maker and the taker to the smart contract (a kind of deposit concept), and the maker and the taker want to move After confirming that the assets are correctly deposited in the smart contract that

8. If the transaction time limit is exceeded or the transaction is not completed, the user can cancel their transaction and retrieve their assets. If only one party made the final signature (i.e., only one party has executed an approved transaction), or if the signature is not registered in the smart contract at the same time, the relay can invalidate (cancel) the transaction and retrieve their own assets. let it be

1 and 2 are flowcharts for explaining an asset exchange method between compatible blockchain networks according to an embodiment of the present invention.

1 and 2, an asset exchange method between compatible blockchain networks according to an embodiment of the present invention is executed by a relay entity (a service in FIGS. 1 and 2) relaying asset exchange, (a) A smart contract for an asset exchange transaction between a first entity (User 1 in FIGS. 1 and 2, see the above-mentioned maker) and a second entity (User 2 in FIGS. 1 and 2, see the above-mentioned Taker) acquiring a meta-transaction for entrustment created for this purpose; (b) executing the smart contract through the consignment meta transaction, withdrawing assets corresponding to each exchange amount from each blockchain wallet and depositing it in the smart contract of each blockchain; (c) As a meta-transaction for approval confirming that the assets corresponding to each exchange amount are normally deposited, executing the withdrawal transaction to execute the withdrawal so that the assets deposited in the smart contract are transferred to each counterparty; includes ;

Here, the first entity holds assets in a first blockchain (blockchain 1 in FIGS. 1 and 2), which is a specific blockchain platform, and the second entity is another blockchain compatible with the first blockchain. Assets are held on the platform, the second blockchain (blockchain 2 in FIGS. 1 and 2).

Also, here, the entrustment meta-transaction and the authorization meta-transaction are transactions processed without incurring a transaction fee to the first entity and the second entity. To this end, the relay entity pays a transaction fee for transactions generated for an asset exchange transaction between the first entity and the second entity on behalf of the first entity and the second entity, A smart contract is executed, and an asset exchange transaction between the first entity and the second entity can be relayed through the transaction transfer relay between the compatible blockchain networks.

In the present invention, the meta-transaction for entrustment includes a first meta-transaction for entrustment generated by the first entity and a second meta-transaction for entrustment generated by the second entity.

At this time, the first meta-transaction for entrustment (refer to S110 in FIG. 1) is a transaction parameter that functions as a condition command for the execution of the smart contract. ID, type of asset to be exchanged, exchange amount, transaction validity time limit, and distribution including a signature by the first entity.

The execution function of the first entrustment meta transaction may be, for example, as follows.

function make(uint256[2] memory _chainids, address[2] memory _tokens,

uint256[3] memory _amounts, uint256 _deadline)

A maker creates and signs a smart contract command that records the assets it wants to exchange with its own assets and the information on the blockchain in which the assets are circulated. Accordingly, the maker makes this command into an offline transaction with a meta-transaction (meta-tx) method.

At this time, the arguments included in the execution function are: i) _chainids: own blockchain ID and ID of the blockchain to be transferred, ii) _tokens: type of asset to be exchanged, iii) _amounts: to be transferred from own blockchain It includes the amount and the amount on the blockchain that you want to receive (this value may be different because the value is different), iv) _deadline: time limit (this operation will not be performed if the time is exceeded).

Also, at this time, the second meta-transaction for entrustment (refer to S120 of FIG. 1 ) is the transaction parameter, as the transaction parameters, included in the first meta-transaction for entrustment, the signature of the first entity, and the block of the first entity. It contains a chain wallet address and is distributed with a signature by the second entity.

The execution function of the second entrustment meta transaction may be, for example, as follows.

function take(uint256[2] memory _chainids, address[2] memory _tokens,

uint256[3] memory _amounts, uint256 _deadline, address _maker, bytes

memory_sigMaker)

Other users (takers) or companies that move assets add their own signatures to the transaction based on the information disclosed by the maker and disclose them online or offline again. At this time, the taker makes the contents of the offline transaction created by the maker and the above command into an offline transaction using meta-transaction (meta-tx).

At this time, the parameters included in the execution function are: i) _chainids: own block chain ID and block chain ID to be transferred, ii) _tokens: type of asset to be exchanged, iii. _amounts: Amount to be transmitted from their own blockchain and the amount from the blockchain they want to receive, iv) _deadline: time limit, v) _maker: wallet address of the user who initiated the transaction, vi) _sigMaker: The user who initiated the transaction Included is the signature (with this signature verifying that the transaction was made by a legitimate user).

In the present invention, in step (b), generating a meta transaction for deposit (S130 in FIG. 1) is included. In this case, the deposit meta-transaction includes, as the transaction parameters, a transaction parameter included in the second entrustment meta-transaction, a signature of the second entity, and a blockchain wallet address of the second entity. Here, if the asset exchange transaction is not validly established until the transaction validity time limit included in the deposit meta transaction is exceeded, the relay entity may process the deposited asset to be returned to each entity. .

The execution function of the meta transaction for deposit may be, for example, as follows.

function deposit( uint256[2] memory _chainids, address[2] memory _tokens, uint256[3] memory _amounts, uint256 _deadline, address[2] memory _signers, bytes memory _sigMaker, bytes memory _sigTaker) external ensure(_deadline) lock returns ( bytes32 hash)

The relay executes a smart contract that contains both the maker and taker signatures through meta-transactions (meta-tx). At this time, the smart contract is distributed to different blockchains with the same logic. At this time, the deposit meta-transaction executed by the relay transfers the amount of assets set by the maker and the taker to the smart contract and deposits it.

Deposited assets can be retrieved by each user if a transaction is not established after the time limit. Alternatively, even if the signature is executed on both smart contracts, but only one is executed depending on the execution speed of each block chain, the transaction is not completed as well. Uncompleted assets can be withdrawn directly by the user or returned by an intermediary.

At this time, the arguments included in the execution function are: i) _chainids: own blockchain ID and ID of the blockchain to be transferred, ii) _tokens: type of asset to be exchanged, iii) _amounts: to be transferred from own blockchain Amount and amount in the block chain you want to receive, iv) _deadline: time limit, v) _signers: wallet addresses of the maker and taker, vi) _sigMaker: the user who initiated the transaction signed their transaction, vii) _sigTaker: This includes re-signing the transaction request of the user who initiated the transaction by the user who accepted the transaction with his/her private key.

In the present invention, the meta-transaction for approval [see S140 in FIG. 2] is generated by the first entity and the second entity, respectively, and as the transaction parameters, a blockchain ID (Identifier) in which the asset is stored, the asset a blockchain ID to which to transfer, a first hash value obtained by hashing the signature of the first entrustment meta-transaction, and a second hash value obtained by hashing the signature of the second entrustment meta-transaction. At this time, when the meta-transaction for approval is not received from each of the first entity and the second entity, the relay entity may invalidate the asset exchange transaction and process the deposited asset to be returned to each entity. .

The execution function of the meta transaction for approval may be, for example, as follows.

confirm(uint256[2] memory _chainids, bytes32[2] memory _hashes)

When the smart contract is executed safely and the assets of both sides are safely deposited in the smart contract of each block chain, the maker and taker check whether the assets set as their share in the block chain to be transferred are safely deposited, and then confirm the command is created, signed, and sent to the relay. The confirmation of the deposit can be confirmed in the smart contract of the other party's blockchain through the hash of the offline transaction.

At this time, the parameters included in the execution function are: i) _chainids: own block chain ID and ID of the block chain to be transferred, ii) _hashes: function 1 (execution function of the first entrustment meta transaction) and number 2 The hashed signature of the function (the execution function of the meta-transaction for the second entrustment) is included.

In the present invention, the step (c) further includes, after the approval meta-transaction is obtained, before executing the withdrawal transaction, generating a waiting-for-withdraw transaction and executing it in the blockchain of each entity.

In this case, the transaction waiting for withdrawal (see S150 of FIG. 2 ) is, as the transaction parameters, a transaction parameter of the meta-transaction for approval, a confirmation signature by the first entity regarding the meta-transaction for approval of the second entity, and the and a confirming signature by the second entity regarding the meta-transaction for approval of the first entity.

The execution function of the fetch waiting transaction may be, for example, as follows.

confirms(uint256[2] memory _chainids, bytes32[2] memory _hashes, bytes memory _sigMaker, bytes memory _sigTaker)

When the maker and taker signature information are all gathered, the relay executes the signed transaction on each block chain so that users can wait for withdrawal. At this time, the reason for waiting without withdrawing immediately is because there is a possibility that either one will not be executed depending on the execution speed and state of the block chain.

At this time, the parameters included in the execution function are: i) _chainids: own block chain ID and ID of the block chain to be transferred, ii) _hashes: function 1 (execution function of the first entrustment meta transaction) and number 2 Hashing the signature of the function (the execution function of the second entrustment meta transaction), iii) _sigMaker: The maker signed the taker's deposit confirmation (using this signature to verify that the transaction was made by a legitimate user) iv ) _sigTaker: Contains the taker signing the maker's deposit confirmation.

Also, in this case, the withdrawal transaction may include, as the transaction parameters, a first hash value obtained by hashing the signature of the first entrustment meta-transaction, and a second hash value obtained by hashing the signature of the second entrustment meta-transaction. have.

The execution function of the withdrawal transaction may be, for example, as follows.

withdraw(bytes32 _hash) external lock returns (bool)

If the fetch waiting command is executed properly, the relay executes the fetch command to execute the retrieval to each user.

At this time, the arguments included in the execution function are i) _hashes: hashed signatures of function 1 (execution function of the first meta-transaction for entrustment) and function 2 (execution function of the meta transaction for entrustment) thing is included

Although the above has been described with reference to the embodiments of the present invention, those of ordinary skill in the art may variously modify the present invention within the scope not departing from the spirit and scope of the present invention described in the claims below. and can be changed.

Claims (6)

A method of asset exchange in a blockchain network executed by a relay entity relaying asset exchange, comprising:
(a) acquiring a meta-transaction for entrustment created for a smart contract for an asset exchange transaction between a first entity and a second entity;
(b) executing the smart contract through the consignment meta transaction, withdrawing assets corresponding to each exchange amount from each blockchain wallet and depositing it in the smart contract of each blockchain;
(c) As the meta-transaction for approval confirming that the assets corresponding to each exchange amount are normally deposited, executing the withdrawal transaction to execute the withdrawal so that the assets deposited in the smart contract are transferred to each counterparty; ;
A method of asset exchange in a blockchain network that includes
According to claim 1,
The first entity holds assets in a first blockchain that is a specific blockchain platform, and the second entity holds assets in a second blockchain that is another blockchain platform compatible with the first blockchain,
The entrustment meta-transaction and the approval meta-transaction are transactions processed without incurring a transaction fee to the first entity and the second entity,
The relay entity pays a transaction fee for transactions generated for an asset exchange transaction between the first entity and the second entity on behalf of the first entity and the second entity, so that the smart contract for the transaction is and relaying an asset exchange transaction between the first entity and the second entity through a transaction transfer relay between the compatible blockchain networks.
According to claim 1,
The entrustment meta transaction is
a first meta-transaction for entrustment generated by the first entity and a second meta-transaction for entrustment generated by the second entity;
The first entrustment meta transaction is
As a transaction parameter that functions as a conditional command for the execution of a smart contract, it includes the blockchain ID (Identifier) where the asset is stored, the blockchain ID to transfer the asset, the type of asset to be exchanged, the amount of exchange, and the transaction validity time limit. , distributed including a signature by the first entity,
The second entrustment meta transaction is
As the transaction parameters, the transaction parameters included in the first entrustment meta-transaction, the signature of the first entity, and the blockchain wallet address of the first entity are distributed, including the signature by the second entity. An asset exchange method in a blockchain network, characterized in that.
4. The method of claim 3,
In step (b),
creating a meta-transaction for deposit;
The deposit meta transaction is
As the transaction parameters, it includes a transaction parameter included in the second entrustment meta-transaction, a signature of the second entity, and a blockchain wallet address of the second entity,
The relay entity, if the asset exchange transaction is not validly established until the transaction validity time limit included in the deposit meta-transaction is exceeded, the deposited asset is returned to each entity, characterized in that , a method of asset exchange in a blockchain network.
5. The method of claim 4,
The approval meta transaction is
generated by the first entity and the second entity, respectively;
As the transaction parameters, the blockchain ID (Identifier) in which the asset is stored, the blockchain ID to which the asset is to be transferred, the first hash value obtained by hashing the signature of the first entrustment meta transaction, and the signature of the second entrustment meta transaction Including a second hash value hashed,
the relay entity, if the meta-transaction for authorization is not received from each of the first entity and the second entity, invalidates the asset exchange transaction and processes the deposited asset to be returned to each entity , a method of asset exchange in a blockchain network.
6. The method of claim 5,
Step (c) is,
After the meta-transaction for approval is obtained, before executing the withdrawal transaction, generating a transaction waiting for withdrawal and executing the transaction in the blockchain of each entity,
The withdrawal waiting transaction is
As the transaction parameters, a transaction parameter of the meta-transaction for approval, a confirmation signature by the first entity for the meta-transaction for approval of the second entity, and a meta-transaction for approval of the first entity to the second entity related to the meta-transaction for approval including a confirmation signature by
The withdrawal transaction is
As the transaction parameter, a first hash value obtained by hashing the signature of the first meta-transaction for entrustment, and a second hash value obtained by hashing the signature of the second meta-transaction for entrustment. of asset exchange methods.

Images