Bitcoin <> BVM bridge

Summary

• Bridge BTC to SHARD_BVM trustlessly

• Any Bitcoin L2 powered by BVM network can bridge BTC from SHARD_BVM via a native ZK bridge

• Stake BVM to be a bridge validator

• And earn bridging fees in BTC

• Bridge governed by BVM DAO

Introduction

Bitcoin Decentralized Bridge is one of the most important problems that Bitcoin has to solve. Such a bridge would allow BTC to be bridged in and out of Bitcoin L2s trustlessly. It opens up so many new use cases for Bitcoin.

The BVM team proposes a decentralized, bidirectional bridge connecting Bitcoin and SHARD_BVM. This bridge will pave the way for bringing BTC to all Bitcoin L2s powered by the BVM network via a native ZK bridge between SHARD_BVM and these L2s. The design of this bridge is guided by the following principles:

A fairer participation model

Anyone can become a validator by staking some BVM. This inclusive approach broadens participation and strengthens network security, vastly differing from other Bitcoin Bridge designs based on a few big validators.

Security

The protocol utilizes a Bitcoin Tapscript to lock vault assets securely. These assets can only be unlocked through the validated signatures of bridge validators, enhancing the security and integrity of transactions.

Smart contracts

All transactions (deposits and withdrawals) are verified using Simplified Payment Verification (SPV) on the bridge smart contract deployed on SHARD_BVM. This ensures the accuracy and legitimacy of transactions across the network.

Verifiable

The bridge smart contract manages the Bitcoin header chain used for SPV and bridge states. It is accessible and verifiable by all network participants, fostering a transparent and accountable ecosystem.

Staking & Validator Dynamics

Open participation

The staking mechanism is open to all, allowing anyone to stake BVM and partake in the validator set.

Over-collateralization

Validators stake BVM as collateral, securing their commitment and incentivizing the maintenance of a 1:1 peg between bridged BTC and minted bBTC.

Over-collateralization requires that the total staked BVM be greater than the value of the total BTC in the vault. This helps discourage validators from malicious actions, as the penalty for such behavior would be significantly greater than any potential gains.

Technically, the size of the validator set and the required number of signatures from validators are determined by the limitations of Bitcoin Taproot transactions, primarily concerning transaction and op stack sizes. Details of the Bitcoin transaction construction can be found in the Deposits section.

We choose to set the initial over-collateralization rate to 3 and the size of the validator to 500 in a k-of-n multisig scheme (where k = 250 and n = 500), with a required stake amount of 100,000 BVM each.

Therefore, the bridge can handle a maximum of 500 × 100,000 × $0.5 / 3 = $8.3 million worth of BTC in the initial stage, assuming the BVM price is $0.5. These parameters may be adjusted according to demand.

Bridge params governed by the BVM DAO

The parameters are subject to change by the BVM DAO. Thanks to the Taproot upgrade, 'k' can be increased to about 999, and 'n' can be significantly larger.

Validator selection & rewards

Before each epoch, 500 validators will be randomly selected from the staker list to reduce the potential for collusion among validators. They earn bridging fees in BTC.

Validator responsibilities

Validators play a crucial role in the system by submitting signatures to unlock funds from the asset vault to fulfill bridge-outs. Additionally, they facilitate the seamless transition of all funds to a new asset vault for the subsequent validator set after each epoch.

Staking smart contract

The Staking contract contains a stake(public_key) function, which allows individuals to lock BVM and register their BTC public keys. This function is crucial in forming the Tapscript vault, which secures BTC bridge-ins.

Deposits ("bridge in")

Vault address construction

As previously outlined, bridge-in funds are securely held within a Bitcoin Tapscript, the construction derived from the bridge-in payload and the public keys of validators.

<BRIDGE_IN_PAYLOAD> OP_DROP <MULTISIG_SCRIPT>

BRIDGE_IN_PAYLOAD

This includes the current validator set's base vault address and the BVM network's recipient address. The base vault address also serves as the Tapscript, crafted from the current validator set's public keys.

MULTISIG_SCRIPT

This script represents a 250-of-500 multisig setup formulated from the 500 public keys of the current validator set. Let's delve into the specifics:

<PK0> OP_CHECKSIG <PK1> OP_CHECKSIGADD … <PKN> OP_CHECKSIGADD <K> OP_NUMEQUAL

The construction of the vault address is inherently verifiable, ensuring its integrity. At the same time, the bridge-in payload remains immutable to external manipulation. Importantly, this process eliminates the need for any trusted intermediary to monitor deposit payloads off-chain, thus enhancing decentralization and security.

SPV bridge-in proof

The bridge-in proof acts as a Merkle proof that validates the inclusion of a transaction—transferring Bitcoin to the vault address—within a Bitcoin block.

This proof is meticulously verified by SPV against the Bitcoin header chain directly on the bridge contract.

As a result, individuals can autonomously and permissionlessly submit their deposit proof to the smart contract, enabling the seamless claiming of bBTC on SHARD_BVM.

Additionally, the proof includes the bridge-in payload, aiding in the reconstruction of the vault address. This process ensures the output address in the Bitcoin bridge-in transaction meets the expectations defined in the Bridge contract.

Workflow

Step 1: The user sends BTC to the vault address constructed from his bridge-in payload.

Step 2: Once the Bitcoin network confirms the transaction with sufficient block confirmations, the user submits bridge-in proof to the bridge smart contract on SHARD_BVM.

Step 3: The contract verifies both Merkle proof and transaction output address. If the verification is successful, the contract mints bBTC at a 1:1 ratio relative to the bridge-in amount and sends it to the recipient address specified in the bridge-in payload.

Withdrawals ("bridge out")

The coordinator

We introduce the coordinator role to ensure consistency in the raw fulfillment transaction among validators and to reduce complexity. The cooperation between the coordinator and validators in processing bridge-out requests is as follows.

Workflow

Step 1: The user initiates a bridge-out request by invoking the contract's burn(receiver_address, burn_amount) function.

Step 2: The coordinator takes responsibility for creating a raw transaction to unlock Bitcoin from one or more UTXOs within the vault assets, thereby fulfilling the bridge-out requests.

Simultaneously, the leader submits the signature on the transaction hash using its private key corresponding to the registered public key from staking.

Step 3: Other validators monitor the raw fulfillment transaction relayed by the bridge contract. Upon verifying its accuracy, including the correct amount and output address, validators submit their signatures on the transaction hash to the bridge contract, endorsing its validity.

Step 4: Once at least 250 signatures are collected for the fulfillment transaction, the coordinator combines them into a complete transaction and broadcasts it to the Bitcoin network.

Step 5: Following the confirmation of the fulfillment transaction on the Bitcoin network, with the minimum required confirmation blocks, the coordinator submits the SPV proof to the contract.

This proof, comprising a Merkle proof of the fulfillment transaction, substantiates the validity (e.g., utilizing unspent, valid inputs, legitimate signatures, and sending to appropriate bridge-out addresses) of the transaction generated by validators on the Bitcoin network.

Note: Multiple bridge-out requests can be processed in a single Bitcoin transaction to reduce network fees, which will be deducted from the bridge-out amounts.

Shuffle validators

At the end of each epoch, the new validator set will be randomly selected from the staker list at the epoch's final block. From this point forward, all vault addresses for new bridge-ins will be generated with a new set of public keys.

Additionally, the outgoing validator set must transfer the old vault assets to the incoming validator set's base vault address.

Risk Analysis

Since the SHARD_BVM supports smart contracts, the logic for verifying obligations and slashing stakes for validator misbehavior can be implemented in the Bridge contract.

This functionality is feasible because the contract can track all bridge-in and bridge-out states occurring on the Bitcoin network (thanks to the SPV capability) and SHARD_BVM.

Let's examine three critical cases of malicious behavior where validators fail to fulfill their obligations and how the bridge contract can verify and penalize them:

Validators fail to co-create fulfillment transactions for bridge-out requests.

The bridge contract tracks bridge-out requests once users burn their bBTC. These requests have an expiry time, requiring validators to submit an SPV proof to promptly verify the fulfillment transaction's inclusion in the Bitcoin blockchain.

Their stakes will be slashed if they fail to do so or the SPV proof is inappropriate (e.g., invalid Merkle proof, incorrect recipient address, or amount).

Validators fail to co-create a transaction to transfer old vault assets to the new base vault address.

Similarly, when the validator set changes, the outgoing validators must submit an SPV proof confirming the transition transaction's inclusion in the Bitcoin blockchain before expiry.

Failure to provide valid SPV proof (e.g., invalid Merkle proof, wrong base vault address, or incorrect amount) will result in a slash of their stakes.

Validators co-create a transaction to transfer vault assets to an inappropriate address.

In cases where this occurs and the vault is emptied, the validators will fail to fulfill bridge-out requests and transfer the old vault assets to the new base vault address. They will be penalized as described in the scenarios above.

The security level in these cases primarily depends on the collateralization rate of the staked BVM and the BTC held in the vault. As a rule of thumb, the total value of the staked BVM should always exceed the total value of BTC in the vault to deter validators from committing fraud.

Moreover, a reliable oracle price feed for the BVM/BTC rate will be necessary to maintain a safe collateralization rate. The core team will initially manage this, and plans to decentralize the oracle are in progress.

Additionally, all numbers are public, allowing users to monitor the rate and bridge their assets out if they feel uncomfortable, such as in extreme scenarios where the price of the BVM drops significantly.

Conclusion

Bitcoin L2s and Bitcoin Decentralized Bridges will unlock many new use cases for Bitcoin. We propose a decentralized bridge design connecting the Bitcoin network and all Bitcoin L2s powered by the BVM network.