Bidirectional coupling transaction scheduling method and system for payment channel
By adopting the two-way coupled transaction scheduling method and balance update prediction algorithm in the payment channel network, the problems of low transaction success rate and transaction queue blocking in the payment channel network are solved, and higher transaction throughput and success rate are achieved, while maintaining the atomicity of transactions.
Patent Information
- Application Number
- CN202510351755.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-24
- Publication Date
- 2025-06-24
- Estimated Expiration
- 2045-03-24
AI Technical Summary
During the transaction routing process, it is difficult for the existing payment channel network to ensure that there is sufficient available balance in the payment channel, resulting in a low transaction success rate and the transaction queue is prone to blocking, and the funds in the payment channel cannot be fully utilized.
The two-way coupled transaction scheduling method is adopted to receive transaction keys and balance update messages, use the balance update prediction algorithm to predict the upcoming balance update situation of the counterparty, update the transaction queue and transaction set, and calculate the transaction execution and non-execution benefits based on the current available balance and predicted balance update value, thereby flexibly selecting the best transaction execution method.
It realizes that without introducing additional communication overhead, accurately predicts the execution of the peer transaction, assists the transaction scheduling system to make more flexible decisions, makes full use of funds in the payment channel, improves transaction throughput and success rate, and retains the atomicity of the transaction.
Smart Images

Figure CN120198112A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to online payment technology, and in particular to a two-way coupling transaction scheduling method and system for payment channels. Background Art
[0002] The payment channel network is a mainstream Layer-2 solution for solving the scalability problem of blockchain-based digital cryptocurrencies. In the payment channel network, most transactions use the funds hosted by users in each payment channel to complete off-chain payments, without going through a cumbersome consensus process on the blockchain, greatly improving the transaction throughput and transaction processing speed of the digital cryptocurrency system.
[0003] Each payment channel is created by the cooperation of two users. When two users conduct a transaction (i.e., one user pays a certain amount to another user), usually one or more paths are first found between the two users and the transaction amounts to be executed on each path are determined, and then the transaction payment is completed in the way of routing and forwarding. Only when the available balance of the payment channels along the way meets the transaction amount can the transaction be successfully forwarded. Once the transaction amount is determined, each payment channel on the path processes the transaction to be forwarded in an atomic form, that is: the transaction cannot be further split during the transaction routing process, and the payer in the payment channel either pays the complete transaction amount to the payee at one time or determines that the transaction fails and cancels the transaction.
[0004] How to make full use of the funds hosted in the payment channels to execute as many off-chain transactions as possible is a major difficulty currently faced by the payment channel network. On the one hand, since there is no trusted central management node in the payment channel network and each payment channel independently executes off-chain transactions and updates the balance distribution, the nodes in the network cannot know the available balance distribution in other payment channels in real time, and it is difficult to ensure that there is enough available balance in the payment channels along the way during the transaction routing process. Most existing payment channel networks adopt the "process immediately upon arrival" method to execute transactions. Once there is not enough available balance in the payment channel when the transaction arrives, the transaction is determined to fail. On the other hand, every time a payment is completed in the payment channel, the corresponding amount of money is permanently transferred to the payee. When the available balance of a user on one side of the payment channel is insufficient, it can only passively wait for the other user to execute a transaction and pay the user on this side before having more available balance to execute other transactions.
[0005] To improve the transaction success rate, some methods propose to introduce transaction queues on both sides of the payment channel to alleviate the sensitivity of the transaction execution process to the real-time available balance, and cooperate with the transaction scheduling algorithm to complete the transaction processing within the queue. When the available balance on one side of the payment channel is insufficient, newly arrived transactions will be stored in the transaction queue. When the other side executes a number of transactions and brings sufficient balance updates, the transaction can be successfully executed, thus avoiding the loss of success rate caused by directly discarding transactions. However, the users on both sides of the payment channel are independent of each other. For a unilateral transaction queue, it is impossible to determine when the other side will bring how much balance update. The process of passive waiting for balance updates for a long time will cause the transaction queue to become blocked, which is not conducive to the effective utilization of funds in the payment channel. Existing transaction scheduling methods can only avoid long-term queue blocking, but cannot timely obtain the upcoming balance update situation on the other side of the payment channel, and cannot fully utilize the funds in the payment channel to maximize the successfully executed transaction amount. Summary of the Invention
[0006] In view of the above deficiencies in the prior art, the two-way coupled transaction scheduling method and system for payment channels provided by the present invention solve the problem that existing methods cannot fully utilize the funds in the payment channel and are prone to channel blocking.
[0007] To achieve the above invention purpose, the technical solution adopted by the present invention is as follows:
[0008] In the first aspect, a two-way coupled transaction scheduling method for a payment channel is provided, which includes the steps of:
[0009] S1. Receive a message. When the message is a transaction key, go to step S2. When the message is a balance update, go to step S3. When the message is a transaction message, go to step S4;
[0010] S2. Send the transaction key to the other end, and use the balance update prediction algorithm to calculate the estimated balance update completion time and balance update prediction value of the transaction corresponding to the current message, and then return to step S1 until no more messages are received;
[0011] S3. Use the balance update prediction algorithm to update the balance update prediction value at the estimated balance update completion time of the transaction corresponding to the current message, and then enter step S4;
[0012] S4. Update the transaction queue as a transaction set After that, the local end obtains the current available balance b t and the balance update prediction value θ at the minimum time among the estimated balance update completion times corresponding to multiple transactions currently recorded; u ;
[0013] S5. According to the transaction execution situation in the previous scheduling interval, from the transaction set Select multiple transactions from the total transaction value not exceeding the current available balance b at this end t and store them in the transaction set
[0014] S6. According to the transaction set and the current available balance b t and the balance update value θ u , calculate the benefits g1 and g2 that can be obtained when executing transactions and not executing transactions within the current scheduling interval and obtaining the balance update next time;
[0015] S7. When g1 ≥ g2, update the transaction set to be executed and execute them in sequence in the transaction set. When g1 < g2, update and then return to step S1 in both cases until no more messages are received.
[0016] Furthermore, the method for calculating the predicted balance update completion time and balance update prediction value of the transaction corresponding to the current message using the balance update prediction algorithm includes:
[0017] S21. Initialize the dictionary of transactions to be completed by the peer end to be empty, where the ID in the dictionary structure r is the transaction ID of transaction r, and is the predicted balance update completion time of transaction r;
[0018] S22. Initialize the balance update prediction value dictionary U = {t u : θ} to be empty, where t in the dictionary structure u is the predicted balance update completion time, and θ is the balance update prediction value corresponding to time t u ;
[0019] S23. When the message is a transaction key, calculate the predicted balance update completion time of the transaction r corresponding to the current message where t is the current time and Δ [A,B] is the round-trip time of the current payment channel;
[0020] S24. Add the transaction r corresponding to the current message to the dictionary of transactions to be completed by the peer end Update the balance update prediction value at time r according to the transaction value θ U[O[ID r = U[O[ID r + θ r ;
[0021] S25. When the message is a balance update, update the transaction r corresponding to the current message′ The predicted balance update value U[O[ID r′ = U[O[ID r′ - θ r′ , and delete the transaction r' from the transaction dictionary that the peer is about to complete.
[0022] The beneficial effects of the above technical solution are as follows: This solution uses the payment channel network to predict the balance update value that will be obtained from the peer based on the time difference between sending the transaction secret key message and the balance update message during the transaction process. Without introducing additional communication overhead, it realizes an accurate prediction of the peer's transaction execution situation, thereby assisting the transaction scheduling system to make more flexible scheduling decisions and make full use of the funds in the payment channel.
[0023] Furthermore, in step S4, when the message is a transaction message, add the new transaction to the transaction queue and delete the timeout transactions in the transaction queue; when the message is a balance update, delete the timeout transactions in the transaction queue; then sort the transactions in the transaction queue in descending order of transaction value to obtain the transaction set
[0024] Furthermore, step S5 further includes:
[0025] S51. Determine whether a transaction was executed in the previous scheduling interval. If so, go to step S52; otherwise, go to step S53.
[0026] S52. Select transactions from in ascending order of transaction value and add them to the transaction set and make the total transaction value of all transactions in t , the total transaction value of all transactions in
[0027] S53. Select transactions from in descending order of transaction value and add them to the transaction set and make the total transaction value of all transactions in t , the total transaction value of all transactions in
[0028] The beneficial effects of the above technical solution are as follows: Avoid the scheduling algorithm showing a single preference for large-value or small-value transactions, and to a certain extent ensure the fairness of the scheduling algorithm among different transaction values.
[0029] Furthermore, step S6 further includes:
[0030] S61. Calculate the remaining transaction set
[0031] S62. Select transactions from in ascending order of transaction value and add them to the transaction set successively, and make the total transaction value of all transactions in t ―c1 + θ u , and record the total transaction value of all transactions in
[0032] as c2; S63. Calculate the subset of transactions that cannot be satisfied by the current available balance b t in
[0033] S64. Select transactions from in ascending order of transaction value and add them to the transaction set successively, and make the total transaction value of all transactions in t + θ u , and record the total transaction value of all transactions in
[0034] S65. Calculate the profit that can be obtained by executing transactions until the next balance update is obtained within the current scheduling interval:
[0035] g1 = c1·Δ [A,B] + c2·(t + Δ [A,B] ―t u )
[0036] where Δ [A,B] is the round - trip time of the current payment channel; t is the current time; t u is the minimum time among the estimated balance update completion times of multiple transactions recorded currently;
[0037] S66. Calculate the profit that can be obtained by not executing transactions within the current scheduling interval and executing transactions at the next balance update: g2 = c3·(t + Δ [A,B] ―t u ).
[0038] The beneficial effects of the above - mentioned technical solution are as follows: According to the current balance situation in the payment channel and the upcoming balance update situation at this end, calculate the maximum profits that can be obtained by executing transactions and not executing transactions within the current scheduling interval respectively, flexibly select the transaction execution method with higher profit, so as to make full use of the funds in the payment channel, improve transaction throughput and transaction success rate, and at the same time, the entire scheduling process will not destroy the atomicity of transactions.
[0039] Further, when the two-way coupled transaction scheduling method is executed, when the first received message is a balance update or a transaction message, the previous scheduling interval is initialized as a non-executed transaction.
[0040] In a second aspect, a two-way coupled transaction scheduling system for a payment channel is provided, which includes:
[0041] A message determination module, configured to receive a message. When the message is a transaction key, it enters the first prediction value update module. When the message is a balance update, it enters the second prediction value update module. When the message is a transaction message, it enters the queue update and data collection module;
[0042] A first balance update module, configured to send the transaction key to the peer end, and calculate the estimated balance update completion time and the balance update prediction value of the transaction corresponding to the current message by using a balance update prediction algorithm, and then return to the message determination module until no more messages are received;
[0043] A second balance update module, configured to update the balance update prediction value at the estimated balance update completion time corresponding to the current message by using a balance update prediction algorithm, and then enter the queue update and data collection module;
[0044] The queue update and data collection module is configured to update the transaction queue as a transaction set After that, the local end obtains the current available balance b t and the balance update prediction value θ at the minimum time among the estimated balance update completion times corresponding to multiple current recorded transactions; u ;
[0045] The transaction set generation module is configured to select multiple transactions with a total transaction value not exceeding the current available balance b of the local end from the transaction set t according to the transaction execution situation in the previous scheduling interval, and store them in the transaction set
[0046] The revenue calculation module is configured to calculate the revenues g1 and g2 that can be obtained when executing transactions and not executing transactions in the current scheduling interval when the balance update is obtained next time according to the transaction set and the current available balance b t and the balance update value θ; u
[0047] The transaction update and execution module is configured to update the executed transaction set and sequentially execute the transactions therein when g1≥g2, and update when g1<g2. In both cases, it returns to the message determination module until no more messages are received.
[0048] The beneficial effects of the present invention are as follows: The balance update prediction algorithm proposed in this solution utilizes the time difference between the transaction key and the sending of the balance update message in the HTLC protocol workflow to predict the balance update value to be obtained from the peer in the future; then, based on the balance update prediction value and the real-time available balance value, the optimal set of executed transactions is selected. While making full use of the funds in the payment channel, the atomicity feature of the transaction is retained, and there will be no fund security issues caused by the split transmission of transactions. On this premise, the transaction scheduling algorithm of the present invention can effectively utilize the funds in the payment channel and execute as many transactions as possible, with advantages such as high throughput and high transaction success rate. BRIEF DESCRIPTION OF THE DRAWINGS
[0049] Figure 1 FIG. is a workflow diagram of the HTLC protocol.
[0050] Figure 2 FIG. is a schematic diagram of the two-way coordinated payment channel transaction scheduling of this solution.
[0051] Figure 3 FIG. is a flowchart of a two-way coupled transaction scheduling method for a payment channel.
[0052] Figure 4 FIG. is a detailed flowchart of calculating the estimated balance update completion time and the balance update prediction value of the transaction corresponding to the current message using the balance update prediction algorithm.
[0053] Figure 5 FIG. is a detailed implementation flowchart of steps S3 to S7.
[0054] Figure 6 FIG. is a comparison chart between the balance update prediction value and the actually achieved balance update value in the embodiment.
[0055] Figure 7 FIG. is a comparison chart of transactions successfully executed by multiple transaction scheduling schemes. (a) is a comparison chart of the number of successful transactions; (b) is a comparison chart of the amount of successful transactions. DETAILED DESCRIPTION OF THE EMBODIMENTS
[0056] The following describes the specific embodiments of the present invention to facilitate those skilled in the art of the present technology to understand the present invention. However, it should be clear that the present invention is not limited to the scope of the specific embodiments. For those of ordinary skill in the art of the present technology, as long as various changes are within the spirit and scope of the present invention defined and determined by the appended claims, these changes are obvious, and all inventions and creations using the concept of the present invention are within the scope of protection.
[0057] To facilitate understanding of the execution process of the two-way coupled transaction scheduling method proposed in this solution, this solution first briefly introduces the workflow of the HTLC protocol used when the payment channel network transmits transactions. As Figure 1As shown, it demonstrates the process of user A paying 2 yuan to user E through the path A→B→E on the payment channel network. Among them, within the payment channel [A, B], the initial available balances of user A and user B are both 5 yuan. Within the payment channel [B, E], the initial available balances of user B and user E are 4 yuan and 6 yuan respectively.
[0058] Before the formal transmission of the transaction, user E first generates a corresponding hash value using a locally randomly generated secret key and sends this hash value to user A. Then, user A and user B successively use this hash value within the payment channels [A, B] and [B, E] to generate a transaction with an amount of 2 and send it to user B and user E. After the transaction is generated, 2 yuan in the corresponding available balances of user A and user B will be temporarily locked. When user E successfully receives the transaction, it sends the secret key corresponding to this transaction to user B. After user B receives the correct secret key it sends the updated balance status of the payment channel [B, E] to user E. At this time, within the payment channel [B, E], the balance of user B is updated to 2, and the balance of user E is updated to 8. Meanwhile, user B sends the secret key to user A in a similar manner
[0059] and completes the balance update within the payment channel [A, B]. Each transaction within a payment channel corresponds to a valid time. If the payer does not receive the correct secret key within the valid time the locked amount will be refunded to the payer. The overall operation block diagram of this solution is as shown in
[0060] In, users A and B at both ends of the payment channel, one is the local end and the other is the peer end. When A is the local end, B is the peer end; when B is the local end, A is the peer end. This solution mainly includes two functional algorithms: 1) The balance update prediction algorithm, which is mainly used to predict and record the upcoming balance update situation of the corresponding users within the payment channel to assist in making transaction scheduling decisions; 2) The transaction scheduling algorithm (the steps from step S3 to step S7 correspond to the steps), which is mainly used to decide which transactions to execute at what time. Figure 2 as shown in Figure 2 where users A and B at both ends of the payment channel, one is the local end and the other is the peer end. When A is the local end, B is the peer end; when B is the local end, A is the peer end. This solution mainly includes two functional algorithms: 1) The balance update prediction algorithm, which is mainly used to predict and record the upcoming balance update situation of the corresponding users within the payment channel to assist in making transaction scheduling decisions; 2) The transaction scheduling algorithm (the steps from step S3 to step S7 correspond to the steps), which is mainly used to decide which transactions to execute at what time.
[0061] The method proposed in this solution adopts a "single user - single channel" deployment method, that is, the user creates module entities of the above two functional algorithms for each payment channel that needs to perform transaction scheduling. The two functional modules are bound to the transaction queue of the corresponding user in the payment channel, and the corresponding channel balance and the execution status of transactions in the payment channel are obtained in real time to make transaction scheduling decisions. The following describes the specific implementation process of the two - way coupled transaction scheduling method including the balance update prediction algorithm and the transaction scheduling algorithm.
[0062] Reference Figure 3 , Figure 3 shows the flowchart of the two - way coupled transaction scheduling method for a payment channel. As Figure 1 shown, this method S includes steps S1 to S7, which are executed at the local end.
[0063] In step S1, a message is received. When the message is a transaction key, it enters step S2; when the message is a balance update, it enters step S3; when the message is a transaction message, it enters step S4.
[0064] In step S2, the transaction key is sent to the peer end, and the balance update prediction algorithm is used to calculate the estimated balance update completion time and the balance update prediction value for the transaction corresponding to the current message. Then it returns to step S1 until no more messages are received.
[0065] In step S3, the balance update prediction algorithm is used to update the balance update prediction value at the estimated balance update completion time corresponding to the transaction of the current message, and then it enters step S4.
[0066] As Figure 4 shown, in steps S2 and S3, the method of using the balance update prediction algorithm to calculate the estimated balance update completion time and the balance update prediction value for the transaction corresponding to the current message includes:
[0067] S21. Initialize the dictionary of transactions that the peer end is about to complete as empty, where in the dictionary structure, ID r is the transaction ID of transaction r, is the estimated balance update completion time of transaction r;
[0068] S22. Initialize the balance update prediction value dictionary U = {t u : θ} as empty, where in the dictionary structure, t u is the estimated balance update completion time, and θ is the balance update prediction value corresponding to time t u ;
[0069] S23. When the message is a transaction key, calculate the estimated balance update completion time of the transaction r corresponding to the message where t is the current time, Δ[A,B] is the round-trip time of the current payment channel;
[0070] S24. Add the message-corresponding transaction r to the dictionary of transactions that the peer is about to complete According to the transaction value θ r Update the predicted balance update value U[O[ID r = U[O[ID r + θ r ;
[0071] S25. When the message is a balance update, delete the message-corresponding transaction r ′ from the predicted balance update value U[O[ID r′ = U[O[ID r′ - θ r′ , and delete the transaction r from the dictionary of transactions that the peer is about to complete ′ .
[0072] In step S4, update the transaction queue as a transaction set After that, the local end obtains the current available balance b t and the predicted balance update value θ at the minimum time among the predicted balance update completion times corresponding to multiple transactions currently recorded u .
[0073] In step S4, when the message is a transaction message, add the new transaction to the transaction queue and delete the timeout transactions in the transaction queue; when the message is a balance update, delete the timeout transactions in the transaction queue; then sort the transactions in the transaction queue in descending order of transaction value to obtain a transaction set
[0074] In step S5, according to the transaction execution situation in the previous scheduling interval, select multiple transactions from the transaction set whose total transaction value does not exceed the current available balance b of the local end t and store them in the transaction set
[0075] As Figure 5 shown, in an embodiment of the present invention, step S5 further includes:
[0076] S51. Judge whether a transaction was executed in the previous scheduling interval. If so, go to step S52; otherwise, go to step S53;
[0077] S52. Select transactions from in ascending order of transaction value and add them to the transaction set and make The total transaction value of all transactions does not exceed b t , The total transaction value of all transactions in it is denoted as c1;
[0078] S53. Select transactions from in descending order of transaction value and add them to the transaction set and make The total transaction value of all transactions does not exceed b t , The total transaction value of all transactions in it is denoted as c1.
[0079] In step S6, according to the transaction set and the current available balance b t and the balance update value θ u , calculate the benefits g1 and g2 that can be obtained when executing transactions and not executing transactions during the current scheduling interval and when obtaining the balance update next time.
[0080] As Figure 5 shown, in an embodiment of the present invention, step S6 further includes:
[0081] S61. Calculate the remaining transaction set
[0082] S62. Select transactions from in ascending order of transaction value and add them to the transaction set and make The total transaction value of all transactions does not exceed b t ―c1 + θ u , The total transaction value of all transactions in it is denoted as c2;
[0083] S63. Calculate the subset of transactions that cannot be satisfied by the current available balance b t in
[0084] S64. Select transactions from in ascending order of transaction value and add them to the transaction set and make The total transaction value of all transactions does not exceed b t + θ u , The total transaction value of all transactions in it is denoted as c3;
[0085] S65. Calculate the benefit that can be obtained when executing transactions until the balance update is obtained next time during the current scheduling interval:
[0086] g1 = c1·Δ [A,B] + c2·(t + Δ[A,B] -t u )
[0087] where, Δ [A,B] is the round-trip time of the current payment channel; t is the current time; t u is the minimum time among the predicted balance update completion times of multiple transactions recorded currently;
[0088] S66. Calculate the profit that can be obtained by not executing the transaction within the current scheduling interval and executing the transaction when obtaining the balance update next time: g2 = c3·(t + Δ [A,B] -t u ).
[0089] In step S7, when g1 ≥ g2, update the set of transactions to be executed and execute the transactions in sequentially. When g1 < g2, update and then return to step S1 in both cases until no more messages are received.
[0090] When the two-way coupled transaction scheduling method is executed, when the balance update or transaction message is received for the first time, initialize the previous scheduling interval as unexecuted transactions.
[0091] This solution also provides a two-way coupled transaction scheduling system for a payment channel, which includes:
[0092] A message determination module, configured to receive messages. When the message is a transaction key, it enters the first predicted value update module. When the message is a balance update, it enters the second predicted value update module. When the message is a transaction message, it enters the queue update and data collection module;
[0093] A first balance update module, configured to send the transaction key to the peer end, calculate the predicted balance update completion time and the balance update predicted value of the transaction corresponding to the current message by using the balance update prediction algorithm, and then return to the message determination module until no more messages are received;
[0094] A second balance update module, configured to update the balance update predicted value at the predicted balance update completion time of the transaction corresponding to the current message by using the balance update prediction algorithm, and then enter the queue update and data collection module;
[0095] A queue update and data collection module, configured to update the transaction queue as the set of transactions and then the local end obtains the current available balance b t and updates the corresponding balance update value θ with the minimum value among the current balance update predicted values corresponding to multiple transactions at the current moment u ;
[0096] A transaction set generation module, which is used to select, according to the transaction execution situation in the previous scheduling interval, multiple transactions from the transaction set whose total transaction value does not exceed the current available balance b at this end t and store them in the transaction set
[0097] A revenue calculation module, which is used to calculate the revenues g1 and g2 that can be obtained when executing transactions and not executing transactions in the current scheduling interval when the next balance update is obtained, according to the transaction set and the current available balance b t and the balance update value θ u ;
[0098] A transaction update and execution module, which is used to update the executed transaction set and sequentially execute the transactions in when g1≥g2, and update in both of the following cases and then return to the message determination module until no more messages are received.
[0099] Figure 6 shows the comparison result between the balance update value predicted by the balance update prediction algorithm proposed in this solution and the actually arrived balance update value during the transaction scheduling process of a single payment channel. In this experiment, the initial balances on both sides of the payment channel are 0 and 300 respectively, and a number of transactions arrive on both sides of the payment channel within the time range of 0 - 1000 seconds according to the Poisson distribution, and the average arrival rate of transactions is 50 transactions per second. The transaction values are sampled according to the Kaggle credit card dataset.
[0100] As Figure 6 shown, the accuracy rate of the balance prediction algorithm proposed in this solution reaches 100%. According to the situation of the balance update prediction value, this solution can make more flexible transaction scheduling decisions and make full use of the funds in the payment channel when performing subsequent transaction scheduling.
[0101] Figure 7 shows the transaction situation successfully executed by different transaction scheduling algorithms under different workloads. Among them, the initial balance of the payment channel, the transaction arrival mode, and the transaction value size are the same as the Figure 6 corresponding experimental conditions, and the workload value represents the average arrival rate of transactions on both sides of the payment channel. Among the comparison algorithms, Bishe-HG is the two-way coupled transaction scheduling method proposed in this solution, and PDME, PRI-IP, Spider, and LND are the scheduling methods in the existing technologies, which are introduced as follows:
[0102] Spider first introduced a transaction queue into the payment channel and proposed to perform transaction transmission based on a packet-switching architecture. Before each transaction is transmitted, it is pre-split into a set of very small transaction units, and then these transaction units are sent at a certain rate. Each transaction unit is independently transmitted and confirmed. During the transmission of transaction units, the transaction units are marked according to their queuing situation in the queue, and then the sender adjusts the sending rate of the transaction units in a manner similar to a congestion control protocol based on the marking situation of the transaction units, so as to avoid network congestion while making full use of the funds in the payment channel.
[0103] PRI processes the transactions in the queue in a periodic scanning manner. Whenever a new transaction arrives, PRI can choose to add only the transactions with insufficient balance to the queue or directly add all transactions to the queue. Then, the queue is scanned once at a fixed time interval, and the transactions in the queue are scanned in turn. If the balance is sufficient, the transaction is executed; if the balance is insufficient, the transaction continues to queue.
[0104] PDME sets a time limit for each transaction, and the transaction must wait in the queue before the time limit expires. When a certain transaction exceeds the time limit, PDME will judge whether the current available balance is sufficient to execute the transaction. If the balance is insufficient, PDME will scan whether there are some executable transactions in the opposite transaction queue that can bring sufficient balance updates to this side. If so, the transactions in the opposite queue will be executed immediately and then this transaction will be executed; otherwise, the transaction will be discarded.
[0105] LND is the transaction processing method adopted by the existing payment channel, that is, all transactions are not put into the transaction queue and are executed in the "come and process immediately" manner.
[0106] As Figure 7 It can be seen from the comparison data in (a) and (b) of that the proposed two-way coupled transaction scheduling algorithm in this scheme has obvious advantages in terms of the number of successfully executed transactions; in terms of the amount of successfully executed transactions, the proposed two-way coupled transaction scheduling method in this scheme has obvious advantages compared with other transaction scheduling algorithms that retain transaction atomicity, and the amount of successful transactions is almost the same as that of the Spider algorithm that does not consider transaction atomicity.
Claims
1. A bidirectional coupling transaction scheduling method for payment channels, characterized in that: Includes steps: S1. Receive a message. When the message is a transaction key, proceed to step S2. When the message is a balance update, proceed to step S3. When the message is a transaction message, proceed to step S4. S2. Send the transaction key to the peer end, and use the balance update prediction algorithm to calculate the estimated balance update completion time and balance update prediction value of the transaction corresponding to the current message, and then return to step S1 until no more messages are received; S3, using the balance update prediction algorithm to update the balance update prediction value at the estimated balance update completion time of the transaction corresponding to the current message, and then proceeding to step S4; S4. Update the transaction queue as a transaction set After that, the local end obtains the current available balance b t The predicted balance update value θ at the minimum time among the estimated balance update completion times corresponding to the multiple transactions currently recorded u ; S5. According to the transaction execution status of the previous scheduling interval, Select multiple transactions with a total transaction value not exceeding the current available balance b on this end t Transaction and store it in the transaction collection S6. Based on transaction collection and current available balance b t and the balance update value θ u , calculate the benefits g1 and g2 that can be obtained when the balance is updated next time if the transaction is executed or not executed during the current scheduling interval; S7. When g1 ≥ g2, update the execution transaction set and execute them in sequence the transactions in. When g1 < g2, update In both cases afterwards, return to step S1 until no more messages are received.
2. The bidirectional coupling transaction scheduling method according to claim 1, characterized in that: The method of using the balance update prediction algorithm to calculate the estimated balance update completion time and the balance update prediction value corresponding to the current message includes: S21. Initialize the transaction dictionary that is about to be completed on the other end Is empty, where the dictionary structure ID r is the transaction ID of transaction r, The estimated balance update completion time of transaction r; S22, initialize the balance update prediction value dictionary U = {t u :θ} is empty, where t u is the estimated balance update completion time, θ is t u The updated balance value corresponding to the moment; S23. When the message is a transaction key, calculate the estimated balance update completion time of the transaction r corresponding to the message =t+Δ [A,B] , where t is the current time, Δ [A,B] The round trip time of the current payment channel; S24. Add the transaction r corresponding to the message to the transaction dictionary that is about to be completed on the other end. According to the transaction value θ r renew The balance update prediction value corresponding to the time U[O[ID r ]]=U[O[ID r ]]+θ r ; S25. When the message is a balance update, the balance update prediction value U[O[ID r′ ]]=U[O[ID r′ ]]―θ r′ , and delete transaction r′ from the transaction dictionary that is about to be completed by the other end.
3. The bidirectional coupling transaction scheduling method according to claim 1, characterized in that: In step S4, when the message is a transaction message, the new transaction is added to the transaction queue and the timed-out transaction in the transaction queue is deleted; when the message is a balance update, the timed-out transaction in the transaction queue is deleted; then the transactions in the transaction queue are sorted in descending order of transaction value to obtain a transaction set.
4. The bidirectional coupling transaction scheduling method according to claim 1, characterized in that: Step S5 further comprises: S51, determine whether the transaction was executed in the previous scheduling interval, if so, proceed to step S52, otherwise proceed to step S53; S52, in ascending order of transaction value Select transactions in turn to add to the transaction collection and make The total transaction value of all transactions in does not exceed b t , The total transaction value of all transactions in is recorded as c1; S53, in descending order of transaction value Select transactions in turn to add to the transaction collection and make The total transaction value of all transactions in does not exceed b t , The total transaction value of all transactions in is recorded as c1.
5. The bidirectional coupling transaction scheduling method according to claim 4, characterized in that: Step S6 further comprises: S61. Calculate the remaining transaction set S62, in ascending order of transaction value Select transactions in turn to add to the transaction collection and make The total transaction value of all transactions in does not exceed b t ―c1+θ u , The total transaction value of all transactions in is recorded as c2; S63, calculation Current available balance in b t Unsatisfiable transaction subset S64, in ascending order of transaction value Select transactions in turn to add to the transaction collection and make The total transaction value of all transactions in does not exceed b t +θ u , The total transaction value of all transactions in is recorded as c3; S65. Calculate the profit that can be obtained when executing transactions in the current scheduling interval until the next balance update: g1=c1·Δ [A,B] +c2·(t+Δ [A,B] ―t u ) Among them, Δ [A,B] is the round trip time of the current payment channel; t is the current time; t u The minimum time among the estimated balance update completion times of multiple transactions currently recorded; S66. Calculate the profit that can be obtained by executing the transaction when the balance is updated next time without executing the transaction in the current scheduling interval: g2 = c3·(t+Δ [A,B] ―t u ).
6. The bidirectional coupling transaction scheduling method according to claim 1, characterized in that: When the bidirectional coupling transaction scheduling method is executed, when the first received message is a balance update or transaction message, the previous scheduling interval is initialized to unexecuted transactions.
7. A bidirectional coupling transaction scheduling system for payment channels, characterized in that: include: A message determination module, used to receive a message, enter the first prediction value update module when the message is a transaction key, enter the second prediction value update module when the message is a balance update, and enter the queue update and data collection module when the message is a transaction message; The first balance update module is used to send the transaction key to the peer end, and use the balance update prediction algorithm to calculate the estimated balance update completion time and balance update prediction value of the transaction corresponding to the current message, and then return to the message confirmation module until no more messages are received; The second balance update module is used to update the balance update prediction value at the estimated balance update completion time of the transaction corresponding to the current message using the balance update prediction algorithm, and then enter the queue update and data collection module; Queue update and data collection module, used to update the transaction queue as a transaction collection After that, the local end obtains the current available balance b t The predicted balance update value θ corresponding to the minimum time among the estimated balance update completion times corresponding to the multiple transactions currently recorded u ; The transaction set generation module is used to generate transactions from the transaction set according to the transaction execution status of the previous scheduling interval. Select multiple transactions with a total transaction value not exceeding the current available balance b on this end t Transaction and store it in the transaction collection The profit calculation module is used to calculate the profit based on the transaction set. and current available balance b t and the balance update value θ u , calculate the benefits g1 and g2 that can be obtained when the balance is updated next time if the transaction is executed or not executed during the current scheduling interval; A transaction update and execution module, used to update and execute a transaction set when g1 ≥ g2 and execute them sequentially the transactions in, when g1 < g2, update In both of the following cases, return to the message determination module until no more messages are received.
Citation Information
Patent Citations
Networking payment device and networking payment method
CN104835038A
Anonymous secure payment channel method and device
CN110378690A
Multidirectional state channel method and system for blockchain extension, and medium
CN110751468A
Blockchain payment channels with trusted execution environments
US20190095879A1
Hot wallet protection using a layer-2 blockchain network
WO2023215103A1