BitVM Bridge and OP-DLC (Part1) : Next Generation of Bitcoin Layer2 Bridges

This article provides an interpretation of future technological solutions from Bitlayer and citrea

Authors:

@Nickqiaoo & @faustliu1997

It’s highly recommended since it might be one of the most important reference on the BitVM bridge. Bitlayer has introduced a DLC bridge to address the shortcomings of the BitVM optimistic bridge.

Summary:

· Bitlayer and Citrea use the BitVM2 solution, incorporating pre-signatures and channel concepts. Before depositing, users set restrictions on the post-deposit process, preventing the cross-chain bridge officials from misusing the funds.

· BitVM2 operates on a “pay-and-reimburse” model. Dedicated Operator nodes pay withdrawal users and periodically request reimbursements from the public deposit address. False reimbursement claims of operators can be challenged and slashed.

· Theoretically, BitVM2 has no security issues but faces liveness/availability problems and cannot meet specific users’ needs for fund independence and anti-money laundering (as it essentially remains a pooled model).

· Bitlayer introduced a bridge solution called OP-DLC. Similar to http://DLC.link, its security relies on oracles. However, Bitlayer additionally incorporates fraud proofs to prevent oracle misbehavior.

· Since it’s really challenging to implement BitVM and fraud proofs, the DLC bridge will be the temperate alternative.

· By addressing the trust risks of oracles and integrating more reliable and mature third-party oracles, it’s safer to use DLC bridge as a verification solution of withdrawal than multi-signature bridges at the current stage.

Main Text

Recently, Monanaut who is founder of Mempool publicly noted that if a Bitcoin Layer2 solely uses a multi-signature withdrawal bridge, it cannot allow users to withdraw assets in a trustless manner. Such a project is not a true Layer2.

Interestingly, Vitalik previously pointed out that Layer2 should provide at least more security than systems solely relying on multi-signature.

Currently, due to the limitations of Bitcoin Script, most withdrawal bridges are normal custodians/multi-signature bridges. These bridges designate a few witness off-chain to monitor if anyone deposits funds into the cross-chain bridge address.

The security model of such cross-chain bridges is essentially the same as that of multi-signature wallets. It follows a trust model based on multi-signature settings such as M/N, but ultimately relies on the honesty majority assumption.

In contrast, “Optimistic Bridges” based on fraud-proof protocols and “ZK Bridges” based on zero-knowledge proofs are much more secure.

For example, a ZK Bridge sets up a dedicated verifier contract on the target chain to directly verify withdrawal proofs on-chain, eliminating the reliance on off-chain custodians.

“Optimistic Bridges” introduce fraud proofs to challenge cross-chain messages, similar to the concept used in Optimistic Rollups.

To summarize, the trust assumption for M/N multi-signature bridges is (N — (M-1)) / N. Assume that there are at most (M-1) malicious actors, meaning at least (N — (M-1)) must be honest.

For ZK Bridges, the trust assumption is negligible. For Optimistic Bridges based on fraud proofs, the trust assumption is 1/N. Out of N custodians, 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, only ZK Bridges for Bitcoin deposits to Layer2 can be implemented. For withdrawals from Layer2 to the Bitcoin chain, only multi-signature bridges, optimistic bridges, or channel-like models are possible (the OP-DLC bridge discussed below is more like a channel).

To implement optimistic bridges on the Bitcoin chain, fraud proofs need to be introduced. BitVM creates favorable conditions for the implementation of this technology.

In our previous article “Simplified Explanation of BitVM: How to Verify Fraud Proofs on the BTC Chain,” we discussed how fraud proofs essentially break down complex off-chain computation tasks into numerous simple steps, then select one step to verify directly on-chain.

(As mentioned in the BitVM2 documentation, Lamport signatures will be used to break down a computation task into numerous intermediate steps, allowing anyone to challenge a specific intermediate step.)

Analysis of the BitVM Bridge Principles by Bitlayer and Citrea

Using the publicly disclosed BitVM bridge solution from Bitlayer and Citrea as our material, let’s elucidate the operational flow of the BitVM bridge.

First, when a user withdraws through the BitVM bridge, they must utilize the Bridge contract on Layer2 to generate a withdrawal declaration. This declaration specifies the following parameters:

The amount of mapped BTC that the user intends to destroy on L2 (e.g., 1 BTC).

The cross-chain transaction fee that the user intends to pay (assuming it’s 0.01 BTC).

The receiving address on L1 for the user (L1_receipt).

The amount the user intends to receive (i.e., 1–0.01 = 0.99 BTC).

Subsequently, the aforementioned withdrawal declaration will be included in a block on Layer2. The Relayer nodes of the BitVM bridge will synchronize Layer2 blocks, monitor for included withdrawal statements, and forward them to the Operator node, which will then process the payment for the withdrawing user.

The Operator pays the money on the BitVM bridge’s behalf and then apply for compensation from the BitVM bridge’s fund pool.

When the Operator applies for reimbursement, they need to provide proof of their payment on the Bitcoin chain (i.e., proof that they made the payment to the user’s specified address on L1, by extracting specific transfer records included in the Bitcoin block).

The Operator also needs to provide the withdrawal declaration generated by the user on L2 (using a Merkle Proof to prove that the withdrawal declaration originates from an L2 block and not fabricated by the Operator).

Subsequently, the Operator needs to prove the following things:

• The funds paid by the Operator to the user on behalf of the BitVM bridge match the amount requested by the user in the declaration.
• The reimbursement amount requested by the Operator does not exceed the amount of mapped BTC destroyed by the user on Layer2.
• The Operator has indeed processed all withdrawal statements from L2 to L1 within a certain period, and each withdrawal declaration matches a withdrawal transfer record on the Bitcoin chain.

This essentially serves as punishment for the Operator for falsely reporting the amount of the advance payment or refusing to process the withdrawal declaration (which can address the anti-censorship issue of withdrawal bridges).

The Operator needs to compare and verify key fields of the advance payment proof and withdrawal declaration off-chain, proving that the BTC amounts involved in both are equal.

If the withdrawal bridge Operator falsifies the payment proof on L1, which does not match the Withdrawal Statement issued by the L2 withdrawer, it indicates an error in the ZKP (Zero-Knowledge Proof) that proves Payment Proof = Withdrawal Statement.

Once this ZKP is published, a Challenger can identify which step is incorrect and challenge it using BitVM2’s fraud-proof protocol.

Bitlayer, Citrea, ZKBase, and others have adopted BitVM2, the latest version of BitVM. This approach involves transforming off-chain computational tasks into Zero-Knowledge (ZK) tasks, generating ZK Proofs for the off-chain computations, verifying these proofs, and then adapting the verification process into a format compatible with BitVM for subsequent challenges.

Using Lamport signatures and pre-signatures, multiple rounds of interactive challenges can be optimized into single-round challenges, significantly reducing the difficulty of challenges.

BitVM challenges need something called “commitment”.

Let’s explain what “commitment” means. Generally, when someone publishes a “commitment” on the Bitcoin chain, they assert that certain data stored off-chain or off-chain computational tasks are accurate, and the related declaration published on-chain represents the “commitment.”

Commitment can be roughly understood as the hash of a large batch of off-chain data.

The size of a commitment is often compressed to be very small, but it can be bound to a large amount of off-chain data using methods like Merkle Trees. These associated off-chain data do not need to be stored on-chain.

In the BitVM2 scheme, if someone believes that the commitment published by the withdrawal bridge Operator on-chain is problematic, linking to an invalid ZKP verification process, they can initiate a permissionless challenge.

Since the Operator pays the withdrawal users on behalf of the BitVM fund pool and then applies for reimbursement from the fund pool, they need to publish a Commitment when applying for reimbursement.

This Commitment proves that the money they transferred to the withdrawal users on L1 equals the amount declared by the withdrawal users on L2.

If this Commitment remains unchallenged after the fraud-proof window, the Operator can then withdraw the reimbursement amount they need.

We’ll explain how the public fund pool of the BitVM bridge is maintained, as this is the most crucial aspect of a cross-chain bridge.

The funds available to pay withdrawal users through the bridge come from deposits made by depositors or contributions from other LPs. The money advanced by the Operator ultimately needs to be withdrawn from the public fund pool. From a purely financial perspective, the total amount deposited into the BitVM bridge should equal the total amount withdrawn.

How to safeguard the deposited funds is a critical issue.

Bitlayer and Citrea’s BitVM bridge adopts a concept similar to channels. Before depositing, users communicate with members of the BitVM bridge federation and let them sign in advance, achieving the following effects:

After the user deposits, the money is locked in a Taproot address, accessible only by the Operator.

The Operator advances withdrawal funds for the user and applies for reimbursement from the above address. They can withdraw a certain amount of money only after the challenge period ends.

In the BitVM bridge, there is a BitVM Federation composed of N members who coordinate the deposits made by users.

However, these N members cannot misappropriate users’ deposits privately. Before users make payments to designated addresses, they request the BitVM Federation to provide pre-signatures, ensuring that these deposits can only be legally claimed by the Operator.

In a nutshell, the BitVM bridge adopts a channel-like approach, allowing users to “verify by yourself” by using pre-signatures to prevent the BitVM bridge from manipulating the deposit pool without authorization.

If this approach is implemented, the BitVM bridge will become one of the most secure Bitcoin withdrawal bridges: it has no security issues but may face availability/liveness issues.

Users may face rejection by the BitVM Federation when depositing, but this is unrelated to security and falls under the category of availability/liveness issues.

However, BitVM bridge is difficult to implement, and it fails to meet the transparency requirements for funds. In order to address the liveness issues of the BitVM bridge and provide a clean and independent channel for individuals with specific needs, the BitLayer team has additionally introduced a cross-chain bridge solution called OP-DLC.

This solution offers users two gateways, namely the BitVM bridge and the OP-DLC bridge, reducing reliance on the BitVM bridge.

In our next article, we will provide a detailed introduction to OP-DLC.