Last October, Robin Linus of Zerosync dropped a bomb in the form of BitVM. One of the longest-running criticisms of Bitcoin is that it is not possible to create arbitrary programs to control how money is spent or locked. Bitcoin has only a very limited degree of programmability in its scripting language, and the primitives available are extremely limited. You can check a signature, you can add a timeslot to something, you can manipulate data in a few simple ways, but that’s it.

You can program a Bitcoin UTXO to require a signature check, a timeslot verification, etc. But you can’t program it to unlock based on arbitrary conditions. Robin’s insight with BitVM was that one primitive in computing could be are enforced in Bitcoin script: NAND gate, one of the basic principles of computing at the physical/electrical level. Every possible calculation can be built from NAND gates.

Script can actually verify a NAND gate thanks to a neat trick with OP_BOOLAND and OP_NOT. OP_BOOLAND is an AND operation, the opposite of NAND. OP_NOT takes a binary value of 1 or 0 and inverts it. This allows you to actually force a single NAND operation directly in the script. In combination with hashlocks, a NAND gate script can be created where each input and output field has two possible hashlocks to ‘unlock’ that spend path, each pushing a 1 or 0 onto the stack to perform the NAND operation. Each script also has a path where you can reveal it both preimages to a value of one bit, you can claim the money immediately. This is so that once someone has decided what to input into the NAND gate, he or she cannot change their mind without losing money.

A huge amount of NAND gate scripts can all be compressed into a taproot tree, and once someone commits to inputting the off-chain bit values ​​to feed into that computation, the other party can challenge them at each individual step in the computation to to prove that this is so. are carried out correctly in the chain. Each ‘challenge’ allows the challenged party to prove that the individual gate was calculated correctly, otherwise the other party can claim the money after a time slot. Going back and forth in this way when a calculation is disputed guarantees that the cheating party will eventually be caught and lose money.

The limitations

The main limitation of BitVM is that only the people involved in creating a BitVM contract can participate, and the roles are very limited. There is the prover, the person who asserts how the off-chain computation occurred, and the verifier, the person who can challenge the computation and force it to be proven on-chain if the prover does not complete or attempt the off-chain computation to do this. lie about the results.

One of the reasons for designing BitVM was to set up bi-directional pegs for sidechains or other systems. The scheme provides a very powerful primitive in that case, the ability to actually enforce money given to one party or the other based on the correctness of an arbitrary calculation, i.e. a validity check whether a pegout is valid according to the rules of a side chain. . The problem is that only the people who hold the keys to that BitVM UTXO can actually say, “Hey, you’re cheating!” when someone is, and participate in the challenge protocol. This ultimately ensures that the system is still trusted.

Another limitation is that the challenge-response protocol can be very long. If someone realizes that the outcome of the calculation will cause them to lose money and they become unresponsive, the verifier must essentially guess where the individual NAND gate is in the calculation where the prover would have to lie and reveal both preimages to a little that the verifier would make the money. Until that specific gate in the chain is challenged, the prover can still correctly respond to a challenge and drag it out. This can be very time consuming and inefficient.

Some improvements have been made to this design since the original proposal to allow multiple verifiers in the system with the prover, to create a 1-of-n trust model where only a single verifier is needed to identify a dishonest challenge the prover. However, this requires the instantiation of multiple BitVM instances in parallel to achieve this, and therefore increases the inefficiency with the original two-party design.

BitVM 2

Robin recently proposed a design scheme for BitVM 2. This plan attempts to make a few tradeoffs compared to the original design to mitigate its two main shortcomings. BitVM 2 shortens the length of the challenge/response protocol from an indefinite series of transactions that can number in the dozens in the worst case, to two rounds in the challenge/response. Furthermore, this is possible with the use of connector outputs everyone to act as a verifier. It is not necessary for anyone to be a member involved in setting up the BitVM to challenge a dishonest prover.

The fundamental shift here is moving away from using scripted NAND gates directly to implement the raw computational trace directly, and moving towards using them to implement a general-purpose SNARK zero-knowledge proof verifier (one of the core primitives which Robin wanted to implement from the start using BitVM). Instead of putting the raw input into the raw compute trace and executing it port by port in their own tapleaf scripts, the input to the BitVM 2 instance would simply be a zero-knowledge resistant input combined with an asserted output of the computation .

In addition to eliminating the compute implementation with a ZKP, the tapleaf scripts are greatly expanded from a single NAND gate per leaf to a full subfunction of the ZKP authenticator. Instead of the challenge response protocol being based on the verifier guessing which NAND gate the prover was trying to cheat at, and selectively challenging at a single gate, the verifier can prove that the output of an entire subfunction is invalid according to the input.

Like BitVM 1, the contract is pre-negotiated using pre-signed transactions and branching scripts. Funds associated with the BitVM are sent to a n-of-n multisig that signs two possible execution transactions, one in which no challenge occurs, and one in which a challenge occurs. To start the process of executing the contract, the prover initiates a kick-off transaction. This start transaction deals with the output value ‘y’ that it believes the computation produces, and includes three outputs: a time-bound output included in the run transaction without challenge, a connector output A, and a connector output B, both of which are also issued in the no challenge transaction.

Here the design makes it possible for anyone to participate as a verifier. Connector output A has a second pre-signed transaction that it can issue, the challenge transaction. This is a pre-signed transaction that pays the prover a bond in bitcoin, but the connector output A is not enough to fund it. Literally anyone can add their own input to fund the transaction and spend connector output A, making the withdraw transaction void without a challenge to the prover (one of the inputs that doesn’t need a challenge exists).

This forces the challenge path. Connector output B can also be issued using a pre-signed transaction, the assert transaction, for the output of each subfunction in the entire BitVM 2 contract. This requires a large transaction with a lot of data, but remember that the final output ‘y’ that the prover claims the computation produced was already committed to the starting transaction. This creates two exits. One is a timelocked output, the other is a connector output C. Both outputs, in addition to the original pinned funds, are all spent in the second successful withdrawal transaction for the prover after the timeslot.

Connector output C can also be issued by anyone who can prove that each subfunction output in the BitVM 2 contract produces an invalid output. This requires a very large transaction, because the script required to prove that an entire section of the BitVM calculation is incorrect is enormous, but in this single transaction a verifier can claim the coins in the connector output with a valid proof. This voids the second withdrawal transaction for the prover and effectively burns the coins. The only way to get them back at this point is if the prover and all of the verifiers in the original n-of-n funding multisig are all working together to recover it. Connector output B in the kickoff transaction can also be used after a much longer timeout than withdrawing no challenge to invalidate both the no-challenge and assert transactions, thus burning the linked coins.

This reduces what could have been a ridiculous chain of transactions in the original BitVM proposal to enforce the correct contract outcome to a maximum of four transactions (albeit admittedly very large ones), while in the process the set of verifiers for the BitVM 2 instance literally is made. anyone with bitcoin who will fund the challenge transaction.

BitVM 2 could be a major breakthrough when it comes to the wave of rollups and other layer 2s aimed at using BitVM as a two-way peg. The operator of a rollup (the prover in the BitVM) can use its own funds to cover withdrawals from users associated with the system, and can periodically withdraw these funds from the BitVM to compensate themselves. Each The user or interested party could then penalize him by burning his money if he could provide proof that the operator did not process all withdrawals correctly.

It is important to note that the security of a BitVM 2 instance is ultimately held back by the n-of-n keyholder, even though non-participants can still challenge the prover as a verifier. But because the prover has an efficient exit when there are no challengers, and anyone can fund the challenge transaction to act as a verifier, the n-of-n funding multisig could follow a setup and key removal ceremony similar to the launch of Zcash to ensure security improve it.

BitVM 2 is likely to be a major breakthrough in terms of improving the flexibility and trust model of two-way pegs using BitVM. Once again Robin has proven that he is a true wizard.

Leave a Reply

Your email address will not be published. Required fields are marked *