BitVM recently came under some scrutiny after Taproot Wizards, Tyler and Rijndael, posted their criticism of the liquidity requirements imposed on the BitVM-based two-way peg operator. In all the recent discussions about BitVM-based Layer 2 solutions, I take it for granted that the people discussing them who are interested in the design space understand the collateral/liquidity requirements that the architecture imposes on the operator(s). The recent discussion of the “liquidity crunch” problem shows me that I was wrong about this assumption, and that many people outside of those actively involved in BitVM development were not aware of this problem.
Before I get into the liquidity crunch, I think it's important to clarify one of the unique features of BitVM bridging (called bridging by altcoin developers). In bridges built on other networks, funds held in the actual bridge nodes that control the movement of funds between networks are what is used to actually process withdrawals. If BitVM is linked, these funds cannot be accessed in order to complete withdrawals. The system operator (accumulator, sidechain, etc.) must provide its own liquidity in order to process user withdrawal requests.
As users withdraw requests come in, the operator, who moves the pooled value state forward, actually considers each request, and processes those withdrawals using their personal funds. After a while, the system then checks its status in a chunk that commits all pending withdrawals. After the operator All pending withdrawals from the last case have been fulfilled They can then participate in the process of claiming BitVM's collateralized funds to make themselves whole for all the capital they have provided. The BitVM contract was created so that operators can demand the cancellation of these funds if they do not honor all pending withdrawals from the last state.
So the general user flow is a deposit entered into a contract guaranteed by BitVM, the operator provides his own capital to process withdrawals, and then the operator periodically reimburses himself for the money he spent out of pocket from the BitVM contract. This distinguishes BitVM splicing from any other type of two-way splicing, providing liquidity requirements similar to an accelerator network.
Liquidity crisis
The issue identified by Taproot Wizards in its write-up is the result of a combination of upfront liquidity requirements imposed on the operator and a fraud-proof system that allows BitVM auditors to revoke an operator's access to funds if they do not. All withdrawals are fulfilled in a certain cumulative period. This creates a huge potential problem for the system, especially for the operator.
For now, let's completely ignore the possible scenario of an operator deliberately refusing to process a withdrawal due to malicious censorship. This is not a concern at this time when considering the potential issues, as if the operator had done something like this He should Their access will be revoked and they will incur a loss of any money they have already spent processing withdrawals.
It is quite possible that an honest operator will encounter a situation where, through no malicious intent on his part, he will not be able to access sufficient liquidity to process pending withdrawals in one cumulative period. If this happens, the honest operator will now not be able to compensate himself from the BitVM nodes for what he does Owns They were processed without exposing themselves to a single auditor who would challenge them and cause them to permanently lose access to the funds. Everything they spent processing withdrawals in that era will be wasted money that they can't recover.
This creates a huge risk for the linkage operator. By doing nothing harmful at all, simply through restrictions on their own funds, increased interest rates on borrowing money, just factors in the time needed to access the funds, they can lose an enormous amount of money. This creates significant potential instability in the connection, and also begs the question where does user money go if the operator is exposed to evidence of fraud?
Options
The important thing to note is that the final destination of the funds depends on certain design choices made by the implementers of any given link. There is a good degree of freedom available in design choices, the final destination of the funds after a challenge by the player has multiple options, and the period after the end of the era in which the player has to fulfill all withdrawals is configurable, and none of these things are set in stone as one method. possible to configure.
Now that we understand the problem, let's take a look at some potential solutions.
stuffy
You can address the problem by restricting withdrawals. This necessitates establishing a cap on the funds that the operator can commit to the contract to fulfill in any given cumulative period. This would allow the operator to ensure that it has sufficient capital to process the maximum amount it has to process. In each epoch, an operator can process several withdrawals, go through a claim process to redeem themselves from BitVM nodes, and then in the next epoch recycle that amount to meet the next wave of withdrawals.
The problem with this is that you don't know when there will be a significant increase in money tied to the system, nor do you know when market activity will align to motivate a huge amount of money to want to tie it up outside the system. . As more funds are tied, the likelihood of a significant increase in the amount to be tied at once increases. This dynamic essentially leads to an ever-increasing queue to exit the system unless you increase the maximum withdrawal amount, which also increases the liquidity requirements of the operator.
This exacerbates the liquidity requirements these connections require, and essentially creates significant friction for withdrawals. Swaps do not solve the problem, as they end up holding counterparties' liquidity in an ever-growing queue, unlike other two-way pegs where they can exit practically immediately after facilitating the swap.
Multiple operators
Both BitVM 1 and BitVM 2 support having multiple validators in different ways, allowing more than one to participate and be able to revoke an operator's access to funds. It is also possible in BitVM 2 (and some BitVM based stakes such as the Citrea cluster) to have multiple operators running in parallel. More than one entity can help process withdrawals from the peg, so multiple pools of liquidity are available to facilitate peg.
This would in principle make the entire liquidity dynamic more scalable, because it would not be limited to a single entity that would have to provide liquidity to facilitate timely withdrawals from the system, but it raises complex questions. Every UTXO deposited into the BitVM peg and committed to the contract needs to specify claim conditions. This contract must now be able to differentiate between multiple operators, ensure a way to differentiate between withdrawals associated with each operator, and ensure that they can only claim what they have facilitated rather than funds allocated to a different operator.
It must also take into account how to handle the global withdrawal request that all operators exist to facilitate. What if each operator has used all of their capital, but there is still unmet demand? Do they all have access to the revoked BitVM funds? None of them? Is there a grace period for passing similar to having the throttle in queue? If so, who is responsible if these withdrawals are not facilitated in the coming period? These are all things that need to be worked on concretely.
Multiple linear operators
In addition to having multiple parallel operators, you can have a series of linear operators. One operator can operate at a time, facilitating withdrawals, and if at any time it encounters a liquidity issue and its access to BitVM funds is revoked, the funds after the objection/reversal process can be sent immediately to a new BitVM with a new operator. This will not at all address the risk of one operator experiencing a liquidity crisis, and realizing the loss of any withdrawals they have already deposited, but it will ensure that someone else can step in and have the opportunity to continue facilitating withdrawals in capacity. To claim compensation from BitVM.
But this adds a significant amount of cost to the bonding process. Creating a BitVM instance is not cheap in terms of data and interaction, which means that to link two linear BitVM drivers together like this, you have to create that many BitVMs to link them.
Support
In all cases of any tie-in with BitVM, there is one final question: Where do the funds end up going in the worst case? There are ultimately two options. Either actually burn the money, or put it under the control of the verifier. The first means that users' funds are now destroyed, and everyone who holds funds in the peg system is now intact. The second means that the trust model has completely shifted to trusting an individual auditor or a group of auditors in a consortium that unilaterally controls the funds.
Burning money is a no-no in a model without withdrawal throttling, as that would validate the worst-case scenario concerns expressed by Taproot Wizards. The constant failure state of operators, regardless of parallelism or linearity, will literally destroy users' money. The only model that would be remotely safe would be one with a pull-through throttle; But even in this case, if the operator(s) specified in the contract disappear or their access is revoked, the risk of permanent loss of funds will still exist.
This leaves the return of funds under the control of one auditor or a group of them. In the event of a complete failure of all operators, this would allow the auditor(s) involved in the system to recover users' funds and make them whole. I don't think this is that bad.
Each BitVM instance is set up using n-of-n multisig which handles the signing of all pre-signed transactions included in the BitVM contract. The ultimate security paradigm for the entire scheme is that one and only one of these key holders must remain honest, and refuse to sign on to a dishonest distribution of funds, for the system to be secure.
The same security model can be applied to where the money goes (minus the trigger(s)) if the trigger fails entirely. This runs the risk of losing one key or uncooperative burning money, so you might as well make it a traditional m-of-n multisig.
I don't see any problem with this type of setup at all, it achieves the goal of ensuring that users' funds are not irretrievably burned without radically changing the trust model. Ultimately, if you are not a direct participant in the BitVM contract, i.e. you hold one of the n-of-n keys yourself, you are still trusting a federation of some sort. Obviously only needing to trust one member to be honest to keep things safe is better than having to trust 3 people in 5 of 7 multisig, but it's still a form of delegated trust.
wrapping
Ultimately, I think the liquidity crunch problem identified by Taproot Wizards is a very legitimate problem. Depending on the specific architecture of the connection in question, this can lead to problems ranging from completely burning users' funds, to losing operators' funds even without malicious action, to creating an ever-increasing exit queue without stopping deposits or returning to the system. n-of-n array to bypass the queue.
However, in my opinion, this does not mean that the idea of using BitVM to secure two-way binding is fundamentally broken. I think I've laid out quite a few ways that specific implementations can support or mitigate the issue, and ultimately the reality of a non-existent pool and the possibility of paying funds in the event of failure to a pool authorized to handle withdrawals can address the risk of permanent loss of funds.
As a final note, the pace of development in this area has reached a pace in the last year or so that I have never seen before in my time here, and I think it is important when discussing these developments to step back and remain calm while considering the discussions that occur around trade-offs and risks. Yes, public perception is one aspect of these conversations taking place in public, but these discussions must be rooted in the goal of arriving at an accurate understanding of the issues at hand. This should not detract from trying to prevent or defend any particular public perception first.
