The main difficulties currently faced by the Lightning Network

Author: RGB++ Fans; Source: Byte Yuan CKB

In the previous article "How does the Lightning Network work (2)", we explored the working principle of the Bitcoin Lightning Network. In essence, the Lightning Network is a carefully designed payment channel system that connects payment channels in series to form a broad, interconnected payment network, allowing parties that are not directly connected to pay each other through multi-hop routing. HTLC, PTLC and other contracts will ensure the security of the routing.

After years of development, although the Lightning Network has made great progress in technology and user experience, we have to face a reality: it is still not at the level of large-scale adoption. In this article today, we will focus on a key challenge currently facing the Lightning Network: liquidity issues. This problem can be further divided into two aspects, one is lack of overall network liquidity, and the other is liquidity distribution issues.

Insufficient overall network liquidity

According to the latest statistics from mempool, the Bitcoin Lightning Network currently has 12,389 nodes and 48,000 payment channels, with a total channel capacity of 5311.8 BTC.

The Lightning Network is a P2P liquidity network. If it is to be truly adopted on a large scale, the number of nodes, the number of channels, and the channel capacity will need to increase by hundreds or even thousands of times. So, how to attract more nodes to join the network?

First, it is crucial to lower the threshold for setting up and maintaining lightning network nodes so that ordinary users without technical background can easily run lightning network nodes. In the Bitcoin ecosystem, many teams have launched plug-and-play hardware devices, such as Umbrel's hardware box, which supports running Bitcoin lightning network nodes. Another example is Fi5Box, which not only supports Bitcoin lightning network, but also supports running nodes of other lightning networks (such as CKB's Fiber Network). They provide users with maintenance-free lightning network node solutions.

Second, introducing additional incentive mechanisms is the key to promoting the lightning network into a virtuous cycle. After the lightning network opens a channel, the funds are locked. If Alice wants to be a lightning network service provider (LSP), she needs to open channels with 100 people and put 1 BTC in each channel, then she needs to lock 100 BTC. These 100 BTC will only generate income when they are flowing, not when they are stationary, because the income of the Lightning Network node mainly comes from the handling fee. The charging standard for the handling fee is "Base Fee + Fee Rate", where the Base Fee is a fixed fee charged by the Lightning Network node for each transaction invoice, regardless of the transaction amount, and the Fee Rate is the proportion of the fee charged for each Sat of the transaction invoice.

According to statistics from mempool, the current average base fee of the Bitcoin Lightning Network is 950 mSat (i.e. 0.95 Sat), and the average Fee Rate per Sat is 764 ppm (i.e. 0.000764 Sat per Sat), which means that for a transaction of 10,000 Sat (0.0001 BTC, currently about $6.5), the routing node receives less than 9 Sat in fees. Moreover, the current transaction volume of the Lightning Network is not large, and many of the transactions do not need to be conducted through routing nodes (i.e., the two parties to the transaction have a direct payment channel). Therefore, those who hold BTC and want to manage their finances, the first choice is not to deposit BTC into the Lightning Network to earn fees, but to lend at exchanges or do Staking/Restaking on some emerging projects.

If additional incentive mechanisms can be introduced to make more people willing to run Lightning Network nodes or become LSPs, and to make more BTC holders willing to deposit BTC into the Lightning Network to earn incentives, the problem of insufficient network liquidity will likely be solved, and the Lightning Network will become more useful. After the Lightning Network becomes more useful, it will attract more people to use the Lightning Network, bring more transactions, increase the fee income of routing nodes, and encourage more people to become LSPs... Ultimately, the Lightning Network will enter a virtuous circle.

Currently, in the Bitcoin ecosystem, UTXO Stack has announced its transformation into a Lightning Network staking layer, providing better liquidity and a better revenue model for the Lightning Network through a decentralized staking 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 Lightning Network payment channel.

Liquidity allocation problem

Even if the problem of insufficient overall liquidity is solved, how to effectively allocate this liquidity is still a challenge.

Let's take Alice's payment to Carol through the routing node Bob as an example. Assume that Alice and Carol each have 20,000 Satoshis in the channel at the initial state, and Bob has 10,000 Satoshis in each channel. After several transactions, the balance in the channel is distributed as follows (for simplicity, the fees charged by routing node Bob are not considered):

What should be done if Alice and Carol still have business dealings in the future and Alice needs to make payments to Carol? Bob can no longer route payments (that is, in the channel between Bob and Carol, Bob can no longer transfer funds to Carol), and he needs to rebalance his own channel.

The above situation is very common for routing nodes in the Lightning Network. Node operators must constantly balance liquidity between their channels. If there is no funds on your side of the channel, you cannot send payments; if all the funds in the channel are on your side, you cannot receive payments.

In the above example, one method is to directly close the channel between Bob and Carol and open a new channel, but this method is not economical because both the closing and opening transactions need to be on-chain and require the payment of Bitcoin mining fees. The original intention of the design of the Lightning Network is to reduce on-chain operations and place as many transactions as possible in off-chain channels. If the Lightning Network has hundreds of millions of channels to open and close every day, the Bitcoin blockchain will always be congested and the mining fees will be ridiculously high.

To this end, the Bitcoin community has proposed a variety of innovative solutions to solve the liquidity allocation problem:

Submarine Swap

In simple terms, Submarine Swap allows users to send BTC in the channel to the swap service provider in the Lightning Network, and the swap service provider will send the corresponding amount of BTC to the payment address on the Bitcoin chain, or vice versa, the user sends the BTC on the chain to the swap service provider, and the swap service provider sends the BTC in the channel to the designated receiving node. Although the swap service provider is involved in this process, through HTLC (Hash Time Lock Contract), there is no need for trust throughout the process.

Submarine Swap has also inspired many later comers, such as the channel balance adjustment protocol PeerSwap, which allows users to directly conduct submarine swaps with their channel counterparts. In the above example, Carol can directly act as a swap service provider. Bob transfers the BTC on the chain to Carol, and Carol pays the corresponding amount of BTC to Bob in the channel. Specifically:

1. Bob generates a secret value R (preimage) and its hash value H.

2. Bob uses the hash value H to create an HTLC on the Bitcoin blockchain: Bob will pay Carol 10,000 satoshis as long as she can provide the secret value R within 5 blocks, otherwise the money will be returned to Bob.

3. Carol uses the same hash value H to create an HTLC in her payment channel with Bob: Carol will pay Bob 10,000 satoshis 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 swap service provider is not considered here).

4. Bob uses the secret value R to unlock the HTLC in the channel and take the 10,000 satoshis.

5. After Bob takes the funds, Carol also knows the secret value R, and she uses R to unlock the HTLC on the Bitcoin chain and take the 10,000 satoshis.

Compared to closing a channel and opening a new one, Submarine Swap only has one on-chain transaction, which is more economical and trustless throughout the process.

Channel Splicing

Channel splicing is an on-chain rebalancing method where a node closes and reopens a channel in a single transaction, changing the balance locked in the channel. When a node does this, it is called "splice in"; if it reduces the locked funds, it is called "splice out". In the example above, the channel between Bob and Carol can be lengthened by channel splicing.

Channel splicing is much more convenient than closing and reopening a channel in two transactions, but it still requires broadcasting the transaction to the network, paying the on-chain mining fee, and waiting for the transaction to be confirmed.

Multi-Path Payment (MPP)

Multi-path payment can split a payment into several parts, which can be parked or circulated in different places at the same time. If Alice needs to continue to pay Carol 10,000 satoshis, although Bob can no longer route the payment, Alice can pay Carol 6,000 satoshis through routing node David and 4,000 satoshis through routing node Eva, then Alice's 10,000 satoshis transaction can be completed through multi-path payment.

The original intention of multi-path payment technology is to overcome the limitations of single-path payment, allowing larger payments to be delivered by splitting into smaller parts.For example, a lightning network transaction of 1 BTC can be divided into 100 transactions of 0.01 BTC each. Multi-path payment is good for the decentralization of the network and the privacy protection of transactions. In terms of security, the atomic multi-path payment (AMP) technology can ensure that if one path cannot complete the payment, all payments will not be successful, thereby preventing confusion and fraud.

By the way, in the lightning network,in addition to multi-path payments, large transactions can also be completed through Wumbo channels.Wumbo channels remove the upper limit of the number of bitcoins that can be held by regular lightning channels - 0.1667 BTC, allowing nodes to have higher channel capacity, thereby supporting large transactions.

Conclusion

Liquidity is one of the main factors restricting the development of the Lightning Network. By lowering the threshold for building and maintaining Lightning Network nodes and introducing additional incentive mechanisms, the Lightning Network can solve the problem of insufficient network liquidity. Submarine Swap, channel splicing, multi-path payment and other solutions are helpful in solving the problem of Lightning Network liquidity allocation.

In addition to the above solutions, the Bitcoin community has also proposed other solutions such as Lightning Pool (a channel leasing auction market), Liquidity Advertisement (a channel leasing solution), loop payment (a node pays itself through a loop formed by a payment channel to achieve off-chain rebalancing) to optimize the liquidity of the network.

Liquidity management is undoubtedly a complex project facing the Lightning Network, but with the continuous advancement of technology and the continued efforts of the community, we have reason to believe that these liquidity problems will eventually be solved.