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 worry about its future again. 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 mainnet block 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 mainnet 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 the 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 equivalent to users opening their own bank accounts to some extent, and they also need to bring their own reserves. The typical problem is that users need to ensure channel liquidity when receiving funds, and the capital efficiency is very low. 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.
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?
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 unlikely to meet the needs of large-scale C-end users in the short term. In addition, due to the limitations of Bitcoin block capacity, the Lightning Network's potential for expansion will also be significantly restricted in the long run.
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. Improve capital efficiency while meeting non-custodial needs
4. Cheap and efficient liquidity management mechanism, even without the need for 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 parties (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
These problems 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 to introduce the SIGHASH_ANYPREOUT signature mode, which allows the input of a transaction to update its previous transaction without fully specifying the previous output 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 originated from the paper eltoo: A Simple Layer2 Protocol for Bitcoin. In recent discussions on the development of the Lightning Network, 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 state update mechanism is transformed into a version of UTXO confirmed by multiple parties' joint signatures. This method not only simplifies the state 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 UTXO, while maintaining the security and efficiency of the system. More importantly, it reduces the reliance on each participant's independent liquidity needs, providing a lighter and more flexible solution for multi-party collaboration, breaking through the limitations of the traditional LN model in multi-party interaction and liquidity management.
However, why has such a solution with significant advantages not been widely adopted so far? What is the root cause 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 needs 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 general 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 the 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 facing the implementation of CoinPool is that it requires lightweight state update mechanism APO and Shared UTXO operation code to help implement it, both of which require soft fork upgrades of Bitcoin. As a result, CoinPool is still a paper solution many years after its birth.
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 a certain 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 subjects 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 thing about adapter signatures is that they can be extracted, that is, when the complete signature is released, the party that initiated the Psign 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 features 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. This ensures that users can be fined when they double spend.
· The counterparties cooperate to sign the adapter to confirm the off-chain transaction. If a user uses the same input twice, the output can be fined by the service provider.
· Requires users 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 and added using 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 constantly exchanged. 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, systems 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 state of UTXO online, even if each state 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 required to ensure dynamic denomination payments (change transactions): This requires retaining the channel design and can also avoid 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 in 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 all "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 committed transactions and HTLC. Therefore, the problem of communication and interaction still exists, and the implementation complexity of this solution is even higher than the current LN-Panelty.
3.6 ARK JoinPool and Temporary Channels
Through the previous case review of the channel factory, 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 brought by liquidity;
2. Easy to exit.
Based on this, a design of temporary channels 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 a 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 continuously 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. When I have completed a transaction with my 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 and 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 direction and one-time capital injection .
Unidirectionality: In a unidirectional channel, funds are only 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 the latest research such as CRAB, relies on users to provide collateral to ensure the safety of funds, and requires users to stay 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 are transferred 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 responsibility for liquidity management is 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 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 on their own 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.
Welcome to BlockBeats the BlockBeats official community:
Telegram subscription group: https://t.me/theblockbeats
Telegram group: https://t.me/BlockBeats_App
Official Twitter account: https://twitter.com/BlockBeatsAsia
