Author: Faust & Nickqiao, Geek web3

Abstract:

• ZK bridge deploys smart contracts on Chain A to directly receive and verify B chain block headers and corresponding zero-knowledge proofs, confirming the validity of cross-chain messages, which is the highest level of security for bridge solutions. Optimistic/OP bridge uses fraud proofs to challenge invalid cross-chain messages on-chain. With just one reliable challenger, the security of the cross-chain bridge fund pool can be ensured.

• Due to technical limitations, the Bitcoin mainnet cannot directly deploy ZK bridges, but can achieve optimistic bridges through BitVM and fraud proofs. Teams such as Bitlayer and Citrea have adopted the BitVM bridge solution, introducing pre-signing and combining the concept of channels, allowing users to limit the post-deposit processing before the formal deposit, preventing the official cross-chain bridge from misappropriating user deposits.

• The BitVM bridge is essentially based on the "advance payment-reimbursement" model, with dedicated Operator nodes paying withdrawal users. Operators can regularly apply for reimbursement from the public deposit address. If an Operator makes a false reimbursement request, it can be challenged and slashed by anyone.

• The BitVM bridge theoretically has no security issues, but it has liveness/availability issues and cannot meet specific users' needs for fund independence and anti-money laundering (essentially still a fund pool model). Bitlayer has added an OP-DLC bridge solution to address this, which is similar to DLC.link, introducing fraud proofs based on channels and DLC to prevent malicious behavior by the DLC bridge's oracle.

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

Introduction: Since the rune craze last year, the Bitcoin ecosystem has entered a period of rapid growth, with nearly 100 projects claiming to be BTC Layer2 in just six months. It has become a chaotic new land of opportunities and scams. It is not an exaggeration to say that the current Bitcoin ecosystem has become a "multi-ethnic melting pot" of Ethereum, Cosmos and Celestia, CKB, and Bitcoin native ecosystems, and the lack of authoritative voices has made the Bitcoin ecosystem like the United States in the 19th century, attracting various forces. While this brings prosperity and vitality to the entire Web3 narrative, it also introduces significant risks.

Many projects have been hyping up without even releasing their technical solutions, claiming to fully inherit the security of the Bitcoin mainnet under the banner of native Layer2. Some have even resorted to creating concepts and terms to promote their superiority. Although self-promotion is the current state of the Bitcoin ecosystem, many top KOLs have issued objective calls.

Not long ago, Monanaut, the founder of the blockchain explorer Mempool, publicly criticized the current issues in the Bitcoin ecosystem, sharply pointing out that if a Bitcoin Layer2 simply uses a multi-signature withdrawal bridge, it cannot allow users to withdraw assets in a trustless manner at any time, making such a project not a true Layer2. Interestingly, Vitalik had previously pointed out that Layer2 should be at least as secure as systems that rely solely on multi-signatures.

It can be said that Monanaut and Vitalik have bluntly pointed out the technical issues in Bitcoin Layer2: many L2 withdrawal bridges are essentially multi-signature bridges. They either involve several well-known institutions each holding a key, or use decentralized signatures based on POS. However, in any case, their security model is based on the assumption of majority honesty, assuming that the majority of multi-signature participants are not colluding.

This heavy reliance on credit endorsement for withdrawal bridge solutions is not a long-term solution. History has shown us that multi-signature bridges will inevitably encounter various problems. Only asset custody methods that minimize trust or tend towards complete trustlessness can withstand the test of time and hackers. However, the current state of the Bitcoin ecosystem is that many project teams have not even released a technical roadmap for withdrawal bridges, let alone a well-formed design approach for how to minimize trust or achieve trustlessness in the bridge.

However, this does not represent the entire Bitcoin ecosystem. Some project teams have expressed their opinions on optimizing withdrawal bridge solutions. In this article, we will briefly analyze the Bitlayer and Citrea's BitVM bridge, and introduce Bitlayer's OP-DLC bridge proposed to address the shortcomings of the BitVM bridge, which is crucial for the vast participants in the Bitcoin ecosystem to understand the risks and design ideas of cross-chain bridges.

Optimistic Bridge: Bridge verification solution based on fraud proofs

In fact, the essence of a cross-chain bridge is very simple, which is to prove to Chain B that a certain event has indeed occurred on Chain A. For example, if you want to cross 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 an equivalent amount of funds on the Polygon chain.

Traditional cross-chain bridges generally use multi-signature witnesses. They will designate several witnesses off-chain, and these witnesses need to run nodes for various public chains to monitor whether someone has deposited funds into the cross-chain bridge receiving address.

The security model of these cross-chain bridges is basically the same as that of multi-signature wallets, and follows a trust model based on multi-signature settings such as M/N. However, they ultimately all follow the assumption of majority honesty, assuming that the majority of notaries are not malicious, with limited fault tolerance. There have been several cases of large-scale thefts of cross-chain bridges, most of which occurred with these multi-signature bridges, either due to self-theft or hacker attacks.

In contrast, the "optimistic bridge" based on fraud-proof protocols, and the "ZK bridge" based on zero-knowledge proofs, are much safer. Taking the ZK bridge as an example, it will deploy a dedicated verifier contract on the target chain to directly verify the withdrawal proof on-chain, eliminating the need to rely on off-chain witnesses.

For example, a ZK bridge spanning ETH and Polygon will deploy a verifier contract on Polygon, referred to as Verifier. The ZK bridge's Relayer nodes will forward the latest Ethereum block header and the proof of validity ZK Proof to the Verifier, which will then verify them. This is equivalent to allowing the Verifier contract on the Polygon chain to synchronize and verify the latest Ethereum block header. The merkle root recorded in the block header is related to the set of transactions contained in the block and can be used to verify whether a certain transaction is included in the block.

If, in Ethereum block height 101, there are 10 cross-chain transfers from ETH to Polygon, the Relayer will generate a Merkle Proof related to these 10 transactions and submit the proof to the Verifier contract on the Polygon chain.

101st Ethereum block contains 10 cross-chain transactions from ETH to Polygon. Of course, the ZK bridge can ZKify the Merkle Proof and directly submit the ZK Proof to the Verifier contract. In this entire process, users only need to trust that the cross-chain bridge's smart contract is free of vulnerabilities and that the zero-knowledge proof technology itself is secure and reliable, without the need to introduce excessive trust assumptions like traditional multi-signature bridges.

The "Optimistic Bridge" is slightly different. Some optimistic bridges retain settings similar to witnesses but introduce fraud proofs and challenge windows. After the witnesses generate a multi-signature for the cross-chain message, although it is submitted to the target chain, its validity will not be immediately recognized. It must pass through a challenge window without anyone questioning it to be deemed valid. This is actually somewhat similar to the approach of Optimistic Rollup. Of course, optimistic bridges have other product models, but ultimately, security is guaranteed by fraud-proof protocols.

The trust assumption of an M/N multi-signature bridge is N-(M-1)/N, where you assume that the maximum number of malicious actors in the network is M-1, and the minimum number of honest actors is at least N-(M-1). The trust assumption of a ZK bridge can be negligible, while for an optimistic bridge based on fraud proofs, the trust assumption is 1/N, where out of N witnesses, only one needs to be honest and willing to challenge invalid cross-chain messages submitted to the target chain to ensure the bridge's security.

Currently, due to technical limitations, only the deposit direction of Bitcoin to Layer2 can be achieved with a ZK bridge. If the direction is reversed, from Layer2 to the Bitcoin chain for withdrawals, only multi-signature bridges or optimistic bridges are supported, or a mode similar to channels (the upcoming OP-DLC bridge is more like a channel). To implement an optimistic bridge on the Bitcoin chain, fraud proofs need to be introduced, and BitVM has created favorable conditions for the implementation of this technology.

In a previous article "A Simple Explanation of BitVM: How to Verify Fraud Proofs on the BTC Chain," we briefly introduced the fraud proofs of BitVM, which essentially breaks down complex off-chain computing tasks into many simple steps, and then selects a specific step to be directly verified on the Bitcoin chain. This approach is similar to Arbitrum, Optimism, and other Ethereum optimistic rollups.

Of course, the above explanation may be somewhat obscure, but I believe that most people already have some understanding of 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 fraud-proof protocols, as this involves a series of complex interaction processes.

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

Brief Analysis of Bitlayer and Citrea's BitVM Bridge Principles

In the following text, we will use the materials provided by Bitlayer, Citrea, and Bob to explain the general operation process of the BitVM withdrawal bridge.

In their official documents and technical blogs, the above-mentioned project teams have provided a relatively clear explanation of the product design concept of the BitVM withdrawal bridge (currently in the theoretical stage). First, when a user withdraws funds through the BitVM bridge, they need to use the Bridge contract on Layer2 to generate a withdrawal declaration. The withdrawal declaration will specify the following key parameters:

• The amount of mapped BTC to be destroyed on L2 by the withdrawal person (e.g., 1 BTC);
• The cross-chain transaction fee the withdrawal person intends to pay (assumed to be 0.01 BTC);
• The receiving address of the withdrawal person on L1: L1_receipt;
• The amount the withdrawal person intends to receive (i.e., 1 - 0.01 = 0.99 BTC)

Subsequently, the above withdrawal declaration will be included in the Layer2 block. The BitVM bridge's Relayer nodes will synchronize the Layer2 block, monitor the included withdrawal declarations, and forward them to the Operator node, who will make the payment to the withdrawal user.

It is important to note that the Operator first pays out of pocket on the Bitcoin chain to the withdrawal user, essentially "advancing" the funds for the BitVM bridge, and then applies for reimbursement from the BitVM bridge's fund pool.

When applying for reimbursement, the Operator needs to provide proof of their advance payment on the Bitcoin chain (i.e., proof that they made the payment to the withdrawal user's specified address on L1, extracting the specific transfer record included in the Bitcoin block). At the same time, the Operator also needs to provide the withdrawal declaration generated by the withdrawal person on L2 (through Merkle Proof, proving that the issued withdrawal declaration comes from the L2 block and is not fabricated out of thin air by the Operator). Subsequently, the Operator needs to prove the following:

The funds advanced by the Operator for the BitVM bridge to the withdrawal person are equal to the amount requested by the withdrawal person in the declaration; When applying for reimbursement, the reimbursement amount does not exceed the amount of mapped BTC destroyed by the withdrawal person on Layer2; The Operator has indeed processed all the L2-L1 withdrawal declarations over a period of time, and each withdrawal declaration can be matched to the withdrawal transfer record on the Bitcoin chain; This essentially serves as a penalty for the Operator for falsely reporting the amount advanced or refusing to process withdrawal declarations (which can address the censorship resistance issue of the withdrawal bridge). The Operator needs to compare and verify the key fields of the advance payment proof and the withdrawal declaration off-chain, proving that the BTC amounts involved are equal.

If the withdrawal bridge Operator falsely reports the amount advanced, it means that the Operator claims that the payment proof on L1 matches the Withdrawal Statement issued by the withdrawal person on L2, but in reality, they do not match.

In this case, the ZKP proving that Payment Proof = Withdrawal Statement must be incorrect. As soon as this ZKP is published, the Challenger can point out where the error is and challenge it through the fraud-proof protocol of BitVM2.

It is important to emphasize that Bitlayer, Citrea, BOB, ZKBase, and others have adopted the latest BitVM2 route, which is the new version of the BitVM solution. This approach will ZKify the off-chain computing tasks, meaning that it will generate ZK Proofs for the off-chain computing process and then verify the Proof. The verification process will be transformed into a form suitable for BitVM, making it easier for subsequent challenges.

At the same time, by using Lamport and presigning, the original multi-round interactive challenge of BitVM has been optimized to a single-round non-interactive challenge, greatly reducing the difficulty of the challenge.

The challenge process of BitVM requires the use of something called a "Commitment." Let's explain what a "Commitment" is. Generally, when someone publishes a "Commitment" on the Bitcoin chain, they claim that certain off-chain data/computing tasks are accurate, and the related declaration published on the chain is the "Commitment."

We can roughly understand Commitment as the hash of a large amount 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 methods such as Merkle Tree, and this associated off-chain data does not need to be put on the chain.

In the BitVM2, Citrea, and BitLayer's BitVM bridge solutions, if someone believes that the Commitment published by the withdrawal bridge Operator on the chain is problematic and is associated with an invalid ZKP verification process, they can initiate a challenge, and the challenge permission is Permissionless. (The interaction process inside is quite complex and will not be explained here.)

Since the Operator is advancing funds from the BitVM fund pool to make payments to the withdrawal person, and then applying for reimbursement from the fund pool, when applying, the Operator needs to publish a Commitment to prove that they transferred the money to the withdrawal person on L1, equal to the amount the withdrawal person declared to receive on L2. If this Commitment is not challenged after the fraud-proof window, the Operator can take the reimbursement amount they need.

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 withdrawal person come from the deposits of depositors or other LP-contributed assets. The money advanced by the Operator must ultimately be withdrawn from the public fund pool, so simply looking at the result of the fund transfer, the amount of deposit absorbed by the BitVM bridge should be equal to the amount withdrawn by the withdrawal person. Therefore, how to safeguard the deposited funds is a very important issue.

In most Bitcoin Layer2 bridge solutions, public assets are often managed through multi-signature, where users' deposits are aggregated into a multi-signature account. When it is necessary to make payments to the withdrawal person, this multi-signature account is responsible for making the payment. This approach obviously carries significant trust risks.

However, Bitlayer and Citrea's BitVM bridge have adopted a similar approach to the Lightning Network and channels. Before depositing, users will communicate with the BitVM alliance and have the latter presign, achieving the following effects:

After the user deposits funds into the deposit address, the money will be directly locked in a Taproot address and can only be claimed by the Operator of the bridge. Moreover, the Operator can only claim the funds from the above-mentioned deposit Taproot address after advancing the withdrawal funds to the user and applying for reimbursement. After the challenge period ends, the Operator can take a certain amount of the user's deposit.

In the BitVM bridge solution, there is a BitVM alliance composed of N members, and they are responsible for managing the user's deposits. However, these N members cannot misappropriate the user's deposits, because before making a payment to the specified address, the user will require the BitVM alliance to presign, ensuring that these deposits can only be legitimately claimed by the Operator.

In summary, the BitVM bridge has adopted a similar approach to channels and the Lightning Network, allowing users to "verify by yourself" and preventing the BitVM alliance from manipulating the deposit pool through presigning. The money in the deposit pool can only be used to reimburse the Operator. If the Operator falsely reports the amount advanced, anyone can publish a fraud proof and challenge it.

If the above solution can be implemented, the BitVM bridge will become one of the safest Bitcoin withdrawal bridges: this bridge does not have security issues, only availability/liquidity issues. When users try to deposit funds into BitVM, they may face scrutiny or lack of cooperation from the BitVM alliance, leading to the inability to deposit funds smoothly, but this is not related to security and falls under the category of availability/liquidity issues.

However, the implementation difficulty of the BitVM bridge is quite high, and it also cannot meet the needs of high-net-worth individuals who have specific requirements for fund transparency: these individuals may be involved in anti-money laundering issues and may not want to mix their funds with others, but the BitVM bridge will consolidate the funds of depositors, to some extent creating a pool of mixed funds.

To address the availability issues of the BitVM bridge and provide a clean and independent fund entry and exit channel for those with specific needs, the BitLayer team has additionally added a cross-chain bridge solution called OP-DLC. In addition to the optimistic bridge of BitVM2, it adopts a DLC bridge similar to DLC.link, providing users with two entry and exit points for the BitVM bridge and OP-DLC bridge, thereby reducing reliance on the BitVM bridge and even the BitVM alliance.

DLC: Discreet Log Contracts

DLC (Discreet Log Contracts) is also known as Discreet Log Contracts, proposed by MIT's Digital Currency Initiative. This technology was originally used to implement a lightweight smart contract on Bitcoin, without the need to put the contract content on the chain. It can achieve privacy-protecting smart contract functionality on the Bitcoin chain through off-chain interactive communication and presigning methods. Below, we will explain the working principle of DLC through a sports betting example.

Suppose Alice and Bob want to bet on the outcome of a match between Real Madrid and Barcelona three days later, with each of them putting in 1 BTC. If Real Madrid wins, Alice can receive 1.5 BTC, and Bob can only get back 0.5 BTC, which means Alice gains 0.5 BTC, and Bob loses 0.5 BTC; if Barcelona wins, Alice can only get back 0.5 BTC, and Bob can take 1.5 BTC. If it's a draw, both of them will get back 1 BTC each.

If we want to make the above betting process trustless, we need to prevent either party from cheating. Using a simple 2/2 or 2/3 multi-signature is obviously not enough to achieve trustlessness. DLC provides its own solution to this point (which depends on a third-party oracle). Its entire workflow can be roughly divided into four parts.

Taking the example of Alice and Bob, first, both parties create a fund transaction off-chain, which locks each other's 1 BTC in a 2/2 multi-signature address. If this fund transaction takes effect, the 2 BTC in this multi-signature address will require authorization from both parties to be spent.

Of course, this fund transaction is not put on the chain for now, it only exists locally in the clients of Alice and Bob, and they both know the consequences if this fund transaction takes effect. Currently, both parties are only engaging in theoretical deduction and then reaching a series of agreements based on the deduction results.

In the first stage of creating a DLC, it is certain 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 the possible events and results in the future: For example, after the match result is announced, there could be various possibilities such as Alice winning and Bob losing, Alice losing and Bob winning, a draw, and so on, leading to different allocation results of the 2/2 multi-signature address mentioned earlier.

Different results require different transaction instructions to be triggered. These "transactions instructions that may be put on the chain in the future" are called CET, which stands for Contract Execution Transaction. Alice and Bob need to deduce all possible CETs in advance and generate a transaction dataset containing all CETs.

For example, based on the various possible results of the bet between Alice and Bob mentioned earlier, Alice creates the following CETs:

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

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

CET3: Each party can receive 1 BTC.

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

The meaning of this transaction is to transfer the 1.5 BTC from the multi-signature address to a Taproot address triggered jointly by Alice and the oracle's output result, and transfer the remaining 0.5 BTC to Bob's address. At this point, the corresponding event is: Real Madrid wins, Alice wins 0.5 BTC, and Bob loses 0.5 BTC.

Of course, for Alice to spend this 1.5 BTC, she must obtain 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 content of CET2 and CET3, we can infer similarly, and it will not be elaborated here.

It is important to note that CET is essentially a pending transaction waiting to take effect on the chain. What would happen if Alice were to broadcast CET1 in advance, or if she were to put CET1 on the chain in the event of "Barcelona wins," when it should only be triggered after "Real Madrid wins"?

As mentioned in the previous diagram, when CET1 is put on the chain, the 2 BTC locked in the original multi-signature address will be transferred, with 0.5 BTC going to Bob and 1.5 BTC going 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 following diagram.

At the same time, this Taproot address is subject to a time lock restriction. If Alice cannot successfully withdraw the 1.5 BTC within the time lock period, Bob has the right to take the money directly.

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

For Alice, regardless of whether she ultimately wins or loses, the most advantageous approach is to put the correct CET on the chain. Putting the incorrect CET on the chain will result in greater losses for her.

In fact, when constructing the aforementioned CET, improvements have been made to the Taproot's schnorr signature, which can be understood as using the public key of the oracle + the event result to construct independent addresses for different results. Later, when the oracle publishes the signature corresponding to a certain result, the BTC locked in the address corresponding to that result can be spent.

Of course, there is an additional possibility here. If Alice knows she has lost, she might simply not put the CET1 she constructed on the chain. How would this be handled? This is easily resolved, because Bob can construct a custom CET for the "Alice loses, Bob wins" scenario, which achieves the same effect as the CET constructed by Alice, with only minor differences in the specific details, but the result is the same.

The above describes the most critical process of constructing CET. In the third step of DLC, Alice and Bob communicate with each other, check the CET transactions constructed by the other party, add their own signatures to the CET, and after confirming that everything is correct, they can trust each other. They each contribute 1 BTC and lock it into the 2/2 multi-signature address mentioned earlier, and then wait for a CET to be put on the chain, triggering the subsequent process.

Finally, when the oracle publishes the result and obtains the signature for the result from the oracle, either party can put the correct CET on the chain, causing the 2 BTC locked in the multi-signature address to be reallocated. If the losing party puts the incorrect CET on the chain first, they will lose all their money. If they put the correct CET on the chain, the losing party can still recover 0.5 BTC.

Some may ask, how is DLC different from a regular 2/3 multi-signature? Firstly, under a 2/3 multi-signature, any two parties can conspire to steal all the assets, while DLC restricts all possible scenarios between the opposing parties by pre-constructing a set of CETs. Even if the oracle participates in the conspiracy, the resulting losses are often limited.

Secondly, in a multi-signature, each party needs to sign specific pending transactions, while in DLC's setting, the oracle only needs to sign the result of a specific event, without needing to know the content of the CET/pending transactions, or even the existence of Alice and Bob, just like a regular oracle interacting with users.

We can consider that DLC essentially transforms trust in the participating parties of a multi-signature into trust in the oracle. As long as the oracle does not engage in malicious behavior, the protocol design of DLC can be trusted enough. In theory, DLC can use a more mature and complete third-party oracle to avoid malicious behavior. DLC.link and BitLayer utilize this feature of DLC, shifting the trust issue of the bridge to a third-party oracle.

In addition, BitLayer's DLC bridge also supports self-built oracle nodes, adding a layer of fraud proof. When a self-built oracle puts an invalid CET on the chain, anyone is allowed to challenge it. The principles of its OP-DLC bridge will be briefly described below.

OP-DLC Bridge: DLC Channel + Fraud Proof

We will explain the operation principle of the OP-DLC bridge from the entire process of deposit and withdrawal. Suppose Alice is depositing 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 in the following diagram:

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

If BitVM alliance members are willing to cooperate with Alice, both parties can generate the formal Fund deposit transaction (not yet on the chain) and all CET scenarios for withdrawals through off-chain communication. After the CET generation and verification are completed, both parties can submit the Fund transaction to the chain.

In the Witness/signature data of the Fund transaction, Alice will specify her receiving address in Layer2. After the Fund transaction is on the chain, Alice can submit the above fund transaction data to the bridge contract on Layer2, proving that she has completed the deposit action on the Bitcoin chain and is eligible to have the bridge contract on L2 release tokens to the specified receiving address.

After the Fund transaction is triggered, the deposit is actually still locked in the Taproot multi-signature address jointly controlled by Alice and BitVM alliance members. However, it is important to note that this multi-signature address can only be unlocked by CET to release the BTC locked in the address, and the BitVM alliance cannot transfer the money without cause.

Next, let's analyze the pre-built CET by Alice and the BitVM alliance. These CETs are used to meet potential scenarios for future withdrawals. For example, Alice may deposit 1 BTC, but when she first withdraws, she only takes out 0.3 BTC, and the remaining 0.7 BTC is to be controlled by the BitVM alliance's public fund pool. However, any further withdrawals can only be done through the BitVM bridge as mentioned earlier; or simply use the 0.7 BTC to initiate a new pre-fund deposit, as a new asset injected into the DLC bridge, repeating the previously mentioned fund transaction and CET construction process.

The above process is not difficult to understand. It essentially allows the depositor Alice and the BitVM alliance to act as opponents to each other, creating CET for different withdrawal amounts, and then allows the oracle to read the withdrawal declaration initiated by Alice in Layer2, determining which CET (how much money to withdraw) Alice wants to trigger.

The risk here is that the oracle may conspire with the BitVM alliance. For example, Alice declares a withdrawal of 0.5 BTC, but the oracle forges the withdrawal declaration, ultimately causing an incorrect CET to be put on the chain, resulting in "Alice receives 0.1 BTC, and the BitVM alliance receives 0.9 BTC."

There are several solutions to this issue. Firstly, a more well-designed third-party oracle can be used to prevent such conspiracy behavior (at this point, it would be extremely difficult for the BitVM alliance to conspire with the oracle), or the oracle can be required to make a pledge. The oracle needs to regularly publish Commitments on the Bitcoin chain, declaring that it has honestly processed the withdrawal requests of the depositor. Anyone can challenge the Commitment through BitVM's fraud proof protocol, and if the challenge is successful, the malicious oracle will be slashed.

In the design of the OP-DLC bridge, users can always "participate first-hand" in their own assets, preventing the BitVM alliance from misappropriating the assets. This channel-like design scheme gives users more autonomy and does not require their funds to be mixed with others' funds, resembling a peer-to-peer deposit and withdrawal scheme.

Furthermore, considering that the BitVM solution will take some time to be implemented, compared to a simple multi-signature solution, the DLC bridge is a more reliable bridging processing model. This solution can also serve as one of the two major deposit and withdrawal gateways used in parallel with the BitVM bridge. If one gateway fails, users can use the other gateway, serving as a good fault-tolerant method.

Conclusion

BitLayer and Citrea's BitVM bridge solution is essentially a "advance payment-reimbursement" model, with dedicated Operator nodes to pay depositors, and Operators can regularly apply for reimbursement from the public deposit address. If the Operator submits false reimbursement requests, anyone can challenge and slash them.

The BitVM2 solution introduces pre-signing and combines the concept of channels, allowing users to limit the post-deposit processing flow before the formal deposit, preventing the official cross-chain bridge from misappropriating user deposits.

This bridge theoretically has no security issues, but it has liveness/availability issues and cannot meet specific user needs for fund independence and anti-money laundering (essentially a fund pool model). It also has a high implementation difficulty.

To address this, Bitlayer has added the OP-DLC bridge solution, which is similar to DLC.link, introducing fraud proof based on channels and DLC to prevent malicious behavior by the DLC bridge's oracle.

However, due to the high implementation difficulty of BitVM, the DLC bridge will be implemented first and serve as 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 more secure withdrawal verification solution than a multi-signature bridge at the current stage.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。