Author: Ben, Founder of Discoco Labs

Preface

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

When we delved into the Lightning Network and tried to implement non-custodial business on it, we felt some inconsistencies. Two-party channels theoretically have the strongest transaction throughput, but the actual maintenance and use problems are much more than expected. The Lightning Network is currently not performing well in the initial micropayment direction, and the core reason is liquidity. Even though a large amount of so-called infrastructure to improve liquidity has been introduced, the actual effect has not met expectations.

During the writing of this article, Mutiny Wallet, a well-known lightning self-custodial wallet in the industry, announced its closure, and its partner Liquidity Service Provider (LSP) also ceased operations. The collaboration model between self-custodial wallets and LSPs has always been considered an important direction for the future of the lightning network, which inevitably makes people worried about its future. Therefore, at this point in time, this article will explore the evolution of the channel network and its future development trends from the perspective of liquidity expansion.

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

Bitcoin's block capacity is limited and the main network block generation time is long, about 10 minutes on average, which is obviously far from the requirement for it to become a peer-to-peer cash system for the whole world. In view of this, we urgently need an expansion solution: it needs to occupy little block space, can be settled quickly, and must be a solution natively based on Bitcoin. Thus, the Lightning Network came into being.

Lightning Network defines that after locking assets on the chain, the exchange of a committed transaction is completed off the chain, which is why it is called instant payment. Compared with the 10-minute confirmation time of Bitcoin main network payment, this undoubtedly solves the number one problem for small payment scenarios.

However, in the actual development and use of the Lightning Network, multiple problems have gradually emerged. This article summarizes four core issues:

1.1 Node maintenance is difficult

The current Lightning Network is based on a P2P penalty transaction game model. In order to monitor whether the other party will upload an old state that is unfavorable to itself to the chain during the existence of the channel, the model requires WatchTower to be online at all times, which requires users to maintain the node themselves. In addition, users also need to save the penalty private key and commitment transaction data locally, resulting in high node maintenance thresholds and education costs.

1.2 High Interactivity

In the Lightning Network, interactivity usually refers to a series of interactive operations that users need to perform during the transaction process. These operations often involve signing, exchanging commitment transactions, punishing private keys, etc. For example, every time the off-chain status is updated, both parties to the transaction must be online at the same time and sign a new commitment transaction for exchange, which places strict requirements on user interactivity. In addition, when multiple parties interact, the complexity brought by HTLC and multi-hop is difficult to overcome.

1.3 Low capital efficiency

The LN-Panelty mechanism of the two-party channel is to some extent equivalent to users opening their own bank accounts and bringing their own reserves. The typical problem is that users need to ensure channel liquidity when receiving funds, which is very low in capital efficiency. Moreover, the liquidity of many marginal channels will not be fully utilized.

1.4 High channel management cost

In P2P channels, liquidity imbalance is very likely to occur, and users have to rely on various tools to supplement liquidity, such as submarine swaps, channel splicing, etc. However, these technologies require additional on-chain transactions to adjust the original FundingTx. In general, all adjustment methods are costly, especially when the handling fee increases, the cost is difficult for users to ignore.

Imagine how embarrassing it would be for users who thought they were using Layer 2 technology to make cheap transactions to suddenly face several mainnet on-chain fees. This embarrassment becomes more obvious when the mainnet on-chain fees become higher, which can be called a "fee assassin".

These problems have also shown obvious consequences in the actual adoption of the Lightning Network: user growth is weak, and most of the new users will choose the custody solution, as can be seen from the statistics in the figure below.

Statistics on the number of newly added Lightning Network users who choose to use custodial wallet solutions and non-custodial wallet solutions

It is not difficult to understand the reason for this situation. After all, it is too difficult for most ordinary users to maintain nodes and channels by themselves.

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

Lightning Network White Paper Excerpt

According to the Lightning Network white paper, if everyone in the world opens and closes channels twice a year, the Bitcoin block capacity will eventually need to grow to 133MB. In comparison, the current Bitcoin mainnet has a block size of only 1MB, and even a P2TR address using segregated witness is only 4MB, which is a huge gap. In addition, considering that the actual technology for adjusting channel liquidity (submarine swaps, channel splicing) requires additional on-chain transactions, the problem of insufficient Bitcoin block space faced by the Lightning Network will be even more severe in real scenarios.

It can be seen that the current Lightning Network is difficult to meet the needs of large-scale C-end users in the short term. In addition, limited by the Bitcoin block capacity, the expansion potential of the Lightning Network is also significantly restricted in the long term.

The question then arises: What kind of Bitcoin off-chain scaling network do we need?

2.1 Current Status of Lightning Network

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

The current Lightning Network model is also called LN-Panelty. This model is generally a two-party channel model based on penalty transactions. Its security depends on the user's locally stored transaction and penalty private keys to check and balance the other party, and to always monitor the Bitcoin chain to ensure that the counterparty's every move is under their surveillance.

Under this model design, it is inevitable for users to run their own nodes, because local storage and WatchTower functions are indispensable. This part has been repeatedly emphasized in the previous article.

From the perspective of capital and communication efficiency, the current popular model of the Lightning Network is that an LSP super node provides liquidity in the middle, and then the user establishes a channel with the super node of the LSP maintainer, which has deviated from the P2P mesh model originally envisioned. In the case of natural evolution, it finally returned to the classic hub-and-spoke model.

Take the following picture as an example. The left side is the ideal lightning network, and the right side is the actual status of the lightning network.

2.2 Characteristics of an ideal toC off-chain expansion network

Now let’s imagine what features the Bitcoin off-chain expansion network really needs from C-end users:

1. Using a non-P2P model, users do not need to maintain nodes themselves, while maintaining good security and convenience

2. On the interactive side, users do not need to be online at the same time when paying, and one party can be offline or asynchronous operation can be realized

3. Improving capital efficiency while meeting non-custodial needs

4. A cheap and efficient liquidity management mechanism that does not even require users to maintain liquidity themselves

Based on these goals, this article will lead readers to explore the future development direction of the Bitcoin off-chain expansion network.

3. BTC’s native expansion evolution

First of all, we need to make it clear that in the core mechanism of the current Lightning Network design, "LN-Panelty", the basis of the state update mechanism is:

• Storage and continuous monitoring of committed transactions

• Multi-hop mechanism for collaboration across multiple people (HTLC/PTLC)

These elements form the basis of the current lightning network design and directly lead to the complexity of node design, which is manifested as:

• Complex encrypted communication interactions

• Storage of local commitment transactions and penalty private keys

• WatchTower cannot be interrupted during the channel's existence

These issues prompted us to think about whether a lighter state update mechanism could be used to replace "LN-Penalty". In this context, BIP118 (SIGHASH_ANYPREOUT) was proposed as a possible alternative.

3.1 LN-Symmetry: Status Update Introduces Version Mechanism

BIP118 proposes the introduction of the SIGHASH_ANYPREOUT signature mode, which allows a transaction's inputs to be updated without completely specifying the previous output, and to update its previous transaction without changing the signature. Such a design can significantly reduce the complexity and storage requirements of encrypted communication between nodes compared to "LN-Penalty". SIGHASH_ANYPREOUT comes from the paper eltoo: A Simple Layer2 Protocol for Bitcoin. In recent discussions on Lightning Network development, the Lightning Network model based on this improvement is also called "LN-Symmetry".

Although LN-Symmetry reduces the pressure of local commitment transaction storage, it does not completely 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 old state to the chain, the other party still needs to monitor in real time and publish the latest state transaction in time to replace the old state. The monitoring task in this process still requires the traditional WatchTower. At this time, the purpose of running WatchTower changes from punishment to state replacement. Users still need to maintain their own nodes.

At the same time, LN-Symmetry still requires mechanisms such as HTLC/PTLC to ensure multi-person collaboration, which will still have a serious communication burden, just like the previous lightning network node design.

Therefore, from the overall effect point of view, the improvement that LN-Symmetry brings to the current Lightning Network experience is limited, and there is still a long way to go before we can achieve our goal.

For further improvement, this article introduces the direction of the next stage: Shared UTXO.

3.2 CoinPool: Reducing the interactivity and liquidity requirements of multi-party channels

The first paper that introduced the concept of Shared UTXO was CoinPool: efficient off-chain payment pools for Bitcoin. Its core goal was to further solve the problem of multi-party interaction under the version update mechanism of SIGHASH_ANYPREOUT.

In the LN-Symmetry design, the new state update mechanism introduced by Eltoo does simplify 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 all parties and multiple encrypted communications.

The innovation of CoinPool is that it uses the Shared UTXO model to allow multiple parties to collaborate on the same UTXO with version control. In this way, multiple participants can jointly commit to and manage the status of a UTXO without relying on complex HTLC/PTLC mechanisms. Its main advantages are:

• Significantly reduces the complexity of multi-party channel interactions: Since all participants share the same UTXO, they can reach consensus by signing the version update of the UTXO without multiple on-chain transactions or complex off-chain interactions. This simplification makes the management of multi-party channels more efficient.

• The off-chain update mechanism becomes more direct: Under this design, the off-chain status update mechanism is transformed into a version of UTXO confirmed by multiple parties' joint signatures. This method not only simplifies the status update process, but also further reduces the dependencies and potential conflict points between the parties.

• Eliminate independent liquidity requirements: Through the Shared UTXO model, multiple participants actually share the same liquidity pool, without the need for each participant to independently maintain sufficient liquidity. In the multi-party collaborative CoinPool design, liquidity requirements can be significantly reduced or redistributed. Participants can use the liquidity in the shared UTXO to complete payments without having to lock up a large amount of funds for their own channels. This not only improves the efficiency of fund utilization, but also reduces the funding pressure of individual participants.

CoinPool's design successfully reduces the complexity of interactions in multi-party channels to a reasonable level by sharing UTXOs, while maintaining the security and efficiency of the system. More importantly, it reduces the reliance on each participant's independent liquidity needs, provides a lighter and more flexible solution for multi-party collaboration, and breaks through the limitations of the traditional LN model in multi-party interaction and liquidity management.

However, why has such a solution with obvious advantages not been adopted on a large scale so far? What is the root of the problem?

3.3 Why is CoinPool not actually implemented?

Although CoinPool has many advantages and is considered an ideal expansion model, the soft fork upgrade it relies on has so many requirements that we may not see it implemented on the Bitcoin network in our lifetime. CoinPool's requirements for soft fork upgrades are mainly concentrated in the following two aspects:

3.3.1 Status update mechanism upgrade

Since CoinPool is designed based on Eltoo, it inherits its demand for soft forks in the state update mechanism, which requires Bitcoin to be upgraded to enable a new signature mode SIGHASH_ANYPREVOUT (APO). However, as we all know, Bitcoin soft fork upgrades are slow, making the technology that CoinPool's state update mechanism relies on difficult to apply in reality.

3.3.2 Shared UTXO requires a contract to simplify the operation mechanism

As mentioned above, each update of the Shared UTXO status requires the collection of signatures from all parties that share a certain version of the UTXO. During this process, if one party is offline, the entire system will come to a standstill. In blockchain terms, the liveness of such a system is very poor. To overcome this challenge, the system requires a mechanism that can update Shared UTXO at a lower cost and does not rely entirely on cooperation.

In the CoinPool paper, OP_MERKLESUB is proposed, which aims to verify and update the status of specific participants through the Merkle tree structure. Although this design idea is theoretically feasible, it faces similar problems as other Merkle tree-based operation contracts, namely, the logic implementation is complex and it is difficult to form a universal and reusable contract. For example, contracts like **OP_TAPLEAFUPDATEVERIFY(TLUV)**, etc. In addition, the contract function of OP_EVICT, which directly kicks the uncooperative party out of Shared UTXO, is too simple, and it is difficult to foresee whether it can successfully pass the upgrade of the Bitcoin network.

Among these contract proposals, OP_CheckTemplateVerify (CTV) has gradually become the focus of attention. Unlike directly building and verifying a Merkle tree, CTV uses a predefined transaction template to set spending limits. CTV is not only simple to implement, but also can commit a series of off-chain UTXOs through an on-chain UTXO through a transaction commitment chain. These off-chain UTXOs committed on the chain are the original origin of the concept of Virtual UTXO.

Among these contracts, CTV has the highest popularity because it is simple and universal. CTV's powerful capabilities can not only realize ideas similar to CoinPool, but can also be used for Rollup. It can be imagined that by performing ZKP-MerkleState verification through OP_CAT every time, and directly committing to the Shared UTXO corresponding to the Layer2 state in the script, we will be able to build a true Bitcoin ZK-Rollup solution.

In summary, the main problem faced by the implementation of CoinPool is that it requires a lightweight state update mechanism APO and Shared UTXO opcodes to help implement it, both of which require a soft fork upgrade of Bitcoin. As a result, many years after the birth of the CoinPool paper, it is still a paper solution.

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

In the discussion of the CoinPool model above, we learned that the APO mechanism it relies on requires a soft fork upgrade to make the solution possible, which is difficult to achieve in the short term. If there is a new off-chain anti-double-spending primitive that does not rely on Bitcoin soft fork upgrades, then the implementation problem will be solved to a large extent.

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, the problem of off-chain state update can be solved, and the update requirements of Bitcoin operation primitives can be avoided. The emergence of the Bitcoin Clique paper brought new hope. It introduced a new cryptographic primitive, 2-shot-adaptor-signature (2-AS), which provides a new solution for off-chain double spending prevention.

2-AS is a cryptographic primitive based on Schnorr adaptor signature. To understand 2-AS, we must first have some understanding of Schnorr signature and adapter signature.

3.4.1 Schnorr Signature

Schnorr signatures have linear properties, which means that multiple signatures can be aggregated into one signature. In simple terms, if there are multiple signatures $S_1$ and $S_2$, they can be aggregated into one signature $S=S_1+S_2$ through addition, and the corresponding public keys during verification can also be aggregated into $P = P_1 + P_2$.

3.4.2 Adapter Signature

There are several basic steps in adapter signing, such as Gen, PSign, PVrfy, Adapt, and Extract. When understanding 2-AS, it is particularly important to understand the two steps of Psign ​​and Extract.

This article focuses on understanding adapter signatures from the perspective of usage rather than cryptography. In short, when two entities want to cooperate to confirm a signature, they often use the other party's adapter as part of the signature, and the adapter is often the public key part of the public-private key. Then the party holding the private key corresponding to the adapter, which is the so-called secret, has the ability to Adapt to complete the partial signature left by Psign. If that's all, isn't it similar to MuSig? However, the unique feature of adapter signatures is that they can be extracted, that is, when the complete signature is released, the party that initiated the Psign ​​of the adapter signature can extract the corresponding secret (private key) through the complete signature, the previous partial signature, and the adapter (public key).

3.4.3 Combination of the two: 2-AS

Now that we have learned about the characteristics of Schnorr signatures and adapter signatures, we can now look at the magic that combines the two: 2-AS.

Assuming we have a VTXO and want to ensure that it can be fined in the event of double spending off-chain, we can design it like this:

• First, we need a penalty output, where the pubkey that can be unlocked is a penalty public key, ensuring that users can be fined when double-spending.

• Counterparties collaborate to sign adapters to confirm off-chain transactions. If a user uses the same input twice, the output can be confiscated by the service provider.

• Users are required to generate a pubkey as a penalty output every time they update their status. The penalty public key of the penalty output is composed of two pairs of public keys determined in advance using the Schnorr signature technology.

Therefore, we confirm the public and private key pairs to be used before each transaction and generate the penalty output in advance. Then, once double spending occurs, the service provider can finally obtain the private key corresponding to the penalty output through two adapter signatures.

3.4.4 Advantages and Disadvantages of Bitcoin Clique

The Bitcoin Clique solution is not perfect. Its disadvantage is that when the off-chain status is updated, the 2-AS key used to build a new penalty public key needs to be exchanged continuously. And because the solution is based on the CoinPool design, in order to exchange the 2-AS key and verify the signature of the new version of UTXO each time, the solution also requires everyone to be online when the status is updated. In other words, the complexity and interactivity of communication are still very high.

The most important point is that such a model is a StateChain-like design. Every time we transfer the ownership of a UTXO off-chain, the system using double-spend-prevent signatures like 2-AS cannot make change in off-chain payments, which makes the application scenarios very limited.

In addition, even with the easy-to-operate SharedUTXO mechanism and the off-chain anti-double-spending primitives that do not require soft forks, we still need everyone to update and confirm the new status of UTXO online, even if each status update only affects a part of the off-chain network. It is unreasonable to let unrelated people participate in on-chain updates online. And completely eliminating the need for liquidity is not what we expect. Payment solutions that lack liquidity lubrication cannot perform denomination change, and due to exit issues, the denominations of everyone must often be the same.

Therefore, there is currently no off-chain expansion solution that is non-channel, supports dynamic denominations, and is based on UTXO. Ethereum was once troubled by this route, which we call the Plasma trap. For related research, please refer to the paper Lower Bounds for Off-Chain Protocols: Exploring the Limits of Plasma.

Summary of problems and lessons:

1. Liquidity lubrication is needed to ensure dynamic denomination payments (changeable transactions): this requires retaining the channel design and at the same time avoiding exit problems.

2. Reduce the reliance on all participants being online simultaneously: We do not want every user to be online when making any status updates on the off-chain network. Shared UTXO updates should be collaborative updates by relevant people online.

Based on the above understanding, this paper continues in this direction to explore more optimized solutions.

3.5 Channel Factories and Virtual Channels

In the previous discussion, we realized that we need to not only keep the channel design, but also need Shared UTXO to bring us low-cost benefits off-chain. Then a concept that has been discussed in the field of lightning network for a long time came into our view, namely Channel Factory.

Previously, we mentioned that the off-chain UTXO promised by the on-chain UTXO is called Virtual UTXO. If the off-chain Virtual UTXO is used as the FundingTx of the channel, we get a new concept, namely Virtual Channel. Then the off-chain virtual channel in this Shared UTXO is connected by Virtual HTLC. Everything is off-chain and "virtualized". This seems to provide an ideal solution: most functions, including liquidity adjustment, are implemented off-chain, and the expansion of the Lightning Network seems to be solved.

But is the truth really so beautiful?

Due to the inherited characteristics of Shared UTXO, the channel factory requires the collaborative work of multiple users to open and close. If any one of the users fails to cooperate in time (for example, offline or unresponsive), it may affect the function of the entire channel factory. Since the channel factory involves multiple parties co-signing status updates, any party's asynchronous or malicious behavior may cause other users to be unable to successfully close the channel and withdraw funds.

And the problem of such a design is also obvious. Although the cost of channel switching is reduced in this way, the security model between channels still relies on commitment transactions and HTLC. Therefore, the problem of communication and interaction still exists, and the implementation complexity of this solution is even higher than that of the current LN-Panelty.

3.6 ARK JoinPool and Temporary Channels

Through the review of the previous channel factory case, we have come to a conclusion: in the channel design based on Shared UTXO, perhaps the classic "LN-Panelty" channel design should not be continued, but at the same time the advantages of introducing channels should be retained:

1. Dynamic denominations due to liquidity;

2. Easy to exit.

Based on this, a design of a temporary channel using JoinPool came into being, namely ARK Protocol.

3.6.1 JoinPool: Some people participate in the update

As mentioned above, CoinPool brings potential to the off-chain collaborative expansion of multiple people, such as no need for complex and fault-prone designs such as liquidity, multi-hop, and HTLC. However, the most critical problem of the CoinPool model is the online requirement for users: all users in the entire Shared UTXO must be online when the off-chain status is updated. Even if the status of some users has not changed, they still need to be verified online and give corresponding signatures. This requirement makes it impossible for us to avoid the problem that users need to run their own nodes.

In order to solve this problem, a new model was proposed, namely JoinPool. The concept of JoinPool in Shared UTXO is: every time a user needs to update its off-chain status, everyone joins a Shared UTXO that represents the new status of its corresponding UTXO. This solves the problem that unrelated users need to be online when others are executing. In other words, in the design based on JoinPool, users only need to be online when they need to conduct transactions.

But we all know that the need to run lightning network nodes uninterruptedly is not only to ensure that the user's private key is online for signing, but also because each channel member needs WatchTower to continuously monitor whether the counterparty has traded unfavorable commitments to the chain. This leads to the second problem we need to solve.

3.6.2 WatchTower responsibility transfer: users do not need to maintain nodes themselves

In the classic LN-Panelty design, each user needs to build his own WatchTower to monitor whether the other party has uploaded the old state to the chain, and if so, he will be punished. In this old model, all of our counterparties are peer-to-peer lightning nodes, and each transaction may be opened with a different node. But in ARK, all users actually interact with ASP (ARK Service Provider) and do not interact directly with other users.

For ASP, once the user's off-chain VTXO is traded, a waiver transaction will be signed. This is because ideally, the user's off-chain VTXO will not be brought to the chain, but will be constantly referenced and carried out in the next round of transactions. If a VTXO is traded off-chain and brought up on the chain at the same time, it means that the VTXO has been double-spent by the user, then ASP will use the waiver transaction signed by the user off-chain to confiscate the funds brought to the chain by the user. ASP will monitor all VTXOs that have appeared in history to prevent someone from maliciously withdrawing from the VTXO that has been spent off-chain.

This shifts the operational responsibility of WatchTower from ordinary users to operators, which is a huge improvement over the Lightning Network: we no longer need ordinary users to run their own nodes to ensure their own security.

Summary of other solutions in optimizing user node operation:

• Lightning Network Node Cloud Hosting

Some solutions choose to run Lightning Network nodes on cloud platforms to help users lower the threshold for running nodes. However, this solution essentially violates the security assumptions of the Lightning Network itself. In Lightning Network technology, the storage of private keys and committed transactions is equally important in many scenarios. Therefore, simply using a remote private key does not guarantee security.

In essence, this scheme turns the two-party game scenario into a three-party game scenario involving me, the counterparty, and the cloud custodian. After I have traded with the counterparty but the status has not yet been uploaded to the chain, the cloud custodian can unilaterally delete the committed transaction in my cloud node, and my counterparty can then upload the status that is beneficial to it to the chain. In such a Lightning Network cloud node hosting scheme, there is a risk of collusion between the cloud hosting platform and the counterparty.

• CRAB 和 Sleepy CRAB

The CRAB (Channel Resistant Against Bribery) protocol proposed by Aumayr et al. ensures the security of payment channels by adding additional collateral combined with a mechanism to incentivize miners, especially when users are offline. This mechanism reduces the reliance on the third-party WatchtTower. However, this collateral mechanism undoubtedly further exacerbates problems such as "account liquidity". Because it requires users to lock up more funds that are not related to the purpose of the transaction when joining the off-chain network, although it ensures security, it sacrifices the liquidity and efficiency of funds. And this type of solution still requires users to run nodes themselves, but it reduces the requirements for users to be online.

3.6.3 Temporary channels: users do not need to maintain channel liquidity by themselves

Some people may ask, why are ASP service providers willing to inject liquidity into our channels in JoinPool? This is because if users want to use VTXO based on the ARK network, they must first deposit their UTXO with the operator into a multi-signature address, which is similar to a FundingTx, in exchange for VTXO. In essence, every off-chain transaction by the user is using the operator's funds, but will transfer the funds that they previously multi-signed with the operator.

The reason why ARK's channel is called a temporary channel is because it has the characteristics of one-way and one-time capital injection.

• Unidirectionality: In a one-way channel, funds will only be transferred from the designated initiator to the corresponding output party.

• One-time capital injection: ARK’s channel only requires a one-time capital injection. After the capital injection, there is no need to continue to maintain the liquidity of the channel.

With such a temporary channel design, after the injection is completed, the channel does not need to be rebalanced or adjusted. Compared with Lightning, not only do users no longer need to worry about channel liquidity, but liquidity providers no longer need to maintain channel liquidity. The only change in the channel is the user exit event.

3.6.4 Summary of ARK Protocol

To sum up the above, we can clearly see that the design of ARK Protocol has made amazing progress in user experience compared to the Lightning Network:

• Users do not need to maintain nodes themselves

• Users do not need to maintain channel liquidity by themselves, and there is no problem of account liquidity

• Supports asynchronous interaction, no need for both parties to be online at the same time

4. Changes in Bitcoin’s native scaling paradigm

Through the above research, we have explored multiple off-chain expansion solutions based on Shared UTXO. The original intention of Shared UTXO was to solve the liquidity problem. However, as the protocol continues to evolve, we unexpectedly discovered that it brings many advantages that we had expected but did not dare to expect.

This marks a new development direction for Bitcoin off-chain expansion. Compared with the original lightning network model, this is a paradigm shift:

• From P2P model to the introduction of trustless operator

The logic of the off-chain expansion 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 facilities themselves to ensure asset security

The traditional LN-Penalty model, as well as recent research such as CRAB, relies on users to provide their own collateral to secure their funds, while requiring users to remain online and run nodes for the duration of the channel. However, future solutions will no longer require these operations. More importantly, these processes remain non-custodial, and users always retain control of their assets.

• Liquidity management responsibilities shift from users to operators

In the classic LN-Penalty model and improved design, users need to adjust the liquidity in the channel by themselves, especially when the liquidity is unbalanced. This usually requires a certain amount of expertise and is complicated to operate without the help of LSP (liquidity service provider). However, as the liquidity management responsibility is transferred to a third-party operator, users no longer need to worry about liquidity management. This greatly simplifies the user experience and removes barriers to joining the network.

• Capital efficiency and potential greatly improved

New protocol designs are all moving towards the P2POOL model, which is fundamentally different from the current Lightning Network in terms of capital efficiency. In the LN-Penalty model, each user must provide liquidity when opening a lightning channel, but the liquidity of these channels is idle most of the time (payments do not occur frequently, and payments are unevenly distributed across channels), resulting in the ineffective use of user funds. In the new protocol design trend, liquidity is concentrated in the liquidity pool for unified management, which provides unlimited possibilities for future DeFi scenarios.

This paradigm shift shows that liquidity management is the essence of Bitcoin’s native off-chain expansion evolution and the core theme of future evolution.

In the future, with the continuous advancement of technology and the emergence of new solutions, Bitcoin's off-chain expansion will surely usher in a brighter development prospect. We will continue to conduct in-depth research in this field, and readers are welcome to look forward to our further results.