Lighting Network Liquidity Management Plan Popular Science

Author: RGB++ Fans; Source: Bytecoin CKB

In the previous popular science article, we have briefly introduced the core concepts related to Lighting Network such as payment channels, multi-hop routing, HTLC, etc.

We mentioned that in the Lighting Network, transfers often need to go through multiple middleman nodes to build a path, and the available balance of these middle nodes is often limited, which ultimately affects the success rate of payments. To ensure that nodes in the path have sufficient funds and enhance the user experience, it is necessary to adjust through some liquidity management solutions. However, to deeply understand liquidity management issues, we need to introduce several basic concepts, such as local balance and remote balance, inbound capacity and outbound capacity, etc.

In the past, we mentioned that the basic components of the Lighting Network are Nodes and channels, the latter being an off-chain 1-to-1 transfer facility built on the BTC network. During the initialization of the channel, both parties will transfer some money as the initial balance. The balance on your side is called ‘local balance’, and the balance on the other side is called ‘remote balance’. The local balance determines how much money you can transfer to the other party, limiting your payment capacity, that is, ‘outgoing capacity’. The remote balance determines how much money the other party can transfer to you, limiting your ‘incoming capacity’, that is, the ability to receive payments.

Although the respective balances of the participants can be changed frequently before the channel is closed, the total capacity of the channel cannot be changed unless you restart the channel in its entirety or inject funds with “channel splicing”.

(This graph shows the balances of you and Robert, your local balance is 5, the remote balance is 3, and the overall capacity of the channel is 8)

After understanding the above basic concepts, let’s take a look at what problems Liquidity management in the Lighting Network is trying to solve. The simplified Node connectivity diagram shown in the figure below makes it easy to see that you (bottom left corner) are only connected to one Node, LNTop, and due to your remote balance being 3, you can receive a maximum transfer of 3 USD. However, if Sophie wants to transfer 1 USD to you, it will fail due to insufficient transferable balance between the middle Node and LNTop (highlighted in red, the outgoing capacity of the Node to LNTop is 0).

It can be said that channel capacity is one of the serious problems encountered by the Lighting Network in its early stages. If the distribution of Liquidity in the entire network is more sufficient, such problems will be effectively alleviated, and the solutions to this are often collectively referred to as ‘Liquidity management’, such as allowing clients to connect to multiple Nodes with abundant Liquidity through leasing markets (Lighting Pool), opening/closing new channels as needed, or introducing methods such as channel splicing and channel rebalancing to regulate the balance in the channels on-chain or off-chain.

Some wallet clients now provide automated channel management functions, intelligently managing channels based on user payment behavior and network conditions to ensure sufficient liquidity for transfers. New users can also adopt a ‘one-way funding’ mode when first connected to the Lighting Network, which means only allowing the counterparty to fund the channel without funding it themselves during channel initialization. This can reduce users’ economic costs, but the downside is that there is no outgoing payment capacity at the initial stage.

Below we will provide a more detailed popular science of the common techniques for Liquidity management in the Lighting Network. First, let’s understand the channel leasing, which mainly solves the “incoming capacity” problem of Nodes, that is, when others want to transfer money to you, you must ensure that you can successfully build a payment path for the other party, which requires requirements for each Node included in the path, such as sufficient transferable balance/outgoing capacity. The scenario of the failed path we mentioned earlier is rooted in the insufficient Liquidity in the channels established between some intermediate Nodes and other Nodes.

Building channels comes with a cost, as participants often need to lock up a portion of their funds, incurring opportunity costs. The concept of channel leasing, on the other hand, is to facilitate direct transactions among Node operators through market-based means, enabling surplus funds-rich Nodes to proactively establish channels for other Nodes through a ‘leasing’ mechanism. For example, if you are a merchant who needs to receive money from others at any time and has high requirements for the limit, your ‘receipt capability’ within a day needs to exceed 200 BTC.

So you reach a protocol with 4 large Nodes through the Lighting Pool. These 4 Nodes set up a 24-hour channel with you and lock in 50 BTC each, providing you with a remote balance of 50 BTC each. This way, your receiving capacity in each channel will reach 50 BTC. If someone wants to transfer funds to you, you can use any one of these 4 Nodes as a middleman to build a payment path.

(On 1ml.com, we can see multiple well-known Lighting Network Node operators, these Nodes have surplus funds, and have established multiple channels with other Nodes, which can obtain income by renting Liquidity)

In addition to the leasing pool mentioned above, there are Liquidity Advertisements, where Liquidity providers can use lightning Node’s gossip messages to broadcast their asking price and channel duration, and Nodes accepting the asking price can open channels with them. Such leasing-based schemes will always combine the Margin system to prevent sudden default by either party.

Currently, developers of Lighting Network such as Lighting Labs and Fiber are trying to optimize the liquidity leasing scenario under one-way funding. For example, Fiber plans to introduce liquidity payment on the basis of CKB smart contract functionality. There will be designated LSP service provider nodes to establish channels with users and provide free inbound capacity for a period of time to meet their receiving needs. When users receive some money, the contract will automatically withdraw the cost. The liquidity staking mechanism related to such scenarios is also under discussion.

In general, channel leasing is often used to solve the problem of establishing connections between nodes and obtaining incoming liquidity, while the following channel splicing solution will inject/withdraw funds through on-chain operations, directly changing the total balance of both parties in the channel. Normally, 2/2 signatures are used to open and close channels, allowing participating parties to redistribute on-chain assets they jointly own. In the early Lighting Network scheme, once a channel is opened, the overall balance in the channel cannot be changed unless it is closed and reopened.

Channel splicing is a new solution proposed later, which can update the existing channel without closing it. Under the collaboration of participants, it directly reorganizes and updates the UTXO jointly controlled by both parties on-chain. For example, adding new assets based on existing assets for joint control by participants, thereby changing the overall balance in the channel. The figure below briefly outlines this idea. On the left side is the on-chain asset (UTXO1) corresponding to the old channel, controlled by Alice and Bob’s multi-signature. Afterwards, both parties initiate channel splicing, adding another asset (UTXO2) to be jointly managed. Finally, the amount of assets (UTXO3) that can be jointly controlled by both parties in the channel increases, and the capacity increases.

Channel splicing can also be used to reduce excess funds in the channel, transferring idle assets out of the channel to improve capital utilization efficiency. Compared to the traditional close/reopen channel that requires two on-chain interactions, channel splicing only requires a single on-chain operation, which can significantly reduce costs. Although channel splicing has obvious advantages, due to historical reasons, the widespread adoption of this solution still needs time to mature and land.

After understanding the channel splicing, we continue to introduce the idea of channel rebalancing, which is also a means of adjusting off-chain balances in different channels without closing the channels or changing the total capacity within the channels (ignoring fees). Suppose you are running a Lighting Network client and have established a total of three payment channels with other Nodes:

• Channel 1: Established with Node X, total capacity is 1 BTC
• Channel 2: Established with Node Y, total capacity is 0.5 BTC
• Channel 3: Established with Node Z, total capacity of 0.5 BTC

The fund distribution of each channel is as follows:

• Channel 1: Your local balance: 0.9 BTC Remote balance: 0.1 BTC
• Channel 2: Your local balance: 0.1 BTC Remote balance: 0.4 BTC
• Channel 3: Your local balance: 0.1 BTC Remote balance: 0.4 BTC

The current problem is that your outbound capacity in channels 2 and 3 is insufficient. You can only transfer a maximum of 0.1 BTC to the counterparty, which cannot meet the needs of large transfers. At the same time, the outbound capacity in channel 1 is excessive, reaching 0.9 BTC, but you won’t be able to use that much in the short term. Obviously, the best solution is to transfer the surplus funds from channel 1 to the other two channels. So you plan to transfer 0.4 BTC from the local balance of channel 1 to channel 2 and 0.4 BTC to channel 3. To achieve this, you need to complete two circular payments.

The specific operation method is as shown in the above figure. You can directly transfer 0.8 BTC to Node X, who will then transfer 0.4 BTC to both Y and Z respectively. Then, Y and Z will transfer 0.4 BTC to you in channels 2 and 3, increasing your local balance. This way, you will have sufficient transferable funds to meet future large transfer needs.

By observing the above chart, it is not difficult to find that the essence of the loop payment is to transfer money to yourself, transfer your balance in different channels back and forth, and finally distribute the overall balance to achieve your expected results. However, this method alone cannot increase the total balance of any channel out of thin air. In addition, its implementation relies on the following assumptions: X has sufficient transferable funds for Y and Z. In other words, loop payments often require related nodes to have a certain liquidity reserve in advance.

Loop payment is an implementation idea of channel rebalancing, and the rebalancing scheme can also be combined with other methods in practice, such as Submarine Swaps. Let’s introduce Submarine Swaps, the core idea of this scheme is to swap on-chain and off-chain funds without closing the channel, using methods such as HTLC.

The simplest submarine swapping scenario is to deposit from on-chain to the channel. Assuming Alice has established a 1-to-1 channel with Bob, but after a while, Alice’s local balance is almost exhausted and she cannot make any more outgoing payments. At this time, Alice needs to inject more funds, which requires closing and restarting the channel. However, this channel is rented, and it is not cost-effective to close it in advance. So what should be done?

If exchanged through submarine, the process will be relatively easy, but it requires the help of HTLC. First, Alice can generate a random number R and take the hash H® of it. Later, Alice can send BTC to Bob’s Address on-chain, with the unlocking condition restricted by HTLC. For Bob to unlock these BTC on-chain, he must know the pre-image R corresponding to H®.

Bob trades with Alice through HTLC in the off-chain channel, but the direction is reversed: Alice needs to present R before unlocking the money paid by Bob. As long as Alice presents the value of R, Bob can use it to unlock the BTC locked by Alice on-chain. Afterwards, Alice’s local balance in the channel increases, and the asset balance on-chain equivalently decreases (ignoring fees), basically a 1-to-1 exchange (in order to facilitate the explanation of the principle, the conventional operation order of submarine swapping is not strictly followed in the above explanation. In fact, most of the time, one party creates HTLC off-chain first, and the other party creates symmetric HTLC on-chain later).

The above scenario is mainly used for swapping on-chain assets for off-chain balances. As long as the direction of operation for Alice and Bob is adjusted, it can be exchanged for withdrawal operations, converting off-chain balances into on-chain assets. Submarine swaps rely on the combination of HTLC and time lock to ensure security, even if the other party refuses to cooperate with you midway, the money locked in HTLC is safe because the other party does not know the Secret Key to unlock HTLC. After the time lock expires, you can retrieve the principal.

However, it should be noted that although your principal will not be stolen in the above scenarios, one party needs to create an HTLC on-chain to lock the funds, which will inevitably incur transaction fee wear and tear. If the other party reneges, it will definitely have a certain impact on you. To solve these problems, submarine swaps often have some coordinated auxiliary measures, such as advance payment, reputation system, and other penalty measures.

Let’s summarize again, the core idea of submarine swaps is to enable flexible swapping of on-chain/off-chain assets. If we follow the idea of channel rebalancing, we can implement more optimal liquidity adjustment measures. Here’s a simple example:

However, summarizing the above knowledge points, it is not difficult to find that submarine swaps, channel splicing, channel leasing, and other Liquidity adjustment operations will leave operation traces on-chain, thereby generating transaction fees. If such operations are frequently carried out, it will inevitably create pressure on users’ economic costs and UX. Since BTC Lighting Network relies on BTC Mainnet, frequent on-chain interactions are not realistic, while the Fiber based on CKB faces relatively less pressure in Liquidity management experience. However, both Lighting Network and Fiber are deeply researching innovative Liquidity solutions, and may explore more suitable paths in active cooperation with project teams such as Mercury Layer in the future.