25.9.2024
Never miss an important update, event, or early access
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
BitVM and BitVM2 solutions have made huge strides toward introducing Turing-completeness and smart-contract functionalities to Bitcoin. Meanwhile, BitSNARK launched as a focused, optimized application inspired by BitVM specifically for zk-SNARK verification.
In this guide, we’ll go over the basics of BitSNARK, BitVM, and BitVM2, their similarities and differences, and how each of them offers some advantages over the previous solution.
Bitcoin Script is the scripting language of Bitcoin. It is intentionally limited in its abilities in order to protect Bitcoin from unintended exploits. However, Robin Linus, the creator of BitVM, noticed an intriguing property of Script. Because it contains all the basic logic operations OP_AND, OP_OR, and OP_NOT, it can simulate the equivalent of a digital circuit with arbitrary functionality.
With this insight in place, complex operations can then be built up from these simple opcodes. This insight underlies all three paradigms—BitVM, BitVMS, and BitSNARK.
BitVM (an allusion to the idea of a virtual machine (VM) on Bitcoin) is the original computing paradigm developed by Robin Linus to use digital-logic opcodes to simulate arbitrary functions in Script. It aims to enable smart-contract functionalities on Bitcoin.
It enables a simulation of a Turing-complete machine off-chain, meaning it can run any program (or smart-contract, in this case), given enough time and resources. BitVM is also the basis for some Bitcoin Layer 2 (L2) projects like Citrea.
Bitcoin is not a natively Turing-complete blockchain, and BitVM doesn’t bring this option to the blockchain itself. Instead, most of its processes are computed off-chain, and it only brings matters of verification onto the chain in case there is a dispute, similar to optimistic rollups.
By functioning mostly off-chain, BitVM doesn’t require a fork—soft or hard—to be implemented. Instead, it functions on an opt-in basis: users who want to take advantage of it can do so freely, while others never even have to know of its existence. That means it requires no changes to the network’s consensus rules.
BitVM functions within a two-party framework, made up of a prover and a verifier. After they both deposit bitcoin in a shared Taproot address, they engage in a sequence of challenge-response transactions, through which the verifier offers a challenge for the smart contract and the prover offers a solution. The challenges are built to let the verifier expose a dishonest prover and take their deposit, meaning attackers always lose the funds they’ve locked into the shared address.
In case of disagreements, they are resolved on-chain, involving the blockchain as a sort of impartial judge. The verifier publishes the proof of fraud on the chain, the prover loses their money, and the smart contract is not executed. Additionally, verifiers can add timelocks to the process. If the prover doesn’t respond adequately within the specified timeframe, they again risk losing their deposit.
BitVM2 is an improvement on BitVM, addressing some perceived shortcomings of its (still under development) predecessor. Most significantly, BitVM2 verifier participation is permissionless, as anyone can challenge a fraudulent transaction, not just the verifier chosen at the beginning of the process.
Robin Linus, the Bitcoin developer behind BitVM, is also the creator of BitVM2 along with five co-authors of the whitepaper.
Like BitVM, BitVM2 relies upon an optimistic approach: transactions are considered valid until challenged and double-checked. In other words, they don’t have to be checked by everyone in the network; a single honest verifier is enough to maintain the validity of the entire system.
In BitVM, that verifier must be chosen at the beginning of the smart-contract execution. BitVM2 changes the game by letting anyone challenge an output they consider faulty, making the system less permissioned.
LIke BitVM, BitVM2 penalizes malicious actors by allowing their funds locked in the shared address to be forfeited. If the prover and all the verifiers are dishonest, they can still steal funds. However, if even one verifier is honest; the locked funds become irretrievably lost and effectively burned, so this behavior remains disincentivized in BitVM2.
BitVM2 also claims to require fewer transactions than BitVM. However, the transactions are very large, which might cause delays in the mining of the transactions and may not always result in a faster verification process.
BitSNARK is a software library built upon BitVM as an optimized version of this paradigm to tackle issues with program size and challenge/response protocol present in BitVM.
BitSNARK is not a general-purpose system like BitVM. BitSNARK is specifically designed to verify SNARK proofs on the Bitcoin blockchain. It can do general-purpose operations by recasting them as a SNARK proof and then using BitSNARK to verify them, but that is not its intended purpose.
BitSNARK was created as part of the BitcoinOS system, initiated by Sovryn. The whitepaper was authored by Ariel Futoransky, Eden Yago, and Gadi Guy, and it also includes Grail, an implementation of BitSNARK that creates a Bitcoin Rollup Bridge.
BitSNARK is a protocol for the verification of a zk-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge), which is a fast and easy way to verify knowledge of some information without revealing that information itself.
These quick verifications are useful for executing smart contracts easily and securely without actually computing them on-chain; instead, they prove only their validity on-chain, which significantly decreases the amount of computational resources needed.
Like BitVM, BitSNARK uses a two-party verification system made up of a prover and a verifier. During a series of challenge-and-response interactions, the prover cuts the program execution in half and commits to that point in the virtual machine. The verifier chooses which of the two parts they believe is false, and all of this continues until a single BitSNARK operation remains, which is executed on-chain and the winner is revealed.
BitVM, BitVM2, and BitSNARK function in a similar way that ultimately aims to bring improved programmability to Bitcoin. However, there are some significant differences that set them apart.
All of them make strides towards the realization of Bitcoin programmability (and thus enabling DeFi functionalities on Bitcoin), but their approach isn’t always the same.
BitVM, BitVM2, and BitSNARK are all systems that can theoretically verify any program given enough time and resources. The biggest difference between BitVM and BitVM2 on one hand and BitSNARK on the other is that the latter is designed specifically to verify zk-SNARK protocols.
For BitSNARK, that means using SNARK tools that allow proof of general-purpose programs, and then only verifying that proof instead of the computation as a whole.
Because of this specific structure, BitSNARK offers an order of magnitude improvement to program size and as much as a 50% reduction in challenge/response protocol length for the kind of computations required by bridges. Further, BitSNARK only requires a single challenge type—single-instruction execution error proofs. By contrast, BitVM requires six different challenge types. Because the protocol is simpler, the system is more secure, transparent, and auditable.
Because BitVM and BitVM2 are inherently general-purpose verification systems, they require pregenerating, presigning, and storing billions of transactions, one for each potential challenge
in a verification game. As such, they are represented on-chain by very large transactions. Because of their size, a BitVM/BitVM2 transaction may be delayed in fitting into a block. BitSNARK solves this problem by progressively cutting the program in half until the prover commits to a single BitSNARK operation. This operation is capable of being executed by the verifier on-chain with Bitcoin Script to challenge a fraudulent operation.
Unlike BitVM2, BitSNARK requires that verifiers be defined as part of the transaction setup. , but Although verifiers must be determined in advance, anyone can be a verifier if they choose to stake and verify.
BitSNARK has a special advantage in bridging. Because SNARKs can significantly reduce the input data requirements, the data availability requirements for bridging make a BitSNARK-based bridge potentially much lower in cost.
BitVM has taken steps toward bringing full-scale programmability to Bitcoin, and BitVM2 has improved upon the shortcomings of its initial version. However, both still suffer from potentially large transactions and large required input size as a natural consequence of their general-purpose nature.
BitSNARK addresses and solves these issues by only verifying SNARKs instead of the whole computation, thus reducing the required input size significantly. Additionally, SNARKs only require one challenge type between the prover and verifier, so the speed and auditability of the verification are also improved.
In conclusion, BitSNARK eliminates some key problems present in both BitVM and BitVM2, potentially giving rise to a new era of Bitcoin smart contracts.
