The main dilemma currently faced by the Lightning Network (2)

In the previous article "The Main Dilemmas Facing the Lightning Network (1)", we introduced one of the main factors restricting the development of the Lightning Network: liquidity. The liquidity issue can be further divided into two aspects: one is the overall lack of liquidity in the network, which requires lowering the barriers to building and maintaining Lightning Network nodes and introducing additional incentive mechanisms to address it; the other is the liquidity distribution problem. Currently, there are solutions such as Submarine Swap, Splicing, Multi-Path Payments (MPP), Lightning Pool, Liquidity Advertisement, and Loop Payments to optimize the liquidity of the Lightning Network.

In today's article, we continue to introduce other challenges currently faced by the Lightning Network and the innovative solutions proposed by the community.

Support for Stablecoins#

The Lightning Network excels in four aspects: high throughput, low latency, low cost, and privacy protection. It is the best way to achieve cryptocurrency payments and an important payment infrastructure for building a P2P economy. After El Salvador adopted Bitcoin as legal tender in 2021, the Lightning Network saw increased applications, with the number and amount of payments rising rapidly, peaking at over 82,000 payment channels in the network. However, as we can see from the chart below, the capacity of funds in the Bitcoin Lightning Network has grown slowly over the past two years, and the number of channels has even declined.

Source: https://mempool.space/graphs/lightning/capacity

Currently, the main currency circulating in the Bitcoin Lightning Network is BTC, and one of the biggest challenges BTC faces as a medium of exchange is its price volatility. In fact, the price volatility of BTC has always been a significant barrier to the widespread adoption of the Lightning Network. If the Lightning Network is to enter households and become the preferred choice for daily small and frequent payments, it must support stablecoins, as people in real life are accustomed to using stable-value currencies for everyday payments.

To this end, on July 23, 2024, Lightning Labs released the first mainnet version of the multi-asset Lightning Network, officially introducing Taproot Assets into the Lightning Network. Taproot Assets is an asset issuance protocol on Bitcoin, and the issued assets can be deposited into payment channels of the Lightning Network and transferred through the existing Lightning Network. The release of the multi-asset Lightning Network mainnet version marks the official support for stablecoins on the Bitcoin Lightning Network, meaning that applications such as global instant settlement of foreign exchange transactions through the Lightning Network and direct payment of stablecoins for purchasing goods using Lightning invoices will become a reality.

Figure: In the Lightning Network, Alice sends a USD stablecoin, and Bob receives a Euro stablecoin; Source: https://www.odaily.news/zhtw/post/5198267

In addition, the Lightning Network Fiber Network launched by Nervos CKB, leveraging the flexibility of the CKB blockchain, natively supports user-defined assets, including Bitcoin-native stablecoins minted by decentralized protocols such as Stable++. In the complete test version released in September, developers can already use the Fiber Network to test the Bitcoin-native stablecoin RUSD.

We believe that the combination of the Lightning Network and stablecoins will unleash powerful synergies, injecting new vitality into the Lightning Network and promoting the adoption of cryptocurrency payments in daily life.

User Experience#

Although the Lightning Network has made significant technical progress, there is still room for improvement in user experience, and there are still some gaps compared to traditional payment experiences, such as:

Need to Stay Online When Receiving/Sending Payments#

Many failed Lightning payments are caused by the recipient being offline. From the user's perspective, this is a poor user experience because traditional payments (such as bank transfers) do not require the other party to be online, and blockchain payments (such as on-chain transfers of USDT) only require knowing the other party's address without needing them to be online continuously.

The current solution is to use Lightning Network Service Providers (LSP) to receive payments for offline users, addressing the "stay online" requirement and making the user experience closer to existing payment solutions. The downside is that it introduces a trust assumption, as users need to trust the Lightning Network service provider.

Lack of Payment Methods for Multiple Receipts of Any Amount#

The Lightning Network's invoice is used to request payment, and the recipient provides necessary information to the initiator through the invoice to assist with the payment. The invoice can be simply understood as the "payment code" commonly used in payment software (a more accurate analogy is a payment invoice). Currently, the default invoice in the Lightning Network is one-time use; it contains a hash value and its denomination for a single payment, and it becomes invalid after a successful payment or timeout. This means that each time a payment is received, the invoice needs to be copied, pasted, and sent to the payer, which involves too many steps. If you are a merchant accustomed to placing a WeChat/Alipay payment QR code at the counter, the user experience of the Lightning Network will definitely frustrate you, especially during busy business hours.

To address this, the Bitcoin community has proposed several solutions:

Keysend#

Keysend utilizes the fact that a node's node_id does not change and will be exposed to the payer after the invoice is given, so it can be used as a static endpoint. The advantage of Keysend is that it relies entirely on the Lightning Network itself without depending on other protocols, while the downside is that the recipient's node, channel, channel UTXO, etc., will all be exposed.

Currently, most Lightning Network clients have implemented the Keysend feature, but it may require users to manually enable this feature during operation.

LNURL and Lightning Address#

LNURL-pay is a standard that allows users to create a static QR code that can receive multiple payments. Its working principle is that the user scans the QR code (LNURL-pay) with a Lightning Network wallet, the wallet decodes the QR code, obtains the URL, and accesses it using the HTTPS protocol. The server responds to the wallet with a message asking for the payment amount (which can also be a fixed amount). The user fills in the amount and sends the information back to the server, which returns a traditional Lightning Network invoice for the amount selected by the user, and finally, the wallet pays the invoice.

Lightning Address allows the user's QR code (LNURL-pay) to become a URL similar to an email address through encoding. Others can access this URL, and the response they receive is an LNURL-pay request. Currently, most wallets implementing LNURL are custodial wallets, which assign a Lightning Address to each user to allow payments to be received using the Lightning Address.

BOLT12#

BOLT12 (Lightning Network Technical Base 12) is a newly proposed Lightning Network technical specification that attempts to implement some of the functionalities provided by LNURL without using a web server. Although BOLT12 has not yet been merged into BOLT, the idea has received support from most developers. Compared to LNURL, the biggest feature of BOLT12 is that it can be implemented within the Lightning Network protocol without relying on other network protocols and communication methods.

Conclusion#

The development path of the Lightning Network still faces many challenges, but with continuous technological advancements and ongoing efforts from the community, these challenges will be gradually overcome. For example, the LN-Penalty used by the Bitcoin Lightning Network, aside from its complexity, also creates storage burdens, and the implementation of its improvement plan, eltoo, requires a soft fork of Bitcoin and the introduction of a new signature hash type; similarly, regarding the privacy issues of HTLC, its improvement plan, PTLC, may be implemented and experimented with first on Lightning Networks of other blockchains.

The Lightning Network is undergoing a continuous optimization and growth process. With the introduction of stablecoins, improvements in user experience, and the emergence of more innovative solutions, we have reason to believe that the Lightning Network is getting closer to the goal of large-scale adoption. It will not only reshape the payment experience of cryptocurrencies but is also expected to become an important force driving global financial innovation.

CKB 中文