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 allocation 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 areas: 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 more applications, with the number and amount of payments rapidly increasing, 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 major barrier to the widespread application 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 are accustomed to using stable-value currencies for daily payments in real life.

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 mainnet version of the multi-asset Lightning Network marks the formal support for stablecoins on the Bitcoin Lightning Network, meaning that application scenarios such as achieving global instant settlement for foreign exchange transactions through the Lightning Network and directly paying for goods with stablecoins via 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 like Stable++. In the complete test version released in September, developers can already test the Bitcoin-native stablecoin RUSD using the Fiber Network.

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 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 (like on-chain USDT transfers) only require knowledge of the other party's address, without needing them to be online continuously.

The current solution is to allow Lightning Network Service Providers (LSPs) 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 payments, and the recipient provides the necessary information to the initiator through the invoice to assist with the payment. The invoice can be simply understood as a "payment code" commonly used in payment software (a more accurate analogy would be a payment receipt). Currently, the default invoice in the Lightning Network is one-time use, containing a hash value and its denomination for a single payment, which becomes invalid after a successful payment or timeout. This means that each time a payment is received, the invoice must 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 peak business times.

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

Keysend#

Keysend takes advantage of the fact that a node's node_id does not change and will be exposed to the payer after the invoice is given, allowing it to serve 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, channels, and channel UTXOs will be exposed.

Currently, most Lightning Network clients have implemented Keysend functionality, although users may need 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 users scan the QR code (LNURL-pay) with their Lightning Network wallet, the wallet decodes the QR code, obtains a 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 encodes the user's QR code (LNURL-pay) into a URL similar to an email address, allowing others to access this URL and receive a response as an LNURL-pay request. Currently, most wallets implementing LNURL are custodial wallets, which assign each user a Lightning Address to allow payments to be received using the Lightning Address.

BOLT12#

BOLT12 (Lightning Network Technical Specification 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. However, with continuous technological advancements and ongoing efforts from the community, these challenges will be gradually overcome. For example, the LN-Penalty used in 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, the improvement plan PTLC may be implemented and experimented with on Lightning Networks of other blockchains first.

The Lightning Network is undergoing a process of continuous optimization and growth. 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 中文