Lightning in a Bottle: Liquidity on the Lightning Network
QUICK TAKE
• Since the Lightning Network is built around payment channels, it is difficult to manage liquidity on the network. Many ideas have been proposed to improve network liquidity, including trampoline routing (Lightning Network reduces data and computational pressure in the payment process by outsourcing routing to trampoline nodes) and atomic multipath payments (AmPs).
• Congestion attacks allow malicious Lightning users to lock large amounts of funds cheaply.
By Karim Helmy Translator: Colin
https://www.theblockcrypto.com/
secondary title
lightning in a bottle
The Lightning Network solves several problems with Bitcoin, notably the inability of Bitcoin's underlying layers to efficiently process large volumes of transactions. Lightning Network transactions are instant and trustless, but lack underlying settlement guarantees. The Lightning Network transfers transactions off-chain, resulting in faster speeds and lower fees, but liquidity management is also more difficult due to its network structure.
The Lightning Network supports both parties to lock the funds on the chain in the payment channel. At this time, the two parties can trade freely without submitting payment to the underlying chain. The maximum net transaction each party can send is the initial amount locked in the channel by that party.
Users can make payments through a route consisting of multiple channels, so that users can make payments to recipients that do not have payment channels open to them directly. The payer specifies the payment path and pays a small fee to the operator of the intermediate channel. Transactions are routed using onion to prevent intermediary nodes from gaining the identity of the paying parties.
Making an indirect payment requires an indirect path between the payer and receiver, usually requiring a relatively good network connection between the parties. The algorithm used to select payment paths is not specified by the Lightning Network protocol, and the protocol authors consider the algorithm to be an implementation detail.
By moving transactions off-chain, the Lightning Network scales the Bitcoin network without compromising the verifiability of the underlying blockchain. As with any new technology, the Lightning Network has many issues, most of which, like the current channel capacity limit of 0.16 BTC, will eventually be resolved.
However, some issues are inherent to the Lightning Network architecture. Some of these problems stem from the two-party payment channels dedicated to the Lightning Network. While the underlying unspent transaction output (UTXO) can be used as an input to any transaction, a user's balance in one channel cannot be sent directly to a receiver in another channel.
secondary title
channel rebalancing
In order to ensure that off-chain payments can be made, users can employ a set of channel rebalancing techniques. Users can reallocate funds through Lightning channels and bring in new funds from their on-chain balances in several ways.
In order to increase the amount of funds on the Lightning Network, funds must be transferred from the bottom layer of Bitcoin. This can be achieved by opening new channels or through a technique called splicing, which allows users to close and reopen channels, increasing the balance in the channel. Both of these methods require the execution of on-chain transactions.
An atomic swap is a cryptocurrency transaction that is either fully executed or completely aborted. The most common implementation of atomic swap technology for most bitcoins is using a hashed time-lock contract (HTLC). The contract locks funds until one party presents a key or the lock expires. Users can increase channel balances by performing Submarine Swaps, an atomic swap between Bitcoins held on the underlying layer and Bitcoins held on Lightning Network channels. With this technique, the total amount of funds locked in the Lightning Network remains the same, but users' total balances increase.
Lightning Network users can also achieve channel rebalancing through circular payments, where users send funds from one channel and then receive them on another channel through a circular path. In this way, the user increases the balance of the receiving channel and decreases the balance of the sending channel - keeping the total net balance constant at a lower fee.
secondary title
Keeping the Lightning Network Liquid
Splicing payment channels, performing deep swaps, and opening new channels all require on-chain payments, and recurring payments are not convenient enough. Therefore, channel rebalancing can be quite expensive and time-consuming. To overcome this, several techniques have been proposed to reduce the frequency of channel rebalancing and improve the liquidity of the network when channel capacity is low.
The ACINQ team proposed trampoline routing, which reduces the amount of memory and calculation required by users while maintaining the current routing mode. In trampoline routing, users send transactions and intended recipients to well-connected trampoline nodes and ask trampoline nodes to compute payment paths on their behalf. Since these nodes are well-connected, users need to maintain fewer channels, improving liquidity. This mode encourages a certain degree of centralization, and users may need to pay higher routing fees than other modes in exchange for reduced calculations.
Trampoline routing compromises user privacy if payments are routed through a single trampoline node, as this node knows the ultimate recipient's information. To solve this problem, the protocol allows users to specify multiple trampoline nodes, so that intermediate nodes are responsible for finding the path to the next receiver according to the request of the sender. Trampoline nodes are not sure if the next receiver is the final receiver or another intermediate node.
Another proposal, Atomic Multipath Payments (AMP), allows users to atomically split payments and route them through multiple paths, allowing users to send larger transactions through illiquid channels. In addition to solving the liquidity problem, this technique has the added benefit of making it harder for intermediary nodes to determine the amount of payment they are routing, thus benefiting user privacy. The implementation of atomic multipath payments requires an update to the Lightning Network specification, but only the sender and receiver of the payment need to enable this update.
To reduce the frequency of channel rebalancing, several other transaction routing techniques have been proposed. An academic paper suggests using a technology called Spider, which is inspired by packet switching protocols and supports multi-path payments like AMP. However, Spider does not support transaction atomization, so some parts of the transaction may be successfully processed, while other parts may fail to process. The protocol also introduces transaction batching, increasing throughput at the cost of increased latency.
"just in time (JIT)"shortcoming
shortcoming
There are bugs in the Lightning Network protocol that could reduce liquidity, or work against the vision of improving liquidity.
The Lightning Network's reliance on payment channels makes it vulnerable to congestion attacks, where attackers lock the channel capacity of other nodes for a long time. A variant of the attack was recently proposed that reduces the amount of funds required to launch the attack by using recurring payments. Under current network conditions, the developers of this attack estimate that an attacker could lock 650 BTC of liquidity for three days for a fee of only 0.25 BTC.
In order to reduce the effectiveness of the attack, the researchers propose reducing the maximum number of hops that can be used when paying, and adopting an additional hash time-lock contract resolution mechanism instead of the mechanism currently used by the Lightning Network.
The researchers also discussed implementing a strategy to avoid loops, in which routing nodes would refuse to provide routing services for a payment when a node appears multiple times along the payment path. Such a measure would prevent honest users from performing recurring payments, limit their use of the technique for rebalancing, and limit the implementation of timely routing.
Lightning payments that contain only a small number of intermediary nodes may be vulnerable to traffic analysis attacks by these nodes. In such attacks, intermediary nodes learn possible deanonymization information from payment patterns of transaction participants. Users can overcome this weakness by deliberately choosing longer payment paths, but this results in a slight increase in fee and complexity.
Traffic analysis attacks are especially effective when most traffic passes through a small number of nodes. Therefore, techniques such as trampoline routing that increase liquidity at the expense of increased centralization will aggravate such attacks.
Directed congestion attacks may be launched by adversaries who wish to obtain the identity of Lightning Network users through traffic analysis attacks. Attackers can use congestion attacks to reduce the channel capacity of alternative paths, forcing users to hand over traffic to the attacker's nodes, ultimately enabling them to more effectively monitor transactions.
