Author: Ben, founder of Discoco Labs

Introduction

For an extended period, I have been pondering a key question: What is the fundamental logic behind Bitcoin’s native scalability?

While studying the Lightning Network and attempting to implement non-custodial services, we have noticed some inconsistencies. The peer-to-peer (P2P) model, known as “LN-Penalty,” theoretically offers the highest transaction throughput. However, in practice, it presents many usability challenges than expected and requires plenty of maintenance. Currently, the Lightning Network has not fully achieved its original vision of micro-payments as promised, and the main reason for this is the lack of liquidity. Even though numerous infrastructures aimed at improving liquidity have been introduced, the actual results still fell short of the industry’s expectations.

During the composition of this article, Mutiny Wallet, a well-known self-custodial wallet in the industry, announced its closure. Shortly after, its partner, the Liquidity Service Provider (LSP), also ceased operations. The collaboration between self-custodial wallets and LSPs has long been seen as an important direction for the future of the Lightning Network. Therefore, at this point, this paper will explore the evolution and future trends of channel networks from the perspective of liquidity scaling.

1. Current Problems with Lightning Network

The Lightning Network is regarded as a crucial solution for Bitcoin scalability due to Bitcoin’s limited block size and the relatively long block time on the mainnet, averaging around 10 minutes. These limitations make it challenging for Bitcoin to function as a global peer-to-peer cash system.

Given this, there is an urgent need for a Bitcoin-native scaling solution that occupies minimal block space and allows for rapid settlement. Consequently, the Lightning Network was developed and has become a significant player in the landscape of Bitcoin scalability.

However, as the Lightning Network has developed and been used in practice, several issues have gradually emerged. This article summarizes four core problems:

1.1 High Difficulty in Node Maintenance

The current Lightning Network is based on a P2P penalty transaction game model. This model requires WatchTowers to be online at all times to continuously monitor whether the counterparty attempts to broadcast an outdated state that disadvantages the user during the channel’s lifetime. This necessitates users maintaining their own nodes. Additionally, users must locally store penalty private keys and commitment transaction data, resulting in high barriers for node maintenance and increased educational costs.

1.2 High Interactivity

Interactivity refers to the series of actions users must perform during transactions. These actions often involve signing, exchanging commitment transactions, and managing penalty private keys. For example, every time an off-chain state is updated, both parties must be online simultaneously to sign and exchange new commitment transactions, imposing strict interactivity requirements on users. Furthermore, the complexity introduced by Hash Time-Locked Contracts (HTLCs) and multi-hop transactions in multi-party interactions is difficult to manage.

1.3 Low Capital Efficiency

The LN-Penalty mechanism in P2P channels is somewhat analogous to users opening their own bank accounts, requiring them to provide their own reserves. A common issue is that when users receive funds, they also need to ensure channel liquidity, leading to low capital efficiency. Additionally, the liquidity in many peripheral channels is not fully utilized, further diminishing capital efficiency.

1.4 High Channel Management Costs

In P2P channels, liquidity imbalances are very common, forcing users to rely on various tools to replenish liquidity, such as submarine swaps and channel stitching. However, these techniques require additional on-chain transactions to adjust the original FundingTx. Overall, all these adjustment methods are costly, especially when transaction fees rise, making the costs too high to ignore.

Imagining users who expect to conduct inexpensive transactions using Layer 2 technology suddenly face several on-chain transaction fees. This predicament becomes more pronounced as mainnet transaction fees increase, aptly termed the “fee assassin.”

All these issues have led to noticeable consequences in the actual adoption of the Lightning Network: user growth has been sluggish, and most new users opt for custodial solutions, as shown in the statistical data below.

It is easy to understand the reasons behind this situation, as maintaining their own nodes and channels is simply too challenging for most ordinary users.

2. What kind of Off-Chain Scaling Network for Bitcoin Do We Need?

According to the Lightning Network whitepaper, if everyone in the world were to open and close two channels annually, Bitcoin’s block capacity would need to increase to 133MB. In contrast, the current Bitcoin mainnet has a block size of only 1MB, and even with Segregated Witness (P2TR) addresses, the capacity is merely 4MB, highlighting a significant gap. Additionally, considering that techniques for adjusting channel liquidity in practice require extra on-chain transactions, the issue of insufficient block space makes the challenges for the Lightning Network even more severe in real-world scenarios.

The existing Lightning Network cannot meet the demands of a large-scale customer base in the short term. Furthermore, constrained by Bitcoin’s block capacity, the Lightning Network’s long-term scalability potential is also significantly limited.

This raises the question: What type of off-chain scaling network for Bitcoin do we truly need?

2.1 Current Status of the Lightning Network

To understand the current limitations of the Lightning Network, it is essential to revisit its design principles.

The present Lightning Network model is also referred to as LN-Penalty. Essentially, this model is a P2P channel model based on penalty transactions. Its security relies on users locally storing the counterparty’s transactions and penalty private keys, as well as continuously monitoring the Bitcoin blockchain to ensure that every action of the trading counterpart is under their supervision.

Under such a model design, it is unavoidable for users to run their own nodes because local storage and WatchTower functionalities are indispensable. This aspect has been repeatedly emphasized in previous sections.

From the perspectives of capital and transport efficiency, the currently prevalent Lightning Network model involves an LSP supernode offering liquidity centrally, with users establishing channels with the LSP maintainer’s supernode. This inherently deviates from the initially envisioned P2P mesh model. In its natural evolution, it ultimately reverts to the classic hub-and-spoke model.

The following figure exemplifies this, with the left side depicting the ideal Lightning Network and the right side illustrating its actual current state.

2.2 Characteristics of an Ideal toC Off-Chain Scaling Network

Let us now envision the characteristics that a Bitcoin off-chain scaling network truly required by customer (toC) users should possess:

1. Adoption of a non-P2P model, where users are not required to maintain their own nodes while still ensuring robust security and user convenience.

2. On the interactive front, users do not need to be online simultaneously when making payments; one party can be offline, and asynchronous operations are achievable.

3. Enhanced capital efficiency while fulfilling non-custodial requirements.

4. A cost-effective and efficient liquidity management mechanism, potentially eliminating the need for users to manage liquidity themselves.

Based on these objectives, this article will guide readers in exploring the future development directions of Bitcoin off-chain scaling networks.

3. The Evolution Path of Native Bitcoin Scalability

First, it is essential to clarify that in the current core mechanism of the Lightning Network design, known as LN-Penalty, the foundation of the state update mechanism is based on:

• The storage and continuous monitoring of commitment transactions

• The multi-hop mechanism (HTLC/PTLC) for collaboration across multiple participants

These elements constitute the basis of the current Lightning Network design and directly contribute to the complexity of node design, manifesting as:

• Complex encrypted communication interactions

• Local storage of commitment transactions and penalty private keys

• WatchTower must remain operational continuously during the channel’s lifetime

These issues lead us to consider whether a more light state update mechanism can replace LN-Penalty. In this context, BIP118 (SIGHASH_ANYPREOUT) has been proposed as a potential alternative solution.

3.1 LN-Symmetry: Introducing a Version Mechanism in State Updates

BIP118 proposes the introduction of the SIGHASH_ANYPREOUT signature mode, which allows transaction inputs to not fully specify previous outputs and to update their predecessor transactions without altering the signature. Compared to LN-Penalty, this design can significantly reduce the complexity of encrypted communications between nodes and the storage requirements. SIGHASH_ANYPREOUT originates from the paper eltoo: A Simple Layer2 Protocol for Bitcoin, and in recent Lightning Network development discussions, the Lightning Network model based on this improvement is also referred to as LN-Symmetry.

Although LN-Symmetry reduces the pressure on local commitment transaction storage, it does not entirely eliminate the need for monitoring. Although Eltoo does not require the exchange of commitment transactions and private key signatures, if a participant attempts to publish an outdated state to the blockchain, the other party still needs to monitor in real-time and promptly publish the latest state transaction to replace the old state. The monitoring task in this process still requires a traditional WatchTower, with the purpose of operating WatchTower shifting from punishment to state replacement. Users still need to maintain their own nodes.

Additionally, LN-Symmetry still requires mechanisms like HTLC/PTLC to ensure multi-party collaboration, which continues to impose significant communication burdens on the Lightning Network node design as before.

Therefore, overall, the improvements brought by LN-Symmetry to the current Lightning Network experience are limited, and we still have a long way to go to achieve our desired goals.

For further improvements, this article introduces the next phase: Shared UTXO.

3.2 CoinPool: Reducing Interactivity and Liquidity Requirements in Multi-Party Channels

The first paper to introduce the concept of Shared UTXO is CoinPool: efficient off-chain payment pools for Bitcoin, whose core objective is to further address the challenges of multi-party interactions under the SIGHASH_ANYPREOUT version update mechanism.

In the LN-Symmetry design, the new state update mechanism introduced by Eltoo indeed simplifies the state management of P2P channels. However, when it comes to multi-party collaboration, the complexity of interactions persists, especially in multi-hop payments (HTLC/PTLC), which require close coordination among parties and multiple rounds of encrypted communications.

CoinPool’s innovation lies in its utilization of the Shared UTXO model, allowing multiple parties to collaborate on the same UTXO with version control. This approach enables several participants to jointly commit to and manage the state of a UTXO without relying on complex HTLC/PTLC mechanisms. The main advantages are:

• Significantly Reducing the Interactivity Complexity of Multi-Party Channels: Since all participants share the same UTXO, they can reach consensus by signing version updates of that UTXO, eliminating the need for multiple on-chain transactions or intricate off-chain interactions. This simplification makes the management of multi-party channels more efficient.

• Making Off-Chain Update Mechanisms More Direct: In this design, the off-chain state update mechanism transforms into multi-party joint signatures confirming a specific version of the UTXO. This method not only streamlines the state update process but also further reduces dependencies and potential conflict points among parties.

• Eliminating Independent Liquidity Requirements: Through the Shared UTXO model, multiple participants effectively share a single liquidity pool, removing the necessity for each participant to maintain sufficient liquidity independently. In the multi-party collaborative design of CoinPool, liquidity needs can be significantly reduced or reallocated. Participants can utilize the liquidity within the shared UTXO to complete payments without having to lock substantial funds in their own channels. This not only enhances capital efficiency but also alleviates the financial burden on individual participants.

CoinPool’s design successfully minimizes the interactivity complexity in multi-party channels by sharing UTXOs while maintaining the system’s security and efficiency. More importantly, it reduces the reliance on each participant’s independent liquidity requirements, providing a lighter and more flexible solution for multi-party collaboration. This breakthrough overcomes the traditional LN model’s limitations in multi-party interactions and liquidity management.

However, given the significant advantages of this solution, why has it not been widely adopted to date? What are the root causes of this issue?

3.3 Why Has CoinPool Not Been Truly Implemented?

Despite its numerous advantages and is regarded as an ideal scaling model, CoinPool faces significant hurdles primarily due to its reliance on soft fork upgrades, making its implementation on the Bitcoin network unlikely within our lifetime. The soft fork upgrade requirements for CoinPool are mainly concentrated in the following two areas:

3.3.1 Upgrading the State Update Mechanism

CoinPool is based on the Eltoo design, inheriting its requirement for a soft fork upgrade to enable a new signature mode, SIGHASH_ANYPREVOUT(APO). However, as widely known, the progress of Bitcoin soft fork upgrades is slow, making the technical requirements for CoinPool’s state update mechanism challenging to apply in reality.

3.3.2 Simplifying the Operational Mechanism for Shared UTXO Covenants

As previously discussed, each state update of a Shared UTXO requires collecting signatures from all parties sharing a specific version of that UTXO. During this process, if any party goes offline, the entire system can become stalled, exhibiting poor system liveness in blockchain terms. To overcome this challenge, the system needs a mechanism that can update the Shared UTXO with lower costs and without entirely relying on cooperative updates.

In the CoinPool paper, OP_MERKLESUB was proposed to validate and update specific participants’ states using a Merkle tree structure. Although this design is theoretically feasible, it faces similar issues as other Merkle tree-based covenant operations, such as complex logical implementations and difficulties in forming universal, reusable covenants. Examples include covenants like OP_TAPLEAFUPDATEVERIFY (TLUV). Additionally, covenants functionalities like OP_EVICT, which directly remove non-cooperative parties from the Shared UTXO, are overly simplistic and unlikely to successfully pass Bitcoin network upgrades.

Among these covenant proposals, OP_CheckTemplateVerify (CTV) has gradually become the focal point. Unlike directly constructing and verifying a Merkle tree, CTV imposes spending restrictions through predefined transaction templates. CTV not only offers a simpler implementation but also allows a series of off-chain UTXOs to be committed via an on-chain UTXO through a transaction’s commitment chain. These on-chain committed off-chain UTXOs are the original concept of Virtual UTXO.

CTV is garnering the most attention among these covenant proposals because it is both simple and versatile. CTV’s powerful capabilities not only enable ideas similar to CoinPool but also make it applicable for Rollups. It is conceivable that each verification of ZKP-MerkelState using OP_CAT and directly committing the corresponding Layer 2 state Shared UTXO within the script could allow the construction of a genuine Bitcoin ZK-Rollup solution.

In summary, the primary obstacles to implementing CoinPool lie in the need for a light state update mechanism (APO) and operational codes for Shared UTXO, both of which require Bitcoin soft fork upgrades. As a result, even years after the CoinPool paper was published, it remains a theoretical proposal without practical implementation.

3.4 Bitcoin Clique: 2-AS, an Off-Chain Anti-Double-Spend Primitive

In the previous discussion of the CoinPool model, we observed that its dependence on the APO mechanism requires soft fork upgrades for implementation, which is unlikely to occur in the near future. However, if a new off-chain anti-double-spend primitive that does not rely on Bitcoin soft fork upgrades is available, many implementation challenges could be significantly mitigated.

The primary function of SIGHASH_ANYPREVOUT is to provide an off-chain state update mechanism that prevents double-spending. Building on this concept, discovering an equivalent cryptographic primitive could resolve the issues related to off-chain state updates while circumventing the need to update Bitcoin’s operational primitives. The emergence of the Bitcoin Clique paper brings new optimism. It introduces a novel cryptographic primitive, the 2-shot adaptor signature (2-AS), offering a fresh solution for off-chain anti-double-spending.

2-AS is a cryptographic primitive based on the Schnorr adaptor signature. To comprehend 2-AS, we must first understand the fundamentals of Schnorr signatures and adaptor signatures.

3.4.1 Schnorr Signatures

Schnorr signatures exhibit linear properties, meaning multiple signatures can be aggregated into a single signature. In simple terms, given multiple signatures $\(S_1\)\( and \)\(S_2\)\(, they can be aggregated through addition into a single signature \)\(S = S_1 + S_2\)\(, and during verification, the corresponding public keys can be aggregated as \)\(P = P_1 + P_2\)$.

3.4.2 Adaptor Signatures

Adaptor signatures involve several fundamental steps, including Gen, PSign, PVrfy, Adapt, and Extract. When understanding 2-AS, it is particularly important to grasp the PSign and Extract steps.

This paper focuses on understanding adaptor signatures from a practical application perspective rather than a cryptographic one. Essentially, when two parties wish to collaboratively confirm a signature, they often use each other’s adaptors as part of the signature. The adaptor typically comprises the public key component of the key pair, and the party holding the corresponding adaptor private key (the so-called secret) has the capability to Adapt and complete the partial signature left by PSign. If it were only this, it would be similar to MuSig. However, the uniqueness of adaptor signatures lies in the ability to Extract. That is, once the complete signature is released, the party who initiated the adaptor signature (the PSign party) can extract the corresponding secret (private key) using the complete signature, the previously partial signature, and the adaptor (public key).

3.4.3 Combining Both: 2-AS

Having understood the features of Schnorr signatures and adaptor signatures, we can now explore their combination: 2-AS.

Suppose we have a Virtual UTXO (VTXO) and wish to ensure that double-spending off-chain can be penalized. We can design it as follows:

• Penalty Output: First, we need a penalty output where the unlockable Pubkey is a penalty public key. This ensures that users can be penalized if they attempt double-spending.

• Collaborative Adaptor Signatures: The transaction counterparts collaboratively perform adaptor signatures to confirm off-chain transactions. If a user attempts to use the same input twice, the service provider can penalize the output.

• Penalty Pubkey Generation: Users are required to generate a Pubkey as a penalty output each time they update the state. This penalty Pubkey is constructed by aggregating two pre-determined key pairs using Schnorr signature aggregation.

Therefore, before each transaction, we confirm the public-private key pairs to be used subsequently and pre-generate the penalty output. Thus, once double-spending occurs, the service provider can ultimately obtain the corresponding private key for the penalty output through two adaptor signatures.

3.4.4 Pros and Cons of Bitcoin Clique

The Bitcoin Clique solution is not without its imperfections. Its primary drawback lies in the necessity to continuously exchange 2-AS keys used for constructing new penalty public keys during off-chain state updates. Moreover, because this solution is based on the CoinPool design, each state update requires the exchange of 2-AS keys and the verification signatures of new UTXO versions, necessitating that all participants be online during state updates.

The most critical aspect is that this model resembles a StateChain design, where each off-chain transfer involves the ownership of a specific UTXO. Consequently, systems employing double-spend-prevent signatures akin to 2-AS cannot perform change transactions in off-chain payments, thereby significantly limiting their application scenarios.

Furthermore, even with the introduction of a user-friendly Shared UTXO mechanism and off-chain anti-double-spend primitives that do not require soft fork upgrades, it remains necessary for all participants to be online to update and confirm the new state of the UTXO. This requirement persists even when a state update affects only a subset of the off-chain network. Requiring unrelated parties to participate online for on-chain updates is impractical. Additionally, completely eliminating liquidity requirements is not desirable; payment solutions lacking liquidity smoothing cannot perform change transactions, and due to exit issues, all participants typically need to maintain the same denominations.

Therefore, a non-channel-based off-chain scaling solution that supports dynamic denominations and is based on UTXOs does not currently exist. Ethereum has also struggled along this path, leading to what is referred to as the Plasma trap. Relevant research can be found in the paper Lower Bounds for Off-Chain Protocols: Exploring the Limits of Plasma.

Summary of Issues and Lessons:

1. Liquidity smoothing is necessary to ensure dynamic denomination payments (change transactions): This requires retaining channel designs and simultaneously avoiding exit issues.

2. Reducing dependence on all participants being online simultaneously: It is undesirable for every user to be online when performing any state updates in the off-chain network. Updates to Shared UTXOs should be collaboratively conducted by the relevant parties online.

Based on these insights, this paper continues to explore more optimized solutions in this direction.

3.5 Channel Factory and Virtual Channels

In our previous discussion, we recognized the necessity of retaining the channels’ design and leveraging Shared UTXO to achieve low-cost off-chain benefits. This introduces a long-discussed concept within the Lightning Network domain: the Channel Factory.

Earlier, we mentioned that off-chain UTXOs committed by on-chain UTXOs are referred to as Virtual UTXOs. By using an off-chain Virtual UTXO as the FoundingTx of a channel, we arrive at a new concept: Virtual Channels. In this Shared UTXO, off-chain Virtual Channels are connected via Virtual HTLCs. Everything operates off-chain, fully “virtualized.” This appears to offer an ideal solution: implementing most functionalities off-chain, including liquidity adjustments, thereby seemingly resolving the scalability challenges of the Lightning Network.

But is the reality as promising as it seems?

Due to the inherent characteristics of Shared UTXO, Channel Factories require the collaborative effort of multiple users to open and close channels. If any user fails to cooperate promptly (e.g., due to being offline or unresponsive), it can impair the functionality of the entire Channel Factory. Since Channel Factories involve multi-party joint signature state updates, any desynchronization or malicious behavior by one party can prevent other users from smoothly closing channels and extracting funds.

Furthermore, the design issues are evident. Although this approach reduces the cost of opening and closing channels, the security model between channels still relies on commitment transactions and HTLCs. Therefore, communication and interaction challenges persist, and the implementation complexity of this solution is even greater than that of the current LN-Penalty.

3.6 ARK JoinPool and Ephemeral Channel

From our previous review of the Channel Factory case, we reach the conclusion that in channel designs based on Shared UTXO, it may not be advisable to continue using the classic LN-Penalty channel design. However, it is essential to retain the advantages introduced by channels:

1. Dynamic Denominations due to Liquidity

2. Ease of Exit

Based on this, a design utilizing ephemeral channels through JoinPool has emerged, known as the ARK Protocol.

3.6.1 JoinPool: Partial Participation in Updates

As previously mentioned, CoinPool offers the potential for multi-party off-chain scaling without the complexities and vulnerabilities associated with liquidity management, multi-hop payments, and HTLCs. However, the most critical issue with the CoinPool model is its requirement for users to remain online: all users within the Shared UTXO must be online during off-chain state updates. Even if some users’ states remain unchanged, they still need to be online to verify and provide the corresponding signatures. This requirement perpetuates the unavoidable need for users to run their own nodes.

To address this challenge, a new model called JoinPool has been proposed. The core idea of JoinPool within Shared UTXO is that whenever a user needs to update their off-chain state, they collectively join into a Shared UTXO that represents the new state of their corresponding UTXO. This resolves the issue of unrelated users needing to be online when others are performing updates. In other words, in the JoinPool-based design, users only need to be online when they are initiating a transaction.

However, it is well understood that continuously running Lightning Network nodes not only requires ensuring that users’ private keys are online for signing but also necessitates that each channel member relies on WatchTowers to constantly monitor whether their counterparties are attempting to publish unfavorable commitment transactions on the blockchain. This introduces the second problem we need to address.

3.6.2 Shift in WatchTower Responsibilities: Users No Longer Need to Maintain Their Own Nodes

In the classic LN-Penalty design, each user is required to set up their own WatchTower to monitor whether their counterparties attempt to publish outdated states on the blockchain, in which case they would be penalized. In this traditional model, all counterparties are equal Lightning nodes, and each transaction may involve opening channels with different nodes.

However, in the ARK Protocol, all users interact with an ASP (ARK Service Provider) rather than directly with other users. For the ASP, once a user’s off-chain Virtual UTXO (VTXO) is involved in a transaction, the user signs a waiver transaction. Ideally, the user’s off-chain VTXO is never published on-chain but is continuously referenced in subsequent transactions. If a VTXO is both spent off-chain and maliciously published on-chain, it constitutes a double-spend attempt by the user. In such cases, the ASP uses the previously signed waiver transaction to penalize the user by seizing the funds published on-chain. The ASP monitors all historical VTXOs to prevent malicious actors from withdrawing spent VTXOs on-chain.

This effectively transfers the operational responsibility of running WatchTowers from ordinary users to the ASP. Compared to the Lightning Network, this represents a significant improvement: users no longer need to operate their own nodes to ensure their security.

Summary of Other Solutions in Optimizing User Node Operations：

• Cloud Custodial of Lightning Network Nodes

Some solutions opt to run Lightning Network nodes on cloud platforms to help users lower the barrier to operating nodes. However, this approach fundamentally violates the security assumptions of the Lightning Network itself. In Lightning Network technology, the storage of private keys and commitment transactions is equally important in many scenarios. Therefore, simply using remote private keys does not guarantee security.

Essentially, this approach transforms a two-party game into a three-party game involving the user, the counterparty, and the cloud custodial provider. For instance, if the user engages in a transaction with a counterparty and the state has not yet been broadcast on-chain, the cloud custodial provider could unilaterally delete the commitment transactions stored on the user’s cloud node. This would allow the counterparty to broadcast a favorable state on-chain. In other words, in such cloud custodial Lightning Network node solutions, there is a risk of collusion between the cloud service provider and the counterparty.

• CRAB and Sleepy CRAB

In the CRAB ( Channel Resistant Against Bribery) protocol proposed by Aumayr et al., the security of payment channels is ensured by adding collateral combined with incentives for miners, particularly in scenarios where users are offline. This mechanism reduced the reliance on third-party WatchTower. However, this collateral mechanism intensifies “inbound liquidity” problems by obligating users to lock more funds unrelated to their transactions when entering the off-chain network. Although it ensures security, it sacrifices the liquidity and efficiency of the funds. Furthermore, such solutions still require users to run their own nodes, merely reducing the requirement for users to be online.

3.6.3 Ephemeral Channels: Users No Longer Need to Maintain Channel Liquidity

Some may ask why ASP service providers are willing to inject liquidity into our channels within the JoinPool. The reason is that if users want to utilize VTXOs within the ARK network, they must first securely deposit their funds with the service provider in exchange for VTXOs. Essentially, every transaction the user conducts is using their own funds. Once an on-chain UTXO is deposited into the ARK network, the resulting VTXO serves as the user’s off-chain transaction credential.

The term ephemeral channel is used to describe ARK channels because they exhibit two key characteristics: unidirectionality and one-time funding.

• Unidirectionality: In a unidirectional channel, funds flow only from the designated initiator to the specified recipient.

• One-Time Funding: ARK channels require only a one-time injection of funds. After funding, there is no need to continuously maintain the channel’s liquidity.

With this design of ephemeral channels, once the funding is complete, liquidity providers no longer need to maintain the channels. Compared to the Lightning Network, not only do users no longer need to worry about channel liquidity, but liquidity providers also do not need to manage channel liquidity. The only change remaining in ARK channels is the user’s exit event.

3.6.4 Summary of the ARK Protocol

In summary, the design of the ARK Protocol demonstrates remarkable advancements in user experience compared to the Lightning Network:

• No Need for Users to Maintain Their Own Nodes: Users are relieved from the responsibility of running and maintaining their own nodes, simplifying their interaction with the network.

• No Need for Users to Maintain Channel Liquidity: Users do not have to manage the liquidity of their channels, eliminating issues related to inbound liquidity.

• Support for Asynchronous Interactions: The protocol allows for asynchronous interactions, meaning that both parties do not need to be online simultaneously to conduct transactions.

Furthermore, the ARK Protocol fundamentally differs from the current Lightning Network in terms of capital efficiency. In the LN-Penalty model, each user must provide their own liquidity when opening a Lightning channel. However, the liquidity in these channels is often idle for most of the time (since payments do not always occur, and even when they do, they are not evenly distributed across all channels), resulting in inefficient returns for users. In contrast, the ARK Protocol centralizes liquidity management within a single liquidity pool. This centralized approach opens up limitless possibilities for future scenarios such as “interest-bearing income” and “asset appreciation,” allowing for more effective capital utilization and potential growth.

4. Shifting Paradigms in Native Bitcoin Scalability

Through our previous research, we have explored multiple off-chain scaling solutions based on Shared UTXO and identified the significant potential of Bitcoin’s off-chain scalability within the ARK Protocol. The original intent behind the Shared UTXO design was to address liquidity challenges. However, as the protocol has continuously evolved, we have identified numerous unforeseen advantages that exceeded our initial expectations.

This advancement signifies a new direction for Bitcoin’s off-chain scalability, representing a paradigm shift from the traditional Lightning Network model:

• The transition from the P2P Model to Trustless Operators

Off-chain scaling networks have evolved from the Lightning Network’s original “user-to-user” bilateral interaction model to a “user-to-operator” model. The primary distinction is that users no longer need to place trust in third-party operators.

• Users No Longer Required to Manage Node for Asset Security

Traditional LN-Penalty models and recent studies, such as CRAB, require users to provide collateral to secure funds and maintain online nodes throughout the channel’s duration. Future solutions will eliminate these operational requirements while preserving a non-custodial structure, ensuring that users retain control over their assets.

• Shift of Liquidity Management Responsibilities from Users to Operators

In the classic LN-Penalty model and its derivatives, users must manage channel liquidity on their own, especially during instances of liquidity imbalance. This process often necessitates specialized knowledge and is complex without assistance from a Liquidity Service Provider (LSP). By transferring liquidity management responsibilities to third-party operators, users are relieved of this burden, thereby simplifying the user experience and reducing barriers to network participation.

• Enhanced Capital Efficiency and Potential

ARK’s P2POOL model fundamentally differs from the current Lightning Network in terms of capital efficiency. In the LN-Penalty model, each user must supply their own liquidity when opening a Lightning channel. However, liquidity in these channels is frequently underutilized due to infrequent and unevenly distributed payment, leading to inefficient use of user funds. In contrast, the ARK Protocol centralizes liquidity management within a liquidity pool, enabling future possibilities such as interest-bearing income and asset appreciation. This centralization facilitates more effective capital utilization and growth potential.

These paradigm shifts underscore that liquidity management is central to the evolution of Bitcoin’s native off-chain scalability and remains a core focus for future developments.

As technology continues to advance and new solutions emerge, Bitcoin’s path toward off-chain scalability appears increasingly promising. We will persist in conducting in-depth research in this domain, and readers can anticipate further advancements from our work.

References

• Poon, J., & Dryja, T. (2016). The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments. Retrieved from https://lightning.network/lightning-network-paper.pdf

• Decker, C., Russell, R., & Osuntokun, O. (n.d.). Eltoo: A Simple Layer2 Protocol for Bitcoin. Blockstream. Retrieved from https://blockstream.com/eltoo.pdf

• Naumenko, G., & Riard, A. (n.d.). CoinPool: Efficient off-chain Payment Pools for Bitcoin. Retrieved from https://coinpool.dev/v0.1.pdf

• Delving Bitcoin. (n.d.). LN-Symmetry Project Recap. Retrieved from https://delvingbitcoin.org/t/ln-symmetry-project-recap/359

• Riahi, S., & Litos, O. S. T. (2024). Bitcoin Clique: Channel-free Off-chain Payments using Two-Shot Adaptor Signatures. Cryptology ePrint Archive, Report ²⁰²⁴⁄₀₂₅. Retrieved from https://eprint.iacr.org/2024/025

• Dziembowski, S., Fabiański, G., Faust, S., & Riahi, S. (2020). Lower Bounds for Off-Chain Protocols: Exploring the Limits of Plasma. Cryptology ePrint Archive, Report ²⁰²⁰⁄₁₇₅. Retrieved from https://eprint.iacr.org/2020/175

• ARK Network Blog. (n.d.). Retrieved from https://github.com/ark-network/arkdev.info/tree/master/blog

• Somsen, R. (n.d.). Simplest Ark Explanation. Retrieved from https://gist.github.com/RubenSomsen/a394beb1dea9e47e981216768e007454?permalink_comment_id=4633382

• BRQGoo. (2023). Introducing ARK. Medium. Retrieved from https://brqgoo.medium.com/introducing-ark-6f87ae45e272

• Shinobi. (n.d.). Timeout Trees: A Solution to Scaling Lightning Network LSPs. Bitcoin Magazine. Retrieved from https://bitcoinmagazine.com/technical/timeout-trees-a-solution-to-scaling-lightning-network-lsps

• JohnLaw2. (n.d.). LN Scaling Covenants. GitHub Repository. Retrieved from https://github.com/JohnLaw2/ln-scaling-covenants

• JohnLaw2. (n.d.). LN Factory Optimized. GitHub Repository. Retrieved from https://github.com/JohnLaw2/ln-factory-optimized

• Rubin, J., & O’Beirne, J. (2020). BIP-119: CHECKTEMPLATEVERIFY. Bitcoin Improvement Proposal. Retrieved from https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki

• Black, B. (2023). [bitcoin-dev] Combined CTV+APO to minimal TXHASH+CSFS. Linux Foundation Mailing List. Retrieved from https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021907.html

• Aumayr, L., Avarikioti, Z., Maffei, M., & Mazumdar, S. (2021). Sleepy Channels: Bitcoin-Compatible Bi-Directional Payment Channels that Do Not Require Monitoring. Cryptology ePrint Archive, Report ²⁰²¹⁄₁₄₄₅. Retrieved from https://eprint.iacr.org/2021/1445

• Aumayr, L., Avarikioti, Z., Maffei, M., & Mazumdar, S. (2024). Securing Lightning Channels against Rational Miners. Cryptology ePrint Archive, Report ²⁰²⁴⁄₈₂₆. Retrieved from https://eprint.iacr.org/2024/826.pdf

• Todd, P. (2024). Covenant-Dependent Layer 2 Review. Retrieved from https://petertodd.org/2024/covenant-dependent-layer-2-review