The BitVM tl;dr

The information on this page can get pretty technical. The short on BitVM is that it offers a major improvement to bridging designs on Bitcoin. It can likely bring us Optimistic rollups, and also make multi-sig bridge custodians effectively obselete. This improvement significantly decreases the trust assumptions Bitcoin users have to take on when interacting with offchain protocols, and it creates an entirely new design space of applications being built on Bitcoin. That's why it's one of the most covered topics in the technical Bitcoin community.

We highlight what this means for rollups below, and also list a number of resources where you can learn more about BitVM. Our favorites to get started are this blog by Tyler Whittle, this tweet thread from Bob Bodily, and this podcast episode on the Stephen Livera Podcast.

BitVM was introduced by the ZeroSync team.

What is BitVM?

The core idea of BitVM is to take computation off-chain with an on-chain fraud proving mechanism. Bitcoin Script is very simple, so to run more advanced programs, you need to run them off-chain and somehow prove that the computation was done correctly. To verify computation, BitVM uses a similar scheme to optimistic rollups - a prover (who executes the computation off-chain) makes a claim about the output of the computation. If this claim is disputed, the verifier can challenge it on the Bitcoin blockchain. The Bitcoin blockchain would only be used for disputes in this scheme.

Tl;dr? It allows you to develop new applications on Bitcoin that may provide more utility to BTC the asset.

Why does it matter to rollups?

BitVM allows us to create a fraud-proof mechanism that is conceptually similar to TrueBit’s or Arbitrum’s design - likely enabling optimistic rollups on Bitcoin!

There are, however, a few subtle but important differences. As of writing, the committee of Provers and Verifiers, i.e., participants who can trigger a dispute, must be pre-defined for each BitVM setup. This means that the trust assumption of a BitVM setup is 1-of-N known participants, rather than “at least any one honest and online network participant”. Another difference is that due to lack of smart contract functionality on Bitcoin, we cannot make use of succinct non-interactive proving techniques, as opposed to Ethereum.

As a result, the challenge-and-response protocol must be interactive. This means that the exchanges between accused Provers, and challenging Verifiers, must be on-chain Bitcoin transactions over a prolonged period. This takes place until either one of them is slashed due to timeout or equivocation. But, the Verifier can make use of a similar bisection protocol as other well-known fraud-proof mechanisms. It can essentially perform an efficient binary search over the pre-committed program (specifically, the program broken down into the underlying logical gates) to determine which parts should be challenged. This optimization already allows to cut down on-chain costs to approximately 30-40 transactions per challenge, in the worst case.

Tl;dr? BitVM can likely give us optimistic rollups with different trust assumptions as to those on, let’s say, Ethereum. This is incredible for Bitcoin scaling.

Can it give us trust-minimized bridging?

First, let’s review the current state of Bitcoin bridges. When a user bridges BTC to an offchain scaling solution (e.g. another blockchain) they have to deposit that BTC into a bridge contract. On Bitcoin, a bridge will use one of two designs:

• Statistical security: a multi-sig (or threshold signature) controlled by N parties. As long as the majority M of N is honest, the bridge is secure. Notable examples include rBTCs (multisig) or tBTC (larger set via threshold signatures).
• Economic security: bridge operators are collateralized on the target chain in assets other than Bitcoin. If an operator steals BTC or fails to perform a peg-out, their collateral is liquidated and used to reimburse the user. While this design is very secure (users always get BTC back or are repaid in full in other assets), the associated capital costs for operators limit scalability. Collateral quality is another concern, as other assets may fluctuate in price compared to BTC or exhibit lesser security properties. Variations of this design are used by Interlay, Cardano (anetaBTC), TeleBTC (on Polygon), Harmony and Stack’s sBTC.

Both designs can be combined to improve security and balance between large signer committees and full/partial collateralization. See here for more details on Bitcoin bridges.

BitVM & Bitcoin Bridges

BitVM can offer a major improvement over existing bridges in terms of security and capital efficiency. Specifically, we may be able to use BitVM to implement a light client for the target chain (e.g. a rollup) that would allow us to verify correct processing of peg-in and pre-out transactions (on the other chain that is assumed to have smart contracts).

The idea is that deposits made into BitVM are controlled by a committee of N Provers and Verifiers, and as long as one of these N participants is honest, the deposits remain secure. Whenever a user requests a peg-out the (current) Prover verifies the state of the rollup off-chain and, if everything is correct, sends BTC to the user. Verifiers observe this process and verify correctness. If the Prover misbehaves, i.e., remains unresponsive or sends BTC to a wrong BTC address, they trigger an on-chain challenge and prevent the Prover from accessing the BTC deposits. This, of course, requires the Prover verify the state of the L2 off-chain.

It makes use of so-called cross-chain light clients: programs that can programmatically verify that certain state changes have happened on another blockchain. The sidechain, assumed to have smart contract functionality, implements a Bitcoin light client that can verify Bitcoin transactions, and vice-versa. Bitcoin’s Script language lacks expressiveness to encode light clients as on-chain programs. Instead, the sidechain light client is implemented via BitVM, a novel paradigm on Bitcoin based on optimistic program execution: participants pre-commit to the program via a set of pre-signed Bitcoin transactions, the execution happens off-chain, and if participants disagree a challenge-response protocol is performed to determine the correct outcome.

The billion dollar question is how to scale the set of Verifiers and ensure a good user experience to users. Given this, BitVM can finally make centralized multi-sig bridges redundant!