The Art of Liquidity: What kind of Bitcoin off-chain expansion network do we need?
Multiple solutions such as LN-Symmetry, CoinPool, Bitcoin Clique and ARK Protocol have been proposed to improve the Lightning Network, but each solution has its limitations, such as reliance on soft fork upgrades, high communication complexity or limited application scenarios.
Original title: The Art of Liquidity: What kind of Bitcoin off-chain expansion network do we need?
Original author: Ben, Discoco Labs founder
Foreword
For a long time, I have been thinking about a question: What is the core logic of Bitcoin native expansion?
When we deeply studied the Lightning Network and tried to implement non-custodial business on the Lightning Network, we felt some inconsistency. The two-party channel theoretically has the most powerful transaction throughput, but the actual maintenance and use problems are much more than expected. The current performance of the Lightning Network in the initial micropayment direction is not satisfactory, and the core reason is liquidity. Even though a large number of so-called infrastructures to improve liquidity have been introduced, the actual effect has not met expectations.
During the writing of this article, the industry-renowned lightning self-custodial wallet Mutiny Wallet announced its closure, and its cooperative 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 main network has a long block time, averaging about 10 minutes, which is obviously far from the requirement for it to become a peer-to-peer cash system for the world. In view of this, we urgently need an expansion plan: it needs to occupy little block space, can be quickly settled, and must be a native Bitcoin-based solution. Thus, the Lightning Network came into being.
The Lightning Network defines that after locking assets on the chain, the exchange of a committed transaction is completed off the chain, which is why it is called instant payment. Compared with the 10-minute confirmation time of Bitcoin main network payment, this undoubtedly solves the number one problem for small payment scenarios.
However, in the actual development and use of the Lightning Network, multiple problems have gradually emerged. This article summarizes four core problems:
1.1 High difficulty in node maintenance
The current Lightning Network is based on the P2P penalty transaction game model. In order to monitor whether the other party will upload the old state that is not beneficial 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 maintenance thresholds and education costs for nodes.
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, and punishing private keys. For example, every time the off-chain state 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. 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 equivalent to the user opening his own bank account to some extent, and he needs to bring his own reserves. The typical problem is that users need to ensure the liquidity of the channel to receive 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, it is very easy to have liquidity imbalance, and users have to rely on various tools to supplement liquidity, such as submarine swaps and channel splicing. However, these technologies require additional on-chain transactions to adjust the original FundingTx to achieve this. 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 Layer2 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, and it can be called a "fee assassin".
All 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 custodial solution, as can be seen from the statistics in the figure below.
Statistics on the number of new Lightning Network users who choose to use the custodial wallet solution and the non-custodial wallet solution
It is not difficult for us to understand the reasons 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 expansion network do we need?
Lightning Network White Paper Excerpt
According to the description of 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. 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 actual adjustment of channel liquidity technologies (submarine exchange, channel splicing) require additional on-chain transactions, the problem of insufficient block space faced by the Lightning Network in Bitcoin will be more severe in real scenarios.
It can be seen that the current Lightning Network is difficult to meet the needs of large-scale C-end users in the short term. In addition, limited by the Bitcoin block capacity, the Lightning Network's potential for expansion in the long run is also significantly restricted.
The question then arises: What kind of Bitcoin off-chain expansion network do we need?
2.1 Current Status of the Lightning Network
In order to understand the current limitations of the Lightning Network, we need to trace back to its design principles.
The current Lightning Network model is also called LN-Panelty, which is generally a two-party channel model based on penalty transactions. Its security depends on the user's locally stored transactions 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 own surveillance.
Under such a 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 in itself has deviated from the originally envisioned P2P mesh model. Under the condition 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
So, now let us imagine what characteristics the Bitcoin off-chain expansion network that C-end users really need should have:
1. Adopting a non-P2P model, users do not need to maintain nodes by themselves, while maintaining good security and convenience
2. On the interactive end, users do not need to be online at the same time when paying, and one party can be offline and asynchronous operations can be achieved
3. Improve capital efficiency while meeting non-custodial needs
4. A cheap and efficient liquidity management mechanism, without even 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. The evolution of BTC’s native expansion
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 lies in:
· Storage and continuous monitoring of committed transactions
· Multi-hop mechanism across multiple people (HTLC/PTLC)
These elements constitute the basis of the current Lightning Network design, and also directly lead to the complexity of node design, which is manifested as:
· Complex encrypted communication interactions
· Storage of local committed transactions and penalty private keys
· WatchTower that cannot be interrupted during the existence of the channel
These problems prompted us to think about whether a lighter state 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: Introducing a version mechanism for state updates
BIP118 proposes the introduction of the SIGHASH_ANYPREOUT signature mode, which allows the input of a transaction to update its predecessor 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 has changed 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 like the past lightning network node design.
Therefore, from the overall effect, LN-Symmetry has limited improvements to the current lightning network experience, and there is still a long way to go to achieve our goal.
In order to further improve, this article introduces 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, whose 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 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 of 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 state of a UTXO without relying on complex HTLC/PTLC mechanisms. Its main advantages are:
· Greatly reduce the interaction complexity of multi-party channels: 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.
· 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 approach not only simplifies the process of state updates, 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 maintain sufficient liquidity independently. In the multi-party collaborative CoinPool design, liquidity requirements can be greatly 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 financial pressure of individual participants.
The design of CoinPool 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 the independent liquidity needs of each participant, provides a lighter and more flexible solution for multi-party collaboration, and breaks through the limitations of the traditional LN model in multi-party interaction and liquidity management.
However, why has such a solution with significant advantages not been widely adopted so far? What is the root cause of the problem?
3.3 Why is CoinPool not really implemented?
Although CoinPool has many advantages and is regarded as an ideal expansion model, the soft fork upgrade requirements it relies on are so many that we may not see it landed on the Bitcoin network in our lifetime. CoinPool's demand for soft fork upgrades is mainly concentrated in the following two aspects:
3.3.1 Upgrade of the status update mechanism
Since CoinPool is designed based on Eltoo, it inherits its demand for soft forks in the status update mechanism, that is, Bitcoin needs to be upgraded to enable a new signature mode SIGHASH_ANYPREVOUT(APO), but as we all know, Bitcoin's soft fork upgrade progresses slowly, making 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 Shared UTXO status requires the collection of all signatures that share a certain version of the UTXO. In this process, if one party is offline, the entire system will stagnate. 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 without relying entirely on cooperation.
In the CoinPool paper, OP_MERKLESUB was 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 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)** and so on. 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 that 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 template of predefined transactions to impose spending restrictions. CTV is not only simple to implement, but also can commit a series of off-chain UTXOs through a UTXO on a chain 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 greatest 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 every time ZKP-MerkleState verification is performed through OP_CAT, and the Shared UTXO corresponding to the Layer2 state is directly committed 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 a lightweight state update mechanism APO and Shared UTXO's opcodes to help implement it, and both 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 discussion of the CoinPool model above, we learned that the APO mechanism it relies on needs to be soft-forked and upgraded to make the solution possible, which is difficult to achieve in the short term. So 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 need to update the Bitcoin operation primitive can be avoided. The emergence of the Bitcoin Clique paper has brought new hope. It introduces a new cryptographic primitive, 2-shot-adaptor-signature (2-AS), which provides a new solution for off-chain anti-double spending.
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 signature has a linear property, 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 a 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
Adapter signature has several basic steps, 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 and private keys. Then the party holding the corresponding private key of the adapter, which is the so-called secret, has the ability to Adapt to complete the partial signature left by Psign. If that's all, isn't it similar to MuSig? However, the unique feature of adapter signatures is that they can Extract, that is, when the complete signature is released, the party that initiated the Psign of the adapter signature can extract the corresponding secret (private key) through the complete signature, the previous partial signature, and the adapter (public key).
3.4.3 Combination of the two: 2-AS
We have already learned about the characteristics of Schnorr signatures and adapter signatures. Now we can look at the magic of combining the two: 2-AS.
Assuming we have a VTXO and want to ensure that it can be confiscated when double-spending, 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. Ensure that users can be confiscated when double-spending.
· The counterparties cooperate to sign the adapter to confirm the off-chain transaction. If the user uses the same input twice, the output can be confiscated by the service provider.
· Require users 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 two pairs of public keys determined in advance and the Schnorr signature technology is added.
Therefore, before each transaction, we confirm the public and private key pairs to be used later 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 scheme is not perfect either. Its disadvantage is that when the off-chain status is updated, the 2-AS key used to construct the new penalty public key needs to be exchanged continuously. And because the scheme is based on the CoinPool design, and in order to exchange the 2-AS key each time and verify the signature of the new version of UTXO, the scheme also requires everyone to be online when the status is updated. In other words, the complexity and interactivity of communication are still very high.
The most important point is that such a model is a StateChain-like design. Every time we transfer the ownership of a UTXO off-chain, the system using double-spend-prevent signatures like 2-AS cannot make changes 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-spend primitives that do not require soft forks, we still need everyone to update and confirm the new state of the 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 it is not what we expect to completely eliminate the demand for liquidity. Payment solutions that lack liquidity lubrication cannot make denomination changes, and due to exit issues, the denominations of all people must often be the same.
Therefore, there is currently no non-channel off-chain expansion solution that supports dynamic denominations and is based on UTXO. Ethereum was once troubled by this route, which we call the Plasma trap. For related research, please refer to the paper Lower Bounds for Off-Chain Protocols: Exploring the Limits of Plasma.
Summary of problems and lessons:
1. Liquidity lubrication is needed to ensure dynamic denomination payments (changeable transactions): This requires retaining 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 any status update is made on the off-chain network. The update of Shared UTXO should be a collaborative update by relevant people online.
Based on the above understanding, this article continues along this direction to explore more optimized solutions.
3.5 Channel Factory and Virtual Channel
In the previous discussion, we realized that we not only need to retain the design of the channel, but also need Shared UTXO to bring us low-cost benefits off-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 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, that is, 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 are implemented off-chain, including liquidity adjustment, and the expansion of the Lightning Network seems to be solved.
But is it really so beautiful?
Due to the inheritance of the characteristics of Shared UTXO, the channel factory requires the collaborative work of multiple users to open and close. If any 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 to sign status updates, any asynchronous or malicious behavior of any party may cause other users to be unable to smoothly close the channel and withdraw funds.
And the problem of such a design is also obvious. Although the cost of channel switching is reduced in this way, the security model between channels still relies on commitment transactions and HTLC. Therefore, the problems of communication and interaction still exist, 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: Partial participation in updates
As mentioned above, CoinPool brings potential to multi-person off-chain collaborative expansion, such as no need for liquidity, multi-hop, HTLC and other complex and fault-prone designs. 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 also need to be online when others execute. In other words, in the design based on JoinPool, users only need to be online when they need to trade.
But we all know that in addition to ensuring that the user's private key is online for signing, another important reason for the uninterrupted operation of the Lightning Network node is that 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 put the old state on 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 to trade. But in ARK, all users actually interact with ASP (ARK Service Provider) and do not interact directly with other users.
For ASP, once the user's off-chain VTXO is traded, a waiver transaction will be signed. This is because ideally, the user's off-chain VTXO will not be brought to the chain, but will be constantly referenced and carried out in the next round of transactions. If a VTXO is traded off-chain and raised 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 that the user has brought to the chain. 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 finally no longer need ordinary users to run their own nodes to ensure their own security.
A 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 remote private keys 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 custodian. After I have traded with my counterparty but the status has not 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 the payment channel by adding additional collateral combined with a mechanism to incentivize miners, especially when the user is 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 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 by themselves, but it reduces the requirements for users to be online.
3.6.3 Temporary Channel: 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 two characteristics: unidirectionality and one-time capital injection.
· Unidirectionality: In a one-way channel, funds will only be transferred from the designated initiator to the corresponding output party.
· One-time capital injection: ARK's channel only needs a one-time injection of funds. 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 rebalanced or adjusted. Compared with lightning, not only do users no longer need to care about channel liquidity, but liquidity providers no longer need to maintain channel liquidity. The only change in the channel is the event of user withdrawal.
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 with Lightning Network:
· Users do not need to maintain nodes by themselves
· Users do not need to maintain channel liquidity by themselves, and there is no problem of account liquidity
· Support asynchronous interaction, and both parties do not need to be online at the same time
4. Changes in Bitcoin's native expansion paradigm
Through the above research, we 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 expected but did not dare to expect.
This marks a new development direction for Bitcoin off-chain expansion, which is a paradigm shift compared to the original Lightning Network model:
· From the P2P model to the introduction of a 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 the security of their assets
The traditional LN-Penalty model and the latest research such as CRAB rely on users to provide collateral to ensure the security of funds, and require users to stay online and run nodes during the existence 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 responsibility shifts from user to operator
In the classic LN-Penalty model and improved design, users need to adjust the liquidity in the channel by themselves, especially when 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, with the liquidity management responsibility shifted to a third-party operator, users no longer need to worry about liquidity management. This greatly simplifies the user experience and removes barriers to joining the network.
· Capital efficiency and potential greatly improved
New protocol designs are 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 across channels), resulting in the ineffective use of users' 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.
References:
· Poon, J., & Dryja, T. (2016). The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments. Retrieved from https://lightning.network/lightning-network-paper.pdf
· Decker, C., Russell, R., & Osuntokun, O. (n.d. ). Eltoo: A Simple Layer2 Protocol for Bitcoin. Blockstream. Retrieved from https://blockstream.com/eltoo.pdf
· Naumenko, G., & Riard, A. (n.d.). N-Symmetry Project Recap. Retrieved from https://delvingbitcoin.org/t/ln-symmetry-project-recap/359
· Riahi, S., & Litos, O. S. T. (2024). Bitcoin Clique: Channel-free Off-chain Payments using Two-Shot Adaptor Signatures. Cryptology ePrint Archive, Report 2024/025.
· Retrieved from https://eprint.iacr.org/2024/025Dziembowski, S., Fabiański, G., Faust, S., & Riahi, S. (2020). Lower Bounds for Off-Chain Protocols: Exploring the Limits of Plasma. Cryptology ePrint Archive, Report 2020/175.
· Retrieved from https://eprint.iacr.org/2020/175ARK Network Blog. (n.d.). Retrieved from https://github.com/ark-network/arkdev.info/tree/master/blog
· Somsen, R. (n.d.). Simplest Ark Explanation. Retrieved from https://gist.github.com/RubenSomsen/a394beb1dea9e47e9 81216768e007454?permalink_comment_id=4633382
· BRQGoo. (2023). Introducing ARK. Medium. Retrieved from https://brqgoo.medium.com/introducing-ark-6f87ae45e272
· JohnLaw2. N Scaling Covenants. GitHub Repository. Retrieved from https://github.com/JohnLaw2/ln-scaling-covenants
· JohnLaw2. (n.d.). LN Factory Optimized. GitHub Repository. Retrieved from https://github.com/JohnLaw2/ln-factory-optimized
· Shinobi. (n.d.). Timeout Trees: A Solution to Scaling Lightning Network LSPs. Bitcoin Magazine. Retrieved from https://bitcoinmagazine.com/technical/timeout-trees-a-solution-to-scaling-lightning-network-lsps
· Rubin, J., & O'Beirne, J. (2020). BIP-119: CHECKTEMPLATEVERIFY. Bitcoin Improvement Proposal. Retrieved from https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
· Black, B. (2023). [bitcoin-dev] Combined CTV+APO to minimal TXHASH+CSFS. Linux Foundation Mailing List. Retrieved from https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021907 .html
· Aumayr, L., Avarikioti, Z., Maffei, M., & Mazumdar, S. (2021). Sleepy Channels: Bitcoin-Compatible Bi-Directional Payment Channels that Do Not Require Monitoring. Cryptology ePrint Archive, Report 2021/1445.
· Retrieved from https://eprint.iacr.org/2021/1445Aumayr, L., Avarikioti, Z., Maffei, M., & Mazumdar, S. (2024). Securing Lightning Channels against Rational Miners. Cryptology ePrint Archive, Report 2024/826. Retrieved from https://eprint.iacr.org/2024/826.pdf
· Todd, P. (2024). Covenant-Dependent Layer 2 Review. Retrieved from https://petertodd.org/2024/covenant-dependent-layer-2-review
Disclaimer: The content of this article solely reflects the author's opinion and does not represent the platform in any capacity. This article is not intended to serve as a reference for making investment decisions.
You may also like
Bitcoin toward $100K: Samson Mow predicts the ‘Omega candle’ era
Indonesian cryptocurrency transactions cross $30B for 2024
XRP market cap exceeds $100 billion
Bitcoin futures price at CME Group crosses $100,000