In our last article, The Main Challenges Facing the Lightning Network (1), we discussed liquidity, one of the key factors constraining the development of the Lightning Network. The liquidity issue can be further broken down 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; the other is the liquidity distribution problem. Currently, solutions such as Submarine Swap, channel stitching, multi-path payments, Lightning Pool, liquidity advertisement, and loop payments are in place to optimize liquidity in the Lightning Network.

Today, we will continue to address other challenges currently facing the Lightning Network and the innovative solutions the community has proposed.

Support for Stablecoins

With its high throughput, low latency, low cost, and privacy features, the Lightning Network has become an ideal choice for cryptocurrency payments and serves as a key payment infrastructure for building a P2P economy. In 2021, following El Salvador’s adoption of Bitcoin as legal tender, the application scope of the Lightning Network expanded significantly, with both the number and amount of payments surging, leading to over 82,000 payment channels in the network at one point.

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

However, in the past two years, there have been some changes in the development trend of the Lightning Network. From the data charts above, we can observe that the growth rate of funds in the Lightning Network has slowed. More notably, the number of channels has even declined. This phenomenon reflects that the Lightning Network is facing new challenges after rapid expansion.

Currently, BTC is the primary currency circulating within the Bitcoin Lightning Network. However, one of the biggest challenges BTC faces as a medium of exchange is its high price volatility. This instability has long been a major barrier to the widespread adoption of the Lightning Network. To truly bring the Lightning Network into households and make the Lightning Network a preferred method for daily small and frequent payments, it is particularly essential to introduce stablecoin support. After all, in real life, people are accustomed to using currencies with stable value for everyday transactions.

To address this, on July 23, 2024, Lightning Labs launched the first mainnet version of the multi-asset Lightning Network, officially introducing Taproot Assets to the Lightning Network. Taproot Assets is an asset issuance protocol on Bitcoin, allowing issued assets to be deposited into Lightning Network payment channels and transferred through the existing Lightning Network. The launch of the multi-asset Lightning Network mainnet version marks the formal support of stablecoins on the Bitcoin Lightning Network, paving the way for applications such as global instant settlement forex trading via the Lightning Network and using stablecoins for purchasing goods.

Image: In the Lightning Network, Alice sends a USD stablecoin, and Bob receives a EUR stablecoin.

In addition, Nervos CKB has launched the Fiber Network for the Lightning Network, which leverages the flexibility of the CKB blockchain to natively support user-defined assets, including Bitcoin-native stablecoins minted by decentralized protocols like Stable++. In the fully functional test version released in September, developers can already test the Bitcoin-native stablecoin RUSD using the Fiber Network.

We believe that the integration of the Lightning Network and stablecoins will unleash powerful synergies, injecting new vitality into the Lightning Network and promoting the widespread adoption of crypto payments in everyday life.

User Experience

Despite significant technological advancements in the Lightning Network, there is still room for improvement in user experience, particularly when compared to traditional payment experiences. Some key gaps include:

Requirement to Stay Online for Payments

Users are required to remain online when receiving or sending payments on the Lightning Network. This is because Lightning Network payments involve changing the state of funds in a channel that is shared with others, meaning both parties must be online to alter the state of the funds together. One major reason for payment failures in the Lightning Network is that the recipient is offline. From a user experience standpoint, this is a significant design flaw. In contrast, traditional payment methods (such as bank transfers) and blockchain payments (like on-chain USDT transfers) do not require the recipient to be online; transactions can be completed simply by knowing the recipient’s account or address.

The current primary solution is to introduce Lightning Network Service Providers (LSPs). LSPs can receive payments on behalf of offline users, eliminating the strict requirement to “stay online.” This solution brings the user experience of the Lightning Network closer to that of existing payment methods, significantly enhancing its practicality and convenience.
However, this solution also introduces a new challenge: trust assumptions. Users need to place a certain degree of trust in their chosen Lightning Network service provider. This reliance on third parties somewhat contradicts the original intent of decentralization and may raise concerns among some users.

Lack of a system for accepting multiple payments of any amount

Invoices in the Lightning Network are the core tool for requesting payments. They are generated by the payment recipient and provide the initiator with all the information needed to complete the transaction. We can simply liken invoices to the “payment codes” commonly found in payment apps.

Currently, the default invoice in the Lightning Network is one-time use only, containing a hash value for a single payment along with its amount. Once the payment is successful or the invoice times out, it becomes invalid. This mechanism results in a cumbersome process: every payment requires generating, copying, pasting, and sending a new invoice to the payer. This design significantly impacts user experience in certain scenarios. For instance, a merchant accustomed to displaying a payment QR code (like those from WeChat or Alipay) would find using the Lightning Network cumbersome. Particularly during busy business hours, the need to frequently generate and share invoices could substantially decrease efficiency and even affect normal operations.

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

Keysend

The node_id of Lightning Network nodes remains unchanged and is exposed to the payer after an invoice is given, so Keysend treats it as a static endpoint. This method has a significant advantage: it relies entirely on the Lightning Network’s architecture without requiring additional protocol support. Its drawback is that it offers weaker privacy protection, as sensitive data such as the recipient’s node, channel, and channel UTXO are exposed.
Nevertheless, the practicality of Keysend has been widely recognized, and most Lightning Network clients have already implemented Keysend functionality.

LNURL and Lightning Address

LNURL-pay is a standard that allows users to create a static QR code capable of receiving multiple payments, significantly enhancing the user experience. The workflow is as follows:

1. The user scans the QR code (LNURL-pay) using a Lightning Network wallet.
2. The wallet decodes the QR code, obtaining the URL and accessing it via HTTPS.
3. After responding, the server asks for the payment amount (which can also be a fixed amount).
4. The user inputs the amount and sends the information back to the server.
5. The server returns a traditional Lightning Network invoice.
6. The wallet processes the payment.

Lightning Address further optimizes this process by encoding the user’s QR code (LNURL-pay) into a URL resembling an email address. When other users access this URL, the system automatically returns an LNURL-pay request, simplifying the entire payment flow.

It’s worth noting that most wallets implementing LNURL functionality currently operate in a custodial mode. These wallet services assign each user a Lightning Address, enabling them to easily receive payments. While this approach offers convenience, it also introduces a degree of centralization, requiring users to weigh the trade-off between convenience and decentralization.

BOLT12

BOLT12 is a new proposal for a Lightning Network technical specification aimed at achieving some of the functionalities offered by LNURL without relying on a web server. Although BOLT12 has not yet been merged into the BOLT (the technical foundation of the Lightning Network), it has garnered support from most developers. The main highlight of BOLT12 compared to LNURL is that it can be implemented within the Lightning Network protocol itself, without needing to depend on other network protocols or communication methods.

Conclusion

In addition to the overall liquidity issues and liquidity distribution problems mentioned in the previous article, and the lack of stablecoin support discussed in this piece, there are many areas for improvement in user experience within the Lightning Network. The development path of the Lightning Network also faces numerous other challenges. For example, the LN-Penalty mechanism used in the Bitcoin Lightning Network not only adds complexity but also imposes storage burdens. Implementing the proposed improvement, eltoo, requires a soft fork of Bitcoin and the introduction of a new signature hash type. Similarly, privacy concerns regarding HTLCs may see improvements through PTLCs, which could first be implemented on Lightning Networks of other blockchains.

Although the road ahead is challenging, continuous technological advancements and sustained community efforts will eventually overcome these obstacles. We have every reason to believe that the Lightning Network is getting closer to its goal of widespread adoption. It will not only transform crypto payments but also has the potential to become a key driver of global financial innovation.

Disclaimer：

1. This article is reprinted from [RGB++ Fans]. All copyrights belong to the original author [Byte CKB]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.