How BitVM2 works

The bitvm2 paper describe a simpler way to achieve bridging bitcoin to l2. By looking into its codebase as of the commit 834199a, here are some notes on the key concepts from both the paper and the implementations.

emulating covenant

Covenant is a way to enforce the rules of how the UTXOs can be spent. Bitcoin doesn't have native covenant. BitVM relies on multi-signatures make agreements on the set of the possible transactions that guide the possible routes of where the UTXOs can be.

Screenshot 2025-01-17 at 21.00.17.png

Take this diagram for example.

The outputs of the Claim tx are multi signed.
They can be only consumed by either the Challenge tx or PayoutOptimistic, as the multi sigs is an agreement on this restriction.
If it is consumed by the Challenge tx, then the route to the PayoutOptimistic tx is disabled, because that output is consumed.
Otherwise, after a certain period of time, the operator can unlock it for PayoutOptimistic tx.

The taproot script makes it passible to achieve this, as it makes a single UTXO spendable by multiple paths.

emulating statefulness

To enable large amount of calculation on bitcoin blockchain, one idea is to chunk a program to sub-programs, each of which is embedded in a unspent output script, such that:

z_{i} = f_{i} (z_{i - 1})

The sub programs be wired up by their inputs and outputs, and eventually results in the last output $z_{i}$ that represents the output of the original program.

However, the current bitcoin transaction script is stateless. There is no native way to pass the calculated state like $z_{i}$ from an input to the output through a transaction.

One time signature like lamport signature enables statefulness on bitcoin blockchain. In bitvm2 codebase, it uses winternitz.

emulating general computation

BitVM2 relies on snark verifier to prove the validity of a program execution. This makes it more succinct than executing the actual program on chain, such that the commitment data is small enough to post on chain for the challengers to review off-chain.

The snark verifier can be chunked into sub programs, which are the same for different transactions. The witnesses posted on chain can be used as intermediate states to verify with these sub programs in order to identify the fraudulent witness off-chain if any.

bitvm1 vs bitvm2

Compared with BitVM1, BitVM2 doesn't verify every opcodes and memory of the program execution directly, instead it verifies the intermediate results representing a verification of a snark proof.

bitvm1

The program can be too big or complicated to be chunked (compared to the well known logic behind a snark verifier) as it does for snark verifier.
So it can't simply extract intermediate states into witnesses for being checked in a batch.
Also it is likely too large to commit both the whole program and memory for each execution on-chain for review.
This seems to be why it needs to run the bisection game to narrow the exact opcode and memory for dispute.

bitvm2

Once agreed on the snark verifier program, the only thing is needed for proving the correction of the verifier execution is the snark proof.
The proof sizes are consistently small enough to be committed on chain for challengers to review in a batch without the need to run bisection game.

statefulness via one time signature

z_{i} = f_{i} (z_{i - 1})

z_{i + 1} = f_{i + 1} (z_{i})

the operator might cheat by manipulating intermediate value $z_{i}$ for the input of $f_{i + 1}$ , so that the $z_{i + 1}$ looks correct but having inconsistent $z_{i}$ values between these two functions.
each of committed public keys of one time signatures only allow committing one value.
so the value inconsistency of the variable $z_{i}$ can be caught by comparing their values and their public keys.

implementation

The implementation of the bitvm2 consists of the following key components.

BitVMClient

BitVMClient seems to be synchronizer for the bitvm2. I think one of its purposes is to achieve the covenant.

When it needs to require multiple signatures and other parties to sign it, it would rely on this synchronizer to broadcast the un-finalized transaction, and manage the status and ongoing workflow.

Screenshot 2025-01-17 at 21.56.11.png

Screenshot 2025-01-17 at 21.56.31.png

transaction graphs

A transaction graph is a set of transactions for a particular workflow. Some of these transactions are pre-signed for the covenant purpose.

The connections between the transactions are made by connectors.

connectors

Connectors encapsulates both the lock and unlock script for a specific type of UTXO.

For example:

tx A has an output of ConnectorZ, which has two path locks using taproot
to unlock the unspent output, ConnectorZ provides the functions to generate the unlock script to unlock the output as an input in a new transaction.

Screenshot 2025-01-17 at 22.04.39.png

How deposit works

When the depositors want to top up their asset in the L2, they initiate a peg in graph which consists of the following transactions:

PegInDepositTransaction
PegInRefundTransaction
PegInConfirmTransaction

The workflow is:

the depositor sign and broadcast the PegInTransaction.
the L2 system detected the transaction, sign PegInConfirmTransaction and broadcast it.
at this point, the depositor can complete the multi signature and broadcast it to confirm the deposit.
also the depositor can withdraw the money by making a refund transaction after the time lock, if the PegInConfirmTransaction is not finalized.

The path to either refund or confirm is achieved by the ConnectorZ:

Screenshot 2025-01-17 at 22.10.30.png

As this workflow involve multi-sign and broadcasting un-finalized transaction, it is guided through the BitVMClient.

program chunkers

The snark verifier is chunked into segments (sub programs), each of which can be executed on chain to verify an intermediate state, both the input and result in order to do the following check:

z_{i} = f_{i} (z_{i - 1})

If this check fails, a corresponding taproot UTXO can be spent with the fraud witness in a disprove transaction.

There are a number of different chunkers for chunking different parts of the snark verifier. I think this is one of the most complication part in the codebase.

codebase evaluation

Overall the codebase seems still in its early stage. The transaction graphs doesn't match up with the bitvm2 paper. some are added, some are renamed.

peg out seems still in an experimental stage, a lot of covenant connectors seems missing.
test is very slow to run
there seems only has a dummy snark circuit for testing
doesn't contain any L2 logic, such as L2 account/balances, neither the connections to referencing the L2 states in the snark dummy circuit for proving peg out.