Showcasing Bitlayer's BitVM Bridge

Bitlayer is on the cusp of a significant milestone as it prepares to launch the BitVM Bridge on mainnet. This article highlights the latest progress by showcasing two critical demonstration cases conducted on bitvmnet, a dedicated testnet for BitVM-powered applications.

Background

The Evolution of Bitlayer’s BitVM Bridge

The BitVM Bridge represents a pivotal development in the broader BitVM ecosystem. Rooted in the groundbreaking work of Robin Linus, the BitVM project has established itself as a cornerstone of trust-minimized cross-chain solutions. Bitlayer’s implementation of the BitVM Bridge directly inherits essential low-level components from this project, which has been collaboratively developed by the BitVM Alliance and the wider BitVM community.

At its core, the Bitlayer BitVM Bridge protocol is an optimized adaptation of the bridge protocol outlined in the BitVM2 paper. These optimizations focus on enhancing efficiency, scalability, and security, making the protocol particularly suitable for high-stakes cross-chain transactions.

How the BitVM Bridge Operates

To provide a simplified overview, the BitVM Bridge enables users to lock Bitcoin on the Bitcoin network and mint equivalent assets, such as Peg-BTC, on Ethereum. The process involves the following key steps:

1. Peg-in: A user locks funds in the BitVM smart contract on Bitcoin, which triggers the minting of an equivalent amount of Peg-BTC on Ethereum.
2. Peg-out: A user initiates a peg-out request to redeem their locked Bitcoin by burning Peg-BTC on Ethereum.
3. Broker’s Role: A broker fulfills the peg-out request by fronting liquidity—transferring Bitcoin to the peg-out user on the Bitcoin network.
4. Reclaim Process: The broker reclaims the fronted funds from the BitVM smart contract through an optimistic reclaim process.
5. Challenge Mechanism: If the reclaim request is fraudulent, watchers can challenge it. Valid challenges result in the broker losing their collateral as a penalty.
6. Finalization: If no valid challenge arises within a predefined period, the broker successfully retrieves the fronted funds.

This workflow ensures a trust-minimized environment where brokers and watchers play crucial roles in maintaining the integrity of the system. For a deeper dive into the mechanics, refer to our blog article: Introducing BitVM Bridge.

Demonstrations

To validate the robustness of the BitVM Bridge, we conducted two demonstrations on bitvmnet, a testnet specifically designed for BitVM-powered applications. These cases highlight the protocol’s capacity to handle both fraudulent and legitimate reclaim scenarios, showcasing its resilience against malicious actors while ensuring fair and transparent outcomes for honest participants.

1. Case 1: INVALID-RECLAIM-CHALLENGED-REJECTED: A broker initiates an invalid reclaim request without fronting any peg-out liquidity, attempting to steal funds from the BitVM smart contract. A vigilant watcher successfully challenges the reclaim request, causing the broker not only to fail in their attempt but also to lose their collateral as a penalty.
2. Case 2: VALID-RECLAIM-SURVIVES-CHALLENGE: A broker initiates a valid reclaim request after fulfilling a peg-out operation. Despite a malicious watcher attempting to challenge the process, the broker successfully retrieves both the reclaim amount and their collateral through the protocol’s unhappy path.

The subsequent sections will include a list of transactions for each case, which readers can view on the bitvmnet mempool explorer.

Case 1: INVALID-RECLAIM-CHALLENGED-REJECTED

This case demonstrates the protocol’s ability to effectively thwart fraudulent reclaim attempts by brokers. The scenario unfolds as follows:

1. Peg-in: A user deposits funds into the BitVM smart contract on Bitcoin. (Pegin TX (Bitcoin))
2. Minting: An equivalent amount of Peg-BTC is minted on Ethereum. (Mint TX (Ethereum))
3. Fraudulent Reclaim: A broker, without fulfilling any peg-out request, attempts to steal funds by initiating an invalid reclaim request. (Kickoff TX)
4. Challenge: A vigilant watcher detects the fraudulent behavior and submits a challenge transaction, forcing the broker onto the unhappy path. (Challenge TX)
5. Verifier Chunk Assertion: The broker is required to reveal all shared verifier chunk values. Since the reclaim is invalid, one of the chunks contains incorrect execution data. (PreAssert TX) (Assert TX)
6. Disprove: The watcher analyzes the verifier chunks off-chain, identifies the incorrect chunk, and replays it on-chain to disprove the broker’s claim. (Disprove TX)

Outcome: The broker’s reclaim request is rejected, and they lose their collateral as a penalty for attempting fraud. This case underscores the effectiveness of the protocol’s challenge mechanism in maintaining system integrity.

Case 2: VALID-RECLAIM-SURVIVES-CHALLENGE

This case highlights the protocol’s ability to protect honest brokers from malicious and baseless challenges. The steps are as follows:

1. Peg-in: A user deposits funds into the BitVM smart contract on Bitcoin. In this case, it is the same tx as Case 1 (Pegin TX (Bitcoin))
2. Minting: An equivalent amount of Peg-BTC is minted on Ethereum. In this case, it is also the same tx as Case 1 (Mint TX (Ethereum))
3. Burn: A user burns Peg-BTC on Ethereum to initiate a peg-out request. (Burn TX (Ethereum))
4. Peg-out: The broker fulfills the peg-out request using their own liquidity, transferring Bitcoin to the peg-out user. (Pegout TX)
5. Reclaim Process: The broker initiates the reclaim process by submitting a kickoff transaction. (Kickoff TX)
6. Challenge: A vigilant watcher detects the fraudulent behavior and submits a Challenge transaction, forcing the broker onto the unhappy path. (Challenge TX)
7. Verifier Chunk Assertion: The broker reveals all shared verifier chunk values. (PreAssert TX),(Assert TX)
8. Finalization: Since the broker’s values are correct, malicious watchers are unable to construct a valid disproof transaction. After the predefined timeout, the broker reclaims both the fronted funds and their collateral. (UnhappyTake TX)

Outcome: The broker successfully retrieves their funds, demonstrating the protocol’s ability to protect honest participants against baseless challenges while maintaining the integrity of the reclaim process.

Transaction Graph Specification

This section offers comprehensive details regarding every transaction.

Pegin

A peg-in user deposits v BTC on the Bitcoin into a BitVM bridge instance through a Pegin transaction. By invoking the Mint function on Ethereum’s bridge contract, they obtain v Peg-BTC in exchange.

Pegout

To withdraw the v Peg-BTC back to Bitcoin, the peg-out user performs a Burn transaction on Ethereum, rendering the v Peg-BTC unspendable. At this point, one of the m brokers temporarily provides v Peg-BTC from their own funds, allowing the peg-out user to receive BTC in return.

Kickoff

The broker starts a reclaim process to retrieve the fronted amount of v BTC from the BitVM bridge instance by broadcasting the Kickoff transaction. If any watcher identifies this reclaim as unexpected or invalid, they can immediately react by broadcasting a Challenge transaction.

Challenge

The watcher initiates a Challenge transaction to stop the broker from reclaiming the v BTC. Consequently, the broker must disclose all the share values produced during the execution of the chunked ZK verifier.

PreAssert

PreAssert transaction sets up all UTXOs that will be utilized to disclose all share values.

Assert

The transaction is required to utilize all UTXOs generated by the PreAssert transaction and reveal all shared values. Subsequently, challengers gain access to the ZK proof data and shared values, execute the chunked ZK verifier to establish a local view, and pinpoint the initial faulty chunk if the local view contradicts the broker’s claim.

AssertTimeout

If the broker fails to submit a PreAssert or Assert transaction within the specified period, the watcher will issue an AssertTimeout transaction to penalize the broker for inactivity.

HappyTake

If the broker acts honestly and no one disputes the reclaim request, the broker will ultimately get the funds returned via a HappyTake Transaction after a waiting period.

UnhappyTake

If the broker acts honestly, once the Assert transaction is issued by the broker, the watcher cannot stop the broker from reclaiming the funds using a valid Disprove transaction. Eventually, the broker will retrieve the funds through an UnhappyTake Transaction.

Disprove

If a share value revealed by the broker through an Assert transaction is deemed incorrect, a watcher can submit a reversed version of the erroneous chunk using a Disprove transaction. If the Disprove transaction is successful, the reclaim is denied, and the broker’s collateral is penalized by slashing.