Payment channel network routing protocol based on short path

Abstract

The invention discloses an efficient and privacy-protection-supporting payment channel network routing protocol based on short paths, which is characterized in that on the basis of analysis of a payment channel network topology structure, short paths not exceeding a set length are searched as a candidate set, and the paths are randomly selected to carry out fund verification and transaction; and the capital availability of all potential paths is prevented from being verified one by one, so that the success rate is improved while the overhead is reduced. In order to protect the privacy of the user, the invention also designs a security comparison protocol, which effectively prevents sensitive information such as transaction amount and channel balance from being leaked in the process of verifying path fund sufficiency. The effectiveness and the high efficiency of the method are verified through comprehensive experimental analysis.

Description

Technical Field

[0001] This invention relates to a high-efficiency and privacy-preserving short-path-based payment channel network routing protocol, belonging to the field of network security technology. Background Technology

[0002] With the rapid development of blockchain technology and cryptocurrency systems, the continuous growth in transaction volume has led to serious scalability issues for public blockchains. Traditional on-chain transaction models require each transaction to be broadcast across the entire network and recorded on the blockchain, resulting in limited system throughput, high confirmation latency, and increased transaction fees, failing to meet the demands of high-frequency, small-amount payment scenarios. To address this problem, payment channel networks have emerged, becoming an important direction for expanding the transaction capabilities of blockchain.

[0003] Payment channel networks transfer a large number of transactions off-chain for settlement by establishing payment channels, with on-chain operations only occurring when channels are established and closed. This effectively reduces the blockchain load and improves overall transaction efficiency. In a payment channel network, payment channels are created by two users jointly locking funds, and transactions between users are realized by updating the balance within the channel, without needing to record every transaction on the blockchain. However, since not all users have directly established payment channels, when two users lack a direct connection, the transaction needs to rely on an efficient path composed of multiple payment channels.

[0004] To ensure the economic viability and efficient operation of a payment channel network, the network must maintain a high transaction success rate (i.e., the proportion of successful transactions out of all transactions) and a high transaction volume (i.e., the total amount of successful transactions). A prerequisite for successful transactions is that all channels along the path have sufficient balances. However, the current balance of a channel changes dynamically with each transaction and is not publicly accessible. If the sender can determine the adequacy of funds along the path in advance, the transaction success rate and efficiency will be significantly improved. Therefore, the transaction path selection strategy, i.e., the routing protocol, is a key factor affecting the performance of the aforementioned payment channel network.

[0005] Currently, most payment gateway network routing protocols employ a "guess-and-verify" strategy. The sender selects several candidate paths based on the network topology and initial channel balance (information publicly available when the channel is established), and randomly chooses one to attempt the transaction. If the transaction fails due to insufficient channel balance, the sender reselects a path and repeats the attempt. This strategy has significant drawbacks: the channel balance changes in real time, leading to a high probability of path failure and resulting in a low transaction success rate. Furthermore, the HTLC mechanism temporarily freezes funds upon transaction failure, releasing them only after a timeout, further reducing transaction efficiency. For example, the LND protocol currently deployed in the Lightning Network uses this strategy, resulting in a low transaction success rate and significant time overhead from repeated attempts.

[0006] A few routing protocols employ an "acknowledgment-send" strategy to address the aforementioned issues. This strategy verifies the adequacy of funds along a path before a transaction, ensuring the selected path can complete the transaction and potentially improving the success rate. However, verifying the availability of funds for each potential path individually incurs significant computational and communication overhead. This is especially problematic in large networks where the number and length of paths requiring verification are substantial, leading to lengthy verification processes and severely impacting transaction efficiency. Furthermore, existing routing protocols using the "acknowledgment-send" strategy generally lack privacy protection mechanisms. Determining path adequacy is typically achieved by directly comparing the transaction amount and channel balance in plaintext. This not only exposes the user's transaction request but may also reveal the actual financial status of the channel, posing a significant risk to user privacy. Summary of the Invention

[0007] Purpose of the invention: To address the shortcomings of current routing protocols deployed in payment channel networks, such as low transaction success rates and lack of user privacy protection, this invention provides a high-efficiency, privacy-protecting short-path-based payment channel network routing protocol that determines the adequacy of funds along the path while protecting privacy, thereby improving transaction success rates.

[0008] Technical solution: A high-efficiency and privacy-preserving short-path-based payment channel network routing protocol, the specific implementation steps of which are as follows: Step 1: Based on the topology of the payment channel network, search for the shortest path; Step 2: Randomly select a candidate path and verify whether the path has sufficient funds; Step 3: If the path has sufficient funds, execute the transaction; otherwise, return to Step 2, select a new path, and verify.

[0009] Furthermore, the specific steps of Step 1 are as follows: Step 1.1: Determine the maximum length parameter k of the search path: For an existing payment channel network, collect the lengths of the most recently successful transactions to determine k. If the payment channel network is brand new, first simulate transactions within the network, and then use the information data from these simulated transactions to determine k.

[0010] Step 1.2: If the recipient of the transaction is in the sender's routing table, proceed directly to Step 2. If the recipient is not in the sender's routing table, then search for a path.

[0011] Step 1.3: The transaction sender generates and sends a Tosignal: The transaction sender generates a Tosignal for each of its neighbors. After initialization, the sender sends the Tosignal to the corresponding neighbor.

[0012] Step 1.4: Forwarding Tosignal by Intermediate Nodes in the Path: After receiving the Tosignal signal, if the current node is the receiver, it will terminate the Tosignal forwarding, generate a Backsignal signal, and initiate a signal return process. If the current path length is equal to or greater than k, the node will immediately stop signal transmission, generate a Nosignal signal, and enter the signal return process. If the current node is neither the transaction receiver nor the current path length is less than k, then the node will act as an intermediate node. To extend the path, the node will update the Tosignal and forward it to neighboring nodes (except for nodes that have already been visited).

[0013] Step 1.5, Signal Backsend: Once a Backsignal or Nosignal is generated, the node initiates the signal backsend process. During the backsend, each node matches the received Backsignal with the stored Tosignal to determine the correct forwarding channel and discards the received Nosignal. If a node does not receive any Backsignal for the transaction, it sends back a Nosignal. Finally, the sender reconstructs the path to the transaction recipient by receiving the Backsignal and combining it with its own information, and records the path in the routing table.

[0014] Furthermore, the specific steps of Step 2 are as follows: Step 2.1: Select a candidate path: The sender randomly selects a path from the paths that can reach the receiver from the routing table.

[0015] Step 2.2: Collaborating with Intermediate Nodes to Determine Path Funding Availability: The transaction sender and each intermediate node employ a secure comparison protocol to compare the transaction amount and channel balance. Specifically, the sender obtains a random share of the comparison result from each node. Because the protocol hides the selection process, the transaction amount is invisible to the intermediate nodes, protecting transaction amount privacy. Ultimately, the transaction sender obtains the masked comparison result, while the intermediate nodes obtain the mask. Multiple intermediate nodes on the path XOR their respective masks together and send them to the sender. The sender then XORs the XOR result with the masked comparison result from each intermediate node on the path to determine if the path funds are sufficient. Throughout this process, the sender cannot know which channel on the path has insufficient funds, effectively protecting balance privacy.

[0016] The specific steps of Step 3 are as follows: Step 3.1, Candidate path has sufficient funds: The sender uses the candidate path to conduct the transaction.

[0017] Step 3.2, Insufficient Funding for Candidate Paths: Go back to Step 2 to reselect candidate paths and determine if funding is sufficient.

[0018] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the short-path-based payment channel network routing protocol as described above.

[0019] A computer-readable storage medium storing a computer program that executes the short-path-based payment channel network routing protocol as described above.

[0020] In the above technical solution, the present invention provides a highly efficient and privacy-preserving short-path-based payment channel network routing protocol, which has the following beneficial effects: 1. This invention selects shorter paths when performing routing transactions and does not require verification of sufficient funds for all possible paths, thereby improving transaction success rate and network throughput while maintaining low overhead.

[0021] 2. This invention supports secure path fund verification, effectively protecting transaction amount privacy and channel availability privacy, and enhancing the privacy and security of payment channel networks. Attached Figure Description

[0022] Figure 1 This is a flowchart of the efficient and privacy-preserving short-path-based payment channel network routing protocol described in this invention. Figure 2 This is a comparison chart of the transaction success rates of various protocols in the Lightning network under different transaction volumes in a specific embodiment of the present invention.

[0023] Figure 3 This is a comparison chart of the transaction success rates of various protocols in the Ripple network under different transaction volumes in a specific embodiment of the present invention.

[0024] Figure 4 This is a comparison chart showing the number of messages for each protocol in a Lightning network under different channel capacities in a specific embodiment of the present invention.

[0025] Figure 5 This is a comparison chart of the number of messages for each protocol in the Ripple network under different channel capacities in a specific embodiment of the present invention.

[0026] Figure 6 This refers to the transaction success rate of each protocol in the specific embodiments of the present invention when the number of user nodes in the payment channel network varies from 10,000 to 20,000. Detailed Implementation

[0027] The present invention will be further illustrated below with reference to specific embodiments. It should be understood that these embodiments are for illustrative purposes only and are not intended to limit the scope of the invention. After reading the present invention, any modifications of the present invention in various equivalent forms by those skilled in the art will fall within the scope defined by the appended claims.

[0028] Example 1: As Figure 1 As shown, the specific steps of an efficient and privacy-preserving short-path-based payment channel network routing protocol are as follows: Step 1: Determine the maximum path length based on the topology of the payment channel network; if the transaction sender does not find a path for the transaction sender in its own routing table, search for the path and record it in the routing table.

[0029] Step 2: Randomly select a candidate path from all paths in the routing table that can reach the transaction sender, and verify whether the path has sufficient funds.

[0030] Step 3: If the path has sufficient funds, execute the transaction; otherwise, return to Step 2, select a new path, and verify.

[0031] The specific steps for Step 1 are as follows: Detection-based pathfinding involves two phases: signal transmission and signal feedback.

[0032] Signal transmission mechanism: The sender generates a signal named Tosignal and transmits it to neighboring nodes. These nodes then update their own states and forward the signal to find a path of length no more than k to reach the receiver.

[0033] Signal return phase: This phase includes two types of signals—Backsignal and Nosignal. The Backsignal is generated by the receiver based on the received Tosignal and returned to the sender along the original path. The Nosignal is used to report pathfinding failure to the sender.

[0034] Although Tosignal, Backsignal, and Nosignal are different names used to distinguish signals during transmission and return, their basic form is the same, which can be described as follows: ρ=(id,h,s,t,F[],flag). Here, the variable id identifies different paths, and h represents the number of intermediate nodes traversed by the sender s to reach the receiver t. The array F[] stores the cost functions of intermediate user nodes on the path. Each element F[i] corresponds to the cost function of the i-th intermediate node along the path probed by Tosignal, containing three parameters: node name, the base cost b of its corresponding cost function, and the rate r. The value of flag can be 0, 1, or -1, representing different signals. During signal transmission, the Tosignal flag is 0. When the signal returns, the Backsignal flag is 1, indicating that a valid path has been found, while the Nosignal flag is -1, indicating that there is no valid path in the probe direction.

[0035] Step 1.1: Determine the maximum path length parameter k: Based on existing research analyzing payment channel network topology, we observe that most transactions in payment channel networks are successfully completed via very short paths. Therefore, for deployed payment channel networks, we can collect information on the lengths of the most recently successful transactions and use the path length of the vast majority of successful transactions as the maximum path length. l max If the payment gateway network is brand new, it is first necessary to simulate transactions within the network, and then the information data after these simulated transactions are executed can be used to determine... l max Each user node maintains a routing table that records the paths between itself as a sender and different receivers, with each path length not exceeding k, where k is initially set to a value. l max .

[0036] Step 1.2: If the recipient of the transaction is in the sender's routing table, proceed directly to Step 2. If the recipient is not in the sender's routing table, then search for a path.

[0037] Step 1.3: The transaction sender generates and sends the search signal Tosignal: The transaction sender sends a signal to each of its neighbors σ. i Generate a Tosignal i And perform initialization. The specific initialization process is as follows: the sender randomly generates a number base, and for each neighbor's Tosignal... i The current encoding of the search signal is Tosignal. i .id=base+i, the current number of intermediate nodes for the search signal is Tosignal i.h=0; Tosignal i .s=Transaction sender name; Tosignal i .t = Transaction recipient name. For j from 0 to k: Each search signal records an array of intermediate node cost functions, Tosignal. i Each value in .F[j] is initialized, which is the node name Tosignal. i .F[j].ξ=NULL; its corresponding cost function has a base cost Tosignal i .F[j].b=0; Node name, its corresponding cost function rate Tosignal i .F[j].r=0; The identifier for distinguishing signals, Tosiganl i .flag=0. After initialization, the sender will send Tosignal. i Send to the corresponding neighbor σ i .

[0038] Step 1.4: Forwarding Tosignal by Intermediate Nodes in the Path: The node receiving the Tosignal signal stores a tuple (Tosignal, ω), where ω represents the name of the node that sent the Tosignal to the current node. This tuple is used during signal return. Since these tuples become obsolete once the pathfinding is complete, storing a large number of (Tosignal, ω) tuples is neither practical nor necessary. In the RCS protocol, each tuple is deleted after a specified timeout. Subsequently, the node updates the Tosignal signal and forwards the signal. If the current node is the receiver, meaning the Tosignal has reached the transaction receiver, the current node terminates Tosignal forwarding, generates a Backsignal signal, and initiates the signal return process. Otherwise, it searches for the current number of intermediate nodes in the signal (Tosignal.h = Tosignal.h + 1) and counts the set of nodes visited by the Tosignal (visitnodes). If the current path length is equal to or greater than k, continuing to extend the path will exceed the maximum allowed length. At this time, the node immediately stops signal transmission and generates a Nosignal signal, indicating that the sender cannot reach the receiver through the current path. Subsequently, Nosignal enters the signal feedback process. If the current node is neither the transaction receiver nor the current path length is less than k, then this node will act as an intermediate node. To extend the path, the current node updates Tosignal. Tosignal.F[Tosignal.h].ξ = current node name, Tosignal.F[Tosignal.h].b = base cost in the current node's cost function, and Tosignal.F[Tosignal.h].r = rate in the current node's cost function. For each neighbor node σ of the current node... j (Except for nodes that have already been visited by Tosignal), the current node generates Tosignal. j Tosignal j =Updated Tosignal; Tosignal j =Tosignal.id + ' / ' + random(size), where size is the number of the current node's neighbors minus the size of the visitnodes set. Then, the current node will use Tosignal... j Send to neighbor σ j If the current node cannot continue forwarding Tosignal (i.e., there are no neighboring nodes to forward to), then a Nosignal is generated for backhaul.

[0039] Since the Tosignal signal is constantly updated and sent, it may eventually reach the transaction receiver, forming a topology path from the sender to the receiver. Once a Backsignal or Nosignal is generated, the signal return process begins.

[0040] Step 1.5, User Node Signal Return: During the signal return process, the node receiving the returned Backsignal and Nosignal signals will also update and forward the signals. When a Backsignal is received, the node first confirms whether it is the transaction sender by comparing its own name with the sender name contained in the signal. If they match, it means that the Backsignal has been successfully delivered to the sender; if they do not match, the Backsignal is updated and the return process continues. In each path of the same sender-receiver, the identifier of each channel is unique. The tuple (Tosignal, ω) stored in the signal transmission and identifier helps identify the correct node for subsequent returns. The current node removes the last ' / ' and its following characters from the encoded Backsignal.id of the returned signal. For each (Tosignal, ω) stored by the current node, if Backsignal.id = Tosignal.id and the signal sender Backsignal.s recorded by Backsignal = the signal sender Tosignal.s recorded by Tosignal, and the signal receiver Backsignal.t recorded by Backsignal = the signal receiver Tosignal.t recorded by Tosignal, then... Then ω is the correct node for the current node to return the Backsignal. Normally, any Nosignal can be discarded upon receipt, unless the node has not received the Backsignal, in which case it must return the Nosignal. Determining the correct node for returning a Nosignal is similar to determining the correct node for a Backsignal.

[0041] Finally, the sender collects all returned backsignals and reconstructs paths using the intermediate nodes recorded in each backsignal. These paths are then added to the sender's routing table. If the sender receives only nosignals and no backsignals, it means the shortest path between the sender and receiver exceeds the value of k. In this case, k can be gradually increased by 1, and the probe-based path search can be re-executed until a path is found. Once a path is found, the sender resets k to k. l max To continue searching for subsequent transaction paths.

[0042] The specific steps for Step 2 are as follows: Step 2.1: Select a candidate path: The sender randomly selects a path from the paths that can reach the receiver from the routing table.

[0043] Step 2.2: Calculate the maximum transaction amount that can be passed through the two channels on both sides of the path at the intermediate nodes: After knowing the fee function of each node on the path, each node can calculate the maximum transaction amount that can be passed through the two channels on the path. Then, calculate the minimum value between the two values ​​to determine whether the path has sufficient funds.

[0044] Step 2.3: The transaction sender and intermediate nodes collaborate to determine if the path funds are sufficient: The transaction sender holds the transaction amount, and each intermediate node holds the minimum value of the maximum transaction amount that can be passed through the two channels on the path. The sender and each intermediate node compare the amounts using a secure comparison protocol. Assume the sender participating in the secure path fund verification is 's', and the set of intermediate nodes is {π1, π2, ..., π}. n The sender s holds transaction amount p. s Each intermediate node π i Holding channel balance The goal is to enable s to securely verify p without revealing additional information. s Does it not exceed any Therefore, s and each π i First, the secure comparison protocol is run, and the Boolean value 1 is securely calculated. <p s If the comparison result of all nodes is 0 (i.e. ≥p s If the path has sufficient funds, then the funding is confirmed; otherwise, if there is any intermediate node with 1{ <p s If} = 1, then the path is considered to have insufficient funds. Specifically, s and π i Will and p s Convert to Let x = 1 / 2 unsigned integer. y=p s Set parameter m, calculate parameter M=2 m Convert x and y to bit representations and divide them into q parts, i.e., x = x q-1 ||x q-2 ||...||x0 and y=y q-1 ||y q-2 ||...||y0. For j from 0 to q-1: π i Randomly generate a string of 0s and 1s of length L. and ; For h from 0 to M - 1: Execute ss under each index pair (j, h) j,h = EXTEND(1{x j <h}, L) and tt j,h = EXTEND(1{x j =h}, L) (where the EXTEND(z, R) function: If z is 0, return 0 R ; If z is not 0, return a randomly generated {0, 1} R ); π i and s call a 1-out-of-M oblivious transfer - OT where π i inputs {ss j,h} h and s inputs y j , and finally s gets ; π i and s call a 1-out-of-M oblivious transfer - OT, where π i inputs {tt j,h} h and s inputs y j , and finally s gets . This calculation result implies the comparison values and equal values (non - plaintext) of each pair of the smallest divided units xj and yj, and can recursively calculate AND and XOR gates until the root node. Finally, s will obtain the masked comparison result , while π i obtains the random mask . Both are of length L bits. To ensure the secure combination of all comparison results, starting from π n , each π i will calculate the XOR value of its random mask and the received "combined mask", and send the new combined mask to π i-1 . Finally, π1 will obtain a combined mask equal to the XOR value of all the random masks of π i , and send it to s. s then calculates the XOR value of all its masked comparison results and the combined mask. If the result is all - zero of L bits, the path has sufficient funds; otherwise, the funds are insufficient.

[0045] The specific steps of Step3 are as follows: Step 3.1, Sufficient Funds for the Candidate Path: The sender uses the candidate path for the transaction. In a payment channel network, multiple transactions may be in progress simultaneously. When multiple senders execute transactions on paths sharing the same channel, path conflicts occur. This invention processes concurrent requests based on transaction start times, with transactions starting earlier having higher priority. When multiple transactions compete for the same channel, higher-priority transactions can use the channel's available balance first. If a transaction fails due to insufficient channel balance, the system immediately returns a failure result instead of waiting for the balance to increase, thus avoiding deadlock.

[0046] Step 3.2, Insufficient Funding for Candidate Paths: Go back to Step 2 to reselect candidate paths and determine if funding is sufficient.

[0047] Example 2: We provide an instantiation scheme for this invention using the Python language and conduct experiments using data from two real payment channel networks—the Lightning network and the Ripple network. The Lightning network consists of 9867 user nodes and 38390 channels, while the Ripple network consists of 1870 user nodes and 17416 channels. Based on data collected from the Lightning and Ripple networks, we determined the corresponding parameters for each network. l max =4, that is, the initial value of k is k= l max =4.

[0048] We will also evaluate and compare the performance of this invention with the following advanced routing protocols to clearly illustrate the advantages of this invention: ①Shortest Path: The sender selects the shortest path from itself to the receiver and uses that path to execute the transaction. This is the core idea of ​​the routing protocol LND currently deployed in Lightning networks.

[0049] ②SpeedyMurmurs: It uses a landmark routing method, where landmark nodes identify paths, and then transactions are randomly split into smaller transactions between these paths to complete the entire transaction.

[0050] ③Spider: Each sender maintains k non-intersecting widest paths for each receiver. Transactions are divided into units for transmission. If a transaction unit cannot be sent, it is placed in the sender's destination queue and processed in a last-in-first-out (LIFO) order.

[0051] ④Flash: It categorizes transactions into "rat payments" and "elephant payments" based on the transaction amount. For rat payments, each node uses a path from its routing table. For elephant payments, Flash employs a maximum flow algorithm to find multiple paths, then splits the transaction and selects the combination of paths with the lowest cost.

[0052] ⑤Deter-Pay: It only probes K paths among all feasible paths, and completes the transaction if the total passable amount between them exceeds the required payment.

[0053] Success rate refers to the percentage of transactions that are successfully completed out of all transactions. For example... Figure 2 and Figure 3 As shown, this invention outperforms all other protocols in both the Lightning and Ripple networks. In the Lightning network, the transaction success rate of this invention is approximately 16% higher than SpeedyMurmurs, 12% higher than Deter-Pay, and approximately 10%, 6%, and 4% higher than Shortest Path, Spider, and Flash, respectively. In the Ripple network, the success rate of this invention is approximately 10% higher than Shortest Path and Deter-Pay, 8% higher than SpeedyMurmurs and Spider, and 3% higher than Flash. The superior performance of this invention stems from its pre-transaction verification mechanism to ensure sufficient funds for the path.

[0054] The total capacity of a payment channel network is currently limited, but it will increase as the network develops. This invention simulates this growth by expanding the current channel capacity from 1x to 20x. The number of transactions is fixed at 5000. Figure 4 and Figure 5 This paper demonstrates the success rate trends of different protocols in Lightning and Ripple networks as channel capacity changes. The success rate of each protocol increases with the increase in payment channel balance. In both Lightning and Ripple networks, this invention consistently maintains the highest success rate. Particularly in Lightning networks, its success rate is approximately 20% higher than SpeedyMurmurs.

[0055] As more users join the payment channel network, the number of nodes in the network will naturally increase. Based on the simulated network topology, we will apply the present invention in our experiments. l max = 6. The transaction quantity is fixed at 5000. For example... Figure 6 As shown, all protocols, including this invention, maintain a relatively stable transaction success rate, indicating their good adaptability to the increase in the number of network user nodes. However, this invention consistently maintains the highest transaction success rate as the number of user nodes increases.

[0056] Related knowledge: Payment Channel Network: Channel opening operations are performed on-chain. To open a payment channel, both parties need to lock funds in a 2-of-2 multisignature address and hold them jointly for a fixed period. A payment channel network consists of multiple such channels. A payment channel network can be represented as a directed weighted graph G=(V,E)

[20] , where V represents the set of network users and E represents the set of payment channels. Each edge is bidirectional and each direction has a weight representing the balance of the user in the channel in that direction. These weights are dynamically updated as transactions occur to reflect changes in the channel balance. The channel capacity Cap of each edge is the sum of the bidirectional balances of that channel. The channel capacity is fixed when the channel is established and recorded on the blockchain so that all network users can query it. Existing payment channels can also be closed, but this operation also needs to be performed on-chain. Once both parties have resolved all outstanding disputes and determined a fund allocation plan, they can withdraw their respective funds from the channel.

[0057] Payment Path: When a transaction occurs between two users, a path with sufficient funds must be found to complete the transaction. Since establishing direct channels between every pair of users is not practically feasible, users typically choose a suitable path that forwards payments through intermediary nodes. As the transaction progresses, the balances of each channel along the transaction path will change.

[0058] Payment Fees: In a payment channel network, intermediate nodes along the path to a successfully completed transaction incur fees. The node's fee function includes two fee types: base fee (F...). base The base fee (F) and the rate (r) are the fees charged by the intermediary node to facilitate the transaction. The rate specifies the fee charged per unit of transfer amount. The node's fee function can be expressed as: F = F base + r × ɑ; where ɑ represents the transaction amount flowing through intermediate nodes. Each payment channel has two different fee functions pre-set independently by both users. Fees are incurred when funds flow into the channel from intermediate nodes, and only one fee function is applied based on the transaction direction. It is important to note that the parameter ɑ in the fee function refers to the amount actually received by the receiver, not the amount initially sent by the sender (the sent amount already includes the fees from all intermediate nodes). The routing protocol of this invention uses the same design paradigm for fee calculation.

[0059] It is obvious to those skilled in the art that the steps of the short-path-based payment channel network routing protocol of the above-described embodiments of the present invention can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using device-executable program code, which can then be stored in a storage device for execution by the computing device. Furthermore, in some cases, the steps shown or described can be performed in a different order than those presented herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the embodiments of the present invention are not limited to any particular hardware and software combination.

Claims

1. A high-efficiency and privacy-preserving short-path-based payment channel network routing protocol, characterized in that, The specific implementation steps of the protocol are as follows: Step 1: Based on the topology of the payment channel network, search for the shortest path; Step 2: Randomly select a candidate path and verify whether the path has sufficient funds; Step 3: If the path has sufficient funds, execute the transaction; otherwise, return to Step 2, select a new path, and verify.

2. The efficient and privacy-preserving short-path-based payment channel network routing protocol according to claim 1, characterized in that, The specific steps of Step 1 are as follows: Step 1.1: Determine the maximum length parameter k of the search path: For an existing payment channel network, collect the length of the most recently successful transactions to determine k; if the payment channel network is brand new, first simulate transactions in the network, and then use the information data after these simulated transactions are executed to determine k. Step 1.2: If the recipient of the transaction is in the routing table of the transaction sender, you can directly jump to Step 2; if the recipient is not in the routing table of the transaction sender, then search for the path. Step 1.3: The transaction sender generates and sends a Tosignal signal: The transaction sender generates a Tosignal for each of its neighbors. After initialization, the sender sends the Tosignal to the corresponding neighbor. Step 1.4: Forwarding Tosignal by intermediate nodes in the path: After receiving the Tosignal signal, if the current node is the receiver, it will terminate the Tosignal forwarding, generate the Backsignal signal, and initiate the signal return process; if the current path length is equal to or greater than k, the node will immediately stop signal transmission, generate the Nosignal signal, and enter the signal return process; if the current node is neither the transaction receiver nor the current path length is less than k, the node will act as an intermediate node; to extend the path, the node will update the Tosignal and forward it to its neighboring nodes. Step 1.5, Signal Backsend: Once a Backsignal or Nosignal is generated, the node initiates the signal backsend process. During the backsend, each node matches the received Backsignal with the stored Tosignal to determine the correct forwarding channel and discards the received Nosignal. If a node does not receive any Backsignal for the transaction, it sends back a Nosignal. Finally, the sender reconstructs the path to the transaction recipient by receiving the Backsignal and combining it with its own information, and records the path in the routing table.

3. The efficient and privacy-preserving short-path-based payment channel network routing protocol according to claim 1, characterized in that, The specific steps of Step 2 are as follows: Step 2.1: Select a candidate path: The sender randomly selects a path from the paths that can reach the receiver in the routing table; Step 2.2: Collaborating with intermediate nodes to determine if the path funds are sufficient: The transaction sender and each intermediate node use a secure comparison protocol to compare the transaction amount and the channel balance. Specifically, the sender obtains a random share of the comparison result from each node. Because the protocol is designed to hide the selection process, the transaction amount is invisible to the intermediate nodes. Finally, the transaction sender obtains the masked comparison result, while the intermediate nodes obtain the mask. Multiple intermediate nodes on the path XOR their respective masks together and send them to the sender. The sender uses the XOR result and the comparison result with the masked mask of each intermediate node on the path to XOR the result again to determine if the path funds are sufficient.

4. The efficient and privacy-preserving short-path-based payment channel network routing protocol according to claim 1, characterized in that, The specific steps of Step 3 are as follows: Step 3.1, Candidate path has sufficient funds: The sender uses the candidate path for the transaction; Step 3.2, Insufficient Funding for Candidate Paths: Go back to Step 2 to reselect candidate paths and determine if funding is sufficient.

5. A computer device, characterized in that: The computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the short-path-based payment channel network routing protocol as described in any one of claims 1-4.

6. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program that executes the short-path-based payment channel network routing protocol as described in any one of claims 1-4.

Images