From the perspective of liquidity expansion, this article explores the evolution of channel networks and their future development trends.

Written by: Ben, founder of Discoco Labs

Introduction

For a long time, I have been pondering a question: What is the core logic of Bitcoin's native scalability?

In-depth research on the Lightning Network and attempts to implement non-custodial services on it have revealed certain inconsistencies. Theoretically, two-party channels have the strongest transaction throughput, but the actual maintenance and usage issues are far more than expected. The Lightning Network's performance in its initial vision of micropayments has been disappointing, primarily due to liquidity. Even with a large number of so-called liquidity-improving infrastructures being introduced, the actual effects have still not met expectations.

During the writing of this article, the well-known Lightning self-custodial wallet Mutiny Wallet announced its closure, followed by the end of operations of its partnered Liquidity Service Provider (LSP). The collaboration model between self-custodial wallets and LSPs has long been considered an important direction for the future of the Lightning Network, which inevitably raises concerns about its future once again. Therefore, at this point in time, this article will explore the evolution of channel networks and their future development trends from the perspective of liquidity expansion.

---

1. What are the current issues with the Lightning Network?

Bitcoin's block capacity is limited, and the average block time on the mainnet is about 10 minutes, which is clearly far from the requirements for it to become a global peer-to-peer cash system. Given this, we urgently need a scalability solution: it must occupy little block space, allow for quick settlement, and must be a native Bitcoin-based solution. Thus, the Lightning Network was born.

The Lightning Network defines that after locking assets on-chain, the exchange of a commitment transaction off-chain is considered a completed transaction, which is why it claims to offer instant payments. This experience is undoubtedly a solution to the primary issue for small payment scenarios compared to the 10-minute confirmation time limited by Bitcoin's mainnet payments.

However, during the actual development and use of the Lightning Network, 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. To monitor whether the other party is putting an unfavorable old state on-chain during the channel's existence, this model requires a WatchTower to be online at all times, which necessitates users to maintain their own nodes. Additionally, users need to locally store penalty private keys and commitment transaction data, leading to high maintenance thresholds and educational costs.

1.2 High Interactivity

In the Lightning Network, interactivity typically refers to a series of interactive operations that users need to perform during a transaction. These operations often involve signing, exchanging commitment transactions, and penalty private keys. For example, each time the off-chain state is updated, both parties must be online simultaneously and sign a new commitment transaction for exchange, which places strict requirements on user interactivity. Moreover, during multi-party interactions, the complexities brought by HTLC and multi-hop are also difficult to overcome.

1.3 Low Capital Efficiency

The two-party channel's LN-Penalty mechanism is somewhat equivalent to users opening their own bank accounts, requiring them to bring their own reserves. A typical issue is that users need to ensure channel liquidity to receive funds, resulting in low capital efficiency. Furthermore, many marginal channel liquidity resources are not fully utilized.

1.4 High Channel Management Costs

In P2P channels, liquidity imbalance can easily occur, forcing users to rely on various tools to assist in supplementing liquidity, such as submarine swaps and channel stitching. However, these technologies require additional on-chain transactions to adjust the original FundingTx. Overall, all adjustment methods are costly, especially when transaction fees rise, making the costs hard for users to ignore.

Imagine the awkward situation for those who believe they are using Layer 2 technology for cheap transactions suddenly facing several on-chain fees on the mainnet. This awkwardness becomes more pronounced as on-chain fees on the mainnet increase, earning it the title of "fee assassin."

These various issues have also shown clear consequences in the actual adoption of the Lightning Network: user growth is sluggish, and most new users tend to choose custodial solutions, as can be seen from the statistics in the following chart.

It is not difficult to understand the reasons for this situation; after all, for most ordinary users, requiring them to maintain nodes and channels is simply too difficult.

2. What kind of Bitcoin off-chain expansion network do we need?

According to the description in the Lightning Network white paper, if everyone in the world opens and closes channels twice a year, the Bitcoin block capacity would ultimately need to grow to 133MB. In contrast, the current Bitcoin mainnet has a block size of only 1MB, and even with the use of SegWit P2TR addresses, it only reaches 4MB, highlighting the significant gap. Additionally, considering that the actual technical adjustments for channel liquidity (submarine swaps, channel stitching) require extra on-chain transactions, the Lightning Network faces an even more severe challenge regarding insufficient Bitcoin block space in real scenarios.

It is evident that the current Lightning Network is unlikely to meet the needs of large-scale C-end users in the short term. Furthermore, constrained by Bitcoin's block capacity, the long-term scalability potential of the Lightning Network is also significantly limited.

The question then arises: what kind of Bitcoin off-chain expansion network do we actually need?

2.1 Current State of the Lightning Network

To understand the current limitations of the Lightning Network, we need to trace back to its design principles.

The current Lightning Network model, also known as LN-Penalty, is essentially a two-party channel model based on penalty transactions. Its security relies on the local storage of counterbalancing transactions and penalty private keys by users, and it requires constant monitoring of the Bitcoin chain to ensure that every move of the counterparty is under their surveillance.

In such a model design, users running their own nodes is unavoidable, as local storage and WatchTower functionality are indispensable. This aspect has been repeatedly emphasized earlier.

From the perspective of capital and communication efficiency, the popular model of the current Lightning Network involves an LSP super node providing liquidity in the middle, and users then establishing channels with the LSP maintainer's super node, which deviates from the originally envisioned P2P mesh model. In a natural evolutionary scenario, it ultimately returns to the classic hub-and-spoke model.

The following diagram illustrates this: the left side represents the ideal Lightning Network, while the right side depicts the current state of the real Lightning Network.

2.2 Characteristics of an Ideal C-end Off-chain Expansion Network

Now, let us envision the characteristics that a truly needed Bitcoin off-chain expansion network for C-end users should possess:

1. Adopts a non-P2P model, allowing users not to maintain their own nodes while ensuring good security and convenience
2. On the interaction side, users do not need to be online simultaneously when making payments; one party can be offline, and asynchronous operations are possible
3. Improves capital efficiency while meeting non-custodial needs
4. Provides a cheap and efficient liquidity management mechanism, potentially eliminating the need for users to maintain liquidity themselves

Based on these goals, this article will guide readers in exploring the future development direction of Bitcoin's off-chain expansion network.

3. The Evolution of BTC Native Scalability

First, we need to clarify that in the current core mechanism of the Lightning Network design, LN-Penalty, the basis of the state update mechanism lies in:

• Storage and continuous monitoring of commitment transactions
• Multi-hop mechanisms for cross-party collaboration (HTLC/PTLC)

These elements constitute the foundation of the current Lightning Network design and directly lead to the complexity of node design, manifested as:

• Complex encrypted communication interactions
• Local storage of commitment transactions and penalty private keys
• The necessity of a WatchTower that cannot interrupt operation during the channel's existence

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

3.1 LN-Symmetry: Introducing Version Mechanism for State Updates

BIP118 proposes the introduction of the SIGHASH_ANYPREOUT signature mode, which allows transaction inputs to not fully specify previous outputs and enables updates to preceding transactions without changing the signature. This design can significantly reduce the complexity of encrypted communication and storage requirements between nodes compared to LN-Penalty.

SIGHASH_ANYPREOUT originates from the paper eltoo: A Simple Layer2 Protocol for Bitcoin, and in recent Lightning Network development discussions, the improved Lightning Network model based on this has also been referred to as LN-Symmetry.

Although LN-Symmetry reduces the pressure of local commitment transaction storage, it does not completely eliminate the need for monitoring. Even though Eltoo does not require the exchange of commitment transactions and private key signatures, if a participant attempts to publish an old state on-chain, 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 running the WatchTower shifting from punishment to state replacement. Users still need to maintain their own nodes.

At the same time, LN-Symmetry still requires mechanisms like HTLC/PTLC to ensure multi-party collaboration, which will still impose a significant communication burden similar to past Lightning Network node designs.

Therefore, from an overall effectiveness perspective, LN-Symmetry offers limited improvements to the current Lightning Network experience, and there is still a long way to go to achieve our desired goals.

To further improve, this article introduces the next phase of direction: 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, which aims to further address the issues of multi-party interaction 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 peer-to-peer channels. However, when it comes to multi-party collaboration, the complexity of interaction still exists, especially in multi-hop payments (HTLC/PTLC), which require close coordination among parties and multiple encrypted communications.

The innovation of CoinPool lies in its use of the Shared UTXO model, allowing multiple parties to collaborate on the same version-controlled UTXO. In this way, multiple participants can jointly commit to and manage the state of a UTXO without relying on complex HTLC/PTLC mechanisms. Its main advantages are reflected in:

• Significantly reducing the interaction complexity of multi-party channels: Since all participants share the same UTXO, they can reach consensus by signing the version updates of that UTXO without needing multiple on-chain transactions or complex off-chain interactions. This simplification makes the management of multi-party channels more efficient.
• Making the off-chain update mechanism more direct: In this design, the off-chain state update mechanism transforms into a process where multiple parties jointly sign to confirm a version of the UTXO. This method not only simplifies 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 the same liquidity pool, eliminating the need for each participant to independently maintain sufficient liquidity. In the multi-party collaborative design of CoinPool, liquidity requirements can be significantly reduced or reallocated. Participants can utilize the liquidity in the shared UTXO to complete payments without having to lock large amounts of funds for their own channels. This not only improves capital utilization efficiency but also reduces the financial pressure on individual participants.

The design of CoinPool successfully reduces the interaction complexity in multi-party channels to a reasonable level through the sharing of UTXO while maintaining the system's security and efficiency. More importantly, it reduces the reliance on independent liquidity requirements for each participant, providing a lighter and more flexible solution for multi-party collaboration, breaking through the limitations of traditional LN models in multi-party interaction and liquidity management.

However, why has such a significantly advantageous solution not been widely adopted to date? Where does the root of the problem lie?

3.3 Why CoinPool Has Not Been Truly Implemented?

Despite the numerous advantages of CoinPool and its recognition as an ideal scalability model, its reliance on soft fork upgrades requires so much that we may not see its implementation on the Bitcoin network in our lifetime. The demands for soft fork upgrades from CoinPool primarily focus on the following two aspects:

3.3.1 Upgrade of the State Update Mechanism

Since CoinPool is designed based on Eltoo, it inherits the need for a soft fork for the state update mechanism, specifically requiring the Bitcoin upgrade to enable a new signature mode SIGHASH_ANYPREVOUT (APO). However, as is well known, the progress of Bitcoin soft fork upgrades is slow, making the technology that CoinPool's state update mechanism relies on difficult to apply in reality.

3.3.2 Shared UTXO Requires Simplified Contract Operation Mechanism

As mentioned earlier, each state update of the Shared UTXO requires collecting signatures from all parties sharing a certain version of that UTXO. In this process, if one party goes offline, the entire system will come to a standstill, which, in blockchain terminology, means that the system's liveness is poor. To overcome this challenge, the system needs a mechanism that can operate at a low cost and does not fully rely on cooperative updates of the Shared UTXO.

In the CoinPool paper, OP_MERKLESUB is proposed, aiming to verify and update the state of specific participants through a Merkle tree structure. Although this design idea is theoretically feasible, it faces similar issues as other Merkle tree-based operational contracts, namely, complex logical implementation and difficulty in forming universal, reusable contracts. For example, contracts similar to OP_TAPLEAFUPDATEVERIFY (TLUV), etc. Additionally, contracts like OP_EVICT, which directly kick out non-cooperative parties from the Shared UTXO, are too singular and it is hard to foresee their smooth passage through Bitcoin network upgrades.

Among these contract proposals, OP_CheckTemplateVerify (CTV) has gradually become the focus of attention. Unlike directly constructing and verifying a Merkle tree, CTV imposes spending restrictions through predefined transaction templates. CTV is not only simple to implement but can also commit a series of off-chain UTXOs through an on-chain UTXO via a commitment chain of a transaction. The off-chain UTXOs committed on-chain are the initial origin of the Virtual UTXO concept.

Among these contracts, CTV has the loudest call for popularity due to its simplicity and universality. The powerful capabilities of CTV can not only realize ideas similar to CoinPool but also be used for Rollup. One can imagine that each time a ZKP-MerkleState verification is performed through OP_CAT, and the corresponding Layer 2 state of the Shared UTXO is directly committed in the script, we could build a truly meaningful Bitcoin ZK-Rollup solution.

In summary, the main issues facing the implementation of CoinPool lie in the need for a lightweight state update mechanism APO and opcode for Shared UTXO to facilitate implementation, both of which require a soft fork upgrade of Bitcoin. As a result, even years after the birth of the CoinPool paper, it remains a theoretical proposal.

3.4 Bitcoin Clique: Off-Chain Anti-Double-Spending Primitive 2-AS

In the previous discussion of the CoinPool model, we learned that its reliance on the APO mechanism requires a soft fork upgrade for the solution to be realized, which is difficult to achieve in the short term. So, if there were a new off-chain anti-double-spending primitive that does not rely on Bitcoin soft fork upgrades, the implementation issues would be largely resolved.

The core function of SIGHASH_ANYPREVOUT is to provide an off-chain state update mechanism that can avoid double spending. Based on this idea, if an equivalent cryptographic primitive can be found, it could solve the off-chain state update problem while avoiding the need for updates to Bitcoin operational primitives. The emergence of the paper Bitcoin Clique brings new hope. It introduces a brand new cryptographic primitive, the 2-shot-adaptor-signature (2-AS), providing a new solution for off-chain anti-double spending.

2-AS is based on the Schnorr adaptor signature cryptographic primitive. To understand 2-AS, we first need to have some understanding of Schnorr signatures and adaptor signatures.

3.4.1 Schnorr Signatures

Schnorr signatures have a linear property, meaning that multiple signatures can be aggregated into a single signature. In simple terms, if there are multiple signatures (S1) and (S2), they can be aggregated into a single signature (S = S1 + S2), and the corresponding public keys can also be aggregated into (P = P1 + P2).

3.4.2 Adaptor Signatures

Adaptor signatures have several basic steps, such as Gen, PSign, PVrfy, Adapt, and Extract. When understanding 2-AS, it is particularly important to grasp the Psign and Extract steps.

This article focuses on understanding adaptor signatures from a usage perspective rather than a cryptographic one. In short, when two parties wish to collaboratively confirm a signature, they often use each other's adaptor as part of the signature, where the adaptor is typically the public key part of the public-private key pair. The party holding the corresponding private key of that adaptor, known as the secret, has the ability to Adapt and complete the partial signature left by Psign. If it were just this, would it be similar to MuSig? However, the uniqueness of adaptor signatures lies in their ability to Extract, meaning that when the complete signature is released, the party that initiated the adaptor signature can extract the corresponding secret (private key) using the complete signature, the previous partial signature, and the adaptor (public key).

3.4.3 Combining the Two: 2-AS

Having understood the characteristics of Schnorr signatures and adaptor signatures, we can now look at the magic of combining the two: 2-AS.

Assuming we have a VTXO and wish to ensure that it can be forfeited in the event of double spending off-chain, we can design it as follows:

• First, we need a penalty output, where the unlockable pubkey is a penalty public key, ensuring that users can be penalized in the event of double spending.
• The trading parties cooperate to confirm the off-chain transaction through adaptor signature, and if a user uses the same input twice, that output can be forfeited by the service provider.
• Require the user to generate a pubkey as a penalty output each time they update the state, with the penalty public key constructed from two predetermined public key pairs using Schnorr signature additive techniques.

Thus, we confirm the public-private key pairs to be used before each transaction and generate the penalty output in advance. Once double spending occurs, the service provider can obtain the private key corresponding to the penalty output through two adaptor signatures.

3.4.4 Pros and Cons of Bitcoin Clique

The Bitcoin Clique solution is not without its flaws. Its downside lies in the need to continuously exchange 2-AS keys used to construct new penalty public keys during off-chain state updates. Additionally, since this solution is based on the CoinPool design, it also requires all participants to be online during state updates to exchange 2-AS keys and verify signatures for the new version of the UTXO. In other words, the complexity of communication and interactivity remains high.

The most important point is that this model resembles a StateChain design, where each time we transfer the ownership of a UTXO off-chain, systems using 2-AS like double-spend-prevent signatures cannot provide change in off-chain payments, which severely limits the application scenarios.

Moreover, even with the operational convenience of the Shared UTXO mechanism and off-chain anti-double-spending primitives that do not require soft forks, we still need everyone online to confirm the new state of the UTXO, even if each state update only affects a portion of the off-chain network. It is unreasonable to require unrelated individuals to participate online for updates. Completely eliminating liquidity requirements is also not what we desire; payment solutions lacking liquidity cannot provide change, and due to exit issues, all participants often must have the same denomination.

Therefore, there is currently no non-channel, dynamic denomination-supporting, and UTXO-based off-chain scalability solution. Ethereum has also struggled with this issue in the past, which we refer 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 is needed to ensure dynamic denomination payments (changeable transactions): This requires retaining channel designs while also avoiding exit issues.
2. Reduce reliance on all participants being online simultaneously: We do not want every user to be online for any state updates in the off-chain network; updates to the Shared UTXO should only require relevant individuals to collaborate online.

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

3.5 Channel Factories and Virtual Channels

From the previous discussion, we recognize that we need to retain the channel design while also benefiting from the low-cost advantages of Shared UTXO. A concept that has been discussed for a long time in the Lightning Network domain has entered our view: the Channel Factory.

Previously, we mentioned that off-chain UTXOs committed by on-chain UTXOs are referred to as Virtual UTXOs. If we treat the off-chain Virtual UTXO as the FundingTx of a channel, we arrive at a new concept: the Virtual Channel. In this Shared UTXO, the off-chain virtual channels are connected by Virtual HTLCs. Everything is off-chain and "virtualized." This seems to provide an ideal solution: implementing most functions off-chain, including liquidity adjustments, appears to solve the scalability of the Lightning Network.

But is the reality really that beautiful?

Due to inheriting the characteristics of Shared UTXO, Channel Factories require the collaboration of multiple users to open and close. If any user cannot cooperate in a timely manner (for example, if they go offline or do not respond), it may affect the functionality of the entire Channel Factory. Since Channel Factories involve multiple parties jointly signing state updates, any party's desynchronization or malicious behavior could prevent other users from smoothly closing the channel and withdrawing funds.

Moreover, the issues with this design are also evident. Although it reduces the cost of opening and closing channels, the security model between channels still relies on commitment transactions and HTLCs. Therefore, communication and interaction issues persist, and the complexity of implementing this solution may even be higher than the current LN-Penalty.

3.6 ARK JoinPool and Temporary Channels

From the review of the previous Channel Factory case, we conclude that in the channel design based on Shared UTXO, we may not need to continue using the classic "LN-Penalty" channel design, but we should retain the advantages of introducing channels:

1. Dynamic denominations brought by liquidity;
2. Ease of exit.

Based on this, a design utilizing JoinPool for temporary channels has emerged, namely the ARK Protocol.

3.6.1 JoinPool: Partial Participation in Updates

As previously mentioned, CoinPool brings potential for off-chain collaboration among multiple parties, such as not requiring liquidity, multi-hop, HTLC, and other complex and failure-prone designs. However, the most critical issue with the CoinPool model is the requirement for users to be online: all users in the Shared UTXO must be online during off-chain state updates, even if some users' states have not changed, they still need to be online to verify and provide corresponding signatures. This requirement makes it impossible to avoid the issue of users needing to run their own nodes.

To solve this problem, a new model has been proposed: JoinPool. The concept of JoinPool within Shared UTXO is that whenever a user needs to update their off-chain state, everyone joins 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 executing transactions. In other words, in the JoinPool-based design, users only need to be online when they need to conduct a transaction.

However, we all understand that the need for continuously running Lightning Network nodes is not only to ensure that users' private keys are online for signing but also because each channel member needs a WatchTower to continuously monitor whether the trading counterpart has put unfavorable commitment transactions on-chain. This leads us to the second problem we need to solve.

3.6.2 Transferring WatchTower Responsibilities: Users Do Not Need to Maintain Nodes

In the classic LN-Penalty design, each user needs to build their own WatchTower to monitor whether the other party has put the old state on-chain; if so, they will impose penalties. In this old model, all of our trading counterparts are equal Lightning nodes, and each time we participate in a transaction, it could involve opening channels with different nodes. However, in ARK, all users actually interact with the ASP (ARK Service Provider) and do not directly interact with other users.

For the ASP, once a user's off-chain VTXO is traded, a waiver transaction will be signed. This is because, ideally, the user's off-chain VTXO should not be brought on-chain but should continuously be referenced for the next round of transactions. If a VTXO is traded off-chain while also being brought on-chain, it indicates that the user has conducted a double spending transaction; thus, the ASP will use the waiver transaction signed by the user off-chain to forfeit the funds brought on-chain by that user. The ASP will monitor all historically appeared VTXOs to prevent anyone from maliciously exiting from already spent VTXOs off-chain.

This shifts the operational responsibility of the WatchTower from ordinary users to the operator. Compared to the Lightning Network, this model represents a significant improvement: we no longer need ordinary users to run their own nodes to ensure their security.

Summary of Other Solutions for Optimizing User Node Operations:

Cloud Hosting for Lightning Network Nodes

Some solutions choose to run Lightning Network nodes on cloud platforms to help users lower the barriers to running nodes. However, this approach fundamentally contradicts 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 solution transforms a two-party game scenario into a three-party game scenario involving me, the trading counterpart, and the cloud hosting party. When I am in a state where I have traded with the counterpart but the state has not yet been put on-chain, the cloud hosting party can unilaterally delete the commitment transaction in my cloud node, allowing my trading counterpart to put a favorable state on-chain. In such a Lightning Network cloud node hosting solution, there is a risk of collusion between the cloud hosting platform and the trading counterpart.

CRAB and Sleepy CRAB

The CRAB (Channel Resistant Against Bribery) protocol proposed by Aumayr and others adds collateral combined with incentives for miners to ensure the security of payment channels, especially when users are offline. This mechanism reduces reliance on third-party WatchTowers. However, this collateral mechanism undoubtedly exacerbates issues similar to "incoming liquidity," as it requires users to lock more funds unrelated to transaction purposes when joining the off-chain network, ensuring security but sacrificing liquidity and efficiency. Moreover, such solutions still require users to run their own nodes, albeit with reduced online requirements.

3.6.3 Temporary Channels: Users Do Not Need to Maintain Channel Liquidity

One might ask why ASP service providers are willing to inject liquidity into our channels in JoinPool. This is because if users want to use VTXOs based on the ARK network, they must first deposit their UTXOs into a multi-signature address with the operator, similar to a FundingTx, in exchange for VTXOs. Essentially, each off-chain transaction by the user utilizes the operator's funds but relinquishes the funds previously held in multi-signature with the operator.

The reason why ARK's channels are referred to as temporary channels is that they possess the characteristics of unidirectionality and one-time funding.

• Unidirectionality: In a unidirectional channel, funds will only flow from the designated initiating party to the corresponding output party.
• One-time funding: ARK's channels only require a one-time injection of funds. After the funds are injected, there is no need to maintain the liquidity of the channel.

In this design of temporary channels, once the funding is completed, the channel does not require further rebalancing or adjustments. Compared to Lightning, not only do users no longer need to worry about channel liquidity, but liquidity providers also do not need to maintain channel liquidity. The only variable remaining in the channel is the event of user exit.

3.6.4 Summary of the ARK Protocol

In summary, we can clearly see that the design of the ARK Protocol has made remarkable progress in user experience compared to the Lightning Network:

• Users do not need to maintain their own nodes.
• Users do not need to maintain channel liquidity, eliminating incoming liquidity issues.
• Supports asynchronous interaction, with no need for both parties to be online simultaneously.

---

4. Changing the Paradigm of Bitcoin's Native Scalability

Through the research above, we have explored multiple off-chain scalability solutions based on Shared UTXO. The original intention of the Shared UTXO design was to address liquidity issues; however, as the protocol has evolved, we have unexpectedly discovered many advantages that we had hoped for but dared not expect.

This marks a new development direction for Bitcoin's off-chain scalability, representing a paradigm shift compared to the original Lightning Network model:

From P2P Model to Introducing Trustless Operators

The logic of the off-chain scalability network has gradually evolved from the initial "user-to-user" bilateral game model of the Lightning Network to a game model between "users and operators." The difference is that users do not need to trust this third-party operator.

Users Do Not Need to Maintain Node Infrastructure to Ensure Asset Security

The traditional LN-Penalty model and the latest research such as CRAB rely on users to provide collateral to ensure the safety of funds, while also requiring users to remain online and run nodes during the channel's existence. However, future solutions will no longer require these operations. More importantly, these processes will still maintain a non-custodial nature, allowing users to retain control over their assets at all times.

Liquidity Management Responsibilities Shift from Users to Operators

In the classic LN-Penalty model and improved designs, users need to adjust the liquidity in the channel themselves, especially when liquidity is imbalanced. This often requires a certain level of expertise and can be complex to operate without the help of LSPs (Liquidity Service Providers). However, as liquidity management responsibilities shift to third-party operators, users no longer need to worry about liquidity management. This greatly simplifies the user experience and eliminates barriers to joining the network.

Capital Efficiency and Potential Greatly Enhanced

The new protocol designs are moving towards the P2POOL model, which fundamentally differs from the current Lightning Network in terms of capital efficiency. In the LN-Penalty model, each user must provide liquidity themselves when opening a Lightning channel, but this liquidity is mostly idle (payments do not occur frequently and are unevenly distributed across channels), leading to ineffective use of users' funds. In the trend of new protocol designs, liquidity is concentrated in liquidity pools for unified management, providing infinite possibilities for future DeFi scenarios.

This paradigm shift indicates that liquidity management is the essence of the evolution of Bitcoin's native off-chain scalability and is the core thread for future evolution.

In the future, with continuous technological advancements and the emergence of new solutions, Bitcoin's path to off-chain scalability is bound to welcome a brighter development prospect. We will continue to conduct in-depth research in this field, and we invite readers to look forward to our further results.

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 2024⁄025. 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 2020⁄175. 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
• 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 2021⁄1445. 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 2024⁄826. 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

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。