KR102428950B1 - Method and system for off-chain payment - Google Patents

Abstract

The present invention is an operation method between terminals for performing a contract between a first terminal and a second terminal in an off-chain, using a Trusted Execution Environment (TEE), the first terminal and Generating a public address and a private key of the second terminal and generating a transaction using information including the public address of the first terminal and the public address of the second terminal includes Through the present invention, payment time can be shortened, and processing performance and stability can be improved.

Description

Off-chain payment method and its system {METHOD AND SYSTEM FOR OFF-CHAIN PAYMENT}

The present invention relates to an off-chain payment method and system, and more particularly, to a payment method and system for performing a block-chain payment service in a block-chain off-chain environment.

Blockchain is a mechanism that helps all nodes see the same transaction ledger even in a distributed system environment where they do not trust each other. A typical use case is Bitcoin.

In addition, a smart contract is a programmable contract that allows all nodes to view the same program state by performing transactions in the same order in a distributed system environment, in addition to simply trading assets such as coins. Ethereum is a representative open project.

On the other hand, the payment service in the blockchain environment is a core service that is absolutely necessary in the blockchain-based application service. In general, in a blockchain network, miners perform a consensus algorithm to generate transactions in block form and deliver them to participating nodes. All nodes participating in the blockchain network maintain the same type of blockchain and can only add consensus blocks. Accordingly, the stability of the blockchain network can be guaranteed.

In public or permissionless blockchains such as Bitcoin or Ethereum blockchain, a unique token is defined, and payment services are inherent, but due to the performance limitations of these public blockchains, There is a limit to being used as a payment service in This is due to the fact that, in the case of a public blockchain, the nodes participating in the network are spread all over the world, and the number of transactions that occur accordingly is also increasing. This is because the number of transactions that can be included in one block is limited.

Specifically, the number of transactions per second (TPS) that VISA, a global digital payment network company, can process is about 25,000, while the TPS of current public blockchains Bitcoin and Ethereum are about 7 and 15, respectively. is known As such, the performance of the public blockchain has a big difference compared to the existing VISA performance. In addition, the TPS of Hyperledger/Fabric, a private or permissioned blockchain, is about 1,000, which is significantly improved compared to the public blockchain, but it is still inferior to the performance of VISA. can

Currently, various technologies are being proposed to solve this block chain scalability problem. Representative technologies include off-chain techniques, consensus algorithm improvement, sharding, and side-chain.

Here, the off-chain technique is a type of technique that allows frequent transaction parties to mutually agree and execute transactions outside the block chain, and record only the final result in the block chain. For example, Lightning Network in the Bitcoin blockchain and Raiden Networks in the Ethereum blockchain are representative off-chain techniques. Among off-chain techniques, off-chain payment channel technology is attracting attention as a blockchain-based payment service that can be applied to daily tasks.

The common limitations of Lightning Network and Raiden Network, which are widely used as existing payment channel technologies, and various payment channel technologies that have been researched and published so far are as follows.

First, the amount of users' money for payment processing on the network is tied up until the payment is completely completed. The user's amount for payment processing is called payment processing cost. The payment processing cost increases in proportion to the total amount of money required for payment on the network and the time the total amount is tied up. The payment processing cost is a cost necessary for the payment channel protocol, but the larger the payment processing cost, the more inconvenient the user is.

Second, when a payment is made between users who have not directly created a payment channel, a very complicated process is required. The more complicated the payment process, the higher the probability of a security flaw, and the problem is that it is difficult to quickly perform the payment.

Third, it is necessary to continuously monitor invalid payment transactions on the blockchain. Since payments are made off-chain between both sides of the payment channel, payment transaction results agreed upon are accumulated between the two users at every moment. The accumulated payment transaction results are valid results based on mutually agreed information when viewed individually, but previous payment results except for the most recent payment transaction results are no longer valid results. At this time, by uploading the resulting invalid transactions to the blockchain, someone can make a malicious cleanup request for the deposit associated with the payment channel. To prevent this, timelock information, which becomes valid only after a certain period of time, is used by connecting it to the payment transaction result of the payment channel.

This time-lock-based method depends on the number of payment transaction results that can be created according to the time-lock value of the first transaction of the payment channel, and on-chain ( There is a problem that an on-chain) real-time monitoring function is absolutely necessary.

An object of the present invention for solving the above problems is to provide an off-chain payment method and a system that provide high speed, high scalability and high stability.

In order to achieve the above object, an inter-terminal operation method for performing a payment between a first terminal and a second terminal in an off-chain according to an embodiment of the present invention for achieving the above object, a trusted execution environment, TEE), generating a public address and a private key of the first terminal and the second terminal, and the public address of the first terminal and the public address of the second terminal are and generating a transaction by using the included information.

Here, the private key is characterized in that it is stored in the trusted execution environment.

Here, a payment path is established between the first terminal and the second terminal, and the first terminal and the second terminal perform an operation related to the payment path through a command returned by the trusted execution environment. characterized in that

Here, the operation related to the payment channel is characterized in that it is associated with a private key stored in the trusted execution environment.

Here, the trusted execution environment is characterized in that it is disposed in the first terminal and the second terminal.

In addition, a system for performing a payment in an off-chain according to an embodiment of the present invention is a payment network including a plurality of terminals and a payment channel connecting the plurality of terminals, and among the plurality of terminals, A payment path calculation module for receiving payment request information between a first terminal and a second terminal to perform and calculating an optimal payment path between the first terminal and the second terminal, and terminals existing in the calculated optimal payment path Including a service provider server including a protocol execution module for transmitting a state transition command to the user, the payment request information is generated using information including public addresses of the first terminal and the second terminal Including the transaction information, the public addresses of the first terminal and the second terminal are generated using a trusted execution environment (TEE).

Here, the first terminal and the second terminal further generate a private key, and the private key is stored in the trusted execution environment.

Here, a payment channel is established between the first terminal and the second terminal, and the first terminal and the second terminal perform an operation related to the payment channel through a command returned by the trusted execution environment. characterized in that

Here, the operation related to the payment channel is characterized in that it is associated with a private key stored in the trusted execution environment.

Here, the trusted execution environment is characterized in that it is disposed in the first terminal and the second terminal.

Here, the optimal payment path between the first terminal and the second terminal is calculated based on a payment network map generated using connection information of the plurality of terminals.

Here, the protocol execution module is characterized in that after generating the optimal payment path, it is characterized in that the request to change the state of the terminals existing in the optimal payment path to a state before update (PRE-UPDATE).

Here, when the protocol execution module receives channel information in a pre-update state from terminals existing in the optimal payment path, the optimal payment path determines the payment request based on balance information of channels existing in the optimal payment path It is characterized in that it is determined whether the information is suitable for processing.

Here, when it is determined that the optimal payment path is suitable for processing the payment request information, the protocol execution module requests to transition the states of terminals existing in the optimal payment path to a POST-UPDATE state. characterized in that

Here, the protocol execution module receives payment-related information including update information based on a trusted execution environment from the terminals existing in the optimal payment path transitioned to the state after the update, and sends a payment execution message to the optimal payment path It is characterized in that it is transmitted to existing terminals.

Here, the system further comprises a payment channel information database (DB) in which connection information between terminals included in the payment network is stored.

Here, the system further comprises a payment channel smart contract including channel information between terminals included in the payment network.

Here, the service providing server, characterized in that it further comprises a contract information synchronization module for performing synchronization with the payment channel smart contract.

Here, the service providing server, characterized in that it further comprises a block chain network communication unit for receiving smart contract information existing in the block chain.

The off-chain payment method and system according to the present invention can reduce the time required for payment by simplifying the configuration of the off-chain payment network protocol, thereby reducing collateral cost.

Also, since the service provider server synchronizes the status of users involved in the payment path, the payment processing time can be significantly reduced.

In addition, since the service provider server receives multiple requests from off-chain payment participants and processes them at once, payment performance can be improved.

In addition, since the payment system performs a payment operation based on the Trusted Execution Environment (TEE), the safety and reliability of the offline payment service may be promoted.

Also, since the payment system performs payment operations based on the trusted execution environment, there is no need to monitor malicious on-chain activities of off-chain payment parties.

However, the effects that the off-chain payment method and the system can achieve according to the embodiments of the present invention are not limited to those mentioned above, and other effects not mentioned are from the following description in the technical field to which the present invention belongs It will be clearly understood by those of ordinary skill in the art.

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are included as a part of the detailed description to help the understanding of the present invention, provide embodiments of the present invention, and together with the detailed description, explain the technical spirit of the present invention.
1 is a block diagram of an off-chain payment system 1000 according to an embodiment of the present invention.
2 is a block diagram of a service provider server 100 according to an embodiment of the present invention.
3 is a block diagram of a payment channel smart contract 300 according to an embodiment of the present invention.
4 is a conceptual diagram illustrating the use of a payment channel 420 between user terminals 410 in a payment network 400 according to an embodiment of the present invention.
5A and 5B are flowcharts illustrating an operation process of the off-chain payment system 1000 according to an embodiment of the present invention.
6 is a conceptual diagram illustrating a state transition diagram of the user terminal 410 according to an embodiment of the present invention.

Since the present invention can have various changes and can have various embodiments, specific embodiments are illustrated in the drawings and described in detail. 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.

Terms such as first, second, etc. may be used to describe various elements, but the elements should not be limited by the terms. The above terms are used only for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, a first component may be referred to as a second component, and similarly, a second component may also be referred to as a first component. and/or includes a combination of a plurality of related listed items or any of a plurality of related listed items.

When a component is referred to as being “connected” or “connected” to another component, it may be directly connected or connected to the other component, but it is understood that other components may exist in between. it should be On the other hand, when it is said that a certain element is "directly connected" or "directly connected" to another element, it should be understood that the other element does not exist in the middle.

The terms used in the present application are only used to describe specific embodiments, and are not intended to limit the present invention. The singular expression includes the plural expression unless the context clearly dictates otherwise. In the present application, terms such as “comprise” or “have” are intended to designate that a feature, number, step, operation, component, part, or combination thereof described in the specification exists, but one or more other features It is to be understood that it does not preclude the possibility of the presence or addition of numbers, steps, operations, components, parts, or combinations thereof.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Terms such as those defined in a commonly used dictionary should be interpreted as having a meaning consistent with the meaning in the context of the related art, and should not be interpreted in an ideal or excessively formal meaning unless explicitly defined in the present application. does not

Hereinafter, preferred embodiments of the present invention will be described in more detail with reference to the accompanying drawings. In describing the present invention, in order to facilitate the overall understanding, the same reference numerals are used for the same components in the drawings, and duplicate descriptions of the same components are omitted.

1 is a block diagram of an off-chain payment system 1000 according to an embodiment of the present invention.

In this specification, a blockchain stores data in a distributed data storage environment, so that anyone can read the data, but no one can arbitrarily modify it. Distributed computing technology-based data forgery prevention technology or distributed data storage technology can mean A block chain is a plurality of blocks connected in a chain form, where a block may be a unit for storing data. As continuously changing data is recorded by all nodes in the blockchain, it may not be possible for any one node to arbitrarily manipulate the entire data.

In the present specification, cryptocurrency may be a digital asset in which transaction safety is secured and forgery is prevented by using the above-described block chain-based encryption method. As an example, cryptocurrencies include Bitcoin, Ethereum, Ripple, Litecoin, and the like.

In this specification, on-chain may mean on a blockchain network. The expression that a certain operation or operation is performed on-chain means that the operation or operation is performed on the blockchain network, and may mean, for example, that the operation or operation is performed by at least one node. Off-chain can mean outside the blockchain network. The expression that an operation or operation is performed off-chain may mean that the operation or operation is performed in a network outside the blockchain network that is distinct from the blockchain network. For example, it can be seen that all communication between user terminals, separate servers, and other communicationable devices is performed off-chain, except for block generation between blockchain nodes and distributed consensus processes.

Referring to FIG. 1 , an off-chain payment system 1000 according to the present invention includes a service provider server 100 , a payment channel information database (DB) 200 , a payment channel smart contract 300 , and a payment network 400 . includes The payment network 400 includes a plurality of user terminals 410 and a payment channel 500 . The off-chain payment system 1000 according to the present invention may support a Turing completeness smart contract.

The service provider server 100 may be a device for controlling and executing a command related to a multi-hop payment protocol, and fetching information about the payment channels 500 . The service provider server 100 may be a desktop or a server. The present invention introduces the service provider server 100 responsible for protocol execution, so that the synchronization of the state of each node can be simplified. A detailed configuration of the service provider server 100 according to the present invention will be described later with reference to FIG. 2 .

The payment channel information database (DB) 200 may continuously receive information and synchronization information of the payment channel smart contract 300 on the block chain from the service provider server 100 . Through this, it is possible to retain the latest connection information between users currently participating in the payment network 400 . As an example, the payment channel information database (DB) 200 may be a MySQL or Oracle database.

The payment channel smart contract 300 may be an application operating on a block chain, and may be used for settlement of off-chain payment processing results and dispute settlement. A transaction can serve as an input to change the state of a smart contract. Here, a transaction may be used in the meaning of an order or an order. For example, the transaction may represent contents such as 'user A sends a predetermined amount of cryptocurrency to user B' in a single character string.

Transactions of blocks on the block chain may change the state of the payment channel smart contract 300 , and the payment channel smart contract 300 may keep the latest state of the payment channel smart contract 300 . Transactions for cryptocurrency exchange, deposit, and withdrawal may change the state of the payment channel smart contract 300 , and accordingly, the changed balance information may be stored in the payment channel smart contract 300 . The block chain may be any block chain that supports the payment channel smart contract 300 . For example, a smart contract-enabled blockchain such as Ethereum can be used. A detailed configuration of the payment channel smart contract 300 according to the present invention will be described later with reference to FIG. 3 .

The payment network 400 includes a payment channel 420 connecting a plurality of user terminals 410 . The payment network 800 may mean that a plurality of user terminals 410 and payment channels 420 are connected to each other to form one network. Meanwhile, the user terminals 410 participating in the off-chain payment processing may all operate through a command based on a trusted execution environment (TEE) 500 . Because the trusted execution environment forces each node to perform only predefined actions, malicious actions of nodes can be prevented in the process of executing the off-chain payment channel protocol. A detailed operation of the payment network 400 based on the trusted execution environment will be described later with reference to FIG. 4 .

The user terminal 410 may be viewed as one node. The user terminal 410 is a device for performing a payment operation by participating in a protocol, and may be a desktop, a laptop, or a mobile device as an embodiment. The user terminal 410 may execute an operation in the payment channel 420 directly connected to the counterpart, or may send and receive messages for conforming to the protocol with the service provider server 100 when participating in the payment path. As such, the user terminal 410 (ie, a node) is one of the components of the payment network 400 and may be a subject that performs an operation for maintaining the corresponding block chain. The maintenance of the blockchain may include the creation of new blocks. Any node of the block chain may generate a block of the block chain using the transaction issued to the user terminal 410 . The generated block is shared among the nodes of the blockchain through the process of distributed consensus and can be linked to the next block of the blockchain.

The user terminal 410 may generate a transaction. In addition, the user terminal 410 may check the balance information stored in the smart contract through any one of the user terminals of the block chain. User client can be used in the same sense as blockchain client. Here, the payment network 400 may mean a network that shares a transaction or a block among a plurality of user terminals 410 .

2 is a block diagram of a service provider server 100 according to an embodiment of the present invention.

Referring to FIG. 2 , the service provider server 100 according to an embodiment of the present invention includes a contract information synchronization module 110 for continuously bringing information of a payment channel smart contract 300 on a block chain to the server, and payment A payment path calculation module 120 that calculates an optimal payment path based on information about the channels 420, a protocol execution module 130 for multi-hop payment processing via several user terminals 410 on the payment path and a block chain network communication unit 140 responsible for communication with the block chain network.

The contract information synchronization module 110 may be a module for synchronization with the payment channel smart contract 300 storing payment channel 420 information of users who are using the payment channel 420 . Each user terminal 410 is represented by a public address internally generated by the Trusted Execution Environment (TEE), and can identify and synchronize a connection relationship by bringing channel information of users.

The payment path calculation module 120 may be a module that calculates an optimal payment path from a sender to a receiver using information synchronized by the contract information synchronization module 110 . In more detail, a payment network map may be generated based on connection information of each user terminal 410 , and an optimal payment path may be determined based on the payment network map.

In order to process the requested payment, the protocol execution module 130 may execute a protocol for payment between a sender, intermediate users (intermediaries), and a receiver included in the payment path calculated by the payment path calculation module 120 . In addition, the protocol execution module 130 may synchronize the states of all user terminals existing in the payment path, so that the user terminals are synchronously expanded. In addition, the protocol execution module 130 may transmit a state transition command to user terminals existing on the payment path.

The block chain network communication unit 140 may receive information on smart contracts existing in the block chain. Specifically, it may be a module in charge of web3-based remote procedure call (JSON-RPC) on Ethereum or a module in charge of submitting a transaction based on Hyperledger/Fabric SDK.

3 is a block diagram of a payment channel smart contract 300 according to an embodiment of the present invention.

Referring to FIG. 3 , the payment channel smart contract 300 according to the present invention includes a payment channel information storage unit 310 , a protocol release information storage unit 320 , a payment channel generation unit 330 , and a payment channel termination unit 340 . ), a protocol release unit 350 and a payment channel settlement unit 360 .

The payment channel information storage unit 310 may store information on payment channels 420 connected between the user terminals 410 . The payment channel information storage unit 310 may determine whether the payment channel 420 actually exists by using the identifier value of the payment channel as a key. When the payment channel 420 actually exists, the addresses of the two user terminals 400 constituting the connection may be obtained as a value.

The protocol release information storage unit 320 includes information on which state the user terminal 410 has departed from, if any user terminal 410 leaves while a transaction is being made on the payment network.

The payment channel generation unit 330 may be a module that is called when a message requesting creation of the payment channel 420 is received from the user terminal 410 . After the payment channel 420 agrees that any two users will create the payment channel 420 in an official or unofficial form, one of the two users sends the public addresses of the two users through the terminal to request channel creation and It can be created by passing a deposit together.

The payment channel termination unit 340 may be a module that is called when a message requesting termination of the corresponding payment channel is received from the user terminal 410 connected to any payment channel. When the payment channel termination unit 340 receives the payment channel termination request, information on final balance distribution may also be received. The payment channel termination unit 340 properly returns the two users' deposits to the public addresses of the two users of the payment channel according to the balance information, respectively, using the information on the balance distribution, and terminates the payment channel. have.

The protocol emitter 350 may be a module that is called when a message requesting departure from the payment network 400 is received from the user terminal 410 . When the protocol emitter 350 receives a release request on the payment network, it may receive status information of related payment channels, final balance distribution information, and information on the payment amount together. The protocol release unit 350 uses the final status information of the related payment channels, the final balance distribution information, and the information on the payment amount to settle the corresponding payment channels and register the emission information in the protocol release information storage unit 320 . can

The payment channel settlement unit 360 may be a module called when a message requesting settlement of the related payment channels is received from the user terminal 410 related to the payment network. When the payment channel settlement unit 360 receives the payment channel settlement request, it may receive status information of related payment channels, final balance distribution information, and information on the payment amount together. The payment channel settlement unit 360 uses the final balance distribution information to properly return the two users' deposits to the public addresses of both users of the payment channel according to the balance information, respectively, and terminate the payment channel. have.

4 is a conceptual diagram illustrating use of a payment channel 420 between user terminals 410 in a payment network 400 according to an embodiment of the present invention.

Referring to FIG. 4 , as an embodiment according to the present invention, a process of using a payment channel 420 between two user terminals 410A and 410B is illustrated.

In order for the user terminals 410A and 410B to perform a specific operation on the payment channel 420 , the command of the untrusted execution environment 600 must pass through the trusted execution environment 500 . For example, an operation related to the payment channel 420 may be performed via a command returned by the trusted execution environment 500 .

Each of the user terminals 410A and 410B may generate a public address and a private key by using a Trusted Execution Environment (TEE). In addition, the trusted execution environment 500 may generate a transaction using information including the public address of the first user terminal 410A and the public address of the second user terminal 410B.

After the trusted execution environment 500 generates a public address, a private key for the corresponding address may be stored therein. Since all actions related to the payment channel 420 are associated with the private key stored inside the trusted execution environment, the user cannot take any action on the payment channel 420 . When the two user terminals 410A and 410B connected to the payment channel 420 operate in a trusted execution environment, the operation command related to the payment channel 420 always returns a result through a predefined operation, so that the user terminals ( 410A, 410B) cannot act arbitrarily. In this case, since the correct operation of the user terminals 410A and 410B is guaranteed, past agreed transactions cannot be uploaded to the block chain, so there is no need to monitor on-chain activity.

In addition, when using the trusted execution execution environment, arbitrary actions of each user terminal 410A, 410B are prevented, so it is not necessary to consider the number of multiple cases, and thus the configuration of the off-chain payment channel protocol can be made simple. have. In addition, since the service provider server 100 transmits the execution status of the protocol to the user terminals related to payment at once, the status of the users may be updated and synchronized together. This can reduce the time required for payment processing, which in turn can reduce the cost of collateral. Meanwhile, the trusted execution environment 500 may be disposed in the first user terminal 410A and the second user terminal 410B.

The trusted execution environment 500 may be provided by various known technologies such as Trusted Execution Technology (TXT), Manageability Engine (ME), TrustZone Security System, Virtualization Technology (VTx), microcode enforced thread, memory access separation, and the like. .

5A and 5B are flowcharts illustrating an operation process of the off-chain payment system 1000 according to an embodiment of the present invention.

Referring to FIGS. 5A and 5B , the service provider server 100 may transmit a message to a plurality of user terminals 410 to share information, and may synchronize an intermediate step of a payment channel process. Here, the plurality of user terminals 410 may be viewed as nodes constituting the payment channel network 400 .

When any one user terminal 410A of the plurality of user terminals 410 wants to perform a payment operation to another specific user terminal 410B, the user terminal requesting the payment operation sends a payment request message to the service provider server 100 ) can be transmitted to (S501). The payment request message may include transaction information generated using information including public addresses of the user terminals 410A and 410B to perform a payment operation. Here, the public addresses of the user terminals 410A and 410B may be generated using a trusted execution environment (TEE).

When the service provider server 100 receives a payment request message (or payment request information) from any one user terminal, the service provider server 100 determines the form in which the payment channels 420 on the payment network 400 are configured. In order to find out, information on the configuration of the payment channels 420 may be requested from the payment channel information database (DB) 200 ( S502 ).

The service provider server 100 may receive information related to the payment channel 420 from the payment channel information database (DB) 200 (S503). In other words, the payment channel information database (DB) 200 may return information related to the payment channel 420 to the service provider server 100 ( S503 ).

After receiving the requested information, the service provider server 100 connects between the user terminal 410A that wants to perform a payment operation based on the information on the corresponding payment channels 420 and the user terminal 410B that will receive the money. It is possible to calculate the optimal payment path of (S504). Thereafter, a payment network map may be configured (S505). Steps S504 to S505 may be performed by the payment path calculation module 120 of the service provider server 100 .

The service provider server 100 verifies whether all payment channels 420 existing on the payment network calculated through steps S504 and S505 have a balance sufficient to process the payment request, and confirms the intention to participate in the payment. In order to confirm, the user terminals included in the optimal payment path may be requested to participate in the payment (S506).

The terminals requested to participate in the payment may transition their respective channels to a PRE-UPDATE state (S507). In addition, the user terminals may transmit the channel information transferred to the state before the update to the service provider server 100 (S508).

The service provider server 100 may receive payment participation intentions from all terminals existing in the payment network, and may check whether payment participation intentions are received from all terminals existing in the payment network (S509).

The service provider server 100 may generate payment-related information corresponding to the payment request, and request user terminals existing in the payment network to update information of related payment channels existing in the trusted execution environment to the payment completion state. (S510).

After the user terminals 410 update the information of the related payment channels existing in the trusted execution environment to the payment completion state, they may transition their channels to the post-update (POST-UPDATE) state (S511). In addition, each user terminal may transmit the update completion fact to the service provider server 100 (S512).

The service provider server 100 may transmit a payment completion message to each user terminal after confirming whether or not the update completion information through the trusted execution environment has been received from all user terminals existing in the path (S513) ( S514). Steps S506 to S514 may be performed by the protocol execution module 130 of the service provider server 100 .

6 is a conceptual diagram illustrating a state transition diagram of a user terminal 410 according to an embodiment of the present invention.

It will be described with reference to FIGS. 6 and 5 together. If the channel of the user terminal is not related to the payment path, the state of the user terminal is the resting state (S601). After receiving a payment network configuration request from the service provider server 100 in the resting state (S602), when a message indicating agreeing to the payment network configuration is transmitted to the service provider server 100 again (S603), the user terminal updates the channel before state can be transferred (S604).

On the other hand, after the user terminal in the state before the update receives a request from the service provider server 100 to update the information of the relevant payment channels existing in the trusted execution environment to the payment completed state (S605), the related payment existing in the trusted execution environment When the information of channels is updated to the payment completion state and the update completion fact is transmitted to the service provider server 100 again (S606), the state of the user terminal may be transferred to the state after the update (S607).

Meanwhile, when a payment completion message is received from the service provider server 100 in the signature state ( S608 ), the state of the user terminal may be transitioned to the rest state ( S601 ).

The operation of the method according to the embodiment of the present invention can be implemented as a computer-readable program or code on a computer-readable recording medium. The computer-readable recording medium includes all types of recording devices in which data that can be read by a computer system is stored. In addition, the computer-readable recording medium may be distributed in a network-connected computer system to store and execute computer-readable programs or codes in a distributed manner.

In addition, the computer-readable recording medium may include a hardware device specially configured to store and execute program instructions, such as ROM, RAM, and flash memory. The program instructions may include not only machine language codes such as those generated by a compiler, but also high-level language codes that can be executed by a computer using an interpreter or the like.

Although some aspects of the invention have been described in the context of an apparatus, it may also represent a description according to a corresponding method, wherein a block or apparatus corresponds to a method step or feature of a method step. Similarly, aspects described in the context of a method may also represent a corresponding block or item or a corresponding device feature. Some or all of the method steps may be performed by (or using) a hardware device such as, for example, a microprocessor, a programmable computer, or an electronic circuit. In some embodiments, one or more of the most important method steps may be performed by such an apparatus.

In embodiments, a programmable logic device (eg, a field programmable gate array) may be used to perform some or all of the functionality of the methods described herein. In embodiments, the field programmable gate array may operate in conjunction with a microprocessor to perform one of the methods described herein. In general, the methods are preferably performed by some hardware device.

Although described above with reference to the preferred embodiments of the present invention, those skilled in the art can variously modify and change the present invention within the scope without departing from the spirit and scope of the present invention as set forth in the claims below. You will understand that you can.

1000: Off-chain payment system
100: service provider server
110: contract information synchronization module 120: payment path calculation module
130: protocol execution module 140: blockchain network communication module
200: payment channel information database (DB)
300: payment channel smart contract
310: payment channel information storage unit 320: protocol release information unit
330: payment channel generation unit 340: payment channel end unit
350: protocol emission unit 360: payment channel settlement unit
400: payment network
410, 410A, 410B, 410C, 410D: user terminal
420: payment channel
500: Trusted Execution Environment (TEE)
600: Untrusted execution environment

Claims (19)

In order to perform a payment between a first terminal and a second terminal among a plurality of terminals in an off-chain, a system including a block chain network and a server executing a smart contract program to control the operation between terminals As,
generating public addresses and private keys of the first terminal and the second terminal using a Trusted Execution Environment (TEE);
A payment network map generated using connection information between the first terminal and the second terminal by receiving payment request information between the first terminal and the second terminal to be paid among the plurality of terminals calculating a payment path that takes the shortest time calculated based on ;
After generating the shortest time required payment path to the terminals existing in the calculated shortest time required payment path, the state of terminals existing in the shortest time required payment path is updated before updating (PRE-UPDATE) and after updating (POST) sending a state transition command requesting a transition to -UPDATE); and
generating a transaction using information including the public address of the first terminal and the public address of the second terminal;
Inter-terminal operation method comprising According to claim 1,
wherein the private key is stored in the trusted execution environment. 3. The method of claim 2,
A payment channel is established between the first terminal and the second terminal,
wherein the first terminal and the second terminal perform an operation related to the payment channel through a command returned by the trusted execution environment. 4. The method of claim 3,
and the operation related to the payment channel is associated with a private key stored in the trusted execution environment. According to claim 1,
wherein the trusted execution environment is disposed in the first terminal and the second terminal. A system for performing payments off-chain,
a payment network comprising a plurality of terminals and a payment channel connecting the plurality of terminals; and
Among the plurality of terminals, by receiving payment request information between a first terminal and a second terminal to perform a payment, the payment network map is generated using connection information between the first terminal and the second terminal. A payment path calculation module for calculating the shortest time required payment path calculated based on the shortest time required payment path, after generating the shortest time required payment path to the terminals existing in the calculated shortest time required payment path, a terminal existing in the shortest time required payment path a service provider server including a protocol execution module that transmits a state transition command requesting to transition the states to a pre-update state (PRE-UPDATE) and a post-update state (POST-UPDATE);
Including, the payment request information includes transaction information generated using information including public addresses of the first terminal and the second terminal, and The system of claim 1 , wherein the public address is generated using a trusted execution environment (TEE). 7. The method of claim 6,
and the first terminal and the second terminal further generate a private key, and the private key is stored in the trusted execution environment. 8. The method of claim 7,
A payment path is established between the first terminal and the second terminal,
The system of claim 1, wherein the first terminal and the second terminal perform an operation related to the payment path through a command returned by the trusted execution environment. 9. The method of claim 8,
and the operation associated with the payment channel is associated with a private key stored within the trusted execution environment. 7. The method of claim 6,
and the trusted execution environment is disposed in the first terminal and the second terminal. 7. The method of claim 6,
The shortest time required payment path between the first terminal and the second terminal,
The system, characterized in that calculated based on a payment network map (payment network map) generated using the connection information of the plurality of terminals. 7. The method of claim 6,
The protocol execution module,
After the generation of the shortest time required payment path, the system, characterized in that requesting to change the state of the terminals existing in the shortest time required payment path to a pre-update state (PRE-UPDATE). 13. The method of claim 12,
The protocol execution module,
When channel information in a state before update is received from terminals existing in the shortest time required payment path, the channels existing in the shortest time required payment path are based on the balance information of channels existing in the shortest time required payment path The system, characterized in that it verifies whether it has a balance capable of processing the payment request information. 14. The method of claim 13,
The protocol execution module,
When it is verified that the channels existing in the shortest time required payment path have a balance that can process the payment request information, after updating the status of the terminals existing in the shortest time required payment path (POST-UPDATE) A system, characterized in that requesting a transition to a state. 15. The method of claim 14,
The protocol execution module,
Receive payment-related information including update information based on a trusted execution environment from terminals existing in the shortest time required payment path transitioned to the state after the update, and send a payment execution message to a terminal existing in the shortest time required payment path A system, characterized in that it transmits to them. 7. The method of claim 6,
The system is
The system, characterized in that it further comprises a payment channel information database (DB) in which connection information between terminals included in the payment network is stored. 7. The method of claim 6,
The system is
The system, characterized in that it further comprises a payment channel smart contract including channel information between terminals included in the payment network. 18. The method of claim 17,
The service providing server,
The system, characterized in that it further comprises a contract information synchronization module for performing synchronization with the payment channel smart contract. 18. The method of claim 17,
The service providing server,
The system, characterized in that it further comprises a block chain network communication unit for receiving smart contract information existing in the block chain.

Images