Author: RGB++ Fans; Source: Byte Yuan CKB
In previous popular science articles, we have briefly popularized the core concepts related to the Lightning Network, such as payment channels, multi-hop routing, and HTLC.
We mentioned that in order to transfer money in the Lightning Network, it is often necessary to build a path through multiple middleman nodes, and the transferable balance of the middleman nodes is often limited, which will eventually affect the success rate of payment. In order to ensure that the nodes in the path have sufficient funds and enhance the user experience, some liquidity management solutions should be used for adjustment. However, to deeply understand the liquidity management problem, we must first introduce several basic concepts, such as local and remote balance, inbound and outbound capacity, etc.
In the past, we mentioned that the basic components of the Lightning Network are nodes and channels, the latter of which is an off-chain 1-to-1 transfer facility built on the Bitcoin network. When the channel is initialized, both parties will transfer some money as the initial balance. The balance on your side is called the "local balance", and the balance on your counterparty is called the "remote balance". The local balance determines how much money you can transfer to your counterparty, limiting your payment ability, i.e., "outgoing capacity", while the remote balance determines how much money your counterparty can transfer to you, limiting your "incoming capacity", i.e., receiving ability.
Although the balances of both parties can change frequently before the channel is closed, the total channel capacity after the sum of the two cannot be changed unless you restart the channel as a whole or inject funds using "channel splicing".
(This picture shows your and Robert's respective balances, 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 Lightning Network is trying to solve. The figure below shows a simplified node connection diagram. It is not difficult to see that you (lower left corner) are only connected to one node, LNTop. Since your remote balance is 3, you can receive a maximum of $3 in transfers. If Sophie wants to transfer $1 to you, it will fail because the intermediate node has insufficient transferable balance for LNTop (in the red box, the node's outgoing capacity for LNTop is 0).
It can be said that channel capacity is one of the serious problems encountered by the Lightning Network in its early stages. If liquidity is more fully distributed throughout the network, such problems will be effectively alleviated. The solutions to this are often collectively referred to as "liquidity management", such as allowing clients to connect to multiple nodes with sufficient liquidity through the rental market (Lighting Pool), opening/closing new channels as needed, or introducing methods such as channel splicing and rebalancing (Channel Rebalancing) to regulate the balance in the channel on or off the chain.
Some wallet clients now also provide automated channel management functions, which intelligently manage channels based on users' payment behavior and network conditions to ensure sufficient liquidity for transfers. When new users first connect to the Lightning Network, they can also adopt the "one-way funding" mode, which means that only the channel counterparty can fund the channel, and they do not fund the channel when it is initialized. This can reduce the economic cost of users, but the cost is that they do not have the ability to make external payments/outgoing capacity at the beginning.
Below, we will provide a more detailed popular science on the common methods of liquidity management solutions in the Lightning Network. First, let us understand channel leasing, which mainly solves the "accounting capacity" problem of nodes. That is, when others want to transfer money to you, you must ensure that the other party can successfully build a payment path, which requires requirements for each node included in the path, such as sufficient transferable balance/outgoing capacity. The root cause of the path failure scenario we mentioned earlier is the lack of liquidity in the channels established between some intermediate nodes and other nodes.
Building a channel is costly, because participants often have to lock up a part of their funds, which will incur opportunity costs. The so-called channel leasing, its idea is to allow node operators to trade directly through market means, and through the "leasing" system, nodes with surplus funds will take the initiative to build channels for other nodes. For example, if you are a merchant, you need to receive money from others at any time, and you have high requirements for the amount. The "collection capacity" in one day must exceed 200 BTC. So you reach an agreement with 4 large nodes through Lighting Pool. These 4 nodes will build a 24-hour channel with you, lock in 50 BTC each, and provide you with a remote balance of 50 BTC respectively, so that your collection capacity in each channel will reach 50 BTC. If someone transfers money to you, you can use any one of these 4 nodes as an intermediary to build a payment path.
(On 1ml.com, we can see several well-known lightning network node operators. These nodes have more surplus funds and have established multiple channels with other nodes. They can earn income by leasing liquidity)
In addition to the leasing pool mentioned above, there is also Liquidity Advertisement. Liquidity providers can use the gossip messages of lightning nodes to broadcast their asking prices and channel durations, and nodes that accept the asking prices can open channels with them. Such leasing-based solutions will be combined with a margin system to prevent one party from suddenly defaulting.
Currently, Lightning Network developers such as Lighting Labs and Fiber are trying to optimize the liquidity leasing scenario under one-way capital injection.For example, Fiber plans to introduce a liquidity payment system based on the CKB smart contract function. There will be designated LSP service provider nodes to build channels with users and provide users with free account capacity for a period of time to meet their payment needs. After the user receives some money, the contract will automatically withdraw the cost from it. The liquidity pledge mechanism related to such scenarios is also under discussion.
Generally speaking, channel leasing is often used to solve the problem of establishing connections between nodes and obtaining account liquidity, and the following channel splicing (Splicing) solution will inject/withdraw funds through on-chain operations, directly changing the total balance of both parties in the channel. Under normal circumstances, the opening and closing of a channel will use 2/2 signatures, and the participating parties will redistribute the jointly owned on-chain assets. In the early lightning network scheme, once a channel is opened, the overall balance in the channel cannot be changed unless it is closed and restarted.
Channel splicing is a new scheme proposed later. It does not close the existing channel. With the cooperation of the participants, the UTXOs jointly controlled by both parties of the channel can be reorganized and updated directly on the chain. For example, new assets are added on the basis of existing assets for the participants to jointly control, thereby changing the overall balance in the channel. The figure below briefly summarizes this idea. On the left is the on-chain asset (UTXO1) corresponding to the old channel, which is controlled by Alice and Bob's multi-signature. After that, the two parties initiate channel splicing and add another asset (UTXO2) to jointly manage it. In the end, the amount of assets (UTXO3) that can be jointly controlled by both parties of the channel increases, and the capacity increases.
Channel splicing can also be used to reduce excess funds in the channel, transfer temporarily idle assets out of the channel, and improve the efficiency of fund utilization. Compared with the traditional closing/restarting of the channel, which 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, this solution has not been fully mature and implemented, and its large-scale adoption will still take time.
After understanding channel splicing, we continue to introduce the idea of channel rebalancing, which is also a means of adjusting the off-chain balances in different channels without closing the channel or changing the total capacity in the channel (ignoring the handling fee). Suppose you run a Lightning Network client and establish a total of three payment channels with other nodes:
Channel 1: established with node X, with a total capacity of 1 BTC
Channel 2: established with node Y, with a total capacity of 0.5 BTC
Channel 3: established with node Z, with a total capacity of 0.5 BTC
The funds in each channel are distributed 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 problem now is that your outgoing capacity in Channel 2 and Channel 3 is insufficient, and you can only transfer 0.1 BTC to your counterparty at most, which cannot meet the needs of large-amount transfers. At the same time, Channel 1 has an excess outgoing capacity of 0.9 BTC, but you can't use so much in the short term. Obviously, the best way is to move the surplus funds in 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 effect, you need to complete two circular payments.
The specific operation method is shown in the figure above. You can directly transfer 0.8 BTC to node X, which then transfers 0.4 BTC to Y and Z respectively. Then Y and Z transfer 0.4 BTC to you in channel 2 and channel 3 respectively to increase your local balance. In this way, you have sufficient transferable funds to meet future large-amount transfer needs.
Observing the above picture, it is not difficult to find that the essence of loop payment is that you transfer money to yourself, transfer your balance in different channels, and finally make the overall balance distribution reach your expected result. However, this method alone cannot increase the total balance of both parties in any channel out of thin air. In addition, its implementation needs to rely on the following assumptions: X has sufficient transferable funds to Y and Z. In other words, loop payment often requires relevant nodes to have a certain amount of liquidity reserves in advance.
Loop payment is a way to realize the idea of channel rebalancing, and the rebalancing scheme can also be combined with other methods in practice, such as submarine swaps. Let us introduce Submarine Swaps. The core idea of this scheme is to exchange on-chain and off-chain funds without closing the channel with the help of methods such as HTLC.
The simplest submarine swap scenario is to top up a channel on the chain. Assume that Alice has established a 1-to-1 channel with Bob, but after a period of time, Alice's local balance is basically exhausted and can no longer pay out. At this time, Alice needs to inject more funds and needs to close the channel and restart it, but this channel is leased, and it is not cost-effective to close it in advance, so what should I do?
If it is swapped through a submarine, the process will be easier, but it requires the help of HTLC. First, Alice can generate a random number R and take the hash H(R) of it. Later, Alice can send BTC to Bob's address on the chain, and its unlocking conditions are restricted by HTLC. In order for Bob to unlock these bitcoins on the chain, he must know the original image R corresponding to H(R).
Bob conducts transactions with Alice through HTLC in the off-chain channel, but in the opposite direction: Alice has to show R before she can unlock the money Bob paid. As long as Alice shows the value of R, Bob can use it to unlock the BTC Alice locked on the chain. After that, Alice's local balance in the channel increases, and the asset balance on the chain decreases by an equivalent amount (ignoring the handling fee), which is basically a 1:1 replacement (in order to facilitate the explanation of the principle, the above explanation is not strictly in accordance with the normal operation order of submarine swaps. In fact, most of the time, one party creates an HTLC off-chain first, and the other party creates a symmetric HTLC on the chain).
The above scenario is mainly used to replace the off-chain balance with the on-chain asset. As long as the operation direction of Alice and Bob is adjusted, it can be switched to a withdrawal operation to convert the off-chain balance into on-chain assets. Submarine swaps rely on the combination of HTLC and time locks to ensure security. Even if the other party fails to cooperate with you, the money you lock in the HTLC is safe because the other party does not know the key to unlock the HTLC. After the time lock expires, you can get your principal back.
But please note that although your principal will not be stolen in the above scenario, one party needs to create an HTLC on the chain to lock the funds, which will inevitably cause handling fee wear and tear. If the other party fails, it will inevitably have a certain impact on you. In order to solve these problems, submarine swaps often have some auxiliary means of cooperation, such as prepayments, reputation systems and other punishment measures.
Let's summarize it again. The core idea of submarine swap is to enable flexible swapping of on-chain/off-chain assets. If we follow the idea of channel rebalancing, we can achieve better liquidity adjustment measures. Here is a simple example:
Suppose you run a node and open multiple channels. The local balance of some channels is surplus, while the local balance of other channels is seriously insufficient, which affects your payment ability. You want to balance the distribution of funds in each channel without closing the channel. Submarine swap can be a good solution. You can choose a channel with too much local balance, transfer the funds to the chain through submarine swap, and then inject the on-chain assets into the target channel through submarine swap. During the whole process, no channel needs to be closed.
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 the chain, and then generate handling fees. If such operations are performed frequently, it will inevitably put pressure on the user's economic cost and UX. Since the Bitcoin Lightning Network relies on the BTC main network, frequent on-chain interactions are not realistic, and Fiber based on CKB faces relatively less pressure of this kind, and the experience of liquidity management is smoother. But in any case, the Lightning Network and Fiber are conducting in-depth research on more novel liquidity solutions, and in the future, they may explore a more suitable path through active cooperation with project teams such as Mercury Layer.
Weatherly
