This article will explore the evolution of channel networks and their future development trends from the perspective of liquidity expansion.
Author: 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 current performance in the initial micropayment direction is unsatisfactory, 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 problems with the Lightning Network?
Bitcoin's block capacity is limited, and the mainnet block time is relatively long, averaging about 10 minutes, which is clearly far from the requirements for it to become a global peer-to-peer cash system. In light of this, we urgently need a scalability solution: it needs to 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, compared to the 10-minute confirmation time limited by Bitcoin's mainnet payments, undoubtedly solves the primary issue for small payment scenarios.
However, during the actual development and use of the Lightning Network, several problems have gradually emerged. This article summarizes four core issues:
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 complexity brought by HTLC and multi-hop is 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 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.
Statistics on the number of new Lightning Network users choosing custodial wallet solutions versus non-custodial wallet solutions.
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 off-chain scalability network do we need for Bitcoin?
Excerpt from the Lightning Network white paper.
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 issue of insufficient Bitcoin block space in real scenarios.
It is evident that the current Lightning Network is unlikely to meet the needs of a large-scale C-end user base 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 off-chain scalability network do we truly need for Bitcoin?
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, running a node independently is unavoidable, as local storage and WatchTower functionality are indispensable. This aspect has been repeatedly emphasized earlier.
From the perspectives of capital and communication efficiency, the popular model of the current Lightning Network involves an LSP super node providing liquidity in the middle, with users establishing channels with the LSP maintainer's super node. This has already deviated from the originally envisioned P2P mesh model. In a natural evolution, 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 To-C Consumer Off-Chain Scalability Network
Now, let us envision what characteristics a truly needed off-chain scalability network for Bitcoin C-end users should possess:
Adopts a non-P2P model, allowing users not to maintain nodes while ensuring good security and convenience.
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.
Improves capital efficiency while meeting non-custodial needs.
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 scalability 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 (HTLC/PTLC) for cross-party collaboration.
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.
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 the inputs of a transaction to not fully specify the previous output and to update its preceding transaction 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 monitoring requirements. 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, and the purpose of running the WatchTower shifts 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 for 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 issue of multi-party interaction under the version update mechanism of SIGHASH_ANYPREOUT.
In the design of LN-Symmetry, 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 straightforward: 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 points of conflict 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 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, despite such significant advantages, why has this solution not been widely adopted to date? Where does the problem lie?
3.3 Why Has CoinPool Not Been Implemented?
Although CoinPool has many advantages and is regarded as an ideal scalability model, its reliance on soft fork upgrades is so extensive that we may not see its implementation on the Bitcoin network in our lifetime. CoinPool's demand for soft fork upgrades mainly focuses on the following two aspects:
3.3.1 Upgrade of the State Update Mechanism
Since CoinPool is designed based on Eltoo, it inherits the requirement for a soft fork for the state update mechanism, which necessitates 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 terms, 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 completely 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. These off-chain UTXOs committed on-chain are the original source of the Virtual UTXO concept.
In summary, the main issues facing the implementation of CoinPool lie in the need for a lightweight state update mechanism APO and operation codes for Shared UTXO to facilitate implementation, both of which require Bitcoin's soft fork upgrades. As a result, even years after the CoinPool paper was born, 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 proposal 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 depend 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 would solve the off-chain state update problem while avoiding the need for updates to Bitcoin operational primitives. 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 a cryptographic primitive based on Schnorr adaptor signatures. 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 $S_1$ and $S_2$, they can be aggregated into a single signature $S=S_1+S_2$, and the corresponding public keys can also be aggregated into $P = P_1 + P_2$ during verification.
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 complete the partial signature left by PSign using Adapt. If it were just this, wouldn't it be similar to MuSig? However, the uniqueness of adaptor signatures lies in the 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 collaborate to confirm the adaptor signature for the off-chain transaction. 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 output's public key constructed using the Schnorr signature technique from two predetermined public key pairs.
Thus, before each transaction, we confirm the public-private key pairs to be used 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 the two adaptor signatures.
3.4.4 Pros and Cons of Bitcoin Clique
The Bitcoin Clique solution is not without its flaws. Its disadvantage is that during off-chain state updates, it requires continuous exchange of 2-AS keys used to construct the new penalty public key. Moreover, since this solution is based on CoinPool design, it also requires all parties to be online during state updates to exchange 2-AS keys and verify signatures for the new version of the UTXO. This means that the complexity of communication and interactivity remains high.
Most importantly, this model is similar to a StateChain design, where each time we transfer the ownership of a certain UTXO off-chain, systems using double-spend-prevent signatures like 2-AS cannot provide change in off-chain payments, which severely limits the application scenarios.
Moreover, even with the user-friendly Shared UTXO mechanism and off-chain anti-double spending primitives that do not require soft forks, we still need everyone online to update and 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 on-chain updates. Additionally, completely eliminating liquidity requirements is not what we desire; payment solutions lacking liquidity lubrication cannot provide change, and due to exit issues, all parties often must have the same denomination.
Therefore, there currently exists no off-chain scaling solution based on UTXO that is non-channel and supports dynamic denominations. Ethereum has also struggled with this issue, 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 Problems and Lessons:
The need for liquidity lubrication to ensure dynamic denomination payments (changeable transactions): This requires retaining channel design while also avoiding exit issues.
Reducing reliance on all participants being online simultaneously: We do not want every user to be online whenever any state update occurs in the off-chain network; updates to the Shared UTXO should only require relevant parties to collaborate online.
Based on the above understanding, this paper continues in this direction to explore more optimized solutions.
3.5 Channel Factory and Virtual Channels
From the previous discussions, we recognize that not only do we need to retain the design of channels, but we also need the low-cost benefits brought by Shared UTXO. A concept that has been discussed for a long time in the Lightning Network field 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: most functions, including liquidity adjustments, can be implemented off-chain, seemingly resolving the scalability of the Lightning Network.
But is the reality really that beautiful?
Due to inheriting the characteristics of Shared UTXO, the Channel Factory requires 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 the Channel Factory involves multiple parties jointly signing state updates, any party's desynchronization or malicious behavior may prevent other users from smoothly closing the channel and withdrawing funds.
Moreover, the issues with such a design are also 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 issues persist, and the complexity of implementing this solution may even be higher than that of the current LN-Penalty.
3.6 ARK JoinPool and Temporary Channels
Through 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:
Dynamic denominations brought by liquidity;
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 eliminating the need for liquidity, multi-hops, HTLCs, 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 the states of some users have not changed, they still need to be online to validate 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 in order to continuously run a Lightning Network node, besides ensuring that the user's private key is online for signing, there is another important reason: each channel member needs a WatchTower to continuously monitor whether the counterparty has put an unfavorable commitment transaction on-chain. This leads us to the second problem we need to solve.
3.6.2 Transfer of 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 a penalty. In this old model, all of our trading counterparts are peer Lightning nodes, and each time we participate in a transaction, we may open a channel 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; then the ASP will use the waiver transaction signed by the user off-chain to forfeit the funds brought on-chain. The ASP will monitor all historically appeared VTXOs to prevent anyone from maliciously exiting from VTXOs that have already been spent 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 safety.
Summary of Other Solutions for Optimizing User Node Operations:
- Cloud Hosting of Lightning Network Nodes
Some solutions choose to run Lightning Network nodes on cloud platforms to help users lower the threshold for running nodes. However, this approach fundamentally contradicts the security assumptions of the Lightning Network itself. In many scenarios, the storage of private keys and commitment transactions is equally important. Therefore, simply using remote private keys does not guarantee security.
Essentially, this approach transforms a two-party game scenario into a three-party game scenario involving me, the counterparty, and the cloud hosting provider. When I am in a state where I have traded with the counterparty but the state has not yet been put on-chain, the cloud hosting provider can unilaterally delete the commitment transaction in my cloud node, at which point my counterparty can put a favorable state on-chain. In such a cloud node hosting solution for the Lightning Network, there is a risk of collusion between the cloud hosting platform and the counterparty.
- CRAB and Sleepy CRAB
The CRAB (Channel Resistant Against Bribery) protocol proposed by Aumayr et al. adds collateral and incentivizes 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 the issue of "incoming liquidity," as it requires users to lock more funds unrelated to the transaction purpose 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 is using the operator's funds, but they will relinquish the funds they previously multi-signed with the operator.
The reason we refer to ARK's channels as temporary channels is that they possess two characteristics: unidirectionality and one-time funding.
Unidirectionality: In a unidirectional channel, funds will only flow from the designated initiator to the corresponding output party.
One-time funding: ARK's channels only require a one-time injection of funds. Once the funds are injected, there is no need to continue maintaining the liquidity of the channel.
In this design of temporary channels, once the funding is completed, the channel does not need to undergo rebalancing or other adjustments. Compared to Lightning, not only do users no longer need to worry about channel liquidity, but liquidity providers also no longer need to maintain channel liquidity. The only variable that remains in the channel is the event of user exit.
3.6.4 Summary of the ARK Protocol
From the above, 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 Scaling
Through the research above, we have explored multiple off-chain scaling solutions based on Shared UTXO. The original intention of the Shared UTXO design was to solve liquidity issues; however, as the protocol continues to evolve, we unexpectedly find that it brings many advantages we had hoped for but dared not expect.
This marks a new direction in the off-chain scaling of Bitcoin, representing a paradigm shift compared to the original Lightning Network model:
- From a P2P model to introducing a trustless operator.
The logic of off-chain scaling networks 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 to ensure asset security.
The traditional LN-Penalty model and the latest research such as CRAB rely on users to provide collateral to ensure fund security while 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.
- The responsibility of liquidity management is transferred 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 operating without the help of LSPs (Liquidity Service Providers) can be complex. However, with the responsibility of liquidity management transferred to a third-party operator, 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), resulting in users' funds not being effectively utilized. In the trend of new protocol designs, liquidity is concentrated in liquidity pools for unified management, providing unlimited possibilities for future DeFi scenarios.
This paradigm shift indicates that liquidity management is the essence of the evolution of Bitcoin's native off-chain scaling and is the core storyline for its continued evolution.
In the future, with continuous technological advancements and the emergence of new solutions, the path of Bitcoin's off-chain scaling will undoubtedly usher in 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.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
