CN113011878A - Encrypted currency multichannel payment method based on intelligent contract - Google Patents
Encrypted currency multichannel payment method based on intelligent contract Download PDFInfo
- Publication number
- CN113011878A CN113011878A CN202110282292.2A CN202110282292A CN113011878A CN 113011878 A CN113011878 A CN 113011878A CN 202110282292 A CN202110282292 A CN 202110282292A CN 113011878 A CN113011878 A CN 113011878A
- Authority
- CN
- China
- Prior art keywords
- transaction
- path
- channel
- sender
- 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.)
- Granted
Links
Images
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
Abstract
The invention discloses a cryptocurrency multi-channel payment method based on an intelligent contract, which comprises the steps of establishing a topological graph of a payment channel network; maintaining and tracking the size of the path and the path window; 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 processing unit; forwarding incoming transactions and confirmations and reducing or increasing channel balances; funds consumed by transactions in the channel are suspended and unavailable until confirmation is received; the receiver generates confirmation information after receiving the transaction and sends the confirmation information to the sender; judging whether the transaction is overtime and processing; and repeating the steps to carry out continuous transaction. The invention realizes that the transaction units are sent at different rates across different paths, and realizes high-throughput payment; the method ensures the balanced use of channels and the fairness of cross-flow, simultaneously maximizes the throughput, and safely and efficiently carries out the transaction of the encryption currency.
Description
Technical Field
The invention particularly relates to an encryption currency multi-channel payment method based on an intelligent contract.
Background
Today, cryptocurrency has been widely adopted, but the scalability of cryptocurrency is still poor. For example, a bitcoin network can handle 7 transactions per second, and an ethernet house can handle 15 transactions per second, which is a big gap from the VISA network that can achieve 1700 transactions per second, and therefore, the throughput required by the market for the crypto currency is far from sufficient. In the research for improving the scalability of cryptocurrency, the researchers have proposed a solution to the payment channel. A payment channel is a cryptocurrency transaction that is a currency hosted or dedicated on a blockchain to be converted with a pre-designated user for a predetermined duration. The payment channel network can enable fast, secure transactions without requiring consensus on the blockchain for each transaction, and many blockchains desire the payment channel network to be able to extend throughput without changing the underlying consensus protocol.
It is now common to extend payment channel networks, such as by means of lightning networks. However, completing payment for a payment channel network is challenging: for example, payment must be made with sufficient funds. As payments flow through a single channel in the same direction, the channel will eventually run out and no further payments in that direction can be supported; thus, routing schemes like shortest path routing exhaust critical payment channels and paralyze the system. The prior art also has the following disadvantages: (1) it is prone to failure when handling large transactions. (2) The payment channel is unbalanced. Payment must be made with sufficient funds. As payments flow through a single channel in the same direction, the channel will eventually exhaust and no further payments in that direction can be supported. (3) Deadlock is easily generated.
Therefore, at present, no cryptocurrency multi-channel payment expansion technology for effectively improving the throughput of the payment channel network exists.
Disclosure of Invention
The invention aims to provide a cryptocurrency multi-channel payment method based on an intelligent contract, which can solve the problems that a payment channel is easy to fail in processing larger transactions and the throughput is reduced due to unbalance of the payment channel.
The invention provides a cryptocurrency multi-channel payment method based on an intelligent contract, which comprises the following steps:
s1, establishing a topological graph of a payment channel network;
s2, maintaining the path and the size of each path window, processing the transaction units, and tracking the transaction units which are sent on each path but are not confirmed or cancelled;
s3, a sender sends 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 of the step S4 does not have enough balance, placing the transaction units in each channel queue of the sender providing service according to the order of first-in and last-out; marking the queuing delay of the transaction unit as being higher than a set threshold value, transmitting the mark to a sender by a receiver, and adjusting the size of a window by the sender;
s6, when the queue is full, discarding the incoming transaction and sending a failure message to the sender;
s7, if the payment channel of the step S4 has enough balance, the sender divides the transaction unit into a plurality of transaction units, and each transaction unit sends and transacts 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 processing unit;
s9, forwarding the incoming transaction and confirmation along a specified payment channel in the path of the transaction processing unit, and simultaneously correspondingly reducing or increasing the balance of the channel;
s10, funds consumed by the transaction in the channel are suspended and unavailable until confirmation is received;
s11, after receiving the transaction, the receiver generates a piece of confirmation information, and the confirmation information is sent to the sender along a reverse path, so that the transaction is successful;
s12, judging whether the transaction is overtime: if the transaction is not overtime, a normal transaction flow is carried out; if the transaction process is overtime and the transmission layer fails to complete payment within the deadline, the sender sends a cancellation message and deletes the transaction processing units queued on the transaction units on each path to the receiver; the sender adjusts the window size and retries the failed transaction part again;
s13, repeating the steps S2-S12 to carry out continuous trading.
Step S2 adopts multi-path transmission protocol, which divides the transaction into several transaction units, each transaction is sent to the receiving end at different speed across different paths in the transaction channel network; the path selection in the multi-path transmission protocol adopts an edge-disjoint widest path algorithm, and the edge-disjoint widest path algorithm is specifically to find a pair of disjoint paths between a sending-receiving node pair, so that the combined bandwidth of the path pair is the maximum bandwidth of all the node pairs.
Step S2 adopts multi-path congestion control algorithm, which is concretely, the sender maintains the window size W for each path reaching the receiverp(ii) a The window size represents the maximum number of transaction units that have not been executed at any point in time on path p; the multi-path congestion control algorithm is used for adjusting the size of a window on each path and the number of unfinished transaction units, specifically, 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 succeeds, the size of the path window of the sender is increased.
The size W of the path windowpThe sender monitors and calculates each path in real time; route of travelThe window size is defined as:
Wp＝Wp- β, when the transaction unit is marked;
wherein, Wpβ is a constant, a decreasing weight for the window size, and a is a constant, an 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 using an onion encryption technology, wherein the onion encryption technology is used for anonymous communication in a network; onion encryption is specifically that a transaction is encrypted in multiple layers and then transmitted on a designated path, wherein an intermediate path cannot detect the whole transmission path.
The cryptocurrency multi-channel payment method based on the intelligent contract adopts a multi-path transmission protocol and a multi-path congestion control algorithm, and can realize that transaction units are sent at different rates across different paths so as to realize high-throughput payment; the method ensures the balanced use of channels and the fairness of cross-flow, simultaneously maximizes the throughput, and safely and efficiently carries out the transaction of the encryption currency.
Drawings
FIG. 1 is a schematic flow diagram of the process of the present invention.
Detailed Description
FIG. 1 is a schematic flow chart of the method of the present invention: the invention provides a cryptocurrency multi-channel payment method based on an intelligent contract, which comprises the following steps:
s1, establishing a topological graph of a payment channel network;
s2, maintaining the path and the size of each path window, processing the transaction units, and tracking the transaction units which are sent on each path but are not confirmed or cancelled;
in specific implementation, the multi-path transmission protocol specifically divides transactions into a plurality of transaction units, and each transaction is sent to a receiving end at different rates across different paths in a transaction channel network; the path selection in the multi-path transmission protocol adopts an edge-disjoint widest path algorithm, and the edge-disjoint widest path algorithm is specifically to find a pair of disjoint paths 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 multi-path congestion control algorithm is specifically that the sender maintains the window size W of each path reaching the receiverp(ii) a The window size represents the maximum number of transaction units that have not been executed at any point in time on path p; the multi-path congestion control algorithm is used for adjusting the size of a window on each path and the number of unfinished transaction units, specifically, 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 succeeds, the size of the path window of the sender is increased; path Window size WpThe sender monitors and calculates each path in real time; the path window size is defined as:
Wp＝Wp- β, when the transaction unit is marked;
wherein, WpIs the size of a path window on a path p between a sender i and a receiver j, beta is a constant, a decreasing weight for the window size, a is a constant, an increasing weight for the window size
S3, a sender sends 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 of the step S4 does not have enough balance, placing the transaction units in each channel queue of the sender providing service according to the order of first-in and last-out; marking the queuing delay of the transaction unit as being higher than a set threshold value, transmitting the mark to a sender by a receiver, and adjusting the size of a window by the sender;
s6, when the queue is full, discarding the incoming transaction and sending a failure message to the sender;
s7, if the payment channel of the step S4 has enough balance, the sender divides the transaction unit into a plurality of transaction units, and each transaction unit sends and transacts 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 processing unit; writing the data into a transaction processing unit by adopting an onion encryption technology, wherein the onion encryption technology is used for anonymous communication in a network; the onion encryption specifically comprises the steps that after multi-layer encryption is carried out on a transaction, transmission is carried out on a designated path, wherein an intermediate path cannot detect the whole transmission path;
s9, forwarding the incoming transaction and confirmation along a specified payment channel in the path of the transaction processing unit, and simultaneously correspondingly reducing or increasing the balance of the channel;
s10, funds consumed by the transaction in the channel are suspended and unavailable until confirmation is received;
s11, after receiving the transaction, the receiver generates a piece of confirmation information, and the confirmation information is sent to the sender along a reverse path, so that the transaction is successful;
s12, judging whether the transaction is overtime: if the transaction is not overtime, a normal transaction flow is carried out; if the transaction process is overtime and the transmission layer fails to complete payment within the deadline, the sender sends a cancellation message and deletes the transaction processing units queued on the transaction units on each path to the receiver; the sender adjusts the window size and retries the failed transaction part again;
s13, repeating the steps S2-S12 to carry out continuous trading.
Claims (6)
1. A multi-channel payment method based on cryptocurrency of intelligent contracts comprises the following steps:
s1, establishing a topological graph of a payment channel network;
s2, maintaining the path and the size of each path window, processing the transaction units, and tracking the transaction units which are sent on each path but are not confirmed or cancelled;
s3, a sender sends 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 of the step S4 does not have enough balance, placing the transaction units in each channel queue of the sender providing service according to the order of first-in and last-out; marking the queuing delay of the transaction unit as being higher than a set threshold value, transmitting the mark to a sender by a receiver, and adjusting the size of a window by the sender;
s6, when the queue is full, discarding the incoming transaction and sending a failure message to the sender;
s7, if the payment channel of the step S4 has enough balance, the sender divides the transaction unit into a plurality of transaction units, and each transaction unit sends and transacts 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 processing unit;
s9, forwarding the incoming transaction and confirmation along a specified payment channel in the path of the transaction processing unit, and simultaneously correspondingly reducing or increasing the balance of the channel;
s10, funds consumed by the transaction in the channel are suspended and unavailable until confirmation is received;
s11, after receiving the transaction, the receiver generates a piece of confirmation information, and the confirmation information is sent to the sender along a reverse path, so that the transaction is successful;
s12, judging whether the transaction is overtime: if the transaction is not overtime, a normal transaction flow is carried out; if the transaction process is overtime and the transmission layer fails to complete payment within the deadline, the sender sends a cancellation message and deletes the transaction processing units queued on the transaction units on each path to the receiver; the sender adjusts the window size and retries the failed transaction part again;
s13, repeating the steps S2-S12 to carry out continuous trading.
2. The multi-channel cryptocurrency payment method according to claim 1, wherein step S2 employs a multi-path transmission protocol, the multi-path transmission protocol is embodied as dividing the transaction into a plurality of transaction units, each transaction is sent to the receiving end at different rates across different paths in the transaction channel network.
3. The multi-channel payment method for cryptocurrency based on smart contracts according to claim 2, wherein the multi-path transmission protocol is embodied to divide transactions into a plurality of transaction units, and each transaction is sent to the receiving end at different rates across different paths in the transaction channel network; the path selection in the multi-path transmission protocol adopts an edge-disjoint widest path algorithm, and the edge-disjoint widest path algorithm is specifically to find a pair of disjoint paths between a sending-receiving node pair, so that the combined bandwidth of the path pair is the maximum bandwidth of all the node pairs.
4. A cryptocurrency multi-channel payment method according to claim 3, wherein the step S2 employs a multi-path congestion control algorithm, specifically, the sender maintains a window size W for each path to the receiverp(ii) a The window size represents the maximum number of transaction units that have not been executed at any point in time on path p; the multi-path congestion control algorithm is used for adjusting the size of a window on each path and the number of unfinished transaction units, specifically, 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 succeeds, the size of the path window of the sender is increased.
5. A cryptocurrency multi-channel payment method based on smart contracts according to claim 4, characterized in that the path window size WpThe sender monitors and calculates each path in real time; the path window size is defined as:
Wp＝Wp-beta whenThe transaction unit is marked;
wherein, Wpβ is a constant, a decreasing weight for the window size, and a is a constant, an increasing weight for the window size.
6. The multi-channel payment method for cryptocurrency based on smart contracts according to any one of claims 1 to 5, wherein the writing of the cryptocurrency into the transaction processing unit in step S8 is specifically performed by using an onion encryption technology, and the onion encryption technology is used for anonymous communication in a network; onion encryption is specifically that a transaction is encrypted in multiple layers and then transmitted on a designated path, wherein an intermediate path cannot detect the whole transmission path.
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 true CN113011878A (en) | 2021-06-22 |
| CN113011878B 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 (4)
| 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 |
| US20200118093A1 (en) * | 2018-08-10 | 2020-04-16 | Hajoon Ko | System and method for arbitrating a blockchain transaction |
| CN112150144A (en) * | 2020-08-12 | 2020-12-29 | 江苏大学 | Block chain anonymous transaction method based on cross-node multi-hop payment |
-
2021
- 2021-03-16 CN CN202110282292.2A patent/CN113011878B/en active Active
Patent Citations (4)
| 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 |
| 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 因素认证的在线支付认证体系设计", 《计算机应用与软件》, vol. 35, no. 8, pages 329 - 333 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113011878B (en) | 2023-10-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Sivaraman et al. | High throughput cryptocurrency routing in payment channel networks | |
| CN111201757B (en) | Network access node virtual structure dynamically configured on underlying network | |
| US8155518B2 (en) | Dynamic load balancing of fibre channel traffic | |
| EP3468119B1 (en) | Method, apparatus and device for balancing load | |
| EP1810466B1 (en) | Directional and priority based flow control between nodes | |
| US6246684B1 (en) | Method and apparatus for re-ordering data packets in a network environment | |
| CN103493449B (en) | Efficient circuit in packet switching network | |
| US6072797A (en) | Methods, apparatus and computer program products for aggregated transmission groups in high speed networks | |
| US20030169688A1 (en) | System and method for dynamic rate flow control | |
| WO2006071492A2 (en) | In-order fibre channel packet delivery | |
| WO2018224942A1 (en) | Method and system for selectively using network coding for propagating transactions in a blockchain network | |
| US20240007404A1 (en) | Local and global quality of service shaper on ingress in a distributed system | |
| JP2004520725A (en) | Internet via satellite | |
| US9275415B2 (en) | System for latency reduction in high frequency trading networks | |
| KR101983088B1 (en) | Method for UDP Packet Processing in the Multi-path Environment | |
| JP2017092692A (en) | Data transmission control system and method, and data transmission control program | |
| CN113011878B (en) | Intelligent contract-based encrypted currency multichannel payment method | |
| US11108666B2 (en) | Latency prediction and network message microtiming | |
| US20060126520A1 (en) | Tape acceleration | |
| Lei et al. | Distributed information-agnostic flow scheduling in data centers based on wait-time | |
| Zhang et al. | Efficient data center flow scheduling without starvation using expansion ratio | |
| Wang et al. | DPCN: Towards Deadline-aware Payment Channel Networks | |
| Rezaei et al. | Resqueue: A smarter datacenter flow scheduler | |
| Nandhini et al. | Exploration and Evaluation of Congestion Control Algorithms for Data Center Networks | |
| Sivaraman | High-efficiency cryptocurrency routing in payment channel networks |
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 |