Author: RGB++ Fans; Source: Bytecoin CKB
In the previous article “How Lighting Network Works (2)”, we discussed the working principle of BTCLighting Network (Lightning Network). Essentially, Lighting Network is a well-designed payment channel system that connects payment channels one by one to form a broad, interconnected Payment Network, allowing parties that are not directly connected to each other to make payments to each other through multi-hop routing, with HTLC, PTLC and other contracts ensuring the security of the routing.
After years of development, and while Lighting Network has come a long way in terms of technology and user experience, we have had to face the reality that it is still not at the point where it can be adopted at scale. In today’s article, we’re going to focus on one of the key challenges that Lighting Network is currently facing: the Liquidity Problem. This problem can be further broken down into two aspects, one is the overall liquidity of the network, and the other is the liquidity allocation problem.
Insufficient overall Liquidity in the network
According to the latest statistics from the mempool, BTCLighting Network currently has 12,389 Nodes and 48,000 payment channels, with a total channel capacity of 5311.8 BTC.
The Lighting Network is a P2P Liquidity network. In order to truly achieve large-scale adoption, the number of Nodes, channels, and channel capacity will need to rise by hundreds or even thousands of times. So, how can we attract more Nodes to join the network?
First, it is crucial to drop the barrier for setting up and maintaining Lighting Network Nodes, allowing ordinary users without technical background to easily run Lighting Network Nodes. In the BTC ecosystem, many teams have introduced plug-and-play hardware devices, such as the Umbrel hardware box, which supports running BTC Lighting Network Nodes, and the Fi5Box, which not only supports BTC Lighting Network but also supports running other Lighting Network Nodes (such as CKB’s Fiber Network), providing users with a maintenance-free Lighting Network Node solution.
Secondly, the introduction of additional incentive mechanisms is key to driving the Lighting Network into a virtuous cycle. After opening a channel in the Lighting Network, funds are locked. If Alice wants to be a Lighting Network service provider (LSP) and open channels with 100 people, with each channel having 1 BTC locked, she needs to lock 100 BTC in total. These 100 BTC will only generate income when they are in motion and not when they are static because the income of Lighting Network Nodes mainly comes from transaction fees. The fee structure for transaction fees is ‘Base Fee + Fee Rate per Satoshi’, where the Base Fee is a fixed fee charged by the Lighting Network Node for each transaction invoice, regardless of the transaction amount, and the Fee Rate per Satoshi is the proportion of fees charged per Satoshi in the transaction invoice.
According to the statistics of the mempool, the average base fee of BTCLighting Network is 950 mSat (i.e. 0.95 Satoshi), with an average fee rate of 764 ppm per Satoshi (i.e. 0.000764 Sat per Satoshi), which means that a transaction of 10,000 Satoshi (0.0001 BTC, currently about $6.5) receives less than 9 Satoshi in fees for the routing Node. Moreover, the volume of the current Lighting Network is not large, and many transactions do not need to go through routing Nodes (i.e. the two parties in the transaction have a direct payment channel). Therefore, for those holding BTC who want to invest, the first choice is not to deposit BTC into the Lighting Network to earn fees, but to lend on an exchange or participate in Staking/Restaking in some emerging projects.
If additional incentive mechanisms can be introduced to make more people willing to run Lighting Network Node or become LSP, and make more BTC holders willing to deposit BTC into Lighting Network to earn incentives, the problem of insufficient network Liquidity may be solved, and Lighting Network will become more user-friendly. After Lighting Network becomes more user-friendly, it will attract more people to use Lighting Network, bring more transactions, increase the transaction fee income of routing Nodes, and incentivize more people to become LSP… Ultimately, this will allow Lighting Network to enter a virtuous cycle.
Currently, in the BTC ecosystem, UTXO Stack has announced its transformation into the Lighting Network stake layer, providing better liquidity and a better revenue model for the Lighting Network through decentralization stake protocol. At the same time, UTXO Stack will also launch a token incentive mechanism to encourage users to stake BTC to enhance the liquidity of the Lighting Network payment channels.
Liquidity Allocation Issue
Even if the problem of overall Liquidity shortage is solved, how to effectively allocate this Liquidity remains a challenge.
Taking the example of Alice making a payment to Carol through routing Node Bob, assuming that initially Alice and Carol each have 20,000 Satoshi in their channels, and Bob has 10,000 Satoshi in each channel. After several transactions, the balance distribution in the channels is as follows (for simplicity, we do not consider the transaction fees charged by routing Node Bob):
If Alice and Carol have business dealings in the future and Alice needs to initiate payment to Carol, what should she do? Bob can no longer route payments (i.e., in Bob and Carol’s channel, Bob can no longer transfer funds to Carol), and he needs to rebalance his channel.
The above situation is very common for those routing Nodes in the Lighting Network. Node operators must constantly balance Liquidity between their own channels. If there is no funds on your end of the channel, you cannot send payments; if all the funds in the channel are on your end, you cannot receive payments.
In the above example, one way is to directly close the channel between Bob and Carol and open a new channel, but this method is not economical because both closing and opening the channel transactions need to be put on-chain and pay BTC gas fee. The original intention of the Lighting Network design is to reduce on-chain operations and conduct as many transactions as possible in off-chain channels. If Lighting Network has billions of channels to open and close every day, the BTC blockchain will be congested and the gas fee will be ridiculously high.
To this end, the BTC community has proposed various innovative solutions to address the Liquidity allocation issue:
Submarine Swap（潜水艇互换）
Simply put, Submarine Swap allows users to send BTC in Lightning Network channels to exchange providers, who will send the corresponding amount of BTC to the on-chain receiving address, or vice versa, users send on-chain BTC to exchange providers, who send BTC in the channel to the designated receiving node. Although exchange providers are involved in this process, there is no need for trust throughout the process through HTLC (Hashed TimeLock Contract).
Submarine Swap has also inspired many followers, such as the channel balance adjustment protocol PeerSwap, which allows users to directly implement submarine swaps with their channel counterparts. In the example above, Carol can directly act as the role of the swap service provider. Bob transfers BTC on-chain to Carol, and Carol pays the corresponding amount of BTC to Bob in the channel. Specifically:
- Bob generates a secret value R (pre-image) and its hash value H.
- Bob creates an HTLC using the hash value H on the BTCBlock on-chain: Bob will pay Carol 10,000 satoshis as long as he can provide the secret value R within 5 blocks, otherwise the money will be returned to Bob.
- Carol creates an HTLC in his payment channel with Bob using the same hash value H: Carol will pay 10,000 satoshis to Bob in the channel, as long as he can provide the secret value R within 4 Blocks. Otherwise, the money will be returned to Carol (for simplicity, the service fee charged by the intermediary is not considered here).
- Bob uses the secret value R to unlock the HTLC in the channel and takes away 10,000 satoshis.
- After Bob took the funds away, Carol also knew the secret value R, and he used R to unlock the HTLC of BTC on-chain and took away 10,000 satoshis.
Compared to closing the channel and then opening a new one, Submarine Swap only requires one on-chain transaction, which is more cost-effective and does not require trust throughout the process.
Channel Splicing
Channel splicing is an on-chain rebalancing method: The Node closes and reopens the channel in a single transaction, thereby changing the balance locked in the channel. When the Node locks in more funds in this way, it is called ‘splice in’; if the locked funds are reduced, it is called ‘splice out’. In the example above, the channel between Bob and Carol can be extended through channel splicing.
Compared to closing and reopening the channel with two transactions, channel splicing is much more convenient, but it still needs to broadcast transactions on the network, pay on-chain gas fee, and wait for transaction confirmation.
Multi-Path Payment (MPP)
Multi-path payment can split a payment into several parts, which can be simultaneously stopped or circulated in different places. If Alice needs to continue to pay 10,000 Satoshi to Carol, although Bob can no longer route the payment, Alice can pay 6,000 Satoshi to Carol through routing Node David and 4,000 Satoshi to Carol through routing Node Eva. In this way, Alice’s 10,000 Satoshi transaction can be completed through multi-path payment.
The original intention of the multi-path payment technology is to overcome the limitations of single-path payment and allow larger amounts of payment to be delivered by splitting them into smaller parts. For example, a Lighting Network transaction with an amount of 1 BTC can be divided into 100 transactions of 0.01 BTC to complete. Multi-path payment has benefits for the decentralization of the network and the privacy protection of transactions. In terms of security, Atomic Multi-Path (AMP) technology can ensure that if one path fails to complete the payment, all payments will not succeed, thereby preventing chaos and fraud.
By the way, in the Lighting Network, in addition to multi-path payments, large transactions can also be completed through Wumbo channels. Wumbo channels eliminate the BTC limit of 0.1667 BTC that regular Lightning channels can hold, allowing Nodes to have higher channel capacity and support large transactions.
Conclusion
Liquidity is one of the main factors restricting the development of the Lighting Network. By dropping the threshold for building and maintaining Lighting Network Nodes, introducing additional incentive mechanisms, Lighting Network can solve the problem of insufficient network liquidity. Solutions such as Submarine Swap, channel splicing, and multi-path payments have some help in solving the distribution of Lighting Network liquidity.
In addition to the above solutions, the BTC community has proposed other solutions to optimize the Liquidity of the network, such as Lightning Pool (a channel leasing auction market), Liquidity Advertisement (a channel leasing scheme), and Loop Payments (a Node pays itself through a loop formed by payment channels to achieve off-chain rebalancing).
Liquidity management is undoubtedly a complex project that Lighting Network faces, but with the continuous progress of technology and the continued efforts of the community, we have reason to believe that these Liquidity problems will eventually be solved.
