KR102100760B1 - METHOD FOR MULTI-HOP TRANSACTION ROUTING USING SMART CONTRACT in payment channel - Google Patents

Abstract

The present invention relates to a method for multi-hop transaction routing using a smart contract in a Payment channel. The method includes: (a) a step in which a requester generates a routing list in Protocol 1; (b) a step in which the requester requests a routing path based on the routing list; (c) a step in which the requester requests a checkRoutingNode (sender, receiver, path, value, time_lock, signature) message in relation to nodes included in each Path_Node in Protocol 2; (d) a step in which the nodes respond in Protocol 3 to the checkRoutingNode sent by the requester in Protocol 1; (e) a step in which the requester generates a Path_list by determining an available path in accordance with the response of the nodes in Protocol 4; and (f) a step in which the requester sends a transaction to a destination node by using one path on the Path_list. Quick transactions without delay are possible with the present invention.

Description

METHOD FOR MULTI-HOP TRANSACTION ROUTING USING SMART CONTRACT in payment channel in a payment channel using a smart contract

The present invention relates to a multi-hop transaction routing method in a payment channel using a smart contract, and more specifically, to respond to transaction delay and fault-tolerance by sending a request to allow routing in advance before creating a transaction. In addition, the performance also relates to a multi-hop transaction routing method in a payment channel using a smart contract that can reduce the transaction delay rate from a linear time delay rate to a constant time as many as the number of existing nodes.

Blockchain can be divided into public blockchain and private blockchain.

In the case of public blockchain, it is also called an unlicensed blockchain, and it is a blockchain that can use the network without limit of participants such as Bitcoin and Ethereum.

Transactions are shared and verified by everyone on the public blockchain network.

Unlike this, a private blockchain is called a closed blockchain, and it is a blockchain specially made by one institution. In order to participate in the private network, only those who have been verified through a predetermined authentication method on the blockchain network can participate in the blockchain network.

Public blockchains such as Bitcoin and Ethereum have a problem that it is difficult to secure scalability. Unlike the existing centralized server system, in a peer-to-peer system such as a blockchain, all nodes must agree on the ledger record.

The consensus process of all nodes is inefficient in terms of speed and cost, and is a major factor limiting the number of transactions that can be processed per second. As such, there is a trade-off between decentralization and scalability.

It can be seen that Bitcoin, one of the representative public blockchains, has a maximum of 7TPS and Ethereum maintains 20TPS. Considering that Visa is 20,000 TPS per second, there are many difficulties in processing real-life transactions.

As a way to increase scalability in the blockchain, the on-chain solution that increases the scalability by modifying the source code of the blockchain and the transaction through the transaction outside the blockchain rather than the value movement inside the blockchain Off-chain solutions exist.

Typical on-chain solutions include ‘SegWit’ of Bitcoin and ‘Bitcoin Cash’ that increases the size of blocks. In addition, Ethereum is actively researching sharding, a method of dividing and processing networks in parallel.

As an off-chain solution, the payment channel is representative, but it does not record all transaction transmission history on the blockchain, such as Bitcoin's 'Lightning Network' and Ethereum's 'Raiden Network', but only the final result on the blockchain. By doing so, the scalability is increased.

Let's take a closer look at the description of the off-chain network and the existing trading methods among blockchain solutions.

As mentioned above, Bitcoin's Lightning Network is a representative payment channel that uses off-chain solutions. In the Lightning Network, scalability is increased by recording not only all transmissions in the Bitcoin blockchain, but only the final result in the blockchain.

Lightning network secures network trust by using multi-signature and hash timelock contract. Control the completion and change of the transaction on the blockchain by using multiple keys, and prevent a person from being able to on-chain the book in an advantageous state to him by using a time lock contract.

Similarly, Ethereum uses a Leiden network to conduct transactions using the Payment channel in the flow shown in FIG. 1.

As illustrated in FIG. 1, first, a channel between the two is opened through a smart contract, and after a certain token is deposited, a transaction is performed within the deposited range. The amount of tokens deposited by each user acts as an escrow. When the transaction between the two ends, the channel is closed and the settlement process for tokens to be received by each other takes place. The party must specify the tokens he or she should receive through a digital signature, Balance Proof.

The payment channel is opened by two users of the channel.

Republic of Korea Registered Patent Publication No. 10-1835335 (2018.02.28)

The present invention solves the above-mentioned problems, and can respond to transaction delay and fault-tolerance by sending a request for routing permission in advance before generating a transaction, and performance is also a delay rate of linear time equal to the number of existing nodes. The goal is to provide a multi-hop transaction routing method in the Payment channel using a smart contract that can reduce the transaction delay rate in constant time.

The payment channel provides a higher scalability by providing a Locked Transfer function as well as direct transfer between two users whose channels are open.

 2 shows the locked transfer function from A to D. A and B, B and C, and C and D have their respective channels open. A does not open a direct channel with D, but wants to trade through B → C → D. In this case, A creates a transaction that can only be resolved through the secret key and sends it to B. In B, the secret key used by A is sent back to C, and the same operation is performed in C. The D that receives the Locked Transaction receives the secret key through A Secret Request to the first sender A. After the locked transaction is released using the transmitted key, the key is transmitted in the reverse order. The locked transaction is timelocked, so if the secret key is not transmitted or the transaction is not transmitted due to a malicious node, the transaction is expired, so the user must claim his Balance Proof through the secret key before the expiration time.

The routing program currently used in the Leiden network is shown in FIG. 3. A aims to send 3 tokens to D. First, A confirms that there is a route with D through a smart contract. We know that there are currently A → B → C → D and A → E → F → G → D on the road to D.

  A first sends a Locked Transaction through B. From the B's point of view, there are C's and E's, but B preferentially sends a transaction to C. The amount that C deposits on the smart contract can be sufficiently transferred, but due to various transactions on the off-chain, the amount of tokens actually available in C is only 2 tokens. 3 Tokens have to be sent, but the refund is made in C because the amount is insufficient.

Then, in B again, select the path to E, not the path to C, and send the transaction. The path to E is safely transmitted to D without any problems.

The transfer from A → B → E → F → G → D is completed using the current protocol.

Previous routing networks as described above have the following problems.

More specifically, since there is no way to check the available amount of nodes in the intermediate path, there is a problem in that overhead occurs on the path because the transaction is sent first and then, if not, refund transfer is performed.

In addition, there is a problem in that a delay occurs in a transaction when a failure due to a fault-tolerance (FT) cannot be relied on only for time lock.

Lastly, there is a problem in that the balance of neighboring nodes can be inferred through the returned network.

As a result, due to the above-described problems, there is a problem in that the delay in the routing process or the overhead in the conveying process and the remaining node balance can be inferred.

A multi-hop transaction routing method in a payment channel utilizing a smart contract according to the present invention for solving the above-mentioned problems includes: (a) a requester generating a routing list in protocol 1; (b) the requester requesting a routing route based on the routing list; (c) the requester requesting a checkRoutingNode (sender, receiver, path, value, time_lock, signature) message to nodes included in each Path_Node in protocol 2; (d) in the protocol 1, the nodes respond to the checkRoutingNode sent by the requester in protocol 3; (e) the requester determines an available path according to the responses of the nodes in protocol 4 to generate a Path_list; And (f) the requester sending a transaction to a destination node through any one of the Path_lists.

In addition, in step (a) of the multi-hop transaction routing method in the payment channel using the smart contract according to the present invention for solving the above-mentioned problems, the requester sets the path in the routing path in the smart contract of the payment channel. It is characterized by executing getPathList (source, destination) to find.

In addition, in step (a) of the multi-hop transaction routing method in the payment channel using the smart contract according to the present invention for solving the above-mentioned problems, the requester has the shortest hop in the shortest hop method to find the Path_Node. It is characterized by creating a list of nodes preferentially.

In addition, in the multi-hop transaction routing method in the payment channel using the smart contract according to the present invention for solving the above-mentioned problems, the requester increases the number of hops if the path_list generation in step (e) fails In this case, Path_list is generated by repeatedly performing (c) requesting a checkRoutingNode message to the nodes and (d) responding to the nodes.

In addition, among the multi-hop transaction routing method in the payment channel using the smart contract according to the present invention for solving the above-mentioned problems, in step (d), the nodes are directly connected to the receiver and the value of the value received from the leader. It is characterized by responding through comparison with the money available on the channel.

In addition, in the multi-hop transaction routing method in the payment channel using the smart contract according to the present invention for solving the above-mentioned problems, the nodes are characterized in that they transmit a response message only with True or False without information on the available amount. do.

In addition, in the multi-hop transaction routing method in the payment channel using the smart contract according to the present invention for solving the above-mentioned problems, the requester does not receive any response from one of the plurality of nodes in step (d) or , If the response is False, PUSH is impossible in the Path_list.

In addition, in the multi-hop transaction routing method in the payment channel using the smart contract according to the present invention to solve the above-mentioned problems, the requester, among the plurality of nodes in step (e), the nodes that do not respond After removal, it is characterized by generating a Path_list.

The multi-hop transaction routing method in the payment channel using the smart contract according to the present invention has an effect of solving the transaction delay problem due to the failure node and the lack of available amount.

In particular, the multi-hop transaction routing method in the payment channel using the smart contract according to the present invention has an effect of maintaining the transaction delay rate at a constant time by sending a routing path confirmation request in advance.

1 is a view showing the transaction progress using the Payment channel using the Leiden network in Ethereum.
2 is a diagram illustrating a Leiden network multi-hop process.
3 is a diagram illustrating a routing protocol currently used in a Leiden network.
4 is a diagram illustrating a multi-hop transaction routing method in a payment channel using a smart contract according to the present invention.
FIG. 5 is a diagram showing a routing list with three hops.

The present invention can be applied to various changes and can have various embodiments, and specific embodiments will be described in detail with reference to the drawings. 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 each drawing, similar reference numerals are used for similar components.

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

When a component is said to be "connected" to or "connected" to another component, it should be understood that other components may be directly connected or connected to the other component, but may exist in the middle. something to do. On the other hand, when a component is said to be "directly connected" or "directly connected" to another component, it should be understood that no other component exists 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. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this application, terms such as “include” or “have” are intended to indicate that a feature, number, step, operation, component, part, or combination thereof described in the specification exists, one or more other features. It should be understood that the existence or addition possibilities of fields or numbers, steps, operations, components, parts or combinations thereof are not excluded in advance.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by a person skilled in the art to which the present invention pertains. Terms, such as those defined in a commonly used dictionary, should be interpreted as having meanings consistent with meanings in the context of related technologies, and should not be interpreted as ideal or excessively formal meanings unless explicitly defined in the present application. Does not.

Throughout the specification and claims, when a part includes a certain component, this means that other components may be further included rather than excluding other components unless otherwise specified.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.

4 is a diagram illustrating a multi-hop transaction routing method in a payment channel using a smart contract according to the present invention.

As shown in FIG. 4, the multi-hop transaction routing system in the payment channel using the smart contract according to the present invention includes a requester 100 and a blockchain 200.

The requester 100 that desires a routing request grasps a routing path stored in the blockchain 200 through a smart contract.

Since there are several routes to the final destination node in the smart contract, a routing list is constructed. Even if there is a large amount of deposit among the configured list, it is impossible to know whether a node that has made a routing request has enough tokens, so a request is sent to all nodes in the route for available tokens.

As shown in [Table 1] below, Protocol 1 is a process in which the requester 100 generates a routing list and asks a corresponding node whether it is possible to route based on the generated list.

Before making a routing request, the requester 100 executes getPathList (source, destination) to find the path in the routing path in the payment channel smart contract. The arguments used here are as follows: 1) src_node, 2) des_node.

To find Path_Node, Path_Node is constructed with the shortest hop method first. In the process of finding the node connected to the requested source and destination, it is desirable to first generate the list of the nodes with the least hops.

 For example, in the case of FIG. 5, A-> B-> C-> D, the destination is passed through two nodes, and the hop at this time may be called 3.

Through this process, the value of hop_counter and path_counter are displayed.

In the case of the path_counter value, the path with 3 hops is A-> B-> C-> D, A-> E-> F-> D, A-> G-> H-> D, A- as shown in FIG. > I-> J-> D, so path_counter is 4. That is, it can be said to be the number of paths with 3 hops.

In the future, if one of the possible routes cannot be obtained through checkRoutingNode, the number of hops is increased, and then the path is searched again. Path_Node list is constructed through the corresponding hop_counter and path_counter. At this time, each node can be classified as Path_Node [path_counter] [hop_counter].

In FIG. 5, for Node B, Path_Node [0] [0], Node C may be represented by Path_Node [0] [1], and Node D may be represented by Path_Node [0] [2]. In more detail, it is Path_Node [2] [0] for G, and Path_Node [3] [1] for J.

After creating a list of Path_Node, as shown in protocol 2 of [Table 2], the requester 100 checkRoutingNode (sender, receiver, path, value, time_lock, signature) message to nodes belonging to each Path_Node Request.

Through this message, it is possible to know whether each node has tokens available through the corresponding path. The arguments used here are as follows.

The parameters of heckRoutingNode are as follows. 1) the requester (100) 2) path_Node [i] [j], 3) path_Node [i] [j + 1], 4) value, 5) limit_time. (i is greater than 0 and less than path_coutner. j is greater than 0 and must be less than hop_cotuner-1)

3) In case of path setting, when receiver is path_Node [i] [j], path is always set to path_Node [i] [j + 1], because it corresponds to the next node on the same path.

A in FIG. 5 should send a corresponding message to all nodes in four paths, B, C, D path, E, F, D, path, G, H, D path, and I, J, D path.

If the receiver is B, we need to ask for the available amount in the channel for path_Node [i] [j + 1], ie C, and if receiver is C, path_Node [i] [j + 1], ie the final path In the form of asking for the amount of money available in the channel for phosphorus D.

In addition, if there is no response within the time defined in 5), it is determined to be a node with communication failure and judged as False. The requester 100 waits for a response to each node until the corresponding time.

Nodes that have received the request from the requester 100 respond to the requester 100 with a result as to whether or not they have an amount greater than the requested amount without revealing the money available on the corresponding path. When responding, each node sends information about the desired fee.

Privacy is maintained between individual channels because the requester 100 is not informed of the available amount but only availability.

In Table 3 below, protocol 3 is a message that responds to checkRoutingNode sent by the requester 100 in protocol 1. Therefore, a message is transmitted from each Path_Node to the requester 100.

Each node responds by comparing the value of the value received from the leader with the money available on the channel directly connected to the receiver. As a response message, only True and False are displayed without information on the available amount.

The equester waits for an acknowledgment from all the nodes in the list in the routing list. If there is not enough token available for one node or no response is returned, it is removed from the routing path. The sender constructs Path_List among the paths that all nodes have responded to.

In Table 4 below, Protocol 4 determines the available paths in the requester 100.

After a certain time, a list of nodes called Ture in the response of Path_Node is collected and generated as Path_List.

Among Path_Node [i] [j], i can be regarded as nodes representing path_counter in the same path, and j represents hop in the path representing hop_counter.

For example, in the case of A → B → C → D in FIG. 5, B represents Path_Node [0] [0] and C represents Path_Node [0] [1]. In the case of Path_Nodes having the same path_coutner, all of True's response must be followed to ASH B → C → D PUSH in Path_List. If one of the nodes using the same path_counter does not respond, or if it responds False, PUSH cannot be performed in Path_List. In order to prevent Fault Tolerance in advance, it is judged and eliminated as a node with no response. The requester 100 constructs a list by generating all possible Path_Lists.

The requester 100 sends a transaction to the destination node using the most efficient path among the newly constructed Path_List.

In the case of the existing routing protocol, if the node in the routing path had a insufficient amount, a message must be sent to another path through a refund transaction.

Whenever such a shortage node is encountered, a refund transcation and a message must be sent through a different path, so the maximum time complexity is linear time. In contrast, in the case of the protocol according to the present invention, since the probability of occurrence of refund transcation is very low, it can be defined as a constant time.

In addition, like Fault Tolerance, when a fault node exists, a delay rate is inevitably caused by the time defined by the hash time lock control. The delay rate increases as the number of fault nodes increases. In this situation, the time complexity also has a delay rate of linear time. On the other hand, in the case of the protocol according to the present invention, since only the time required to send the first routable request needs to be waited, it can be solved with a constant time even in the case of a failure node.

When the requester 100 asks for the amount of money available through a message in advance, the node in the off-line state cannot be answered, and thus is excluded from the routing path.

Therefore, it is possible to respond to Fault-Tolerance naturally.

Since each node does not reveal its available amount from the routing protocol message requested from the requester, and only responds to the availability of routing, privacy is maintained because information about the amount available for each channel is unknown.

The requester 100 receives a response from the nodes as to whether a transaction is possible and creates a list. By sending a transaction on one of the lists, you can confirm that the transaction will be successful. In addition, it is possible to trade quickly without delay.

The above description is merely illustrative of the technical spirit of the present invention, and those skilled in the art to which the present invention pertains may make various modifications and variations without departing from the essential characteristics of the present invention. Therefore, the embodiments disclosed in the present invention are not intended to limit the technical spirit of the present invention, but to explain, and the scope of the technical spirit of the present invention is not limited by these embodiments. The scope of protection of the present invention should be interpreted by the claims below, and all technical spirits within the scope equivalent thereto should be interpreted as being included in the scope of the present invention.

100: requester
200: blockchain

Claims (8)

(a) the requester generating a routing list in protocol 1;
(b) the requester requesting a routing route based on the routing list;
(c) the requester requesting a checkRoutingNode (sender, receiver, path, value, time_lock, signature) message to nodes included in each Path_Node in protocol 2;
(d) in protocol 2, the nodes respond to a request for a checkRoutingNode message sent by the requester in protocol 3 in protocol 3;
(e) the requester determines an available path according to the responses of the nodes in protocol 4 to generate a Path_list; And
(f) the requester sending a transaction to a destination node through any one of the Path_list;
In step (d),
The nodes respond by comparing the value of the value received from the reader with the money available to them on the channel directly connected to the receiver. A multi-hop transaction routing method in a payment channel using a smart contract.
According to claim 1,
In step (a),
The requester
A multi-hop transaction routing method in a payment channel using a smart contract, characterized in that getPathList (source, destination) is executed to find the path in the routing path in the smart contract of the payment channel.
According to claim 2,
In step (a),
The requester
A multi-hop transaction routing method in a payment channel using a smart contract, characterized in that a list of nodes with the least hops is first generated in a shortest hop manner to find the Path_Node.
According to claim 3,
The requester
If the path_list creation in step (e) fails, the number of hops is increased, and then the step (c) of requesting the checkRoutingNode message to the nodes and the step of responding (d) of the nodes are repeatedly performed to generate the path_list. Multi-hop transaction routing method in the Payment channel using a smart contract, characterized in that.
delete According to claim 1,
The nodes are
A multi-hop transaction routing method in a payment channel using a smart contract characterized in that a response message is delivered only with True or False without information on the available amount.
The method of claim 6,
The requester
The multi-hop transaction routing method in a payment channel using a smart contract, characterized in that PUSH is not possible in the Path_list when any of the plurality of nodes in step (d) does not respond or the response is False.
The method of claim 7,
The requester
A multi-hop transaction routing method in a payment channel using a smart contract, characterized in that a path_list is generated after removing nodes that do not receive a response among the plurality of nodes in step (e).

Images