BitVM Primer
Last updated
Was this helpful?
Last updated
Was this helpful?
orginal:
By Tyler Whittle ()
Welcome to the BitVM primer! If you read the abstract below and get it on the first go, kudos to you. Please reach out to me so I can offer you a job at the . If you’re like the 99% of us who are left simultaneously excited and confused, read on!
Abstract - BitVM: Compute Anything on Bitcoin
BitVM is a computing paradigm to express Turing-complete Bitcoin contracts. This requires no changes to the network’s consensus rules. Rather than executing computations on Bitcoin, they are merely verified, similar to optimistic rollups. A prover makes a claim that a given function evaluates for some particular inputs to some specific output. If that claim is false, then the verifier can perform a succinct fraud proof and punish the prover. Using this mechanism, any computable function can be verified on Bitcoin.
Committing to a large program in a Taproot address requires significant amounts of off-chain computation and communication, however the resulting on-chain footprint is minimal. As long as both parties collaborate, they can perform arbitrarily complex, stateful off-chain computation, without leaving any trace in the chain. On-chain execution is required only in case of a dispute.
Though it might be hard to distill from the abstract, BitVM marks a paradigm shift in what we thought was possible on Bitcoin. Put simply, the BitVM allows arbitrary computation to be executed on Bitcoin.
Okay, “arbitrary computation” is a mouthful and doesn’t really help a non-technical reader. So let me give you an example: Chess.
Chess is an example of a well-defined program with set constraints and a win condition. You have certain pieces that can move in certain ways around an 8x8 board. You know the game is over when a king is captured or neither player is able to win. You can consider chess a program with some arbitrary computation (e.g. there is not a chess.move_knight(F4) command built into Bitcoin).
Now let’s say Vicky and Paul want to play a game of chess against each other. What’s more, they want to make a big bet on it: 1 BTC to the winner! Given this game has such large stakes, they want a way to verify who won.
Before blockchains, Vicky & Paul’s best bet was to find a trusted third party (let’s call him Terrance) who would observe the game, declare a winner, and custody/pay out the 1 BTC. But what if Terrance wasn’t so trustworthy? Maybe Terrance decides to run away and keep the 1 BTC for himself. Maybe Paul bribed Terrance to declare him the winner no matter what. Neither of these situations (or the myriad of others that could potentially arise) are ideal.
Enter blockchains! A primary advantage of blockchains is that they shift the need to trust another human to the need to trust cryptography and code.
As an analogy, think of Bitcoin/Script like your high-school calculator and Ethereum/Solidity like your iPhone (or Android if you’re like me). Your iPhone can run any program an app developer can cook up. Your calculator, on the other hand, is relegated to some numbers and a few mathematical functions. Maybe there are a few extra buttons for some calculus on there, but no one is mistaking your TI-83 for an iPhone.
Script, however, is not considered Turing complete. This means it wasn’t possible to run all those cool programs you see on other chains on Bitcoin (until now!).
There are ~100 opcodes on Bitcoin, and they are specifically designed to limit the complexity of the computation that can be done. For example, as of writing there is not an opcode to multiply two numbers, nor is there an opcode to add to strings together. Satoshi removed these and many other opcodes very early in Bitcoin’s life to ensure that Script was not Turing complete.
So why did Satoshi make Bitcoin so restrictive? The answer lies in the economics of Bitcoin. Bitcoin’s security relies on decentralization. It relies on users like you and me to run nodes and VERIFY that the transactions submitted to the network are valid. A full node runs the computation of every transaction in every block on the network. And unlike Ethereum, the fee a user must pay to get their transaction included is only loosely related to the amount of computation required to execute the transaction.2
Now think what might happen if someone got a transaction included in a block that took 2 hours for a node to run. That would effectively be a DDoS on the Bitcoin network! Nodes are expected to verify a block in a timely manner because miners can’t add a new block until the previous one is verified. By restricting the language of Bitcoin, Satoshi ensured the amount of computation required for a node to verify a block would never spiral out of control.
Enter BitVM…
BitVM achieves this through some crazy wizardry.
With all that background knowledge out of the way, we’re brought back to BitVM. BitVM has created a way to verify arbitrary computation on Bitcoin.
Before BitVM, Paul and Vicky couldn’t have played their chess game and had the result verified by Bitcoin. Now they can!
BitVM will allow them to deposit 0.5 BTC each into a 2/2 multisig address that they both control. If they both agree that Vicky won, they both sign a transaction that sends the 1 BTC to Vicky. Easy peasy! If they disagree, however, there is a way to verify every chess move that happened on Bitcoin and force Paul to send Vicky the 1 BTC. This is what makes BitVM so special.
tl;dr zk-rollups are the holy grail of scaling Bitcoin. If BitVM turns Bitcoin from a calculator into an iPhone, then zk rollups will transform that iPhone into a supercomputer.
Up until now, zk rollups haven’t been built on Bitcoin because there was no way to trustlessly get BTC from the main chain to the rollup, nor to verify zk proofs. With BitVM, we just may be able to do both!
If BitVM can supercharge Bitcoin to enable zk rollups, a new era of fully on-chain Bitcoin applications is about to explode. Defi, DAOs, gaming, etc. will all be coming to Bitcoin. THIS, dear readers, is the promise of BitVM. It should have you stoked to see what comes next!
Example BitVM Walkthrough
Part I: What is BitVM and why should I care? (this article)
Part II: Computers, Programs, and Circuits
Part II: Committing to a Program on Bitcoin
Part IV: The Challenge Protocol
Part V: What challenges does BitVM face?
So why don’t we see an on-chain chess game on Bitcoin like we 1?
The answer lies in Bitcoin’s underlying language: .
Ethereum’s smart contract language, Solidity, is considered “”. While this isn’t strictly true, it’s used in this context to mean Solidity can run pretty much any program imaginable. Chess, a Defi protocol, a zero-knowledge proof verifier - these can all be implemented directly on Ethereum.
If you clicked on the earlier, you’ll have seen a list of these things called opcodes. These are essentially the buttons of the Bitcoin calculator. You’ll see opcodes for simple things like addition (OP_ADD) and cryptographic operations like hashing (OP_SHA256).
What and the clever team at have figured out is a way to allow those arbitrary programs to be executed on Bitcoin without making every full node run every line in the program.
First it simulates (the building block of computers) within Script. Then, it uses something called hashlocks and the structure of taproot addresses to verify the arbitrary computation. Finally, through an elegant challenge protocol, the Bitcoin network can adjudicate which party (Paul or Vicky in our example) is correct. We’ll be diving deep into how that all works in future installments. Alternatively, gives a high-level overview for the curious reader. For now, let’s pop back up a level and talk about what this means.
While , the design space on BitVM is limitless. It will allow users to verify that almost any program ran correctly all directly on Bitcoin! We’re just a few weeks in, and we’re already seeing strong groups to test out this new system.
As for me, I’m most excited about the potential for BitVM to: a). enable trust-minimized bridges, and b.) verify zero-knowledge proofs. These are two key components of a zero knowledge (zk) rollup. If you aren’t familiar with zk rollups, I recommend where I cover why Bitcoin will ultimately need zk rollups.
This concludes the BitVM Primer. I’m considering making this Part I in a series that walks the non-technical reader through the BitVM (full outline below). If that gets you excited, please let me know in the comments or on . I’m always looking for new ways to help the community better understand Bitcoin.
Huge shoutouts to , , , , , & for their thoughtful comments on this article.