|
|
BitVM is the latest hot protocol in the Bitcoin ecosystem, with the potential to benefit every project built on Bitcoin. Let's talk about the design of BitVM and the new possibilities it opens up for Bitcoin.
Introducing Fraud Proofs to Bitcoin
"Bitcoin Season 2" is underway, and developers and users are excited about building projects on Bitcoin and bringing new use cases and approaches to solving eternal challenges on Bitcoin.
Bitcoin lacks scalability. Due to limited block space, transaction fees can fluctuate significantly during network congestion. With only 7 transactions processed per second and each block containing about 1MB of data, Bitcoin alone is not enough to serve billions of users. You need scalability solutions.
Significant work has been done on Bitcoin Layer 2s (Layer2 blockchains) to improve Bitcoin's scalability and introduce new features. Today, there are dozens of projects built on Bitcoin, with one of the most promising areas of research and innovation being Bitcoin Rollups. At a high level, Bitcoin Rollups enable transactions to occur off-chain and then "roll up" into a single state change submitted to the blockchain, all while having a cryptographic proof system so that participants can verify whether the submitted state change is accurate.
However, introducing this proof system to Bitcoin poses challenges, and that's where BitVM comes in.
What is BitVM?!
BitVM is a protocol/rule set that enables fraud proofs on Bitcoin, allowing developers to immediately use the protocol to implement various use cases on Bitcoin, including Bitcoin Rollups, minimal trust bridges, and more. The core design of BitVM moves computation off-chain and implements a fraud-proof mechanism on the Bitcoin blockchain.
BitVM enables fraud proofs on Bitcoin.
The BitVM whitepaper was released by Robin Linus in October 2023 (notably, Robin is a member of the ZeroSync team, which is dedicated to developing zero-knowledge proof systems for Bitcoin). Developers have been experimenting with the protocol in the past few months and are becoming increasingly interested.
You can think of BitVM as a distributed protocol/rule set that participants agree to follow beforehand, rather than an actual virtual machine implemented by software (such as the Ethereum Virtual Machine). Similar to how Bitcoin Ordinals work, there is a social consensus component here, where participants choose to adhere to the rules, and these rules are not fully enforced at the protocol level.
What makes BitVM so exciting is that it provides a challenge-response protocol for verifying arbitrary circuits on Bitcoin - you can make declarations off-chain (e.g., this proof is valid) and use Bitcoin L1 to verify. The key here is "on Bitcoin," because building on Bitcoin is very challenging, and if implemented, the BitVM protocol can be used to build optimistic Rollups, bi-directional BTC pegs, and more, benefiting other projects built on Bitcoin.
What problems does BitVM solve?
Anyone who has built projects on Bitcoin knows how challenging it is to interact with the chain (at Hiro, we've experienced this pain firsthand). One of the challenges of building on Bitcoin is that Bitcoin lacks the ability to handle complex computations.
There are no smart contracts. No virtual machine. Programmability is limited to what developers can build with opcodes (operation codes), and that functionality is limited. Introducing new opcodes requires BIPs and Bitcoin forks (which are very difficult).
So, without forks and new opcodes, we can only use limited programmability. In the context of extending Bitcoin, this limitation mainly manifests in two aspects:
If you want to build bi-directional BTC pegs, it's challenging to remove trust from the equation. Most BTC pegs today involve custodians, whether it's a single institution or a consortium controlling multisig, to handle deposits/withdrawals. This is sometimes described as the "write problem." In the Stacks ecosystem, the upcoming Nakamoto upgrade includes designs for minimal trust bridges - more on that later.
If you want to move computation or transactions off-chain via Rollup, it's challenging to validate and verify off-chain data on Bitcoin itself. This is a validation problem.
For both of these issues, BitVM can unlock dramatic design improvements by implementing a challenge/response protocol on Bitcoin L1.
How does BitVM work?
Thinking of BitVM as a protocol or set of rules is a good way to approach it. If two parties agree to follow these rules beforehand (meaning they need to cooperate), they can engage in an arbitrary challenge-response game. In theory, this can be used to verify/prove arbitrarily complex programs on Bitcoin (with the actual execution of these programs happening off-chain).
Let's look at a concrete example.
Suppose Alice and Bob want to play a coin-flipping game. Each player puts 0.5 BTC into the pot. Heads win 1 BTC. Alice holds the coin and will flip it first. Bob wants to ensure that Alice doesn't cheat. Here's how they use BitVM to play this game (many details are omitted for simplicity):
Alice and Bob agree to follow the BitVM protocol.
Suppose heads are represented by the value H0 and tails by the value H1. Alice generates H0 and H1 by hashing two other values, say P0 and P1, respectively. Thus, Hash(P0) = H0 and Hash(P1) = H1. P0 is called the "pre-image" of H0, and P1 is called the pre-image of H1.
Alice shares the values H0 and H1 with Bob (in actuality, Alice irrevocably "commits" to these hash values, so she cannot later claim different values). Bob does not know the pre-images P0 and P1 (and guessing these values is extremely difficult, so we can safely assume Bob won't magically discover them).
Alice and Bob pre-sign two transactions: one for challenging and one for responding.
In the challenge transaction, Bob includes a script that essentially checks if the provided input hashes to one of the known hash values H0 or H1 - if it hashes to H0, Bob knows it's heads; if it's H1, it's tails. Additionally, the script has a time lock, so if no response is received by the deadline, Bob gets the pot.
In the response transaction, Alice can "reveal" the coin flip result by including the corresponding pre-image P0 or P1. If Alice includes no value, includes both values, or includes any value other than P0 or P1, Bob gets the pot. Otherwise, if the value is P0 (heads), Alice gets the pot.
Now we're ready to start the game. Alice flips the coin but hasn't revealed the result yet. Bob issues the challenge transaction, and then Alice broadcasts the response transaction. The logic for "fraud detection" is executed on-chain, as described earlier. Clearly, this is a trivial and contrived example, but it illustrates the key idea. For a slightly more complex example, consider a Tic Tac Toe game designed by a developer named Super Testnet. You can check out the GitHub repository, and you can even play "bit tac toe" today. Super Testnet actually showcased this game to Hiro, and you can watch it below:
Following are the advanced components of the game:
Tic Tac Toe is a 9-cell grid. The first player, Alice, can make up to 5 moves, so there are 45 pre-images and hashes (9 each round). The second player, Bob, can make up to 4 moves, so there are 36 hashes.
There are 3
"cheating" ways in Tic Tac Toe: players can place multiple X/Os on their turn; players can cover squares they previously used; players can cover squares previously used by their opponent. Therefore, the challenge/response protocol revolves around detecting these scenarios.
The challenge transaction will force the other player to "reveal" where they placed X or O in a square.
The response transaction will have a script that checks for all 3 cheating scenarios: if no fraud is detected, the game continues (or ends because someone won). If fraud is detected, the challenger wins, and the prover fails.
Note that in both cases, fraud proofs are handcrafted and specifically designed for the use case: a Tic Tac Toe fraud proof doesn't work for a coin flip or anything else.
Returning to the big picture, the BitVM whitepaper describes a general approach: it provides a way to build validity proofs for any program. Key insights include:
From the coin flip example, we see how to verify a single bit: let's call it a "bit commitment" proof.
With bit commitments, we can build logic gate commitments: consider Boolean AND/OR operators - for any two inputs (each taking a value of 0 or 1), these operators define a single output. Therefore, using 2 bit commitments as input and 1 bit commitment as output, we can create a validity proof for any logic gate. The BitVM whitepaper uses a NAND logic gate.
Finally, any arbitrary computation can be represented using a series of logic gates. The BitVM whitepaper calls this a "binary circuit." Such circuits can be efficiently represented using Tapscript, with each leaf in the tap tree representing a single gate commitment.
Then, the challenge/response protocol essentially involves verifying the output of specific gate commitments. In the worst case, you may need to verify the output of each individual gate.
Check out this repository to see one way of converting any program into a tapleaf circuit.
How does Stacks fit in?
The two most obvious and relevant applications of BitVM in the Stacks ecosystem are:
Improving the trust assumption of sBTC
Adding validity proofs to Stacks blocks on Bitcoin
Why choose these two applications? The current design of sBTC is already one of the most secure and minimal trust bi-directional anchors being developed on Bitcoin. However, there is still room for improvement in the security model and trust assumptions. Unlike requiring at least 30% honest signers or trusting a set of high-reputation signers, an approach based on BitVM theoretically allows sBTC to operate with only one honest participant.
Similarly, while each Stacks block settles on Bitcoin, the current design only allows you to independently verify Stacks data when you have a copy of the chain state. If BitVM were used and Stacks blocks included validity proofs, then you could not only check integrity (given data in a Stacks block matches the hash stored on Bitcoin) but also check correctness (you can verify if transactions in a given Stacks block actually executed correctly by looking at the proof stored on Bitcoin). In other words: this would enable Stacks to evolve into an optimistic Rollup on Bitcoin.
The specific methods of leveraging BitVM to achieve these applications require more research and development. But we can attempt to outline some ideas at a high level.
BitVM and sBTC
Consider the example of sBTC: the anchoring process is straightforward, requiring only the broadcast of Bitcoin transactions. However, in the current design, the anchoring exit process depends on signers to process requests (on Stacks). This brings some constraints:
Exits may take time, depending on how many signers are offline/honest.
You need to trust this network of signers, and more broadly, trust the entire Stacks.
If switched to (or possibly in addition to) generating a validity proof on Bitcoin and using BitVM, then
Exits can be handled optimistically (thus, faster processing on the happy path).
The anchor only requires one honest participant to operate; you don't need to trust 30% of the signer network.
The key is to figure out exactly how to build validity proofs. The brute-force approach described in the BitVM whitepaper may work but could result in a very large tapleaf circuit (billions of nodes). This means any challenge will take a long time (possibly weeks or longer), not to mention the costs in attention and resources (transaction fees!). As we saw in the Tic Tac Toe example, more concise proofs can be constructed, custom-made for specific use cases, and similar approaches might be more effective for this situation.
BitVM and Stacks
As for the validity proof of the entire Stacks block, there are many design spaces worth exploring. For example, is the proof at the granularity of a single transaction, the entire block, or something in between (like transactions forming a causal dependency chain)? Is it possible to take a progressive approach, such as first generating proofs for simple token transfers and then gradually adding Clarity contracts? Is this a good use of Bitcoin block space, given that Stacks miners and network participants already have economic incentives to maintain the full history of the Stacks chain state?!
Conclusion
BitVM is an exciting topic that requires more research, thought, and experimentation than a blog post, but I hope this helps shed light on one of the most exciting recent developments in Bitcoin. |
|
Post time 4-5-2024 13:26:30
