BitVM Bridge and OP-DLC: A new generation of Bitcoin Layer2 cross-chain bridge

Author: Faust & Nickqiao, Geekweb3

Abstract:· ZK bridge deploys smart contracts on chain A, directly receives and verifies block headers and corresponding zero-knowledge proofs on chain B, and confirms the validity of cross-chain messages. It is the bridging solution with the highest security level; Optimistic/OP bridge challenges invalid cross-chain messages on-chain through fraud proofs. Only one reliable challenger is needed to ensure the security of the cross-chain bridge fund pool;

· ZK bridge cannot be directly deployed on Bitcoin mainnet due to technical limitations, but optimistic bridge can be implemented through BitVM and fraud proofs. Teams such as Bitlayer and Citrea adopted the BitVM bridge solution, introduced pre-signatures, and combined the idea of ​​channels, allowing users to limit the processing flow after the deposit is executed before the official deposit, and not giving the cross-chain bridge official the opportunity to embezzle user deposits.

· The BitVM bridge is essentially based on the "advance payment-reimbursement" model. There are dedicated Operator nodes to pay money for withdrawal users, and Operators can apply for reimbursement from the public deposit address regularly. If the Operator has a false reimbursement application, it can be challenged and slashed by anyone;

· The BitVM bridge does not have security issues in theory, but it has activity/availability issues, and it cannot meet the needs of specific users for fund independence and anti-money laundering (it is essentially a fund pool model). Bitlayer has added a bridge solution called OP-DLC, which is similar to DLC.link. It introduces fraud proofs based on channels and DLC to prevent the oracle of the DLC bridge from doing evil.

· Due to the difficulty of implementing BitVM and fraud proofs, the DLC bridge will be implemented first and become a temporary substitute. As long as the trust risk of the oracle is resolved and a more reliable and mature third-party oracle is integrated, the DLC bridge can become a safer withdrawal verification solution than the multi-signature bridge at this stage.

Introduction: Since the inscription boom last year, the Bitcoin ecosystem has entered a period of rapid growth with a blowout momentum. In just half a year, there have been nearly 100 projects under the banner of BTC Layer2, which has become a new world of chaos, opportunities and scams. It is no exaggeration to say that the current Bitcoin ecosystem is already a "multi-ethnic melting pot" of Ethereum, Cosmos and Celestia, CKB and Bitcoin native ecosystem. Coupled with the lack of authoritative voices, the Bitcoin ecosystem is just like the United States in the 19th century, becoming a new world that absorbs various forces. While this brings prosperity and vitality to the entire Web3 narrative, it also introduces huge risks.

Many projects have begun to hype without even releasing technical solutions, claiming to be able to fully inherit the security of the Bitcoin mainnet under the name of native layer2; some even use the propaganda method of creating concepts and invent a bunch of bizarre terms as lines to promote their own superiority. Although self-promotion is already the current situation of the Bitcoin ecosystem, there are still many top KOLs who have made objective calls.

Not long ago, Monanaut, the founder of the blockchain browser Mempool, publicly criticized the current problems of the Bitcoin ecosystem. He pointed out sharply that if a Bitcoin Layer2 simply uses a multi-signature withdrawal bridge and cannot allow users to withdraw assets at any time in a trustless manner, such a project is not a real Layer2. Interestingly, Vitalik also pointed out that Layer2 should be at least more secure in terms of security than a system that simply relies on multi-signatures.

It can be said that Monanaut and Vitalik bluntly pointed out the technical problems of Bitcoin Layer2: Many L2 withdrawal bridges are essentially multi-signature bridges, either several well-known institutions each hold a key, or use decentralized signatures based on POS, but in any case, their security models are based on the majority honesty assumption, that is, the default is that most multi-signature participants do not collude to do evil.

This withdrawal bridge solution that relies heavily on credit endorsement is by no means a long-term solution. History has told us that multi-signature bridges will sooner or later have various problems. Only trust-minimized or completely trustless asset custody methods can withstand the test of time and hackers. But the current situation of Bitcoin ecology is that many project parties have not even released the technical roadmap of the withdrawal bridge, and there is no finalized design idea for how to trust or minimize the trust of the bridge.

But this is not all of Bitcoin ecology. At present, some project parties have expressed their opinions on the optimization ideas of the withdrawal bridge. In this article, we will briefly analyze Bitlayer and Citrea's BitVM bridge, and introduce the OP-DLC bridge proposed by Bitlayer to address the shortcomings of the BitVM bridge, so that more people can understand the risks and design ideas of the cross-chain bridge, which is crucial for the majority of Bitcoin ecological participants.

Optimistic bridge: bridge verification scheme based on fraud proof

In fact, the essence of the cross-chain bridge is very simple, which is to prove to the B chain that an event did happen on the A chain. For example, if you transfer assets from ETH to Polygon, you need the cross-chain bridge to prove that you have indeed transferred assets to a specific address on the ETH chain, and then you can receive the same amount of funds on the Polygon chain.

Traditional cross-chain bridges generally use witness multi-signatures. They will designate several witnesses under the chain. The witnesses must run the nodes of each public chain to monitor whether anyone has charged funds to the cross-chain bridge's payment address.

The security model of this type of cross-chain bridge is basically the same as that of a multi-signature wallet. Its trust model must be determined according to the multi-signature setting method, such as M/N, but in the end it basically follows the honest majority assumption, which is to assume that most notaries are harmless and have a limited fault tolerance rate. Many large-scale cross-chain bridge thefts that have occurred before basically occurred on this type of multi-signature bridge, either because of internal theft or hacker attacks.

In contrast, the "optimistic bridge" based on the fraud proof protocol and the "ZK bridge" based on ZK are much safer. Take the ZK bridge as an example. It will set up a dedicated validator contract on the target chain to verify the withdrawal proof directly on the chain, eliminating the reliance on off-chain witnesses.

For example, a ZK bridge spanning ETH and Polygon will deploy a validator contract on Polygon, temporarily recorded as Verifier. The Relayer node of the ZK bridge will forward the latest Ethereum block header and the ZK Proof proving its validity to the Verifier for verification. This is equivalent to letting the Verifier contract synchronize and verify the latest Ethereum block header on the Polygon chain. The merkle root recorded on the block header is associated with the transaction set contained in the block, and can be used to verify whether a transaction is included in the block.

If there are 10 cross-chain transfer statements from ETH to Polygon in the Ethereum block with a block height of 101, Relayer will generate Merkle Proofs related to these 10 transactions and submit proofs to the Verifier contract on the Polygon chain:

The 101 Ethereum block contains 10 cross-chain transactions from ETH to Polygon. Of course, the ZK bridge can ZK-ify the Merkle Proof and submit the ZK Proof directly to the Verifier contract. In this whole process, users only need to trust that the smart contract of the cross-chain bridge has no loopholes and that the zero-knowledge proof technology itself is safe and reliable, without introducing too many trust assumptions like the traditional multi-signature bridge.

The "Optimistic Bridge" is slightly different. Some optimistic bridges retain settings similar to witnesses, but will introduce fraud proofs and challenge windows. After the witness generates multiple signatures for the cross-chain message, although it will be submitted to the target chain, its validity will not be recognized immediately. It will be judged valid only after a window period has passed and no one has raised any questions. This is actually similar to the idea of ​​Optimistic Rollup. Of course, there are other product models for optimistic bridges, but in the final analysis, security is guaranteed by the fraud proof protocol.

The trust assumption of the M/N multi-signature bridge is N-(M-1)/N. You have to assume that the number of malicious people in the network is at most M-1, and the number of honest people is at least N-(M-1). The trust assumption of the ZK bridge can be ignored, while the trust assumption of the optimistic bridge based on fraud proof is 1/N. Only one of the N witnesses needs to be honest and willing to challenge the invalid cross-chain message submitted to the target chain to ensure the security of the bridge.

Currently, due to technical limitations, only the ZK bridge in the direction of Bitcoin deposits to Layer2 can be realized. If the direction is the opposite, withdrawing from Layer2 to the Bitcoin chain, only multi-signature bridges or optimistic bridges, or a channel-like model (the OP-DLC bridge to be described below is more like a channel) . To realize the optimistic bridge on the Bitcoin chain, fraud proofs must be introduced, and bitVM has created good conditions for the realization of this technology.

In the previous article "A Simple Interpretation of BitVM: How to Verify Fraud Proofs on the BTC Chain", we briefly introduced that BitVM's fraud proof is essentially to break down the complex computing tasks performed off-chain into a large number of simple steps, and then pick out a certain step to verify directly on the Bitcoin chain. This idea is similar to Ethereum optimistic Rollups such as Arbitrum and Optimism.

(The BitVM2 document mentions that a computing task will be split into a large number of intermediate steps through Lamport signatures, and then anyone can challenge a certain intermediate step)

Of course, the above statement is still obscure, but I believe that most people have long understood the meaning of fraud proofs. In today's article, due to the overall length, we do not intend to interpret the technical implementation details of BitVM and the fraud proof protocol, because this involves a series of complex interactive processes.

We will briefly introduce BitLayer and Citrea, BOB and even the official BitVM designed native BitVM bridge from the perspective of product and mechanism design, and how Bitlayer can alleviate the bottleneck of the BitVM bridge through the OP-DLC bridge, and show you how to design a better withdrawal bridge solution on the Bitcoin chain.

(Bitlayer's bridging scheme diagram)

Brief analysis of the BitVM bridge principle of Bitlayer and Citrea

In the following, we use the BitVM bridge scheme announced by Bitlayer, Citrea and Bob as material to illustrate the general operation process of the BitVM bridge.

In its official documents and technical blogs, the above project party clearly explained the product design ideas of the BitVM withdrawal bridge (currently in the theoretical stage). First, when a user withdraws funds through the BitVM bridge, the Bridge contract on Layer2 needs to generate a withdrawal statement. The following key parameters will be specified in the withdrawal statement: The number of mapped BTC that the withdrawer needs to destroy on L2 (e.g., 1 BTC); The cross-chain fee that the withdrawer intends to pay (assuming 0.01 BTC); The withdrawer's receiving address on L1: L1_receipt; The withdrawer's receiving amount (i.e., 1 — 0.01 = 0.99BTC) After that, the above withdrawal statement will be included in the Layer2 block. The Relayer node of the BitVM bridge will synchronize the Layer2 block, listen to the withdrawal statement contained therein, and forward it to the Operator node, which will make the payment for the withdrawing user.

It should be noted here that the Operator first pays for the user on the Bitcoin chain out of his own pocket, that is, "advances" funds for the BitVM bridge, and then applies for compensation from the BitVM bridge's fund pool.

When applying for reimbursement, the Operator needs to provide proof of his advance payment on the Bitcoin chain (that is, to prove that he has paid the money to the address specified by the withdrawal user on L1, and to extract the specific transfer record contained in the Bitcoin block). At the same time, the Operator must also issue a withdrawal statement generated by the withdrawer on L2 (through Merkle Proof, it is proved that the withdrawal statement issued comes from the L2 block, rather than being fabricated by himself). After that, the Operator needs to prove the following: The funds paid by the Operator to the withdrawer on behalf of the BitVM bridge are equal to the amount of money requested by the withdrawer in the statement; When the Operator applies for reimbursement, the reimbursement amount shall not exceed the amount of mapped BTC destroyed by the withdrawer in Layer2; The Operator has indeed processed all L2-L1 withdrawal statements within a period of time, and each withdrawal statement can be matched to the withdrawal transfer record on the Bitcoin chain; This is essentially a punishment for the Operator for lying about the amount of advance payment or refusing to process the withdrawal statement (which can solve the anti-censorship problem of the withdrawal bridge) The Operator needs to compare and verify the key fields of the advance payment proof and the withdrawal statement off-chain to prove that the BTC amounts involved in the two are equal.

If the withdrawal bridge operator falsely reports the advance payment amount, it means that the operator claims that the payment proof on L1 matches the Withdrawal Statement issued by the L2 withdrawer, but the actual situation is that the two do not match.

In this way, the ZKP that proves Payment Proof = Withdrawal Statement must be wrong. As long as this ZKP is released, Challanger can point out which step is wrong and challenge it through BitVM2's fraud proof protocol.

It should be emphasized that Bitlayer, Citrea, BOB, ZKBase, etc. have adopted the latest BitVM2 route, which is the new version of the BitVM solution. This solution will ZK the off-chain computing tasks, that is, generate ZK Proof for the off-chain computing process, then verify the Proof, and then convert the process of verifying ZKP into a form suitable for BitVM for subsequent challenges.

At the same time, by adopting Lamport and pre-signatures, the original BitVM's multi-round interactive challenges can be optimized to a single-round non-interactive challenge, greatly reducing the difficulty of the challenge.

The challenge process of BitVM requires something called "commitment", that is, Commitment. Let's explain what "commitment" is. Generally speaking, people who publish "commitments" on the Bitcoin chain will claim that certain data stored off-chain/computational tasks occurring off-chain are accurate, and the relevant statements published on the chain are "commitments".

We can roughly understand Commitment as a hash of a large number of off-chain data. The size of the Commitment itself is often compressed very small, but it can be bound to a large amount of off-chain data through Merkle Tree and other methods, and these associated off-chain data do not need to be on the chain.

In BitVM2 and Citrea, BitLayer's BitVM bridge solution, if someone thinks that the commitment issued by the withdrawal bridge operator on the chain is problematic and the commitment is associated with an invalid ZKP verification process, a challenge can be initiated, and the challenge authority is permissionless. (The interaction process is quite complicated and will not be explained here)

Since the Operator advances funds on behalf of the BitVM fund pool to pay the withdrawer, and then applies for reimbursement from the fund pool, when applying, the Operator must issue a Commitment to prove that the money transferred to the withdrawer on L1 is equal to the money the withdrawer claims to receive on L2. If this Commitment has not been challenged after the fraud proof window period, the Operator can take the reimbursement amount it needs.

Here we need to explain how the public fund pool of the BitVM bridge is maintained, which is precisely the most critical part of the cross-chain bridge.As we all know, the funds that the cross-chain bridge can pay to the withdrawer come from the assets contributed by the depositor or other LPs, and the money advanced by the Operator will eventually be withdrawn from the public fund pool, so simply looking at the result of the fund transfer, the amount of depositors' Deposit absorbed by the BitVM bridge should be equal to the amount of withdrawers' Withdraw. So how to keep the deposit funds is a very important issue.

In most Bitcoin Layer2 bridge solutions, public assets are often managed through multi-signatures. The user's deposits are aggregated into a multi-signature account. When the withdrawal needs to be paid, this multi-signature account is responsible for the payment. This solution obviously has a huge trust risk.

The BitVM bridge of Bitlayer and Citrea adopts the idea similar to the lightning network and channel.Before making a deposit, the user will first communicate with the BitVM alliance and let the latter pre-sign to achieve the following effects:

After the user transfers the deposit to the recharge address, the money will be directly locked in a Taproot address and can only be collected by the bridge operator.In addition, the operator can only apply for reimbursement to the Taproot address of the above deposit after paying the withdrawal funds to the user. After the challenge period ends, the Operator can withdraw a certain amount of user deposits.

In the BitVM bridge solution, there is a BitVM Federation formed by N members, which dispatches user deposits. However, these N members cannot embezzle user deposits privately, because before users transfer funds to the designated address, they will require the BitVM Federation to pre-sign first to ensure that these deposits can only be legally claimed by the Operator.

(BitVM2's schematic diagram of its optimistic bridge scheme)

In summary, the BitVM bridge adopts an idea similar to that of channels and lightning networks, allowing users to "verify by yourself". Through pre-signatures, the BitVM alliance cannot manipulate the deposit pool without authorization. The money in the deposit pool can only be used to reimburse the Operator. If the Operator falsely reports the advance payment amount, anyone can issue a fraud proof and challenge it.

If the above scheme can be implemented, the BitVM bridge will become one of the safest Bitcoin withdrawal bridges: This bridge does not have security issues, only availability/activity issues. When users try to deposit funds into BitVM, they may be censored or refused to cooperate by the BitVM Alliance, resulting in the inability to deposit funds smoothly, but this has nothing to do with security and is a problem of activity/availability.

However, the implementation of the BitVM bridge is relatively difficult, and it cannot meet the needs of some large users who have high requirements for fund transparency: these people may be involved in anti-money laundering issues and do not want to mix their funds with other people's funds, but the BitVM bridge will collect the depositors' money in a unified manner, which is a pool of mixed money to some extent.

In order to solve the above-mentioned activity problem of the BitVM bridge and provide independent and clean funds in and out channels for people with specific needs, the BitLayer team has added an additional cross-chain bridge solution called OP-DLC. In addition to the optimistic bridge of BitVM2, a DLC bridge similar to DLC.link is used to provide users with two entrances and exits, the BitVM bridge and the OP-DLC bridge, so as to reduce dependence on the BitVM bridge and even the BitVM Alliance.

（DLC Schematic Diagram）

DLC: Discreet Log Contract

DLC (Discreet Log Contracts) is called Discreet Log Contract, proposed by MIT's Digital Currency Initiative. The technology was first used to implement a lightweight smart contract on Bitcoin. It does not need to put the content of the contract on the chain. It can implement the privacy-protecting smart contract function on the Bitcoin chain through off-chain interactive communication and pre-signature methods. Let's use a football betting case to illustrate the working principle of DLC.

Suppose Alice and Bob want to bet on the result of the Real Madrid and Barcelona match held in 3 days, and each of them will put out 1 BTC. If Real Madrid wins, Alice can get 1.5 BTC, and Bob can only get back 0.5 BTC, which is equivalent to Alice earning 0.5 BTC and Bob losing 0.5 BTC; if Barcelona wins, Alice can only get back 0.5 BTC, and Bob can take away 1.5 BTC. If it is a tie, both of them get back 1 BTC.

If we want to make the above gambling process trustless, we have to find a way to prevent any party from cheating. If we simply use 2/2 multi-signature or 2/3 multi-signature, it is obviously not trustworthy enough. DLC has given its own solution to this point (relying on a third-party oracle). The entire workflow can be roughly divided into four parts.

Take Alice and Bob as an example, first, both parties create a fund transaction off-chain, which can lock each other's 1 BTC in a 2/2 multi-signature address. If this fund transaction takes effect, the 2 BTC in the multi-signature address need to be authorized by both parties before they can be spent.

Of course, this Fund transaction will not be uploaded to the chain first, but only stored in the local client of Alice and Bob off-chain. They both know what the consequences will be after this transaction takes effect. At present, the two parties are only conducting theoretical deductions, and then reaching a series of agreements based on the results of the deductions.

In the first stage of DLC creation, we can be sure that both parties will lock their respective 1 BTC into a multi-signature address in the future.

In the second step, both parties continue to deduce possible events and results in the future:For example, when the results of the game are announced, there may be multiple possibilities, such as Alice wins and Bob loses, Alice loses and Bob wins, or a draw, which will lead to different distribution results of Bitcoin in the aforementioned 2/2 multi-signature address.

Different results need to be triggered by different transaction instructions. These "transaction instructions that may be on the chain in the future" are called CET, that is, Contract Execution Transaction. Alice and Bob need to deduce all CETs in advance and generate a transaction data set containing all CETs.

For example, based on the several possible outcomes of the aforementioned bet between Alice and Bob, Alice created the following CETs:

CET1:Alice can get 1.5 BTC from the multi-signature address, and Bob can get 0.5 BTC;

CET2:Alice can get 0.5 BTC from the multi-signature address, and Bob can get 1.5 BTC;

CET3:Both parties can each get 1 BTC.

Let's take CET1 as an example (Alice takes 1.5 BTC, Bob takes 0.5 BTC):

This transaction means that 1.5 BTC in the multi-signature address is transferred to a Taproot address triggered by Alice and the oracle output, and the other 0.5 BTC is transferred to Bob's address. The corresponding event at this time is: Real Madrid wins, Alice wins 0.5 BTC, and Bob loses 0.5 BTC.

Of course, to spend these 1.5 BTC, Alice must get the "Real Madrid wins" result signature sent by the oracle. In other words, only when the oracle outputs the message "Real Madrid wins" can Alice transfer the 1.5 BTC. As for the contents of CET2 and CET3, we can follow the same logic and will not elaborate on them here.

It should be noted that CET is essentially a transaction to be put on the chain and take effect. What will happen if Alice broadcasts CET1 in advance, or puts CET1 on the chain that can only be successfully triggered after "Real Madrid wins" in the case of "Barcelona wins"?

In the previous diagram, we mentioned that after CET1 is put on the chain, the 2 BTC locked in the original multi-signature address will be transferred, 0.5 BTC will be transferred to Bob, and 1.5 BTC will be transferred to a Taproot address. After the oracle outputs "Real Madrid wins", Alice can unlock the BTC locked in the Taproot address. The effect is shown in the figure below.

At the same time, this Taproot address is restricted by the time lock. If Alice cannot successfully withdraw 1.5 BTC within the window period specified by the time lock, Bob has the right to take the money directly.

Therefore, as long as the oracle is honest, Alice cannot take away the 1.5 BTC. When the time lock expires, Bob can take the 1.5 BTC away. Counting the 0.5 BTC directly transferred to Bob when CET1 is put on the chain, all the money will belong to Bob in the end.

For Alice, whether she wins or loses in the end, the most advantageous approach is to put the correct CET on the chain. Putting invalid CET on the chain will make her lose more money.

In fact, when constructing the above CET, the schnorr signature of Taproot was improved. It can be understood as using the public key of the oracle + event results to construct independent addresses for different results. After that, the BTC locked in the address corresponding to the result can be spent after the oracle announces the signature corresponding to a certain result.

Of course, there is an additional possibility here. If Alice knows that she has lost, she simply does not put the CET1 she built on the chain. What should she do at this time? This is easy to solve, because Bob can build a custom CET for the "alice loses, Bob wins" event. The effect achieved by this CET is basically the same as the CET built by Alice, but the specific details are different, but the result is the same.

The above is the most critical CET construction process. The third step of DLC is for Alice and Bob to communicate, check the CET transaction built by the other party, bring their own signatures on the CET, and after checking that they can trust each other, they will each invest 1 BTC, lock it into the 2/2 multi-signature address of Alice and Bob mentioned at the beginning, and then wait for a CET to be on the chain to trigger the subsequent process.

Finally, after the oracle announces the result and gets the oracle's signature on the result, any party can put the correct CET on the chain, so that the 2 BTC locked in the multi-signature address can be redistributed. If the loser rushes to put the wrong CET on the chain, he will lose all his money. If the correct CET is put on the chain, the loser can get back 0.5BTC.

Some people may ask, What is the difference between DLC and ordinary 2/3 multi-signature? First of all, under 2/3 multi-signature, any two parties can steal all assets by collusion, while DLC restricts all scenarios between the opponents by building a CET set in advance. Even if the oracle participates in the conspiracy, the loss is often limited.

Secondly, multi-signature requires all parties to sign specific transactions to be put on the chain, while under the setting of DLC, the oracle only needs to sign the results of specific events, and does not need to know the content of CET/transactions to be put on the chain, and does not even need to know that there are two people, Alice and Bob. It only needs to interact with users normally like an ordinary oracle.

We can think that DLC essentially transforms the trust in multi-signature participants into trust in the oracle. As long as the oracle does not participate in evil, the DLC protocol design can be guaranteed to be trustworthy enough. In theory, DLC can use a more mature and complete third-party oracle to avoid evil. DLC.link and BitLayer take advantage of this feature of DLC and transfer the trust problem of the bridge to the third-party oracle.

In addition, Bitlayer's DLC bridge also supports self-built oracle nodes, on top of which a layer of fraud proof is added. When the self-built oracle puts invalid CET on the chain, anyone can challenge it. As for the principle of its OP-DLC bridge, we will briefly describe it below.

OP-DLC Bridge: DLC Channel + Fraud Proof

We will explain the operating principle of the OP-DLC bridge from the whole process of deposits and withdrawals. Assume that Alice deposits 1 BTC to L2 through the OP-DLC bridge. According to the two-step transaction mechanism, ALice first generates a pre-fund transaction, as shown below:

This is actually first transferring 1 BTC to the Taproot address controlled by Alice and the BitVM alliance members, and then starting a series of processes to create CET. If the BitVM bridge alliance members refuse to cooperate with Alice's deposit request, Alice can withdraw the money immediately after the time lock ends.

If the BitVM alliance members are willing to cooperate with Alice, the two parties will first generate a formal Fund deposit transaction (not on the chain yet) and all CETs in the withdrawal scenario through off-chain communication. After the CET generation and verification are completed, both parties will submit the Fund transaction to the chain.

In the Witness/signature data of the Fund transaction, Alice will specify her Layer2 payment address;After the Fund transaction is on-chain, Alice can submit the above fund transaction data to the bridge contract on Layer2 to prove that she has completed the deposit action on the Bitcoin chain and is eligible for the L2 bridge contract to release the token to the specified payment address.

After the Fund transaction is triggered, the deposit is actually still locked in the Taproot multi-signature address jointly controlled by Alice and the BitVM alliance members.But please note that the multi-signature can only unlock the BTC locked in the address through CET, and the BitVM alliance cannot transfer the money for no reason.

Next, let's analyze the CET that Alice and the BitVM alliance have built in advance. These CETs are used to meet potential scenarios for future withdrawals. For example, Alice may have deposited 1 BTC, but she only withdraws 0.3 BTC in her first withdrawal, and the remaining 0.7 BTC is at the disposal of the BitVM Alliance's public fund pool, but she can only withdraw money through the BitVM bridge mentioned above; or simply use this 0.7 BTC to initiate a new pre-fund deposit, as a new asset charged to the DLC bridge, and repeat the fund transaction and CET construction process mentioned above. The above process is not difficult to understand. In fact, it is to let the depositor Alice and the bitVM Alliance act as counterparties to each other, create CETs for withdrawal events of different amounts, and then let the oracle read the withdrawal statement initiated by Alice in Layer2 to determine which CET Alice wants to trigger (how much money she wants to withdraw).

The risk here is that the oracle may collude with the BitVM Alliance. For example, Alice declares that she wants to withdraw 0.5 BTC, but the oracle forges the withdrawal statement, which eventually causes the wrong CET "Alice withdraws 0.1BTC and the BitVM Alliance receives 0.9BTC" to be put on the chain.

There are several solutions to this. First, you can use a third-party oracle with a relatively complete design to prevent such collusion (it is extremely difficult for the BitVM Alliance to collude with the oracle at this time), or let the oracle pledge. The oracle needs to regularly publish Commitments on the Bitcoin chain, stating that it has honestly processed the withdrawal request of the withdrawer. Anyone can challenge the Commitment through BitVM's fraud proof protocol. If the challenge is successful, the malicious oracle will be slashed.

Under the design of the OP-DLC bridge, users can always "participate" in their assets to prevent the assets from being misappropriated by the BitVM Alliance. Moreover, this channel-like design scheme brings more autonomy to users, and there is no need to mix their funds with other people's funds. It is more like a P2P point-to-point deposit and withdrawal scheme.

In addition, considering that the BitVM scheme will take some time to land, before it lands, the DLC bridge is a more reliable bridge processing model than a simple multi-signature scheme. This scheme can also be used as two major deposit and withdrawal entrances and exits used in parallel with the BitVM bridge. If one of them fails, the user can go to the other entrance and exit, which is also a good fault-tolerant method.

Summary

The BitVM bridge solution of BitLayer and Citrea is essentially a "prepayment-reimbursement" model, with a dedicated Operator node to pay money to users who withdraw money, and the Operator can apply for reimbursement from the public deposit address regularly. If the Operator has a false reimbursement application, it can be challenged and slashed by anyone.

The BitVM2 solution introduces pre-signatures, combined with the idea of ​​channels, allowing users to limit the processing flow after the deposit is executed before the formal deposit, and not giving the cross-chain bridge official the opportunity to embezzle user deposits.

This bridge does not have security issues in theory, but there are activity/availability issues, and it cannot meet the needs of specific users for fund independence and anti-money laundering (it is still a fund pool model in essence), and it is also very difficult to implement.

To this end, Bitlayer has added a bridge solution called OP-DLC, which is similar to DLC.link. It introduces fraud proofs based on channels and DLC to prevent the oracle of the DLC bridge from doing evil.

However, due to the difficulty of BitVM landing, the DLC bridge will be the first to land and become a temporary substitute. As long as the trust risk of the oracle is resolved and a more reliable and mature third-party oracle is integrated, the DLC bridge can become a safer withdrawal verification solution than the multi-signature bridge at this stage.