Summary:· ZK Bridges deploy smart contracts on Chain A to directly receive and verify block headers and corresponding zero-knowledge proofs from Chain B, confirming the validity of cross-chain messages. This is the most secure bridge scheme.

• Optimistic/OP Bridges use fraud proofs to challenge invalid cross-chain messages on-chain. The presence of just one reliable challenger can ensure the safety of the cross-chain bridge’s funds pool.
• Due to technical limitations, the Bitcoin mainnet cannot directly deploy ZK bridges but can achieve optimistic bridges through BitVM and fraud proofs. Teams like Bitlayer and Citrea have adopted the BitVM bridge scheme, introducing pre-signing and incorporating channel concepts, allowing users to predefine the handling process after deposit execution, preventing the cross-chain bridge from misappropriating user deposits.
• The BitVM bridge essentially operates on a “prepay-reimburse” model, with specific Operator nodes providing funds to withdrawal users. Operators can periodically apply for reimbursement from a public deposit address. If an Operator submits a false reimbursement application, it can be challenged and slashed by anyone.
• While theoretically secure, the BitVM bridge has issues with liveness/usability and does not meet specific users’ needs for fund independence and anti-money laundering (as it essentially uses a funds pool model). Bitlayer addresses this with an OP-DLC bridge solution. This solution, similar to DLC.link, introduces fraud proofs based on channels and DLCs to prevent oracle malfeasance.
• Given the difficulty of implementing BitVM and fraud proofs, DLC bridges will be deployed first as a temporary substitute. As long as the trust risks of oracles are resolved and more reliable and mature third-party oracles are integrated, DLC bridges can become a safer withdrawal verification scheme than multi-signature bridges in the current stage.

Introduction:Since the inscription craze last year, the Bitcoin ecosystem has entered a period of rapid growth.In just half a year, the number of projects under the banner of BTC Layer2 has reached nearly 100.It has simply become a new continent full of chaos, where opportunities and scams coexist. 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 the Bitcoin native ecosystem. Coupled with the lack of authoritative voices, the Bitcoin ecosystem is simply like that of the 19th century. Like the United States, it has become a new world that attracts forces from all walks of life. While this brings prosperity and vitality to the entire Web3 narrative, it also introduces huge risks.

Many projects have started to hype without even releasing technical solutions, using the name of native layer 2, claiming that they can completely inherit the security of the Bitcoin main network; some even use propaganda techniques to create concepts. , inventing a bunch of weird nouns and terms as lines to promote one’s own superiority. Although bragging is already the current status of the Bitcoin ecosystem, there are still many top KOLs who have made objective calls.

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

It can be said that Monanaut and Vitalik bluntly pointed out the technical problems of Bitcoin Layer 2:Many L2 withdrawal bridges are essentially multi-signature bridges.Either several well-known institutions each hold a key, or a decentralized signature based on POS is used, but in any case, its security model is based on the majority honesty assumption, that is, it defaults to the majority of multi-signature participants not colluding to do evil.

This kind of 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 have various problems sooner or later. Only trust is minimized or asset custody tends to be completely trustless. Only in this way can it withstand the test of time and hackers. But the current situation of the Bitcoin ecosystem is thatMany project parties have not even released a technical roadmap for the withdrawal bridge. There is no established design idea for how the bridge should be trusted or minimized.

But this is not all of the Bitcoin ecosystem. There are still some project managers who have expressed their opinions on the optimization ideas of the withdrawal bridge. in the text,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 cross-chain bridges.This is crucial for the majority of Bitcoin ecosystem participants.

Optimistic Bridge: A bridge verification scheme based on fraud proof

In fact, the essence of the cross-chain bridge is very simple, which is to prove to chain B that a certain event did occur on chain A. For example, if you cross assets from ETH to Polygon, you need the cross-chain bridge to help you 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-signature.They will designate several witnesses under the chain. The witnesses will run the nodes of each public chain and monitor whether anyone has deposited funds into the cross-chain bridge payment address.

The security model of this type of cross-chain bridge is basically the same as that of multi-signature wallets.The 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 means that most notaries are by default not malicious and the fault tolerance rate is relatively limited. Many large-scale cross-chain bridge theft cases that have occurred before basically all occurred on this type of multi-signature bridges, either because of theft or by hackers.

In contrast,The “Optimistic Bridge” based on the fraud proof protocol and the “ZK Bridge” based on ZK are much safer.Taking ZK Bridge as an example, it will set up a dedicated validator contract on the target chain to directly verify the withdrawal certificate on the chain, eliminating the need for dependence on off-chain witnesses.

For example, a ZK bridge spanning ETH and Polygon will deploy a verifier contract on Polygon, let’s call it Verifier for now. The Relayer node of the ZK Bridge will forward the latest Ethereum block header and the ZK Proof that proves the validity to the Verifier, who will verify it.This is equivalent to having the Verifier contract synchronize on the Polygon chain and verify the latest Ethereum block header.The merkle root recorded in the block header is related to the transaction set contained in the block and can be used to verify whether a certain transaction is included in the block.

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

Ethereum block No. 101 contains 10 cross-chain transactions from ETH to Polygon. Of course, the ZK bridge can convert Merkle Proof into ZK and directly submit ZK Proof to the Verifier contract. During this entire 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. There is no need to introduce too many trust assumptions like traditional multi-signature bridges.

and”Optimistic Bridge” is slightly different. Some optimistic bridges retain settings similar to witnesses, but introduce fraud proofs and challenge windows., after the witness generates a multi-signature for the cross-chain message, although it will be submitted to the target chain, its validity will not be recognized immediately. It must pass a window period and no one questions it before it can be judged as valid. This is actually somewhat similar to the idea of Optimistic Rollup. Of course, Optimistic Bridge has other product models, but in the final analysis, security is guaranteed by the fraud proof protocol.

The trust assumption of M/N multi-signature bridge is N-(M-1)/N. You have to assume that the number of malicious persons in the network is at most M-1, and the number of honest persons is at least N-(M-1). The trust assumption of the ZK bridge is negligible, 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 invalid cross-chain messages submitted to the target chain to ensure the security of the bridge.

at present,Due to technical limitations, only the ZK bridge in the direction of depositing Bitcoin to Layer 2 can be implemented. If the direction is reversed and withdrawals are made from Layer 2 to the Bitcoin chain, only multi-signature bridges or optimistic bridges, or channels-like models are supported. (The OP-DLC bridge to be described below is more like a channel). To implement an optimistic bridge on the Bitcoin chain, fraud proof must be introduced, and bitVM has created good conditions for the implementation of this technology.

in previous articles“A Minimalist Interpretation of BitVM: How to Verify Fraud Proofs on the BTC Chain”, we have briefly introduced,The essence of BitVM’s fraud proof is to break down the complex calculation tasks performed off-chain into a large number of simple steps, and then select a certain step to be directly verified on the Bitcoin chain.. This idea is similar to Ethereum optimistic rollups such as Arbitrum and Optimism.

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

Of course, the above statement is still relatively obscure, but I believe that most people have already understood the meaning of fraud certificate. In today’s article, due to overall space limitations, we do not intend to explain the technical implementation details of BitVM and the fraud proof protocol, because this involves a series of complex interaction processes.

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

(Schematic diagram of Bitlayer’s bridging solution)

A brief analysis of the BitVM bridge principle between Bitlayer and Citrea

below, we use the BitVM bridge solution 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-mentioned project party clearly explained the product design ideas of BitVM Withdrawal Bridge (currently in the theoretical stage). First, when a user withdraws money through the BitVM bridge, he or she needs to use the Bridge contract on Layer 2 to generate a withdrawal statement.The following key parameters are specified in the withdrawal statement:

The number of mapped BTC that the withdrawr needs to destroy in L2 (such as 1 BTC);

The cross-chain handling fee that the withdrawer intends to pay (assumed to be 0.01 BTC);

The withdrawal address of the withdrawer in L1: L1_receipt;

The withdrawal amount of the withdrawer (i.e. 1 — 0.01 = 0.99BTC)

after,The above withdrawal statement will be included in the Layer2 block. BitVM bridgeThe Relayer node will synchronize the Layer2 block, monitor the withdrawal statement contained in it, and forward it to the Operator node, which will pay the withdrawal user.

What needs to be noted here is thatThe Operator first pays users on the Bitcoin chain out of his own pocket, that is, “advances” funds for BitVM Bridge, and then applies for compensation from the BitVM Bridge fund pool.

When applying for reimbursement, the Operator needs to provide proof of advance payment on the Bitcoin chain (that is, to prove that it has transferred money to the address specified by the withdrawal user on L1, and must 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 in L2 (through Merkle Proof, it is proved that the withdrawal statement issued comes from the L2 block and is not fabricated out of thin air). after,Operator needs to prove the following:

The funds advanced by the Operator to the drawee on behalf of the BitVM Bridge are equal to the amount requested by the drawee in the statement;

When the Operator applies for reimbursement, the reimbursement amount shall not be more than the amount of mapped BTC destroyed by the withdrawr in Layer 2;

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 advance amount or refusing to process the withdrawal statement (which can solve the censorship-resistant problem of the withdrawal bridge). The Operator needs to compare and verify the key fields of the advance payment certificate and withdrawal statement off-chain to prove that the amount of BTC involved in both is equal.

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

In this way, it proves that the ZKP of 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.

What needs to be emphasized is thatBitlayer, Citrea, BOB, ZKBase, etc. have all adopted the latest BitVM2 route, which is the new version of the BitVM solution. This solution will ZKize the off-chain computing tasks, that is, generate ZK Proof for the off-chain calculation process, then verify the Proof, and then convert the process of verifying ZKP into Adapted to the form of BitVM to facilitate subsequent challenges.

at the same time,By using Lamport and pre-signing, the multi-round interactive challenge of the original BitVM can be optimized into a single-round non-interactive challenge, greatly reducing the difficulty of the challenge.。

BitVM’s challenge process requires the use of something called “commitment”, that is, Commitment. Let’s explain what “commitment” is. Generally speaking, someone who publishes a “commitment” on the Bitcoin chain will claim that certain data stored off-chain/computation tasks occurring off-chain are accurate, and the relevant statement published on the chain is a “commitment” “.

We can approximately understand Commitment as a 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 these associated off-chain data do not need to be uploaded to the chain.

In the BitVM bridge solution of BitVM2 and Citrea and BitLayer,If someone thinks that there is a problem with the commitment issued by the Withdrawal Bridge Operator on the chain, and that the commitment is associated with an invalid ZKP verification process, he or she can initiate a challenge, and the challenge authority is Permissionless.. (The interaction process inside is relatively complicated and will not be explained here)

Since the Operator advances funds for the BitVM fund pool to pay the withdrawal, and then applies to the fund pool for reimbursement, when applying, the Operator must issue a Commitment to prove that the money it transfers to the withdrawal on L1 is equal to the withdrawal. The payer declares on L2 that he wants to receive the money. If the Commitment has passed the fraud proof window and has not been challenged, the Operator can withdraw the reimbursement amount it needs.

Here we want to explain how the public fund pool of the BitVM bridge is maintained, and this 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 drawee come from the assets contributed by depositors or other LPs, and the money advanced by the Operator will eventually be withdrawn from the public fund pool, so it depends solely on the funds. As a result of the transfer, the depositor’s Deposit amount absorbed by the BitVM bridge should be equal to the withdrawr’s Withdraw amount. So how to keep Deposit funds is a very important issue.

In most Bitcoin Layer 2 bridging solutions, public assets are often managed through multi-signature. User deposits are aggregated into a multi-signature account. When a withdrawal needs to be made, this multi-signature account is responsible for making the payment. There is obviously a huge trust risk in this solution.

Bitlayer and Citrea’s BitVM bridge adopts ideas similar to Lightning Network and channels.Before making a deposit, the user will first communicate with the BitVM Alliance and ask the latter to 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’s Operator.Moreover, the Operator can only claim the funds from the Taproot address of the above deposit by applying for reimbursement after advancing 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 (BitVM Federation) formed by N members, who schedule user deposits.However, these N members cannot misappropriate users’ deposits privately, because users will require the BitVM Alliance to pre-sign before transferring money to the designated address to ensure that these deposits can only be legally claimed by the Operator.

(BitVM2’s diagram of its optimistic bridge solution)

To summarize at a high level, BitVM Bridge adopts ideas similar to channels and lightning networks, allowing users to “verify by yourself” and preventing the BitVM Alliance from manipulating the deposit pool without authorization through pre-signing.The money in the deposit pool can only be used to reimburse the Operator. If an operator misrepresents the advance amount, anyone can issue proof of fraud and challenge it.

If the above solution can be implemented, the BitVM bridge will become one of the safest Bitcoin withdrawal bridges:There are no security issues with this bridge, only availability/liveness issues. When users try to deposit funds to BitVM, they may be censored or refused to cooperate by the BitVM Alliance, resulting in the inability to successfully deposit funds. However, this has nothing to do with security but is a liveness/availability issue.

However, the implementation of the BitVM bridge is relatively difficult.Moreover, it cannot meet the needs of some large investors who have relatively high requirements for fund transparency: these people may be involved in anti-money laundering issues and do not want to mix their own funds with other people’s funds, but the BitVM bridge will uniformly accept depositors’ money. , in a way, it’s a pool where a lot of money is mixed.

In order to solve the above-mentioned BitVM bridge activity problem and provide an independent and clean fund entry and exit channel 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.Provide users with two entrances and exits, the BitVM bridge and the OP-DLC bridge, to reduce dependence on the BitVM bridge and even the BitVM Alliance.

(DLC schematic diagram)

DLC: Cautious Log Contract

DLC (Discreet Log Contracts) is called discreet log contract. It was proposed by MIT’s Digital Currency Initiative. This technology was first used to implement a lightweight smart contract on Bitcoin. It does not require the content of the contract to be uploaded to the chain. Through methods such as off-chain interactive communication and pre-signing, privacy-protecting smart contract functions are implemented on the Bitcoin chain.Below we use a gambling case to illustrate the working principle of DLC.

Suppose Alice and Bob want to bet on the result of the match between Real Madrid and Barcelona to be held three days later, and each of them pays 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 there is a tie, both players will each get 1 BTC back.

If we want to make the above gambling process trustless, we must find ways 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 provides its own solution to this problem (relying on third-party oracles).The entire workflow can be roughly divided into four parts.

Taking the previous Alice and Bob as an example,First, both parties create a fund transaction off-chain, which can lock each other’s 1 BTC on the 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 is not uploaded to the chain yet, but remains local to the Alice and Bob clients off the chain. They all know what the consequences will be after this transaction takes effect.At present, the two sides are only conducting theoretical deductions and then reaching a series of agreements based on the results of the deductions.

In the first phase of DLC creation, what we can determine is that,Both parties will lock their 1 BTC into a multi-signature address in the future.

In the second step, both parties continue to deduce possible future events and outcomes:For example, when the results of the football match are announced, there may be multiple possibilities such as Alice winning and Bob losing, Alice losing and Bob winning, a draw, etc. This will lead to different distribution results of the Bitcoins in the aforementioned 2/2 multi-signature address.

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

For example,Based on the possible outcomes of the bet between Alice and Bob mentioned above, Alice creates 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 receive 1 BTC each.

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

The meaning of this transaction is to transfer 1.5 BTC in the multi-signature address to a Taproot address that is triggered by the output results of Alice and the oracle machine, and transfer the other 0.5 BTC to Bob’s address. The corresponding events at this time are: Real Madrid wins, Alice wins 0.5 BTC, and Bob loses 0.5 BTC.

certainly,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 away. As for the contents of CET2 and CET3, we can deduce them in the same way and will not go into details here.

It should be noted that CET is essentially a transaction that needs to be uploaded to the chain to take effect.What will happen if Alice broadcasts CET1 in advance, or in the case of “Barcelona wins”, still puts CET1 on the chain that can only be successfully triggered after “Real Madrid 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 away, 0.5 BTC will be transferred to Bob, and 1.5 BTC will be transferred to a Taproot address. The oracle machine outputs “ Only after Real Madrid wins” can Alice unlock the BTC locked in the Taproot address. Results as shown below.

at the same time,This Taproot address is subject to a 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 period expires, Bob can take away the 1.5 BTC. In addition to the 0.5 BTC transferred directly to Bob when CET1 was uploaded to the chain, all the money will eventually belong to Bob.

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

In fact, when the above-mentioned CET was constructed, Taproot’s schnorr signature was improved, which can be understood as using the public key of the oracle + event results to construct independent addresses for different results. After that, only when the oracle machine announces the signature corresponding to a certain result can the BTC locked on the address corresponding to the result be spent.

Of course, there is an additional possibility here. What if Alice knows that she has lost and simply does not put the CET1 she built on the chain? This is easy to solve becauseBob can build a custom CET for the issue of “Alice loses, Bob wins”. 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.

What is described above is the most critical CET construction process. The third step of DLC is for Alice and Bob to communicate, check the CET transaction constructed by the other party, and bring their own signature on the CET. After the check is correct, they can trust each other, and each invest 1 BTC, locking in the initial The mentioned 2/2 multi-signature addresses of Alice and Bob, and then wait for a certain CET to be uploaded to the chain to trigger the subsequent process.

Finally, after the oracle machine announces the results and obtains the oracle machine’s signature on the results, either party can put the correct CET on the chain and let the 2 BTC locked in the multi-signature address be redistributed. If the loser puts the wrong CET on the chain first, If you put the correct CET on the chain, you will lose all your money. If you put the correct CET on the chain, the loser can get back 0.5 BTC.

Someone may ask,How is DLC different from regular 2/3 multi-signature?First of all, if more than 2/3 is signed, any two parties can collude to steal all the assets, and the DLC allows the opponents to limit all scenarios by building a CET set in advance. Even if the oracle participates in the collusion, The damage caused is often limited.

Secondly, multi-signature requires all parties to sign for specific transactions to be uploaded to the chain, whileUnder the setting of DLC, the oracle only needs to sign the results of specific events. It does not need to know the content of CET/transactions to be uploaded to the chain. It does not even need to know that there are two people, Alice and Bob. It only needs to act like an ordinary oracle. Just interact with the user normally like a machine.

We can think thatThe essence of DLC is to transform trust in multi-signature participants into trust in oracles.As long as the oracle machine does not participate in evil deeds, it can be ensured that the DLC protocol design is trustworthy enough. Theoretically,DLC can use a relatively mature and complete third-party oracle to avoid doing evil.. DLC.link and BitLayer take advantage of this feature of DLC to transfer the trust issue of the bridge to the third-party oracle.

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

OP-DLC Bridge: DLC Channel + Fraud Proof

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

This is actuallyFirst transfer 1 BTC to the Taproot address jointly controlled by Alice and BitVM Alliance members, and then start a series of processes to create CET.If a member of the BitVM Bridge Alliance refuses 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 use off-chain communication to first generate a formal Fund deposit transaction (not on-chain yet), as well as all CET in the withdrawal scenario. 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 payment address in Layer2;After the Fund transaction is uploaded to the chain, Alice can submit the above fund transaction data to the bridge contract on Layer 2 to prove that she has completed the deposit action on the Bitcoin chain and is eligible for the L2 bridge contract to release Token to the designated payment address.

After the Fund transaction is triggered, the deposit is actually locked in the Taproot multi-signature address jointly controlled by Alice and BitVM alliance members.However, it should be noted that the multi-signature can only unlock the BTC locked by the address through CET, and the BitVM Alliance cannot transfer the money away for no reason.

Next, let’s analyze the CET built in advance by Alice and the BitVM Alliance. These CET are used to meet potential scenarios for future withdrawals. For example, Alice may have deposited 1 BTC, but she only withdrew 0.3 BTC during her first withdrawal, and the remaining 0.7 BTC was handed over to the public fund pool of the BitVM Alliance. To control, but if you want to withdraw money, you can only go through the BitVM bridge mentioned above;

Or simply use these 0.7 BTC to initiate a new pre-fund deposit. As a newly added asset to the DLC bridge, you can repeat the fund transaction and CET construction process mentioned above.

The above process is not difficult to understand. In fact, the depositor Alice and the bitVM alliance act as counterparties to each other, create CET for withdrawal events of different amounts, and then let the oracle read the withdrawal statement initiated by Alice in Layer 2 to determine which transaction Alice wants to trigger. One CET (how much money you want to withdraw).

The risk here is that the oracle machine may collude with the BitVM Alliance. For example, Alice declares that she wants to withdraw 0.5 BTC, but the oracle machine forges the withdrawal statement, which ultimately leads to “Alice withdraws 0.1 BTC and the BitVM Alliance receives 0.9 BTC.” Error CET on the chain.

There are several solutions to this problem. The first is to use a third-party oracle with a relatively complete design.Prevent such collusion (it is extremely difficult for the BitVM Alliance to collude with oracles at this time),Or let the oracle perform staking,The oracle needs to publish Commitment on the Bitcoin chain regularly, stating that it has handled the withdrawal request of the withdrawr honestly.Anyone can challenge the Commitment through BitVM’s fraud proof protocol. If the challenge is successful, the evil oracle will be slashed.

Under the design of the OP-DLC bridge, users can always “take part” in their own assets to prevent assets from being misappropriated by the BitVM Alliance. Moreover, this channel-like design brings more autonomy to users, and also There is no need to mix your own funds with other people’s funds. It is more like a P2P peer-to-peer deposit and withdrawal solution.

also,Considering that it will take some time for the BitVM solution to be implemented, before it is implemented, the DLC bridge will be a more reliable bridging processing model compared to the simple multi-signature solution.This solution can also be used as two major deposit and withdrawal entrances used in parallel with the BitVM bridge. If one of them fails, the user can use the other entrance, which is also a good fault tolerance method.

Summarize

BitLayer and Citrea’s BitVM bridge solution is essentially an “advance payment-reimbursement” model, there is a dedicated Operator node to transfer money to withdrawal users, and the Operator can regularly apply for reimbursement to the public deposit address. If an operator makes a false reimbursement application, it can be challenged and slashed by anyone.

BitVM2’s solution introduces pre-signing and combines the idea of ​​​​a channel to allow users to limit the post-deposit processing process before making a formal deposit, and does not give cross-chain bridge officials the opportunity to misappropriate user deposits.

There are no security issues with this bridge in theory, but there are liveness/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), 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 and introduces fraud proof on the basis of channels and DLC to prevent the oracle machine of the DLC bridge from doing evil.

butSince BitVM is too difficult to implement, the DLC bridge will be implemented first and become a temporary replacement., as long as the trust risk of the oracle machine is solved and a more reliable and mature third-party oracle machine is integrated,DLC bridge can become a more secure withdrawal verification solution than multi-signature bridge at this stage.

Disclaimer：

1. This article is reprinted from [极客web3]. All copyrights belong to the original author [Faust & Nickqiao]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.