Bidirectional coupling transaction scheduling method and system for payment channels

Abstract

The present invention discloses a bidirectional coupling transaction scheduling method and system for payment channels. The scheduling method includes receiving a message, when the message is a transaction key, sending the transaction key to the opposite end, calculating the estimated balance update completion time and the balance update prediction value of the transaction corresponding to the current message; when the message is a balance update, updating the balance update prediction value and entering the transaction queue update step; when the message is a transaction message, updating the transaction queue as a transaction set #imgabs0# based on the transaction execution status of the previous scheduling interval, selecting multiple transactions from #imgabs1# with a total transaction value not exceeding the current available balance b of the local end t Transaction and store it in the transaction set#imgabs2#According to#imgabs3##imgabs4#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 when the transaction is executed or not executed within the current scheduling interval; when g1 ≥ g2, update the execution transaction set #imgabs5# and execute the transactions in #imgabs6# in sequence. When g1

Description

Technical Field

[0001] The present invention relates to online payment technology, a payment channel-oriented bidirectional coupling transaction scheduling method and a system thereof. Background Art

[0002] Payment channel networks are a mainstream Layer-2 solution for addressing the scalability issues of blockchain-based cryptocurrencies. In a payment channel network, most transactions are completed off-chain using funds held in escrow within individual payment channels, eliminating the need for cumbersome consensus processes on the blockchain. This significantly improves the transaction throughput and processing speed of cryptocurrency systems.

[0003] Each payment channel is collaboratively created by two users. When two users conduct a transaction (i.e., one user pays a certain amount to another), they typically first find one or more paths between the two users and determine the transaction amount to be executed on each path. The transaction is then forwarded through the routing process to complete the payment. The transaction is only successfully forwarded if the available balance of the payment channel passing through it meets the transaction amount. Once the transaction amount is determined, each payment channel on the path processes the transaction to be forwarded atomically. This means that the transaction cannot be further split during the routing process. The payer within the payment channel must either pay the full transaction amount to the payee in one go or cancel the transaction if it is deemed to have failed.

[0004] A major challenge currently facing payment channel networks is how to fully utilize the funds held in escrow within payment channels to execute as many off-chain transactions as possible. Firstly, since payment channel networks lack a trusted central management node and each payment channel independently executes off-chain transactions and updates its balance distribution, nodes in the network lack real-time information about the available balance distribution within other payment channels. This makes it difficult to ensure sufficient available balance within the transiting payment channels during transaction routing. Existing payment channel networks mostly execute transactions on a "come, go" basis. If a transaction arrives without sufficient available balance within the payment channel, the transaction is deemed failed. Secondly, each payment completed within a payment channel permanently transfers the corresponding amount to the recipient. When a user on one side of a payment channel runs out of available balance, they can only passively wait for the other user to execute a transaction and pay their own user before more available balance is available for further transactions.

[0005] To improve transaction success rates, some methods propose introducing transaction queues on both sides of the payment channel to mitigate the sensitivity of transaction execution to real-time available balances. These queues are then used in conjunction with transaction scheduling algorithms to complete transaction processing within the queues. When the available balance on one side of the payment channel is insufficient, newly arriving transactions are placed in the transaction queue. Once the other side has executed several transactions and generated sufficient balance updates, the transaction can be successfully executed, thus avoiding the loss in success rate caused by simply discarding transactions. However, the users on both sides of the payment channel are independent of each other. For a single-sided transaction queue, it is impossible to determine when and how much the other side will update its balance. The prolonged passive wait for balance updates can cause the transaction queue to become blocked, hindering the efficient utilization of funds within the payment channel. Existing transaction scheduling methods can only prevent long queue blockages, but fail to provide timely notification of upcoming balance updates from the other side of the payment channel, hindering the full utilization of funds within the payment channel to maximize the amount of successfully executed transactions. Summary of the Invention

[0006] In view of the above-mentioned deficiencies in the prior art, the bidirectional coupling transaction scheduling method and system for payment channels provided by the present invention solve the problem that the prior methods cannot fully utilize the funds in the payment channel, resulting in easy channel congestion.

[0007] In order to achieve the above-mentioned object of the invention, the technical solution adopted by the present invention is:

[0008] In a first aspect, a bidirectional coupling transaction scheduling method for a payment channel is provided, comprising the steps of:

[0009] S1. Receive a message. If the message is a transaction key, proceed to step S2. If the message is a balance update, proceed to step S3. If the message is a transaction message, proceed to step S4.

[0010] 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 for the transaction corresponding to the current message. 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 proceed to step S4;

[0012] S4. Update the transaction queue as a transaction set After that, this 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 ;

[0013] S5. According to the transaction execution status of the previous scheduling interval, Select multiple transactions from the ones whose total transaction value does not exceed 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 and not executing transactions within the current scheduling interval and obtaining the balance update next time;

[0015] S7. When g1≥g2, update the execution transaction set and execute the transactions in it in sequence . When g1<g2, update . In both cases afterwards, return to step S1 until no more messages are received.

[0016] Furthermore, the method for calculating the estimated 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 that the peer is about to complete to be empty, where the ID in the dictionary structure r is the transaction ID of transaction r, and is the estimated 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 estimated 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 estimated 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 that the peer is about to complete 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′ 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 party.

[0022] The beneficial effects of the above technical solution are as follows: this solution uses the time difference between sending the transaction key message and the balance update message during the transaction processing of the payment channel network to predict the balance update value to be obtained from the other end, and achieves accurate prediction of the transaction execution status of the other end without introducing additional communication overhead, thereby assisting the transaction scheduling system to achieve 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, 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.

[0024] Furthermore, step S5 further includes:

[0025] S51: Determine whether a transaction was executed in the previous scheduling interval. If so, proceed to step S52; otherwise, proceed to step S53.

[0026] 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;

[0027] 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.

[0028] The beneficial effect of the above technical solution is: avoiding the scheduling algorithm from showing a single preference for large transactions or small transactions, and to a certain extent ensuring the fairness of the scheduling algorithm between different transaction values.

[0029] Furthermore, step S6 further includes:

[0030] S61. Calculate the remaining transaction set

[0031] 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;

[0032] S63, calculation Current available balance in b t Unsatisfiable transaction subset

[0033] 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;

[0034] S65. Calculate the profit that can be obtained by executing transactions during the current scheduling interval until the next balance update:

[0035] g1=c1·Δ [A,B] +c2·(t+Δ [A,B] ―t u )

[0036] 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;

[0037] S66. Calculate the profit that can be obtained by executing a transaction when the balance is updated next time without executing the transaction within the current scheduling interval: g2 = c3 (t + Δ [A,B] ―t u ).

[0038] The beneficial effects of the above technical solution are: based on the current balance in the payment channel and the balance update to be obtained by this end, the maximum benefits that can be obtained by executing and not executing the transaction within the current scheduling interval are calculated respectively, and the transaction execution method with higher benefits is flexibly selected, thereby making full use of the funds in the payment channel and improving transaction throughput and transaction success rate. At the same time, the entire scheduling process will not destroy the atomicity of the transaction.

[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 an unexecuted transaction.

[0040] Second, 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, calculate the estimated balance update completion time and the balance update prediction value of the current message corresponding transaction 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] A queue update and data collection module, 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] A transaction set generation module, 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 of the previous scheduling interval, and store them in the transaction set

[0046] A revenue calculation module, 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] A transaction update and execution module, configured to update the executed transaction set and sequentially execute the transactions in it 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 uses 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 received from the peer end. It then selects the optimal set of executed transactions based on the balance update prediction value and the real-time available balance value. This fully utilizes the funds in the payment channel while preserving the atomicity of the transaction and eliminating the fund security issues caused by transaction splitting and transmission. Under 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 This is the HTLC protocol workflow diagram.

[0050] Figure 2 Schematic diagram of the bidirectional coordinated payment channel transaction scheduling of this scheme.

[0051] Figure 3 The flowchart of the bidirectional coupling transaction scheduling method for payment channels.

[0052] Figure 4 This is a detailed flow chart for using the balance update prediction algorithm to calculate the estimated balance update completion time and balance update prediction value for the transaction corresponding to the current message.

[0053] Figure 5 This is a detailed implementation flowchart of steps S3 to S7.

[0054] Figure 6 4 is a comparison chart between the predicted balance update value and the actual balance update value achieved in the embodiment.

[0055] Figure 7 Comparison charts of transactions successfully executed under 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

[0056] The specific embodiments of the present invention are described below to facilitate understanding of the present invention by those skilled in the art. However, it should be clear that the present invention is not limited to the scope of the specific embodiments. For those skilled in the art, as long as various changes are within the spirit and scope of the present invention as defined and determined by the appended claims, these changes are obvious, and all inventions and creations utilizing the concepts of the present invention are protected.

[0057] In order to facilitate the understanding of the execution process of the bidirectional coupling transaction scheduling method proposed in this solution, this solution first briefly introduces the workflow of the HTLC protocol used when transmitting transactions in the payment channel network. Figure 1Figure 1 shows a payment channel network where user A pays user E 2 yuan via the path A→B→E. Within the payment channel [A, B], both user A and user B have an initial available balance of 5 yuan. Within the payment channel [B, E], user B and user E have an initial available balance of 4 yuan and 6 yuan, respectively.

[0058] Before the transaction is officially transmitted, user E will first use the locally randomly generated secret key Generate a corresponding hash value And the hash value Sent to user A. Then, user A and user B use the hash value in payment channels [A, B] and [B, E] respectively. Generate a transaction with an amount of 2 and send it to user B and user E. After the transaction is generated, 2 yuan of the available balance of user A and user B will be temporarily locked. When user E successfully receives the transaction, the corresponding secret key of the transaction will be Sent to user B, user B receives the correct key Then the updated balance status of the payment channel [B, E] is sent to user E.

[0059] At this time, in the payment channel [B, E], the balance of user B is updated to 2, and the balance of user E is updated to 8. At the same time, user B sends the secret key to user A in a similar way. And complete the balance update in the payment channel [A, B]. Each transaction in the 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 returned to the payer.

[0060] The overall operation framework of this program is as follows Figure 2 As shown, in Figure 2 In the scheme, users A and B are users at both ends of the payment channel, one being the local end and the other being the counterparty end. When A is the local end, B is the counterparty end, and when B is the local end, A is the counterparty end. This scheme mainly includes two functional algorithms: 1) a balance update prediction algorithm, which is mainly used to predict and record the upcoming balance updates of corresponding users in the payment channel to help make transaction scheduling decisions; 2) a transaction scheduling algorithm (steps S3 to S7 correspond to the steps), which is mainly used to decide which transactions to execute and when.

[0061] The proposed method adopts a "single-user, single-channel" deployment approach. Specifically, each user establishes a module entity for the two functional algorithms described above for each payment channel requiring transaction scheduling. These two functional modules are bound to the corresponding user's transaction queue within the payment channel and utilize real-time access to the corresponding channel balance and transaction execution status within the payment channel to make transaction scheduling decisions. The following describes the specific implementation of this bidirectionally coupled transaction scheduling method, which includes the balance update prediction algorithm and the transaction scheduling algorithm.

[0062] refer to Figure 3 , Figure 3 A flowchart of a bidirectional coupling transaction scheduling method for payment channels is shown. Figure 1 As shown, the method S includes steps S1 to S7, which are executed at the local end.

[0063] In step S1, a message is received. If the message is a transaction key, the process proceeds to step S2. If the message is a balance update, the process proceeds to step S3. If the message is a transaction message, the process proceeds to 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 balance update prediction value for the transaction corresponding to the current message. Then, the process 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 of the transaction corresponding to the current message, and then the process proceeds to step S4;

[0066] like Figure 4 As shown, in step S2 and step S3, the method of using the balance update prediction algorithm to calculate the estimated balance update completion time and the balance update prediction value of the transaction corresponding to the current message includes:

[0067] S21. Initialize the transaction dictionary that is about to be completed by the other party Is empty, where the ID in the dictionary structure r is the transaction ID of transaction r, The estimated balance update completion time of transaction r;

[0068] S22, initialize the balance update prediction value dictionary U = {t u :θ} is empty, where t in the dictionary structure u is the estimated balance update completion time, θ is t u The balance update prediction value corresponding to the moment;

[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] The round trip time of the current payment channel;

[0070] S24. Add the transaction r corresponding to the message to the transaction dictionary to be completed by the other party. According to the transaction value θ r renew Balance update prediction value U[O[ID r ]]=U[O[ID r ]]+θ r ;

[0071] S25. When the message is a balance update, delete the transaction corresponding to the message r ′ 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 on the other side ′ .

[0072] In step S4, update the transaction queue as a transaction set After that, this 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 .

[0073] 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.

[0074] In step S5, based on the transaction execution status of the previous scheduling interval, Select multiple transactions with a total value not exceeding the current available balance b on this side t Transactions and stored in the transaction collection

[0075] like Figure 5 As shown, in one embodiment of the present invention, step S5 further includes:

[0076] S51: Determine whether a transaction was executed in the previous scheduling interval. If so, proceed to step S52; otherwise, proceed to step S53.

[0077] 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;

[0078] 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.

[0079] In step S6, according to 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.

[0080] like Figure 5 As shown, in one embodiment of the present invention, step S6 further includes:

[0081] S61. Calculate the remaining transaction set

[0082] 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;

[0083] S63, calculation Current available balance in b t Unsatisfiable transaction subset

[0084] 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;

[0085] S65. Calculate the profit that can be obtained by executing transactions during the current scheduling interval until the next balance update:

[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 estimated balance update completion times of multiple transactions recorded currently;

[0088] S66. Calculate the benefit 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 transaction execution set and execute the transactions in in sequence. When g1 < g2, update In both cases above, return to step S1 until no more messages are received.

[0090] When the two-way coupled transaction scheduling method is executed, when receiving the balance update or transaction message 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, enter the first prediction value update module. When the message is a balance update, enter the second prediction value update module. When the message is a transaction message, enter the queue update and data collection module;

[0093] A first balance update module, configured to send the transaction key to the peer end, and calculate the estimated balance update completion time and balance update prediction 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 prediction value at the estimated balance update completion time 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 transaction set After that, 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 prediction values corresponding to multiple transactions at the current moment u ;

[0096] A transaction set generation module, which is used to select multiple transactions with a total transaction value not exceeding the current available balance b at this end from the transaction set according to the transaction execution situation in the previous scheduling interval and store them in the transaction set t where the total transaction value does not exceed the current available balance b at this end

[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 balance is updated next time, 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 it when g1≥g2, and update when g1<g2. In both cases above, it returns 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. 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] Figure 6 As 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 Figure 6 shows the transaction situations successfully executed by different transaction scheduling algorithms under different workloads. Among them, the initial balance of the payment channel, the transaction arrival pattern, and the transaction value size are the same as the corresponding experimental conditions. The workload value represents the average arrival rate of transactions on both sides of the payment channel. In the comparison algorithms, Bishe-HG is the two-way coupling transaction scheduling method proposed in this solution, and PDME, PRI-IP, Spider, and LND are scheduling methods in the existing technologies, which are introduced as follows:

[0102] Spider introduced transaction queues within payment channels for the first time, and proposed a packet-switching architecture for transaction transmission. Each transaction is pre-split into a set of very small transaction units before transmission. These units are then sent at a specific rate, with each unit independently transmitted and confirmed. During the transmission process, each unit is marked according to its queue status. The sender then adjusts the rate of each unit's transmission based on this marking, similar to a congestion control protocol. This allows for optimal utilization of funds within the payment channel while minimizing network congestion.

[0103] PRI processes transactions in the queue using a periodic scanning method. Whenever a new transaction arrives, PRI can choose to add only transactions with insufficient balances to the queue or add all transactions directly to the queue. The queue is then scanned at regular intervals, scanning the transactions in the queue one by one. If the balance meets the requirement, the transaction is executed; if the balance is insufficient, the transaction remains in the queue.

[0104] PDME sets a time limit for each transaction, requiring the transaction to wait in the queue before the time limit expires. When a transaction exceeds the time limit, PDME determines whether the current available balance is sufficient to execute the transaction. If the balance is insufficient, PDME scans the other party's transaction queue to see if there are any executable transactions that can bring sufficient balance to this side. If so, PDME immediately executes the transaction in the other party's queue before executing the transaction itself. Otherwise, the transaction is discarded.

[0105] LND is the transaction processing method adopted by existing payment channels, that is, all transactions are not placed in the transaction queue and are executed on a "first-come, first-served" basis.

[0106] like Figure 7 From the comparison data in (a) and (b), it can be seen that the bidirectional coupling transaction scheduling algorithm proposed in this scheme has obvious advantages in the number of successfully executed transactions; in terms of the amount of successfully executed transactions, the bidirectional coupling transaction scheduling method proposed in this scheme has obvious advantages over other transaction scheduling algorithms that retain transaction atomicity, and has achieved a successful transaction amount that 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: Including steps: S1. Receive a message. If the message is a transaction key, proceed to step S2. If the message is a balance update, proceed to step S3. If 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 for the transaction corresponding to the current message. Then, return to step S1 until no more messages are received. 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 proceed to step S4; S4. Update the transaction queue as a transaction set After that, this 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 value not exceeding the current available balance b on this side t Transactions and stored 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 above, 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 by the other party Is empty, where the ID in the dictionary structure 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 in the dictionary structure 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 to be completed by the other party. According to the transaction value θ r renew The balance update prediction value 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 party.

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 a 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 by executing transactions during 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 a transaction when the balance is updated next time without executing the transaction within 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 confirmation module is used to receive messages. 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. 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 a 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, this end obtains the current available balance b t The balance update prediction value θ corresponding to the minimum time among the estimated balance update completion times corresponding to multiple transactions currently recorded u ; The transaction set generation module is used to generate a transaction set based on the transaction execution status of the previous scheduling interval. Select multiple transactions with a total value not exceeding the current available balance b on this side t Transactions and stored in the transaction collection The income calculation module is used to calculate the income of 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; Transaction update and execution module, used to update and execute the transaction set when g1 ≥ g2 and execute them in sequence the transactions in, when g1 < g2, update In both of the above cases, return to the message determination module until no more messages are received.

Images