A Blockchain-Based Method for Optimizing the Routing of High-Frequency Carbon-Trading Payment Channels

Abstract

Carbon trading is an effective way to achieve carbon neutrality. It is a market mechanism aimed at reducing global greenhouse gas emissions and carbon dioxide emissions. Blockchain technology can be applied to the carbon-trading scenario using characteristics that guarantee the security, decentralization, data immutability, and data traceability of the carbon-trading process. It would be difficult to implement carbon trading on blockchains for all enterprises and individuals, as the current performance of blockchains does not meet the requirements. There has been extensive research conducted on blockchain performance optimization, and the off-chain payment channel is one of the more mature solutions. This approach involves the transfer of transactions to off-chain transactions, thus avoiding high transaction fees. Existing research has addressed the problem of routing security and efficiency, with less emphasis on factors such as routing transaction costs, node reputation, and routing path considerations. This paper researches the optimization of payment routing in Payment Channel Networks (PCNs) and proposes the Multi-Factor Routing Payment Scheme (MFPS), which integrates factors such as the node reputation, transaction fee cost, and distance to select the route for payment transactions. In order to improve the success ratio of routing transactions, the transaction-splitting algorithm is proposed. To ensure the security and privacy of the transaction process, the Asymmetric Time-Lock Contract (ATLC) protocol is proposed. The results of extensive experimental simulations show that the MFPS proposed in this paper outperforms the ShortestPath, Cheapest, and SplitDistance algorithms. It achieves an approximately 13.8%∼49% improvement in the transaction success ratio and reduces the average transaction processing cost. The security and privacy measures can defend against wormhole and double-flower attacks and exhibit better performance in terms of computational verification and message overhead.

1. Introduction

Carbon trading refers to the trading of greenhouse gas emission rights and is a market mechanism aimed at reducing global greenhouse gas emissions and carbon dioxide emissions [1]. In December 1997, the governments of the United Nations adopted the Kyoto Protocol, which introduced a market mechanism for carbon dioxide emission rights. These emission rights are treated as a commodity that can be traded, which is referred to as carbon trading [2]. When the Kyoto Protocol came into effect in 2005, the carbon emissions trading market reached $10.9 billion and grew at an annual rate of 108%, reaching approximately $669 billion in 2013 [3]. As the scale of carbon trading increased, so did the need for a platform that was stable, secure, and decentralized, with tamper-proof data and traceable transaction information, to support companies and individuals involved in carbon trading. The features of the blockchain platform can be applied to the carbon-trading scenario.

In 2008, Satoshi Nakamoto published the white paper “Bitcoin: A Peer-to-Peer Electronic Cash System” [4], Bitcoin was born, and blockchain technology entered the public domain and began to develop rapidly. Blockchains are decentralized through P2P networks, consensus mechanisms, and cryptography to ensure the security and consistency of user nodes [5]. At present, blockchains have a wide range of applications in government, finance, the Internet of Things, healthcare, energy, and electricity [6]. In addition, blockchains in carbon-trading applications have also been studied in recent years [7,8].

Due to the technical characteristics of blockchains [9], they can be applied in many industries but public blockchains have certain security problems [10]. Blockchains can be either public blockchains or permissioned blockchains. The biggest difference between them is that permissioned blockchains can only be accessed by users with the correct permissions [11], making them more secure than public blockchains. Permissioned blockchains are represented by Hyperledger Fabric [12]. Although permissioned blockchains have improved security, their poor scalability remains a challenge. When faced with a large number of users conducting transactions concurrently, current blockchains cannot support faster execution.

Bitcoin and Ethereum are digital cryptocurrencies represented using blockchain technology. Bitcoin’s Transactions Per Second (TPS) is only 7, and Ether’s TPS is in the range of 30 to 40 [13]. Clearly, Bitcoin and Ethereum are no longer sufficient for the current digital payment scenario, and it is now difficult to support the current scale of corporate and personal carbon trading. With the explosive growth in the number of blockchain users, the scalability issue has become a significant challenge, limiting the development of blockchains. The transaction process in blockchains involves broadcasting, verification, and a large number of calculations to achieve consensus confirmation, making it less scalable [14]. In addition, the fee for Bitcoin on-chain transactions is determined by the size of the transaction data in the Unspent Transaction Output (UTXO), the number of transactions, and other factors, independent of the transaction amount [15]. Users need to pay substantial fees for each transaction, making these systems unsuitable for high-frequency, small-scale personal carbon-trading applications. In order to solve the scalability problem of blockchains, many solutions have been proposed in the literature [16,17]. Solutions that have been proposed to improve the performance of blockchains include the sharding mechanism [18], directed acyclic graph (DAG)-based blockchains [19], off-chain payment channel networks [20,21], and cross-chain technology [22]. The off-chain payment channel network allows for the transfer of small, high-frequency, and time-consuming on-chain transactions to off-chain channels, enabling fast, low-fee transactions.

Payment channels refer to technologies such as the Bitcoin-based Lightning Network [20] and Ethereum-based Thunderbolt Network technologies [21]. Transferring on-chain transactions to off-chain transactions is the key idea of payment channels. In terms of applied carbon trading, this concept can provide a fast and low-cost off-chain payment channel for small-scale carbon transactions between individuals. In addition, larger transactions involving corporate carbon-trading quotas can be conducted on the blockchain, effectively reducing the burden on the blockchain and increasing transaction throughput, as well as reducing processing fees for small-scale transactions. Payment channels between users form a network of payment channels.

Current research on routing algorithms for payment channel networks focuses on improving privacy and security during transactions and optimizing routing and scheduling problems to improve transaction efficiency and success rates. However, there is a lack of analysis regarding transaction fees in transaction routing. In a small-scale transaction scenario, the more relay nodes that are involved, the higher the fees charged, which can be a significant expense for the user. At the same time, node transactions can cause an imbalance between the two ends of the channel among certain nodes. This imbalance can cause channel blocking and an imbalance of funds, impacting the path selection for certain transaction amounts, which can degrade performance and decrease transaction success rates.

In order to address the above problems, this paper focuses on the following:

• The Multi-Factor Routing Payment Scheme (MFPS)-based algorithm is proposed. The path selection takes into account the transaction fees, node reputation, and distance to select the optimal path for the transaction. In order to reduce channel congestion and avoid the problem of channel capacity imbalances, the channel balance is adjusted by applying different charging percentages based on the channel balance difference. In order to improve the transaction success ratio, when there is no path in the payment channel network to fulfill the amount required for the transaction, the transaction amount is split according to the largest channel balance, employing a greedy transaction splitting approach to minimize the number of splits.
• The Asymmetric Encryption-Based Time-Locked Contract payment protocol (ATLC) is proposed. This protocol uses a combination of asymmetric encryption algorithms and data signing algorithms for encryption, decryption, and verification. It ensures the atomicity of the transaction process, data consistency, balance security, and value privacy.
• Extensive experimental simulations are conducted, demonstrating that the MFPS algorithm achieves higher transaction payment success ratios with lower average handling expenses. The proposed solutions also provide security and privacy protection against wormhole attacks, double-flower attacks, and false-transaction attacks, demonstrating improved performance in terms of computational verification and message overhead.

The remainder of this paper is as follows. In Section 2, the current research in this area is presented. In Section 3, the knowledge related to the study of this paper is introduced. In Section 4, the system model is described and the related equations are given. In Section 5, the design and specific implementation process of the routing algorithm, MFPS, is presented, and the ATLC protocol is introduced in detail. In Section 6, simulation experiments are carried out for algorithm verification. Section 7 summarizes and concludes this paper.

2. Related Works

Ref. [23] analyzes the challenges and latest research trends in off-chain payment channel networks. Current routing algorithms for payment channel networks can be divided into two categories: single-way routing and multi-way routing [24]. In cases where a single route does not allow a transaction to be split, an alternative approach is to find a route path that satisfies the requirements for the transfer of transaction assets. This method is mainly used in scenarios where the network size and the number of transaction transfers are small. Ref. [25] proposes an application of the ant-routing algorithm in lightning networks, inspired by the behavior of ants, using the characteristics of pheromones released on the paths taken by ants to achieve a de-neutralized routing mechanism.

Multi-way routing aims to find at least one path for a transaction, and if necessary, the transaction amount can be split across different paths, which can effectively reduce the problem of channel blocking. Ref. [26] was the first to propose the implementation of the SilentWhispers algorithm for route forwarding using a distributed credit network, which is based on the idea of Landmark routing. This algorithm enables the selection of nodes with the highest network connectivity to generate transaction paths and uses a combination of password-sharing multi-party computation and digital signature chains to enhance user security and privacy. By combining PCN concurrency and privacy protection protocols, a new protocol, MHTLC, was developed. Ref. [27] proposes the SpeedyMurmurs algorithm, a routing algorithm for decentralized path-based transactions, with privacy protection for transaction nodes and transaction amounts using the VOUTE algorithm within Friend-to-Friend networks. The architecture of SpeedyMurmurs is similar to that of SilentWhisper but it offers better efficiency and performance. Ref. [28] proposes the CoinExpress algorithm, which uses distributed dynamic routing to find a routing path for state transfer based on a breadth- or depth-first algorithm. The algorithm effectively addresses the problem of parallelizing transaction processing. Ref. [29] proposes the Flash algorithm, which categorizes transactions into elephant stream payments and mouse stream payments according to their size. Larger transaction amounts use elephant stream payments, which require multiple routing paths to collaborate to complete the transaction. Smaller, single transaction amounts use mouse stream payments, where the transaction path is directly selected from the routing table for transferring assets. Ref. [30] proposes the Spider algorithm, which uses a packet-forwarding-like mechanism to achieve balanced routing and address the issues of network congestion and channel capacity imbalances. Although multi-route splitting transactions can reduce channel blocking and improve network flow, the use of multi-route paths requires real-time network state information and imposes significant communication overhead on nodes, which introduces concerns about transaction atomicity and reduces the efficiency of routing.

Ref. [31] proposes a new mechanism called anonymous multi-hop locking (AMHL) to protect against wormhole attacks in off-chain payment channel networks, effectively reducing the computational and communication overhead in the network. The privacy security protocol of k-HTLC based on PCN transactions proposed in Ref. [32] uses symmetric encryption algorithms to protect against wormhole attacks on payment channel networks, but the security of key transmission cannot be guaranteed. Ref. [33] analyzes congestion attacks on off-chain payment channels and proposes mitigation techniques to increase the difficulty of carrying out such attacks. Ref. [34] proposes the PnP algorithm, which mainly addresses the estimated payment needs between nodes. The PnP algorithm effectively balances channel funds to meet these needs, without relying on any trusted third party, thereby providing strong protection against malicious attacks with minimal overhead.

The above-mentioned works on off-chain payment channels mainly focus on enhancing the security and efficiency of routing, with other factors, such as routing transaction costs, node reputation, and routing paths, often being overlooked. Ref. [35] proposes the CheaPays algorithm to minimize transaction costs while meeting the feasibility and timeliness constraints. However, it does not take into account the node reputation. Ref. [36] proposes a comprehensive routing scheme that takes into account factors such as fee offers, path distance, and historical reputation. However, it does not take into account channel congestion or channel capacity imbalances. In this paper, we design a routing scheme that takes into account factors such as the routing transaction cost, node reputation, and routing path to improve the transaction success ratio in off-chain payment channel networks and reduce the problem of congestion and channel capacity imbalances in the channel. In addition, we propose an ATLC to ensure the consistency and atomicity of transactions, improve the security and privacy of transactions, and protect against wormhole and double-flower attacks.

3. Related Knowledge

3.1. Off-Chain Payment Channels

Off-chain payment channels are used to carry out high-frequency and small-scale transactions off-chain, enabling the transfer of certain on-chain transactions to off-chain. This indirectly improves the transaction throughput of the blockchain while reducing the fees incurred by users for on-chain transactions. The complete payment channel process is shown in Figure 1 and consists of three phases: the establishment phase, the payment phase, and the closing phase. During the establishment phase, a fixed amount of money is deposited on the blockchain as the initial balance of the channel, and this money cannot be accessed on the blockchain until the channel is closed after opening. During the payment phase, both users make payments within the channel, transferring funds and updating the channel’s status. The payment channel can be classified as either a one-way channel or a two-way channel. A one-way channel only allows transactions to be conducted with a specific party, whereas a two-way channel enables transactions between both parties. In this paper, we focus on the analysis of a two-way channel. The closing phase occurs once the payment is finalized and the channel’s status is updated. During this phase, a transaction to close the channel is submitted to the blockchain, and the node transfers the remaining balance from the channel to the blockchain. If any party behaves maliciously during the payment phase, the other party can submit the channel status to the blockchain for broadcasting at any time to penalize the node that engaged in malicious behavior.

3.2. Off-Chain Payment Channels

Cross-channel payments occur when an intermediate user receives a payment from the previous node and refuses to perform the next transfer of funds, and the recipient refuses to receive the payment. In order to address this problem, a Hashed Time-Lock Contract (HTLC) is used, with a hash lock and a time lock at its core. As shown in Figure 2, the receiver first randomly generates the secret R, and after hashing, generates H to send to the sender, which is delivered through a secure messaging channel and not the payment channel. The sender and the intermediate node must include H in the transaction contract, and only after the receiver provides the secret R to the previous hop forwarder within the specified time can the verification process unlock the funds, confirming that Hash(R) = H. The payment process in the HTLC is bound by the time lock, and if the node does not receive the secret R within the specified time, the funds will be returned to the forwarder. The time locks in the transaction path are specified in decreasing order to prevent nodes from experiencing losses in terms of the transaction amount.

4. System Model

This section describes the overall model, which includes the network and payment models. The model architecture is shown in Figure 3.

4.1. Network Model

The topology of a PCN can be represented as a directed acyclic graph of the form G = (V,E), where V denotes the set of nodes in the network and E is the set of payment channels. Each node $v_i\in V$ denotes a user who has a funding account and has established an off-chain payment channel with at least one other node. Each edge $e=(v_i,v_j)\in E$ denotes a payment channel, where $v_i$ is a sender node and $v_j$ is a receiver node, and each edge has the following properties:

• Set each edge $e=(v_i,v_j)\in E$ to have a transaction fee $f_{ij}$, which is the fee charged by node $v_i$ when transferring the transaction amount from $v_i$ to $v_j$.
• Set each edge $e=(v_i,v_j)\in E$ to have a channel balance $b_{ij}$, which represents the maximum transaction amount that can be transferred from $v_i$ to $v_j$.
• Set each edge $e=(v_i,v_j)\in E$ to have an HTLC tolerance time ${\tau }_{ij}$, which is the longest time for $v_i$ to wait for $v_j$ to provide the secret R.
• Set the total balance of each edge $e=(v_i,v_j)\in E$ channel as $c_{i}j$, which denotes the sum of the channel balances on both sides. Therefore, $b_{ij}+b_{ji}=c_{ij}=c_{ji}$ and the balance is always $b_{ij}\le c_{ij}$.

For simplicity, this paper does not consider cases where the total channel balance $c_{ij}$ is 0 or the channel balance $b_{ij}\ge 0$. Only non-negative channel balances are considered, and the payment channels are assumed to be two-way channels.

4.2. Payment Model

Define a payment request $R=(v_s,v_t,a,st,dl,TsId)$, where $v_s$ is the initiator of the payment request; $v_s$ is the sender; $v_t$ is the receiver; a is the amount of the transaction, excluding the processing fee to be paid in the transfer path; $st$ is the start time of the transaction; $dl$ is the transaction cutoff time; and $TsId$ is the unique identifier of the transaction. P is the set of all paths in the PCN, $P_R$ is a set of paths that satisfy the $v_s-v_t$ payment request R, and $p\in P_R$ denotes a path that satisfies the $v_s-v_t$ payment request. Suppose the associated path p is serialized as $p=v_0\to v_1\to \dots \dots \to v_L$, where $v_0=v_s$, $v_L=v_t$, and $v_i\in p$ denotes a node in path p. Define the function $F_{l,m}$ to denote the sum of fees to be paid for a transaction on path p from $v_l$ to $v_m$. Additionally, $f_{i,i+1}$ is used to denote the fees charged for a transaction path passing through node i in channel (i, $i+1$), where $0\le l<m\le L$. The function is shown below:

$$F_{l,m}=\left\{\begin{array}{cc}\sum _{i=l+1}^{m-1}{f}_{i,i+1},\hfill & v_l=v_s\hfill \\ \sum _{i=l}^{m-1}{f}_{i,i+1},\hfill & v_l\ne v_s\hfill \end{array}\right.$$

(1)

To successfully complete the payment request, certain constraints need to be satisfied:

• Timing constraint: To complete the payment request R, the next route must be forwarded within the time-lock tolerance time ${\tau }_{i,i+1}$ of the HTLC in each payment channel, as shown in Equation (2). Timeliness is achieved through the HTLC’s time lock, which guarantees the integrity of transactions in intermediate payment channels.

  $${\tau }_{i,i+1}\ge L-i,\forall i\in [0,L-l]$$

  (2)
• Feasibility constraint: To successfully complete the payment request R by passing through each channel in the path p , it is necessary for the channel balance $b_{i,i+1}$ to be at least equal to the sum of the payment amount and all the handling fees incurred after passing through node $v_i$, as shown in Equation (3).

  $$b_{i,i+1}\ge a+F_p(i+1,L),\forall i\in [0,L-l]$$

  (3)
• Timeliness constraint: To successfully complete the payment request R, the payment must be finalized within the specified completion time of the payment request and reach the intended recipient. Therefore, it is necessary to ensure that the sum of the payment start time st and the time needed to complete the transaction transfer in each link along the path does not exceed the transaction deadline dl specified in the payment request. $d_e$ indicates the transaction transfer time required in channel link e, as shown in Equation (4).

  $$st+\sum _{e\in p}{d}_e\le dl$$

  (4)

5. PCN Routing Optimization Algorithm

Suppose an individual carbon transaction initiator initiates a transaction to a recipient using a payment channel link $p=v_0\to v_1\to \dots \dots \to v_L$, which goes through many node choices in between. In this paper, the selection of paths and nodes is mainly based on the channel handling fee, the historical reputation value of nodes, and the nearest distance. This section proposes an MFPS-based routing optimization algorithm and an ATLC payment protocol. The implementation algorithms include the Route-Init, PaySplit, PaymentRoute, and Recipient routing algorithms.

5.1. MFPS: Multi-Factor Routing Payment Scheme

In this subsection, the MFPS is proposed. The transaction initiator selects the optimal path for the transaction payment based on a combination of factors, including the total transaction fee charged by the path, the node reputation value, and the distance of the path.

5.1.1. Transaction Fees

An important factor to consider in path selection is the cost of the intermediate nodes in the transaction path so that the transaction costs are minimized while satisfying the timing, feasibility, and timeliness constraints. Three types of transaction fees are considered in this paper, namely, a proportional fee for the channel node based on the transaction amount, a fixed fee for the node, and a fee based on the difference in balance between the two ends of the channel. The fee to be charged for a transaction path through node i is shown in Equation (5), where $t_{ij}$ is the amount of money transferred in the channel $e_{ij}$, including the transaction amount and the handling fee charged by the nodes in the chain. is the proportion parameter of the fee charged for the transaction amount, is the proportion parameter of the fee charged according to the balance difference between the two ends of the channel, and H is a constant that indicates the fixed fee charged for the transaction passing through a node. $f_{ij}$ denotes the transaction passing through the channel $e_{ij}$ and the handling fee charged by node $v_i$. The total fee F to be paid for the entire transaction path from the sender side $v_s$ to the receiver side $v_t$ is shown in Equation (6).

$$f_{i,j}=\left\{\begin{array}{cc}0,\hfill & v_i=v_{j}or{v}_i=v_s\hfill \\ t_{i,j}\ast {\alpha }_1+\frac{|b_{ij}-b_{ji}|}{b_{ij}}\ast {\alpha }_2+H,\hfill & otherwise\hfill \end{array}\right.$$

(5)

$$F_{s,t}=\sum _{i=s+1}^{i=t-1}{f}_{i,i+1}$$

(6)

In this paper, we consider the case of channel congestion, i.e., the scenario where there is an imbalance in the channel’s balance at both ends. In the $u,v$ node channel, when the channel is established, both users, that is, both ends of the channel, deposit a balanced amount. However, with the subsequent occurrence of transactions, if the transaction direction has been from node u to node v, the result is that one side of the channel (node v) has sufficient funds, whereas the other side (node u) has insufficient funds, resulting in an imbalance between the two ends of the balance. If a transaction later needs to be transferred from $u\to v$ but the funds available at node u are insufficient to meet the transaction amount, it will result in congestion of the transaction at the node. The transaction will remain congested until the time lock stipulates that the transaction will not be released until the funds are available. The imbalance in the channel balance at both ends of the channel causes a lower transaction success ratio, resulting in channel congestion. Before the transaction is canceled, the balance of the channel that was passed before the transaction will be locked, resulting in the channel-funds deadlock phenomenon. In this paper, we use different percentages of the difference between the two ends of the channel balance to determine the fee. Thus, choosing a path with a higher channel balance results in a lower fee compared to choosing the other end of the path. If there are two or more available paths, the fee becomes a consideration in selecting the path. Under the same conditions, the path with a relatively abundant channel balance at one end is selected first, which can reduce the occurrence of channel congestion due to balance imbalances.

5.1.2. Node Reputation Value

An important factor to consider in transaction path selection is the reputation value of the nodes. If the reputation value of a node is low, there is a higher probability of it being malicious, which can cause the transaction not to reach the intended recipient within the specified time lock, leading to transaction failure. Therefore, in order for the transaction to successfully reach the intended recipient within the specified time, the channels associated with nodes with a higher reputation value should be considered in the transaction path selection. In this paper, we consider that the reputation value of a node is related to the number of times it participates in a transaction and exhibits correct/malicious behavior. Correct/malicious behaviors are defined as follows:

• Correct behavior: The node successfully transfers the transaction amount and required secret within the specified time lock.
• Malicious behavior: The node fails to transfer the amount of the transaction within the prescribed time lock, fails to provide the required secret, or provides a forged secret.

The node reputation value is shown in Equation (8). In order to ensure that the reputation gap between nodes is within a certain range and avoid node centralization, the sigmoid function is used to limit the reputation value within the range of (0, 1). $R_t$ is the reputation value at the iteration and is a sigmoid function that takes values within the range of (0, 1). The impact factor $I_t$ represents the reward factor when node $v_i$ exhibits correct behavior and the penalty factor when node $v_i$ exhibits malicious behavior. $g_i$ denotes the number of correct behaviors exhibited by node i, $m_i$ denotes the number of malicious behaviors exhibited by node $v_i$, and $n_i$ denotes the total number of transactions that node $v_i$ has participated in. The penalty for a node engaging in malicious behavior is greater than the reward for engaging in correct behavior so the penalty factor is generally higher than the reward factor. In the case of the initial state, the $I_t$ influence factor is 0 and the reputation value $R_t$ is 0.5.

$$I_t=\left\{\begin{array}{cc}{I}_{t-1}+{\beta }_1\ast \frac{g_i}{n_i},\hfill & node{v}_{i}behavescorrectly\hfill \\ I_{t-1}-{\beta }_2\ast \frac{m_i}{n_i},\hfill & node{v}_{i}behavesmaliciously\hfill \end{array}\right.$$

(7)

$$R_i=\frac{1}{1+e^{-I_t}}$$

(8)

5.1.3. Distance

The time to perform transactions in the off-chain payment channel mainly considers the processing time at each node while ignoring the time required to transfer funds within the channel. In the case of multiple available paths, the path that passes through as few nodes as possible, i.e., the shortest path, is chosen if all other conditions are the same. A weighted directed graph is constructed by considering factors such as the node reputation, transaction cost, and distance length. The node reputation and transaction fee are used as the weight factors of the edges. The value of the node reputation is a sigmoid function with a range of (0, 1), and the value of the transaction fee is normalized using the max-min technique, as shown in Equation (9). In considering the distance problem, which is equivalent to the transaction time problem, each node has a specified time-lock tolerance time ${\tau }_i$ for transaction processing. This paper considers the minimum number of hops, without considering the comparison of processing times at each node. Therefore, when constructing the directed graph with weights, a constant ${\gamma }_3\in (0,1)$ is added to the weight of each edge. The weight $w_{ij}$ of each edge $e_{ij}$ is shown in Equation (10), where is an argument of ${\gamma }_{i\in 1,2,3}(0,1)$. Weights are assigned to each edge and a non-negative weighted directed graph is constructed. The Dijkstra algorithm is used to find the shortest path, i.e., the optimal path, considering the node reputation, transaction fees, and distance.

$$f_{ij}^{\prime }=\frac{f_{ij}-min(f_{1,2},f_{2,3},\dots ,f_{L-1,L})}{max(f_{1,2},f_{2,3},\dots ,f_{L-1,L})-min(f_{1,2},f_{2,3},\dots ,f_{L-1,L})}$$

(9)

$$w(i,j)={\gamma }_1\ast f_{ij}^{\prime }+{\gamma }_2\ast \frac{1}{R_i}+{\gamma }_3$$

(10)

5.2. ATLC: Time-Locked Contract Payment Protocol Based on Asymmetric Encryption

This subsection proposes an asymmetric encryption-based time-locked contract payment protocol that uses a combination of asymmetric encryption algorithms and digital signatures to secure the transaction process and ensure the atomicity, data consistency, balance security, and value privacy of the transaction process.

5.2.1. Introduction to ATLC Protocol

In this paper, we propose the ATLC protocol for the scenario of off-chain payment channel network transactions. The security of the ATLC protocol relies on the security features of the asymmetric encryption algorithm RSA and the digital signature algorithm DSA. The steps and operational details of the ATLC are described in detail below. In this paper, we use an example of an indirect payment from sender $v_0$ to receiver $v_4$ with a payment path $p=v_0\to v_1\to v_2\to v_3\to v_4$ and a transaction amount value a, as shown in Figure 4. The specific steps are as follows:

1.

The sender $v_0$ generates a random numeric identifier ${\left\{{\phi }_i\right\}}_{i\in [0,4]}$ and $r_4$ using the asymmetric encryption algorithm RSA ${\left\{r_i\right\}}_{i\in [0,3]}$. The sender node $v_0$ transmits ${\{{\phi }_i,r_i\}}_{i\in [1,4]}$ through the anonymous secure communication channel to each intermediate node and the receiver.

2.

Transaction lock phase: The sender $v_0$ transmits transaction-related information $<v_0,v_4,a+F_{0,4},r_0,TsId>$ to the next hop node $v_1$. The intermediate node $v_i$ receives the transaction information from the previous hop and verifies the correctness of the conditions of the incoming contract using the RSA algorithm for decryption and verification. It checks if $r_i.equals(RS{A}_{s{k}_i}\left(r_{i-1}\right).$ If the match is successful, $v_i$ provides funds $a+F_{i,4}$ to the next hop node $v_{i+1}$ and locks them in the channel. If the match is unsuccessful, the transaction is terminated and the funds locked in the channel are unlocked and returned to the original section.

3.

Transaction release phase: After receiving the transaction information, the receiver $v_4$ determines whether the current time is less than dl. If it is satisfied, it proceeds to the verification phase and enters the fund release phase upon successful verification of the match. $v_4$ uses the digital signature algorithm RSA for signature generation ${\phi }_4^{\prime }\leftarrow DS{A}_{s{k}_4}({\phi }_4,r_3)$ and sends ${\phi }_4,{\phi }_4^{\prime }$ to the previous hop stage $v_3$. When the intermediate node $v_i$ receives ${\phi }_{i+1},{\phi }_{i+1}^{\prime }$ from the next hop node of the transaction, it uses the DSA algorithm to verify and determine if $DS{A}_{p{k}_{i+1}}\left({\phi }_{i+1}^{\prime }\right).equals\left(DS{A}_{p{k}_{i+1}}({\phi }_{i+1},r_i)\right)$. If the verification is successful, the funds locked in the channel are released to $v_{i+1}$. If the verification is unsuccessful, the transaction is terminated and the funds locked in the channel are unlocked and returned to the original node.

4.

When the transaction release phase is successfully verified at sender $v_0$, the channel funds are released to node $v_1$, the transaction is closed, and sender $v_0$ successfully transfers the funds to receiver $v_4$.

5.2.2. Privacy Protection Analysis

In this paper, we use the asymmetric encryption algorithm RSA and digital signature algorithm DSA to ensure the security of off-chain payment channel transactions. The n-htlc and ktlc protocols proposed in Ref. [32] use a hash algorithm and a symmetric encryption algorithm. However, the symmetric encryption algorithm requires the transmission of a key, whose secure distribution is a security issue, To address this issue, this paper uses an asymmetric encryption algorithm, which avoids the problems associated with key transmission. During the transaction release phase, this paper uses a digital signature for verifying that the channel amount is released gradually in the order of the transactions. This approach has the advantages of being more resistant to attacks, eliminating the need for key protection, and providing non-repudiation and privacy protection compared to hash verification and symmetric encryption algorithms. The following is an analysis of the nature and privacy protection of the ATLC protocol proposed in this paper:

• Atomicity: Transactions are executed or aborted. Atomicity is a necessary property in the proposed multi-hop payment mechanism. During the transaction process, if there is a node verification mismatch, the transaction will terminate, and the transaction amount in the channel will be released back to the original node, ensuring the atomicity of the transaction.
• Data consistency: During transactions, the balances in the payment phase and release phase are changed and transferred to the node channel. If the verification does not match at any stage of the transaction process, the transaction amount will be returned to the original node, and the channel balance of each node will remain unchanged. The consistency of the balance throughout the channel is ensured.
• Balance security: If there is a malicious node, any intermediate node participating in the transaction does not lose its balance or the transaction fee obtained by participating in the transaction. If an honest node $v_i$ is in the transaction lock phase and encounters a situation where $v_{i-1}$ is a malicious node and the decryption $r_{i-1}^{\prime }$ received by $v_i$ using the private key does not match $r_i$, the transaction terminates and $v_i$ does not lose any fees. In the transaction release phase, if node $v_{i+2}$ directly sends ${\phi }_{i+2},{\phi }_{i+2}^{\prime }$ to $v_i$, $v_i$ uses the public key ${\phi }_{i+2}^{\prime }$ of node $v_{i+1}$ to verify and sign. If it does not match $DS{A}_{p{k}_{i+1}}({\phi }_{i+2},r_i)$, the channel transaction balance of user $v_i$ will remain locked, and the amount will be returned to the original node after the transaction is terminated. In this case, the node will not lose any fees, which ensures the balance security of the node.
• Value privacy: In addition to the sender and receiver intermediate nodes not knowing the transaction amount information of the transaction, the intermediate nodes in the payment path can only see the payment value transmitted by the previous hop node and the payment value paid to the next hop node.

5.3. Design of Routing Algorithm

In this subsection, the implementation process of the MFPS routing algorithm is described in detail and its computations are shown in Algorithms 1–4.

The route initialization phase, Route-Init, is shown in Algorithm 1. The algorithm describes that when a payment request is made, a weighted directed graph is constructed specifically for that payment request. The nodes traverse the graph G (V,E) and build weights for the edges. Table $T^E(i,j)$ is the weight value of stored edge $e_{ij}$. If $v_i=v_j$, $T^E(i,j)=0$, and if there is no channel between $v_i$ and $v_j$, $T^E(i,j)$ is assigned an infinite value. If there is a channel between $v_i$ and $v_j$, the balance of the $v_i$ channel segment is $b_{ij}a+F_p(i+1,L)$. If the feasibility constraint of the transaction is not satisfied, the weight of the edge $T^E(i,j)\leftarrow \infty$ is assigned. In the remaining cases, $w(i,j)$ is calculated according to Equation (10) and assigned to the $T^E(i,j)$ transaction weight table. When the node has traversed all nodes of G, the loop is finished and $T^E(i,j)$ is output. After route initialization, the Breadth-First-Search (BFS) algorithm is used to traverse the entire graph to find the set of paths $P_R(s,t)$ between $v_s$ and $v_t$.

Algorithm 1: Route-Init

Before routing transactions, it should be determined whether there is a path with a sufficient channel balance for the transfer of the funds needed for the transaction. If such a path does not exist, the transaction amount is split and the transaction is forwarded separately. The specific steps of Algorithm 2 (PaySplit algorithm) are shown below and are as follows. Find the channel paths that exist between $v_s$ and $v_t$ and sort the transferable funds from largest to smallest. Next, calculate the total transferable funds and determine if the funds needed for the transaction are reached. If not, return null to indicate that the transaction failed. If the funds needed for the transaction are reached, split transactions are performed from the path with the most transferable funds, thus minimizing the number of split transactions and re-initializing the routes. When the split amount reaches the funds required for the transaction, the cycle ends and the split transaction set is returned.

Algorithm 2: PaySplit

The routing path selects the optimal path for the transaction, as shown in Algorithm 3 (PaymentRoute). The aim of the algorithm is to find the optimal path for forwarding transactions. First, it is necessary to check if $P_R(s,t)$ is not null. Then, define $S=\varphi$ and Q as the set V of all vertices in graph G. When $Q=\varphi$, carry out a loop. Select the intermediate node with the minimum weight from the starting point $v_s$ to $v_t$ in $T^E(s,t)$, remove the node from the set of nodes Q, and add the node to the set S. $p_i$ is an s-t path in $P_R(s,t)$ and is considered the optimal path if all nodes are in set $S\supseteq p_i$. The transaction request R will then choose this path for the transaction. When the transaction path $p_i$ is determined, the sender randomly generates the digital identifier of the participating transaction nodes and the $r_t$ digital identifier ${\left\{{\phi }_i\right\}}_{i\in [0,p_i.length-1]}$ of the receiver. In addition, the digital identifiers of the intermediate nodes and the sender are generated according to $\left\{r_i\right\}\leftarrow RS{A}_{p{k}_{i+1}\left({\phi }_{i+1}\right)}$, and the sender $v_s$ sends ${\{{\phi }_i,r_i\}}_{i\in [0,p_i.length-1]}$ to node $v_i$ through the anonymous communication channel.

Algorithm 3: PaymentRoute

    The transaction reaches the receiver, as shown in Algorithm 4 (Recipient). When the receiver receives the fund transfer, it first verifies whether the transaction timeliness constraint is satisfied. If the receiving time exceeds the deadline specified in the transaction, the receiver has the right to reject the transaction. Subsequently, the intermediate nodes involved in the transaction release the funds and return the fund transfer generated by the transaction to the original owner. If the timeliness constraint is satisfied, the receiver receives the transaction, generates a signature ${\phi }_t^{\prime }\leftarrow DS{A}_{s{k}_t}({\phi }_t,r_{t-1})$, and sends $\{{\phi }_t,{\phi }_t^{\prime }\}$ to $v_{t-1}$. When the intermediate node $v_i$ receives $\{{\phi }_{i+1},{\phi }_{i+1}^{\prime }\}$, verify that $DS{A}_{p{k}_{i+1}}\left({\phi }_{i+1}^{\prime }\right)=?DS{A}_{p{k}_{i+1}}$$({\phi }_{i+1},r_i)$. If verification is successful, generate ${\phi }_{i+1}^{\prime }\leftarrow DS{A}_{s{k}_i}({\phi }_i,r_{i-1})$ and send $\{{\phi }_i,{\phi }_i^{\prime }\}$ to node $v_{i-1}$. Node $v_i$ then releases the locked funds in the channel to node $v_{i+1}$. If the match is unsuccessful, the funds generated by the transaction are transferred back to node $v_i$.

Algorithm 4: Recipient

6. Simulation Experiments

6.1. Environments and Parameter Setting

Experimental data and environment: In this paper, the experimental data were obtained from Ref. [37]. The off-chain payment channel network used was the Lightning Network, where the experimental topology is a real snapshot of lightning. The experimental hardware environment was as follows. CPU, Intel(R) Core(TM) i7-8565U 1.80 GHz; memory, 8.00 GB; and operating system, Windows 10. IntelliJ IDEA 2021.1 x64 software was used for the simulation experiments.

Parameter setting: The parameters for the transaction commission were set as follows. The function $f_{ij}$ parameters were ${\alpha }_1$= 0.01, ${\alpha }_2$ = 0.03, and H = 0.005. In the credibility function, the parameters were ${\beta }_1$ = 0.2 and ${\beta }_2$ = 0.5. In the weighting function, the parameters were ${\gamma }_1={\gamma }_2={\gamma }_3=\frac{1}{3}$.

6.2. Security Analysis

The ATLC security analysis proposed in this paper is described below:

• Anti-wormhole attack: In the path $p=v_0\to v_1\to \dots \dots \to v_L$, if $v_i$ is an honest node, $v_{i-1}$ and $v_{i+1}$ are malicious nodes. If $v_{i-1}$ and $v_{i+1}$ collude to obtain the transaction fee of $v_i$, the malicious attack is a wormhole attack. In this paper, we propose an ATLC that can effectively prevent wormhole attacks. If node $v_{i+1}$ directly sends the transaction information to node $v_{i-1}$ for the digital signature verification phase, and node $v_{i-1}$ does not have the $r_i$ identifier of node $v_i$, the verification result cannot be matched. As a result, the channel balance will not be released or unlocked and the honest node will not lose any funds.
• Anti-double-flower attack: A double-flower attack is when an attacker repeatedly uses the same funds to make payments. In the asymmetric encryption and digital signature used by the ATLC, each transaction node has a unique digital signature and public key for verification, and an attacker cannot forge the digital signature. Therefore, the attacker cannot perform a double-flower attack.
• Anti-fraudulent trading attack: A fake transaction attack is when an attacker sends fake transactions to deceive the trading node and obtain the fee. In the ATLC protocol, each transaction has a unique identification called TsId, and nodes need to sign and verify the transaction. Only through the verification of the node can the transaction be completed, thereby preventing attackers from sending false transactions.
• Anti-replay attack: This is when an attacker retransmits the transmitted data during the data transmission between two communication parties. The ATLC uses the digital signature algorithm (DSA) and encryption algorithm to protect against replay attacks.
• Denial-of-service attack: This is when an attacker sends a large number of invalid requests by forging identities. As a result, communication between two parties cannot proceed as normal. The ATLC uses the DSA to protect against denial-of-service attacks.

6.3. Experimental Results

The comparison algorithms used in the experimental evaluation were as follows:

• ShortestPath: The algorithm chooses the shortest path for trading under the trade constraints;
• Cheapest: In the transaction path selection, this algorithm selects the path with the lowest transaction fee;
• SplitDistance: If the channel balance does not meet the amount needed for the transaction, this algorithm splits the transaction amount along the shortest path.

The performance metrics used in the experimental evaluation were as follows:

• Success ratio: This refers to the percentage of total transactions successfully received by the recipient;
• Average transaction fee: This refers to the average transaction fee paid in successfully completed transactions;
• Average message spending: This refers to the overhead in terms of the average number of messages involved in a successful transaction request;
• Delay: This refers to the time required to complete a transaction (in mesc).

The independent variables used in the experimental evaluation were as follows:

• Number of transactions: This refers to the total number of transactions performed in the off-chain payment channel network;
• Initial channel balance: This refers to the initial balance in the channel of the node that establishes the off-chain payment channel network;
• Transaction value: This refers to setting the transaction amount for each transaction in the off-chain payment channel network;
• TNumber of nodes: This refers to the total number of nodes present in the off-chain payment channel network.

The impact of the number of transactions and the initial channel balance on the transaction success ratio in the MFPS algorithm is illustrated in Figure 5. In Figure 5a, the effect of the number of transactions on the transaction success ratio is shown. The initial channel balance was set to 200 and the transaction amount was set to 25. With the increase in the number of transactions, the transaction success ratio remained consistent at around $84\%$. In addition, it was observed that the change in the number of transactions had little effect on the success ratio of the MFPS routing transactions. In Figure 5b, the effect of the initial channel balance on the transaction success ratio is shown. The number of transactions was set to 10,000 and the transaction amount was set to 250. As the channel balance increased, the transaction success ratio also increased. With an initial channel balance of 500, the transaction success ratio improved by $17\%$ compared to a balance of 50.

We compared the performance of the MFPS algorithm with the ShortestPath, Cheapest, and SplitDistance algorithms. The initial channel balance was set to 25 and the number of transactions was set to 10,000. The independent variable was the transaction amount. The results of the performance comparison are shown in Figure 6 and Figure 7.

Figure 6 shows a comparison of the transaction success ratios when using the ShortestPath, Cheapest, SplitDistance, and MFPS algorithms. The MFPS algorithm improved the transaction success ratio by about 13.84%∼49% compared to the other algorithms for a transaction amount of 50. We can see that the Cheapest algorithm had the fastest decrease in the success ratio as the transaction amount increased. This is because the Cheapest algorithm only chooses the path with the lowest transaction fee, without considering the feasibility constraint of the transaction. This led to a significant decrease in the transaction success ratio. The success ratio of the SplitDistance algorithm was higher than that of the ShortestPath algorithm. This is because the SplitDistance algorithm splits the transaction amount according to the shortest path. This improved the transaction success ratio. When the transaction amount was greater than the initial channel capacity, the transaction success ratio of the SplitDistance and MFPS algorithms tended to be stable. In contrast, the transaction success ratio of the ShortestPath and Cheapest algorithms decreased faster. This is because the SplitDistance and MFPS algorithms used the split amount for transactions, whereas the ShortestPath and Cheapest algorithms did not split the transaction amount. As a result, the number of paths capable of meeting the transaction amount gradually decreased, and the transaction success ratio also gradually decreased. As the amount per transaction increased, the success ratio of all the algorithms decreased because the percentage of paths that could satisfy the feasibility constraint of the transaction also decreased.

Figure 7 shows a comparison of the average transaction fees for the ShortestPath, Cheapest, SplitDistance, and MFPS algorithms. As the transaction amount increased, the transaction fee became more significant due to its correlation with the transaction amount. Subsequently, the average fee for all the algorithms exhibited an upward trend. The Cheapest algorithm’s average transaction fees were lower than those of the MFPS because the Cheapest algorithm chose the path with the lowest transaction fees so its average transaction fees were the lowest. The ShortestPath algorithm had the highest average transaction fees because the ShortestPath algorithm only considered the shortest path and did not consider the transaction fee. The MFPS algorithm, when compared with the ShortestPath and SplitDistance algorithms, achieved significant reductions in the average transaction fee of $41.72\%$ and $28.25\%$, respectively, for a transaction amount of 50.

A latency comparison of the MFPS and ktlc algorithms is shown in Figure 8. The independent variable was the change in the number of nodes, the response variable was the latency of the transaction (in msec), and the number of transactions was set to 10. Since the asymmetric encryption algorithm is slower than the symmetric encryption algorithm, the experimental comparison in this paper excluded the time required for key generation in both algorithms. The aim was to compare the computational verification time delay between the two encryption algorithms. In the figure, it can be seen that the MFPS algorithm computed the verification with lower latency than the ktlc algorithm.

The average message spending values of the MFPS and ktlc algorithms are shown in Figure 9. The independent variable was the change in the number of nodes, the response variable was the average message overhead, and the number of transactions was set to 10. As the number of network nodes increased, the number of transaction hops increased, and the average message overhead also tended to increase. In this figure, it is clear that the MFPS algorithm had a lower overall average message overhead compared to the ktlc protocol.

In summary, the MFPS algorithm had a higher transaction success rate, lower transaction communication overhead, and reduced transaction processing costs compared to the other algorithms. The MFPS achieved better performance and effectively improved the transaction success rate of off-chain payment channels. In addition, it effectively ensured the privacy and security of transactions with minimal communication overhead.

7. Conclusions

Blockchain technology can be successfully applied to the carbon-trading scenario using the characteristics of blockchains to guarantee the security, decentralization, data immutability, and data traceability of the carbon-trading process. This paper uses an off-chain payment channel to improve the performance of carbon trading on the blockchain, moving the small-scale and high-frequency transactions of individuals to the off-chain for trading while keeping the carbon transactions of companies on the blockchain. This approach reduces the burden of trading on the blockchain and also allows individuals engaging in small-scale and high-frequency carbon transactions to avoid expensive processing fees on the blockchain. In this paper, the optimization of PCN routing based on off-chain payment channels is conducted, and a multi-factor-based routing payment scheme is proposed, which takes into account factors such as the transaction fee cost, node reputation, and distance for routing. In order to reduce channel congestion, we propose implementing transaction fees based on the difference between the balances at each end of the channel. In order to improve the transaction success rate, a greedy splitting algorithm is proposed for the transaction amount. In order to ensure the security and privacy of node transactions, an ATLC protocol is proposed in the off-chain payment channel, which is capable of preventing wormhole and double-flower attacks. The experimental results show that the MFPS scheme proposed in this paper achieves a high transaction success rate with low communication overhead and handling costs while guaranteeing the privacy and security of transactions.

The MFPS scheme aims to optimize the performance of the off-chain payment channel by transferring the high-frequency and small-scale carbon trading of individuals to the off-chain, This approach reduces the pressure of on-chain blockchain carbon trading and enables quick processing of large-scale carbon trading business between enterprises on the chain, thus improving the scalability of the blockchain. The MFPS scheme proposed in this paper can improve the success rate of individual carbon trading in the off-chain payment channel, improve the performance of the blockchain in processing individual carbon trading, and reduce the cost burden for individual users by reducing transaction costs. In terms of security and privacy, the security of individual users’ carbon assets can be guaranteed. The MFPS solution addresses the problem of insufficient blockchain scalability, improves blockchain performance, and enables the blockchain to support high-concurrency transactions in large-scale carbon-trading scenarios.

In the future, the influence of a single factor, such as node reputation, transaction cost, or distance, on routing selection will be further analyzed. Additionally, the influence of other factors on routing selection that were not considered in this paper will also be investigated.