CN113011878B - Intelligent contract-based encrypted currency multichannel payment method - Google Patents
Intelligent contract-based encrypted currency multichannel payment method Download PDFInfo
- Publication number
- CN113011878B CN113011878B CN202110282292.2A CN202110282292A CN113011878B CN 113011878 B CN113011878 B CN 113011878B CN 202110282292 A CN202110282292 A CN 202110282292A CN 113011878 B CN113011878 B CN 113011878B
- Authority
- CN
- China
- Prior art keywords
- transaction
- path
- sender
- channel
- payment
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/407—Cancellation of a transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- General Business, Economics & Management (AREA)
- Finance (AREA)
- Theoretical Computer Science (AREA)
- Strategic Management (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Development Economics (AREA)
- Technology Law (AREA)
- Marketing (AREA)
- Economics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The invention discloses an intelligent contract-based encrypted currency multichannel payment method, which comprises the steps of establishing a topological graph of a payment channel network; maintaining the size of a path and a path window and tracking; the sender requests a transaction; judging whether the balance of the payment channel is enough and processing; the sender confirms the route of the transaction unit and writes the route into the transaction unit; forwarding incoming transactions and acknowledgements and reducing or increasing channel balances; funds consumed by transactions in the channel are suspended and not available until confirmation is received; after receiving the transaction, the receiver generates acknowledgement information and sends the acknowledgement information to the sender; judging whether the transaction is overtime and processing; repeating the steps to conduct continuous transaction. The invention realizes that transaction units are sent at different rates across different paths, and realizes high throughput payment; and the balanced use of channels and the fairness of the cross-process are ensured, the throughput is maximized, and the encrypted money transaction is safely and efficiently carried out.
Description
Technical Field
The invention particularly relates to an intelligent contract-based encrypted currency multi-channel payment method.
Background
Today, cryptocurrency has been widely used, but the scalability of cryptocurrency is still poor. For example, a bitcoin network can process 7 transactions per second, and an ethernet can process 15 transactions per second, which is far from being the case when a VISA network can achieve 1700 transactions per second, and thus the throughput required by the market is far from being adequate for cryptocurrency. In research to improve the scalability of cryptocurrency, scholars have proposed solutions for payment channels. The payment channel is a cryptocurrency transaction that is currency hosted on a blockchain or dedicated to exchange with a pre-designated user for a predetermined duration. The payment channel network can enable fast, secure transactions without requiring agreement on the blockchain for each transaction, and many blockchains want the payment channel network to be able to extend throughput without changing the underlying consensus protocol.
The payment channel network is now typically expanded in a manner such as a lightning network. However, completing payment for a payment channel network is challenging: for example, payment must be made with sufficient funds. As payment flows through a single channel in the same direction, the channel eventually becomes depleted, failing to support further payment in that direction; thus, routing schemes such as shortest path routing can deplete critical payment channels and paralyze the system. The prior art has the following defects: (1) is susceptible to failure when handling large transactions. (2) payment channel imbalance. Payment must be made with sufficient funds. As payment flows through a single channel in the same direction, the channel eventually becomes depleted, failing to support further payment in that direction. (3) deadlock is easily generated.
Therefore, no encryption currency multi-channel payment expansion technology for effectively improving the throughput of a payment channel network exists at present.
Disclosure of Invention
The invention aims to provide an intelligent contract-based encrypted currency multi-channel payment method, which can solve the problems that a payment channel is easy to fail to process a large transaction and throughput is reduced due to unbalanced payment channels.
The invention provides an intelligent contract-based encrypted currency multichannel payment method, which comprises the following steps:
s1, establishing a topological graph of a payment channel network;
s2, maintaining paths and the window size of each path, wherein the paths are used for processing transaction units and tracking the transaction units which are sent on each path but are not confirmed or cancelled;
s3, the sender sends out a transaction request through a transmission layer interface of the payment channel network;
s4, judging whether the payment channel has enough balance;
s5, if the payment channel in the step S4 has insufficient balance, placing the transaction unit in each channel queue of the sender providing services according to the order of first in and last out; marking the queuing delay of the transaction unit as higher than a set threshold, transmitting the mark to a sender by a receiver, and adjusting the window size by the sender;
s6, when the queuing queue is full, discarding the incoming transaction, and sending a failure message to the sender;
s7, if the payment channel in the step S4 has enough balance, dividing the transaction unit into a plurality of transaction units by a sender, and sending and transacting the transaction units through a multi-path transmission protocol;
s8, before sending the transaction unit, the sender firstly confirms the route of the transaction unit and writes the route into the transaction unit;
s9, forwarding the transmitted transaction and confirmation along a payment channel appointed in the transaction processing unit path, and correspondingly reducing or increasing the balance of the channel;
s10, funds consumed by transactions in the channel are suspended and unavailable until confirmation is received;
s11, after receiving the transaction, the receiver generates a piece of confirmation information, the confirmation information is sent to the sender along a reverse path, and the transaction is successful;
s12, judging whether the transaction is overtime: if the transaction is not overtime, carrying out a normal transaction flow; if the transaction process is overtime, the transmission layer fails to complete payment within the deadline, the sender sends a cancellation message, and the transaction processing units queued on the transaction units on each path to the receiver are deleted; the sender adjusts the window size and retries the failed transaction part again;
s13, repeating the steps S2 to S12, and carrying out continuous transaction.
Step S2, adopting a multi-path transmission protocol, wherein the multi-path transmission protocol is characterized in that transactions are divided into a plurality of transaction units, and each transaction is respectively transmitted to a receiving end in a transaction channel network at different speeds by crossing different paths; the path selection in the multipath transmission protocol adopts a side-disjoint widest path algorithm, and the side-disjoint widest path algorithm is specifically to find a pair of disjoint paths between the sending-receiving node pairs, so that the combined bandwidth of the path pairs is the maximum bandwidth of all the node pairs.
Step S2 adopts a multipath congestion control algorithm, wherein the multipath congestion control algorithm is specifically that a sender maintains a window size W for each path reaching a receiver p The method comprises the steps of carrying out a first treatment on the surface of the The window size represents the maximum number of transactional units that are not performed at any point in time on path p; the multi-path congestion control algorithm is used for adjusting the window size and the number of unfinished transaction units on each path, particularly when congestion occurs and transmission fails, the transaction units are marked, the path window size of a sender is reduced, and after one-time transmission is successful, the path window size of the sender is increased.
The path window size W p Each path is monitored in real time and calculated by a sender; the path window size is defined as:
W p ＝W p - β, when the transaction unit is marked;
when the transaction unit is not marked;
wherein W is p For the size of the path window on path p between sender i and receiver j, β is a constant, a decreasing weight for the window size, and a is a constant, increasing weight for the window size.
Writing the data into the transaction processing unit in the step S8, specifically writing the data into the transaction processing unit by adopting an onion encryption technology, wherein the onion encryption technology is used for carrying out anonymous communication in a network; the onion encryption specifically means that the transaction is transmitted on a designated path after being subjected to multi-layer encryption, wherein an intermediate path cannot detect the whole transmission path.
The intelligent contract-based encryption currency multichannel payment method provided by the invention adopts a multipath transmission protocol and a multipath congestion control algorithm, and can realize that transaction units are sent at different speeds across different paths so as to realize high-throughput payment; and the balanced use of channels and the fairness of the cross-process are ensured, the throughput is maximized, and the encrypted money transaction is safely and efficiently carried out.
Drawings
FIG. 1 is a schematic flow chart of the method of the present invention.
Detailed Description
FIG. 1 is a schematic flow chart of the method of the present invention: the invention provides an intelligent contract-based encrypted currency multichannel payment method, which comprises the following steps:
s1, establishing a topological graph of a payment channel network;
s2, maintaining paths and the window size of each path, wherein the paths are used for processing transaction units and tracking the transaction units which are sent on each path but are not confirmed or cancelled;
in the implementation, the multi-path transmission protocol is specifically that a transaction is divided into a plurality of transaction units, and each transaction is respectively transmitted to a receiving end in a transaction channel network at different speeds by crossing different paths; the path selection in the multipath transmission protocol adopts a side-disjoint widest path algorithm, and the side-disjoint widest path algorithm is specifically to find a pair of disjoint paths between the sending-receiving node pairs, so that the combined bandwidth of the path pairs is the maximum bandwidth of all the node pairs.
The multipath congestion control algorithm is specifically that the sender maintains a window size W for each path arriving at the receiver p The method comprises the steps of carrying out a first treatment on the surface of the The window size represents the maximum number of transactional units that are not performed at any point in time on path p; the multi-path congestion control algorithm is used for adjusting the window size and the number of unfinished transaction units on each path, particularly when congestion occurs and transmission fails, the transaction units are marked, the window size of the path of a sender is reduced, and after one-time transmission is successful, the sender sendsThe path window size of the square increases; path Window size W p Each path is monitored in real time and calculated by a sender; the path window size is defined as:
W p ＝W p - β, when the transaction unit is marked;
when the transaction unit is not marked;
wherein W is p For the size of the path window on path p between sender i and receiver j, β is a constant, a is a decreasing weight of the window size, a is a constant, an increasing weight of the window size
S3, the sender sends out a transaction request through a transmission layer interface of the payment channel network;
s4, judging whether the payment channel has enough balance;
s5, if the payment channel in the step S4 has insufficient balance, placing the transaction unit in each channel queue of the sender providing services according to the order of first in and last out; marking the queuing delay of the transaction unit as higher than a set threshold, transmitting the mark to a sender by a receiver, and adjusting the window size by the sender;
s6, when the queuing queue is full, discarding the incoming transaction, and sending a failure message to the sender;
s7, if the payment channel in the step S4 has enough balance, dividing the transaction unit into a plurality of transaction units by a sender, and sending and transacting the transaction units through a multi-path transmission protocol;
s8, before sending the transaction unit, the sender firstly confirms the route of the transaction unit and writes the route into the transaction unit; writing the onion encryption technology into a transaction processing unit, wherein the onion encryption technology is used for carrying out anonymous communication in a network; the onion encryption specifically means that the transaction is transmitted on a designated path after being subjected to multi-layer encryption, wherein an intermediate path cannot detect the whole transmission path;
s9, forwarding the transmitted transaction and confirmation along a payment channel appointed in the transaction processing unit path, and correspondingly reducing or increasing the balance of the channel;
s10, funds consumed by transactions in the channel are suspended and unavailable until confirmation is received;
s11, after receiving the transaction, the receiver generates a piece of confirmation information, the confirmation information is sent to the sender along a reverse path, and the transaction is successful;
s12, judging whether the transaction is overtime: if the transaction is not overtime, carrying out a normal transaction flow; if the transaction process is overtime, the transmission layer fails to complete payment within the deadline, the sender sends a cancellation message, and the transaction processing units queued on the transaction units on each path to the receiver are deleted; the sender adjusts the window size and retries the failed transaction part again;
s13, repeating the steps S2 to S12, and carrying out continuous transaction.
Claims (1)
1. An intelligent contract-based encrypted currency multi-channel payment method comprises the following steps:
s1, establishing a topological graph of a payment channel network;
s2, maintaining paths and the window size of each path, wherein the paths are used for processing transaction units and tracking the transaction units which are sent on each path but are not confirmed or cancelled;
in the implementation, the multi-path transmission protocol is specifically that a transaction is divided into a plurality of transaction units, and each transaction is respectively transmitted to a receiving end in a transaction channel network at different speeds by crossing different paths; in the multipath transmission protocol, the path selection adopts a side disjoint widest path algorithm, wherein the side disjoint widest path algorithm is specifically that a pair of disjoint paths is found between a sending-receiving node pair, so that the combined bandwidth of the path pair is the maximum bandwidth of all the node pairs;
the multipath congestion control algorithm is specifically that the sender maintains a window size W for each path arriving at the receiver p The method comprises the steps of carrying out a first treatment on the surface of the The window size represents the maximum number of transactional units that are not performed at any point in time on path p; multipath congestion control algorithm for adjusting window size and non-window size on each pathThe number of transaction units completed, particularly when congestion occurs and transmission fails, the transaction units are marked, the size of a path window of a sender is reduced, and after one-time transmission is successful, the size of the path window of the sender is increased; the path window size W p Each path is monitored in real time and calculated by a sender; the path window size is defined as:
W p ＝W p - β, when the transaction unit is marked;
when the transaction unit is not marked;
wherein W is p The size of the path window on the path p between sender i and receiver j; beta is a constant, beta is a decreasing weight of the window size; a is a constant, a is an increasing weight of the window size;
s3, the sender sends out a transaction request through a transmission layer interface of the payment channel network;
s4, judging whether the payment channel has enough balance;
s5, if the payment channel in the step S4 has insufficient balance, placing the transaction unit in each channel queue of the sender providing services according to the order of first in and last out; marking the queuing delay of the transaction unit as higher than a set threshold, transmitting the mark to a sender by a receiver, and adjusting the window size by the sender;
s6, when the queuing queue is full, discarding the incoming transaction, and sending a failure message to the sender;
s7, if the payment channel in the step S4 has enough balance, dividing the transaction unit into a plurality of transaction units by a sender, and sending and transacting the transaction units through a multi-path transmission protocol;
s8, before sending the transaction unit, the sender firstly confirms the route of the transaction unit and writes the route into the transaction unit; the writing of the onion encryption technology into the transaction processing unit is particularly realized by adopting the onion encryption technology, and the onion encryption technology is used for anonymous communication in a network; the onion encryption specifically means that the transaction is transmitted on a designated path after being subjected to multi-layer encryption, wherein an intermediate path cannot detect the whole transmission path;
s9, forwarding the transmitted transaction and confirmation along a payment channel appointed in the transaction processing unit path, and correspondingly reducing or increasing the balance of the channel;
s10, funds consumed by transactions in the channel are suspended and unavailable until confirmation is received;
s11, after receiving the transaction, the receiver generates a piece of confirmation information, the confirmation information is sent to the sender along a reverse path, and the transaction is successful;
s12, judging whether the transaction is overtime: if the transaction is not overtime, carrying out a normal transaction flow; if the transaction process is overtime, the transmission layer fails to complete payment within the deadline, the sender sends a cancellation message, and the transaction processing units queued on the transaction units on each path to the receiver are deleted; the sender adjusts the window size and retries the failed transaction part again;
s13, repeating the steps S2 to S12, and carrying out continuous transaction.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110282292.2A CN113011878B (en) | 2021-03-16 | 2021-03-16 | Intelligent contract-based encrypted currency multichannel payment method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110282292.2A CN113011878B (en) | 2021-03-16 | 2021-03-16 | Intelligent contract-based encrypted currency multichannel payment method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113011878A CN113011878A (en) | 2021-06-22 |
| CN113011878B true CN113011878B (en) | 2023-10-20 |
Family
ID=76408568
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110282292.2A Active CN113011878B (en) | 2021-03-16 | 2021-03-16 | Intelligent contract-based encrypted currency multichannel payment method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113011878B (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110662256A (en) * | 2019-09-18 | 2020-01-07 | 北京交通大学 | Multi-path cross-protocol transmission data packet scheduling method and system |
| WO2020045797A1 (en) * | 2018-08-31 | 2020-03-05 | 연세대학교 산학협력단 | Device and method for controlling congestion window for multipath transmission control protocol |
| CN112150144A (en) * | 2020-08-12 | 2020-12-29 | 江苏大学 | Block chain anonymous transaction method based on cross-node multi-hop payment |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20200118093A1 (en) * | 2018-08-10 | 2020-04-16 | Hajoon Ko | System and method for arbitrating a blockchain transaction |
-
2021
- 2021-03-16 CN CN202110282292.2A patent/CN113011878B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2020045797A1 (en) * | 2018-08-31 | 2020-03-05 | 연세대학교 산학협력단 | Device and method for controlling congestion window for multipath transmission control protocol |
| CN110662256A (en) * | 2019-09-18 | 2020-01-07 | 北京交通大学 | Multi-path cross-protocol transmission data packet scheduling method and system |
| CN112150144A (en) * | 2020-08-12 | 2020-12-29 | 江苏大学 | Block chain anonymous transaction method based on cross-node multi-hop payment |
Non-Patent Citations (1)
| Title |
|---|
| 基于自适应n 因素认证的在线支付认证体系设计;车力军等;《计算机应用与软件》;第35卷(第8期);第329-333页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113011878A (en) | 2021-06-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6072797A (en) | Methods, apparatus and computer program products for aggregated transmission groups in high speed networks | |
| US9894005B2 (en) | Adaptive routing controlled by source node | |
| US8149704B2 (en) | Communication apparatus and data communication method | |
| US7457245B2 (en) | Directional and priority based flow control mechanism between nodes | |
| Barré et al. | Multipath TCP: from theory to practice | |
| US6246684B1 (en) | Method and apparatus for re-ordering data packets in a network environment | |
| EP0829986B1 (en) | System for improving data throughput of a TCP/IP Network connection with slow return channel | |
| US4951278A (en) | High-level data link control packet assembler/disassembler | |
| EP1832052B1 (en) | In-order fibre channel packet delivery | |
| US9497135B2 (en) | Method and system for reduction of time variance of packets received from bonded communication links | |
| EP3468119A1 (en) | Method, apparatus and device for balancing load | |
| CN103493449B (en) | Efficient circuit in packet switching network | |
| JP2004520725A (en) | Internet via satellite | |
| US8838782B2 (en) | Network protocol processing system and network protocol processing method | |
| Xia et al. | Analysis on packet resequencing for reliable network protocols | |
| CN113011878B (en) | Intelligent contract-based encrypted currency multichannel payment method | |
| CN102594665B (en) | Service data transmission method and device | |
| JP2017092692A (en) | Data transmission control system and method, and data transmission control program | |
| Ruan et al. | PTCP: A priority-based transport control protocol for timeout mitigation in commodity data center | |
| US20230261973A1 (en) | Method for distributing multipath flows in a direct interconnect network | |
| CN114826496A (en) | Out-of-order packet processing | |
| Ruan et al. | Polo: Receiver-driven congestion control for low latency over commodity network fabric | |
| US20060126520A1 (en) | Tape acceleration | |
| JP5761193B2 (en) | Communication apparatus, communication system, packet retransmission control method, and packet retransmission control program | |
| US11622004B1 (en) | Transaction-based reliable transport |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |