I have been thinking about a question for a long time : What is the core logic of Bitcoin’s native expansion?
As we delved into the Lightning Network and tried to implement non-custodial services on the Lightning Network, we sensed some dissonance. Two-party channels theoretically have the most powerful transaction throughput, but actual maintenance and use problems are much more than expected.
The Lightning Network’s current performance in the initial micropayment direction is unsatisfactory, and the core reason is liquidity. Even though a large amount of infrastructure that is said to improve liquidity has been introduced, the actual effect has not yet reached expectations.
Just as this article was being written, the industry-renowned Lightning self-hosted wallet Mutiny Wallet announced its closure, followed by the closure of its partner Liquidity Service Provider (LSP). The collaboration model between self-hosted wallets and LSPs has always been considered an important future direction of the Lightning Network, which makes people once again 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 the liquidity expansion kit.
1. What are the current problems with the Lightning Network?
Bitcoin's block capacity is limited and the mainnet block generation time is long, about 10 minutes on average, which is obviously too far from its requirement to become the world's peer-to-peer cash system. In view of this, we urgently need a scaling solution: it needs to occupy small block space, can be settled quickly, and must be a native Bitcoin-based solution. As a result, the Lightning Network came into being.
The Lightning Network defines that after the assets are locked on the chain, the exchange of a committed transaction under the chain is deemed to be completed, which is why it is known as instant payment. In terms of experience, this is compared to the 10-minute limit on Bitcoin mainnet payment confirmation time. For small-amount payment scenarios, it undoubtedly solves the number one problem.
However, during the actual development and use of the Lightning Network, multiple issues gradually emerged. This article summarizes four core issues here:
1.1 Node maintenance is difficult
The current Lightning Network is based on the P2P penalty transaction game model. In order to constantly monitor whether the other party uploads the old state that is not beneficial to itself during the existence of the channel, this model requires the WatchTower to be online at all times, which requires users to maintain the nodes themselves. In addition, users also need to store private keys and committed transaction data locally, resulting in high maintenance thresholds and high education costs for nodes.
1.2 Highly interactive
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, penalizing 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 has strict requirements on user interactivity. And when multiple parties interact, the complexity brought by HTLC and multi-hop is also difficult to overcome.
1.3 Low capital efficiency
The LN-Panelty mechanism of the two-party channel is to a certain extent equivalent to users opening their own bank accounts and needing to bring their own reserves. A typical problem is that users need to ensure channel liquidity to receive funds, and capital efficiency is very low. And a lot of channel liquidity on the edge will not be fully utilized.
1.4 Channel management cost is high
In P2P channels, it is extremely easy for liquidity imbalance to occur, and users have to rely on various tools to assist in supplementing liquidity, such as submarine swaps, channel splicing, etc. However, these technologies require additional on-chain transactions to adjust the original FundingTx to be implemented. In general, all adjustment methods are costly, especially when handling fees increase, and the cost is difficult for users to ignore.
Imagine what an embarrassing scene it would be for those users who thought they were using Layer 2 technology for cheap transactions to suddenly face several mainnet on-chain handling fees. This embarrassment becomes more obvious as the handling fees on the mainnet chain become higher, which can be called the "handling fee assassin".
Various problems have also shown obvious consequences in the actual adoption of the Lightning Network: user growth is sluggish, and most new users will choose hosting solutions, as can be seen from the statistics in the figure below.
Statistics on the number of newly added Lightning Network users choosing 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 Bitcoin off-chain scaling network do we need?
Excerpt from Lightning Network White Paper
According to the description of the Lightning Network white paper, if everyone in the world switches channels twice a year, the Bitcoin block capacity will eventually need to increase to 133MB. Compared with the current Bitcoin mainnet, the block size is only 1MB, and even the P2TR address using Segregated Witness is only 4MB, which shows a huge gap.
In addition, considering that the technologies that actually adjust channel liquidity (submarine exchange, channel splicing) require additional on-chain transactions, the problem of insufficient block space faced by the Lightning Network in Bitcoin will be problematic in real scenarios. More severe.
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
In order 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. Generally speaking, this model is a two-party channel model based on penalty transactions. Its security relies on the user's locally stored private key to check and balance the other party's transactions and penalties, and to maintain monitoring of the Bitcoin chain at all times to ensure that every move of the counterparty is under his or her own surveillance.
Under such a model design, it is inevitable for users to execute nodes themselves, because local storage and WatchTower functions are indispensable. This part has been emphasized repeatedly 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 LSP maintainer's super node. This itself has deviated from the original idea. P2P mesh model. In the case of natural evolution, it finally returned to the classic hub-and-spoke model.
The following figure is an example. The left side is the ideal Lightning Network, and the right side is the real Lightning Network status quo.
2.2 Characteristics of the ideal to C off-chain expansion network
So, now let’s imagine what features C-side users really need for the Bitcoin off-chain expansion network:
- Using a non-P2P model, users do not need to maintain nodes themselves while maintaining good security and convenience.
- On the interactive side, users do not need to be online at the same time when making payments. Offline and asynchronous operations can be achieved by one party.
- Improve capital efficiency while meeting non-custodial needs
- 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 scaling network.
3. The evolution path of BTC’s native expansion
First of all, we need to make it clear that in the current core mechanism of Lightning Network design "LN-Panelty", the basis of the status update mechanism is:
- Storage and continuous monitoring of committed transactions
- Multi-hop mechanism across multi-person collaboration (HTLC/PTLC)
These elements form the basis of the current Lightning Network design and directly lead to the complexity of node design, as shown in the following:
- Complex encrypted communication interactions
- Local commitment transaction and penalty private key storage
- The execution of WatchTower cannot be interrupted during the duration of the channel.
These problems prompted us to think about whether a lighter status update mechanism can 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 the input of a transaction to update its previous transaction without fully specifying the previous output without changing the signature. Compared with "LN-Penalty", this design can significantly reduce the complexity and storage requirements of encrypted communication between nodes. 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 on 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 release the old state to the chain, the other party still needs to monitor in real time and release the latest state transaction in time to replace the old state.
The monitoring tasks in this process still require traditional WatchTower. At this time, the purpose of executing 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 the same heavy communication burden as the past Lightning Network node design.
Therefore, from the overall effect, the experience improvement that LN-Symmetry brings to the current Lightning Network is limited, and there is still a long way to go before the goal we are pursuing.
For further improvement, this article leads to the direction of the next stage: Shared UTXO.
3.2 CoinPool: Reduce 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 is to further solve the problem of multi-party interaction under the version update mechanism of SIGHASH_ANYPREOUT.
In the LN-Symmetry design, the new status update mechanism introduced by Eltoo indeed simplifies the status management of point-to-point channels. However, when it comes to multi-party collaboration, the complexity of interactions still exists, especially in multi-hop payments (HTLC/PTLC), which require close coordination of all parties and multiple encrypted communications.
The innovation of CoinPool is that it utilizes 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 reflected in:
- Significantly reduces the interaction complexity of multi-party channels: Since all participants share the same UTXO, they can reach consensus by signing version updates of this UTXO without the need for 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 UTXO version that is confirmed by multiple parties jointly signing. This approach not only simplifies the process of status updates, but also further reduces dependencies and potential conflict points between parties.
- Eliminate the need for independent liquidity: Through the Shared UTXO model, multiple participants actually share the same liquidity pool, eliminating the need for each participant to maintain sufficient liquidity independently. In a multi-party collaborative CoinPool design, liquidity needs can be significantly reduced or reallocated. Participants can use the liquidity in the shared UTXO to complete payments without having to lock up large amounts of funds for their own channels. This not only improves the efficiency of fund utilization, but also reduces the financial pressure on individual participants.
The design of CoinPool 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 the independent liquidity needs of each participant, provides a lighter and more flexible solution for multi-party collaboration, and breaks through the traditional LN model in multi-party interaction and liquidity management. limitations.
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 regarded as an ideal expansion model, the soft fork upgrades it relies on require so many requirements that we may not see it implemented on the Bitcoin network in our lifetime. CoinPool’s demand for soft fork upgrades mainly focuses on the following two aspects:
3.3.1 Status update mechanism upgrade
Since CoinPool is designed based on Eltoo, it inherits its need for a status update mechanism for soft forks, which requires Bitcoin upgrade to enable a new signature mode SIGHASH_ANYPREVOUT (APO). However, as we all know, Bitcoin soft fork upgrades are progressing slowly. This makes the technology that CoinPool's status 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 status of Shared UTXO requires collecting the signatures of all shared versions of the UTXO. During this process, if one party goes offline, the entire system will come to a standstill. In blockchain terms, this system has poor liveness. To overcome this challenge, the system requires a mechanism that can update Shared UTXO at low cost and without relying 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 to other operation contracts based on Merkle trees, that is, the logic implementation is complex and it is difficult to form a universal and reusable contract. For example, contracts similar to **OP_TAPLEAFUPDATEVERIFY (TLUV)** and so on. 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 that it can successfully pass the upgrade of the Bitcoin network.
Among these contract proposals, OP_CheckTemplateVerify (CTV) is gradually becoming the focus of attention. Instead of directly building and validating a Merkle tree, CTV limits spending through templates of predefined transactions. CTV is not only simple to implement, but can also 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 Virtual UTXO concept.
Among these contracts, CTV has the greatest appeal for popularity because it is both simple and versatile. The powerful capabilities of CTV can not only realize ideas similar to CoinPool, but can also be used by Rollup. It can be imagined that each time ZKP-MerkleState is verified through OP_CAT, and the Shared UTXO corresponding to the Layer2 state is directly committed in the instruction code, we will be able to build a true Bitcoin ZK-Rollup solution.
To sum up, the main problem faced by the implementation of CoinPool is that it requires lightweight status update mechanism APO and Shared UTXO opcode to help implement it, both of which require Bitcoin's soft fork upgrade. So 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 aforementioned discussion of the CoinPool model, we learned that the APO mechanism it relies on requires a soft fork upgrade to realize the solution, which is difficult to achieve in the short term. So if there is a new off-chain double-spend prevention 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 status update mechanism that can avoid double spending. Based on this idea, if equivalent cryptographic primitives can be found, the problem of off-chain status updates can be solved and the need to update Bitcoin operation primitives can be avoided. The emergence of the paper Bitcoin Clique has brought a new dawn. It introduces 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 adapter signature. To understand 2-AS, we must first have a certain understanding of Schnorr signature and interface card signature.
3.4.1 Schnorr signature
Schnorr signatures have linear properties, which means that multiple signatures can be aggregated into a single signature. To put it simply, 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 key during verification can also be aggregated into $P = P_1 + P_2 $.
3.4.2 Interface card signature
There are several basic steps for interface card signature, 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 interface card 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 interface card as part of the signature, and the interface card is often the public key part of the public and private keys, and then holds the interface card corresponding to the private key. The key, also known as the secret party, has the ability to Adapt to complete the partial signature left by Psign.
If it's just that, is it similar to MuSig? However, the interface card signature is unique in that it can be Extracted. That is, after the complete signature is released, the party that originally initiated the Psign of the interface card signature can extract the corresponding Psign through the complete signature, the previous partial signature, and the interface card (public key). secret (private key).
3.4.3 Combination of the two: 2-AS
Having already understood the characteristics of Schnorr signatures and interface card signatures, now we can look at the magic that combines the two: 2-AS.
Suppose we have a VTXO and want to ensure that it can be slashed off-chain when double-spending, then we can design it like this:
First we need to have a penalty output, in which the pubkey that can be unlocked is a penalty public key. This ensures that users can be slashed when double-spending.
Counterparties cooperate with each other to perform interface card signatures to confirm off-chain transactions. If the 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 the status. The penalty public key of the penalty output is composed of the Schnorr signature technology addition of two pairs of public keys determined in advance.
Therefore, before each transaction, we confirm the public and private key pairs to be used subsequently, and generate 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 interface card signatures.
3.4.4 Pros and cons of Bitcoin Clique
The Bitcoin Clique scheme is not perfect either. The disadvantage is that when the off-chain state is updated, the 2-AS key used to build a new penalty public key needs to be continuously exchanged. And because the solution is based on CoinPool design, and in order to exchange 2-AS keys 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 this model is a design similar to StateChain. Every time we transfer the ownership of a certain UTXO off-chain, a system using double-spend-prevent signatures like 2-AS cannot be used on-chain. Change is made during payment, which makes the application scenarios very limited.
In addition, even with the easy-to-operate SharedUTXO mechanism and the off-chain double-spending primitive that does 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 off-chain Some people on the Internet. It is unreasonable to allow irrelevant people to participate in on-chain updates online.
And it is not desirable to completely eliminate the need for liquidity. Payment schemes that lack liquidity lubrication cannot make change in denominations, and due to exit problems, everyone must often have the same denomination.
Therefore, there is currently no off-chain expansion solution that is non-channel and supports dynamic denomination and is based on UTXO. In the past, Ethereum was also troubled by this route, which we called the Plasma trap. For related research, please refer to the paper Lower Bounds for Off-Chain Protocols: Exploring the Limits of Plasma.
Summary of issues and lessons learned:
- The lubrication of liquidity is required to ensure dynamic denomination payments (changeable transactions): this requires preserving the channel design and at the same time avoiding exit problems.
- Reduce dependence on synchronization of all participants online: We do not want every user to be online when making any status updates on the off-chain network. Shared UTXO updates should be updated collaboratively online by relevant people.
- Based on the above understanding, this article continues to explore more optimized solutions in this direction.
3.5 Channel factory and virtual channel
In the previous discussion, we realized that we not only need to preserve the design of the channel, but also need Shared UTXO to bring us low-cost benefits off the chain. Then a concept that has been discussed for a long time in the field of Lightning Network has entered our field of vision, namely Channel Factory.
Previously, we mentioned that off-chain UTXO committed by on-chain UTXO is called Virtual UTXO. If we use the off-chain Virtual UTXO as the FundingTx of the channel, we will get a new concept, which is a virtual channel (Virtual Channel).
Then the virtual channel under the chain in this Shared UTXO is connected by Virtual HTLC. Everything is off-chain and "virtualized". This seems to provide an ideal solution: implement most functions off-chain, including liquidity adjustments, etc., and the Lightning Network’s expansion suite seems to be easily solved.
But is it really so beautiful?
Because it inherits the characteristics of Shared UTXO, the channel factory requires the collaborative work of multiple users to open and close it. If any one of the users fails to cooperate in time (for example, is offline or unresponsive), it may affect the functionality of the entire channel factory. Since the channel factory involves multiple parties co-signing status updates, any party's out-of-synchronization or malicious behavior may prevent other users from successfully closing the channel and withdrawing funds.
And the problem with this 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, communication and interaction problems still exist, and the implementation complexity of this solution is even higher than the current LN-Panelty.
3.6 ARK JoinPool and temporary channel
Through the review of previous channel factory cases, we came to a conclusion: in the channel design based on Shared UTXO, the classic "LN-Panelty" channel design may not be continued, but at the same time the advantages of introducing channels should be retained:
- Dynamic denominations brought about by liquidity
- Easy to exit
Based on this, a design of temporary channels using JoinPool emerged, namely ARK Protocol.
3.6.1 JoinPool: Partial ginseng and updates
As mentioned above, CoinPool brings the potential for multi-person off-chain collaborative expansion, for example, it does not require complicated and failure-prone designs such as liquidity, multi-hop, and HTLC.
But the most critical issue of the CoinPool model is the online requirements for users: all users in the entire Shared UTXO must be online when updating off-chain status. Even if the status of some users has not changed, they still need to be verified online and given Produce the corresponding signature. This requirement makes it impossible for us to avoid the problem of users needing to execute their own nodes.
In order to solve this problem, a new model is proposed, namely JoinPool. The concept of JoinPool in Shared UTXO is: every time a user needs to update their off-chain status, everyone joins together in a Shared UTXO that represents the new status of its corresponding UTXO.
This solves the problem of unrelated users needing 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 understand that in addition to ensuring that the user's private key can be signed online, there is also an important reason for the need for uninterrupted execution of Lightning Network nodes. Each channel member needs WatchTower to continuously monitor whether the counterparty has corrected the transaction. own unfavorable commitment transactions to the chain. This brings us to the second question we need to address.
3.6.2 WatchTower responsibility transfer: users do not need to maintain nodes by themselves
In the classic LN-Panelty design, each user needs to build his own WatchTower to monitor whether the other party uploads the old status to the chain, and if so, it will be punished. In such an old model, the counterparties of all of us are peer lightning nodes, and every time we participate in a transaction, it is possible to open a channel with a different node for transaction. But in ARK, all users actually interact with ASP (ARK Service Provider) and will not directly interact with other users.
For ASP, once the user trades VTXO off-chain, he or she will sign a waiver transaction. This is because ideally the user's VTXO off-chain will not be mentioned on-chain, but will be continuously referenced and then carried on to the next round of transactions.
If a VTXO is traded off-chain and proposed on-chain at the same time, it means that the VTXO has been double-spended by the user. Then ASP will use the waiver transaction signed by the user off-chain to deal with the transaction. The user mentions the funds on the chain to be slashed. ASP will monitor all VTXOs that have appeared in history to prevent anyone from maliciously exiting the VTXOs that have been spent off the chain and then on the chain.
This transfers the operational responsibility of WatchTower from ordinary users to the operator. Compared with the Lightning Network, this model has been a huge improvement: we finally no longer need ordinary users to execute their own nodes to ensure their own security. .
A summary of other solutions in optimizing user node execution:
Lightning Network Node Cloud Hosting
Some solutions choose to execute Lightning Network nodes on cloud platforms to help users lower the threshold for using execution 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 the remote private key does not guarantee security.
Essentially, this solution turns a two-party game scenario into a three-party game scenario involving me, the counterparty, and the cloud hosting party. When I have traded 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. At this time, my counterparty can easily upload the status that is beneficial to it. In such a Lightning Network cloud node hosting solution, 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. uses additional collateral combined with a mechanism to incentivize miners to ensure the security of payment channels, especially when users are offline. This mechanism reduces dependence on third-party WatchTower. However, this collateral mechanism undoubtedly further exacerbates problems like "booked liquidity". Because it requires users to lock more funds that have nothing to do with the purpose of the transaction when joining the off-chain network. Although it ensures security, it sacrifices the liquidity and efficiency of funds. Moreover, this type of solution still requires users to execute nodes by themselves, but only reduces the online requirements for users.
3.6.3 Temporary channel: users do not need to maintain channel liquidity themselves
Someone may ask, why is the ASP service provider willing to inject liquidity into our channel 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, the user is using the opeator's funds for every off-chain transaction, but will transfer the funds that he has signed with the opeator before.
The reason why ARK's channel is called a temporary channel is that it has two characteristics: one-way and one-time capital injection.
- One-way: 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 funds are injected, there is no need to continue to maintain the liquidity of the channel.
Under the design of such a temporary channel, after the capital injection is completed, the channel does not need to be adjusted such as rebalancing. Compared with Lightning, not only users no longer need to care about channel liquidity, but liquidity providers no longer need to maintain channel liquidity. The only change that exists in the channel is the user exit event.
3.6.4 Summary of ARK protocol
Based on 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 accounting liquidity problem
- Supports asynchronous interaction, no need for both parties to be online at the same time
4. Changes in Bitcoin’s native expansion architecture
Through the above research, we have explored multiple off-chain expansion solutions based on Shared UTXO. Shared UTXO was originally designed to solve liquidity problems. However, as the protocol continues to evolve, we unexpectedly found that it brought many advantages that we had expected but did not dare to dream of.
This marks that Bitcoin off-chain expansion has entered a new development direction. Compared with the original Lightning Network model, this is a formalized transfer:
From the P2P model to the introduction of trustless operators
The logic of the off-chain expansion network has gradually evolved from the initial "user versus user" bilateral game model of the Lightning Network to a game model between "user and operator". 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 and the latest research such as CRAB rely on users to provide collateral to ensure the safety of funds, while requiring users to stay online and execute nodes during the existence of the channel. However, future scenarios 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 designs, users need to adjust the flow in the channel by themselves, especially when the flow is unbalanced. This usually requires some expertise and is complex to operate without the help of an LSP (Liquidity Service Provider). However, as liquidity management responsibilities are transferred to third-party operators, 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 are greatly improved
New protocol designs are 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 by themselves 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 among channels) , resulting in the ineffective use of user funds. In the new protocol design trend, liquidity is centralized into liquidity pools for unified management, which provides unlimited possibilities for future DeFi scenarios.
This formalized transformation shows that liquidity management is the essence of the expansion and evolution of Bitcoin’s native chain, and it is also the core thread of its future evolution.
In the future, with the continuous advancement of technology and the emergence of new solutions, Bitcoin's off-chain expansion will surely have brighter development prospects. We will continue to conduct in-depth research in this area, and readers are invited to look forward to our further results.
