IOSG Ventures: BitVM – The Dawn of Bitcoin's Programmability

原文作者： IOSG Ventures

原文来源： IOSG Ventures

TL; DR:

• Changes to Bitcoin Core are often resisted for a number of reasons: a) People prefer Bitcoin as a store of value rather than as a currency. b) Valuing stability and predictability over rapid innovation. c) Consensus is difficult within a diverse community.
• Many projects claim to have a way around Bitcoin's scalability and without the need to make changes to the Bitcoin chain itself. Recently we have witnessed the superinflation of Bitcoin's "L2s".
• While many of the claims are merely misleading marketing, we also recognize a new computing paradigm that could bring programmability to Bitcoin – BitVM.
• The optimal scaling solution that BitVM is able to support is close to the security assumptions of the OP-Rollup type (although there are some additional caveats).
• The success of BitVM and similar initiatives depends on the viability of the technology, the support of the community, and differentiation from other "over-marketing" projects.

Bitcoin is built as a transactional blockchain with a scripting language that is intentionally limited to stateless to minimize the attack surface and ensure network security. Due to the lack of Turing-completeness, it is not possible to introduce smart contracts directly on the blockchain except by forking and upgrading Bitcoin Core. The traditional Bitcoin community is resistant to change for the following reasons:

• The narrative is more focused on a store of value than a currency in circulation: The Bitcoin community is deliberately focused on maintaining the network as a peer-to-peer payment system, prioritizing security and decentralization over rapid development. As Michael Saylor, a well-known Bitcoin holder, said, "No one is trying to buy a cup of coffee with a fraction of what they do in a building on Fifth Avenue." This quote reflects the community's preference for Bitcoin as a store of value rather than everyday money.
• System stability over innovation: Predictability is critical for assets that are considered excellent stores of value. For example, even if the network has only 10 major upgrades, and each upgrade has a 90% success rate, the probability of a failure occurring is about 65%! According to the normal accident theory: "In a complex system, we should expect small factors that are normally negligible to occasionally lead to major incidents by accident", so the goal of the Bitcoin community has always been the path to reduce potential errors.
• Diverse Community: Many Bitcoin holders understand Bitcoin from different perspectives and value it for different reasons. Reaching consensus in a diverse and decentralized community is inherently challenging, which further slows down the pace of innovation. To illustrate the diversity of the Bitcoin community, one can observe how the community reacts to the inscriptions and Ordinals. While one part of the Bitcoin community celebrates Ordinal's success as Bitcoin's CryptoKitties moment, another sees it as a vulnerability that should be patched.

1. The rapid expansion of Bitcoin's scaling scheme

Recently, we've observed a proliferation of Bitcoin "L2" solutions (there are already more than 50!, according to https://l2.watch/), and yet, the community has been exploring different approaches to scalability for years:

1. Sidechains like Stacks offer smart contract capabilities and a wide range of applications, which are difficult to gain widespread acceptance for, despite their independent consensus mechanisms.
2. Client-side validation projects like RGB utilize Mainnet's UTXO model for more complex off-chain transactions, but their interaction with the Bitcoin mainnet lacks stability.
3. State channels like the Lightning Network, which are closely related to core Bitcoin developers, are seen as a more orthodox approach to scaling.

The first generation of BTC scaling solutions

In our opinion, the most exciting innovations come from encoding programs on Bitcoin (via BitVM) and trustless staking of BTC (e.g. Babylon). This article will focus primarily on the former.

2. Bitwam - 概览

To explain what BitVM is, we should first introduce the primitive that enabled and inspired it - the Bitcoin Taproot upgrade. Taproot is a major upgrade to the Bitcoin protocol, activated in November 2021. With Taproot, the hash of the script needs to be submitted on-chain by default. When a certain path of a script is executed, simply submit the script on that path to the chain. This not only improves efficiency (the size of the transaction does not grow with the size of the script), but also enhances privacy (only the path of the transaction is revealed, not the entire script). Recognizing the tremendous opportunity unlocked by the Taproot upgrade, Robin Linus spearheaded the launch of BitVM, a groundbreaking innovation in the Bitcoin ecosystem. BitVM is a computational paradigm that leverages the Taproot upgrade to facilitate the implementation of Turing-complete contracts on Bitcoin without changing the consensus rules of the network. It allows computations to be validated (rather than executed), similar to Optimistic Rollups. BitVM minimizes the on-chain footprint by submitting the program to a Taproot address while enabling complex off-chain computations that only require on-chain execution in the event of a dispute. This process involves submitting the program's binary circuit in a Taproot address and verifying it using a challenge-response mechanism. In a nutshell, BitVM implements Turing-complete Bitcoin contracts, most importantly:

• BitVM does not require a fork or any changes to the Bitcoin protocol.
• BitVM does not congest the Bitcoin blockchain because computations are not performed on Bitcoin, but are only verified using the Bitcoin network in the event of a dispute.

Build binary circuits on Bitcoin

Binary circuits are constructed as a method of representing computations or programs with binary logic gates (e.g., AND, OR, NOT) capable of executing any computable function. BitVM is like a complex simulation of the logic gates of an electric current passing through a computer chip (tiny structures that determine whether a signal passes through or not, i.e., on or off, on or off, on or off, depending on the presence or absence of the current), into the language of Bitcoin. Essentially, any computer program, from a game to a full Linux operating system, is the result of a complex arrangement of these logic gates, and all digital things are basically based on binary numbers – 0 and 1. By combining these binary digits with logic gates such as AND and NOT gates, we create a variety of circuits, including arithmetic logic units (ALUs) and memory systems. This foundational technology allows us to write and execute programs to perform a wide range of tasks.

Source: Stepping Through Logic Gates; The premise of the basic logic gate (F for 0, T for 1) BitVM is to use Bitcoin Script to commit to off-chain computation (submitting a hash of the computation to the Taproot address), by decomposing any program into a combination of binary circuits, and enabling execution verification, which includes Bitcoin Script, but the script itself does not execute the entire computation logic. Bitcoin Script implements bit-value commitments, which are essential for being able to demonstrate and punish ambiguous behavior. It implements immutability because it allows individuals to submit values that others can't modify. This method involves the use of two hashes to represent each input bit: one for the number 0 and the other for the number 1. When someone wishes to execute a program, they reveal a pre-image to indicate the input. Whether the value will be converted to 0 or 1 is determined by comparing the hash of the preimage with two hashes representing 0 and 1. If the inputs and outputs do not match, the validator has the right to penalize the provider by confiscating the provider's funds.

Challenge-response mechanism

Verification usually takes place off-chain, optimistically assuming that the prover is honest. In the event of a dispute, the process is transferred on-chain and a round of challenge-response is initiated. This mechanism ensures that in most cases, computation and verification can be carried out efficiently and cost-effectively, and that the immutability and transparency of the blockchain are only needed to make a final decision when disagreements arise. The dynamics of the challenge-response mechanism in BitVM involves a system where participants (such as Vicky and Paul) go through the process of verification through the execution of programs on the blockchain. When controversy arises, Vicky challenges Paul to prove the correctness of his procedure. Vicky selects a logic gate from the binary circuit, which Paul opens by revealing the inputs and outputs. This process is repeated until the ambiguity is confirmed or Vicky has exhausted the possibility of further challenges. Ambiguity means that Paul claims that an input X is 0 when one gate is opened, but 1 when another gate is opened. Paul needs to secure the evidence he claims by depositing funds to the response address using a pre-signed transaction. These transactions create a chain that allows funds to swing between the challenge and response addresses based on ongoing interactions. The funds in the response address can flow along multiple paths depending on the outcome of the challenge:

• If Vicky stops the challenge, indicating acceptance of Paul's proof, Paul eventually regains funding after a certain amount of time.
• If Vicky proves that Paul was inconsistent in execution (an ambiguity occurred), she can claim the funds.
• If Vicky suspects that another part of the execution is wrong, she can launch another challenge to move the funds to the next response address. To do this, she must reveal a preimage of a specific tapleaf, which Paul then needs to use to unlock funds and prove him right within a limited amount of time.

This system provides a robust and transparent framework for resolving disputes and verifying the execution of procedures on the blockchain. By incorporating financial incentives, it promotes the completeness and precision of the execution and recording of procedural results. Initially, the design supported a two-party challenge-response mechanism. However, as we'll show later, BitVM contributors have found a solution that allows numerous participants to participate as challengers.

Bisection: Improving the efficiency of dispute resolution

To improve the efficiency of on-chain validation, validators can utilize the bisection, which is an efficient way to search on pre-submitted logic gates to find the gates that should be challenged, which is a significant improvement over the random challenge process. By splitting the problem space in two, the segmentation method allows validators to quickly narrow down the scope of potential errors, reducing the steps and time required to resolve disputes. This approach provides a more efficient and straightforward path when dealing with complex verification processes, especially when the location of errors needs to be precisely determined. Let's take a simplified example to illustrate how partitioning works: Paul and Vicky are working on a math problem with the problem of computing ((1+2)+(3+4))+((5+6)+(7+8)). The process of doing this calculation correctly is ((1+2)+(3+4))+((5+6)+(7+8)) = (3+7)+(11+15) = 10+26 = 36. Paul's answer is 35 because he calculates it as ((1+2)+(3+4))+((5+6)+(7+8)) = (2+7)+(11+15) = 9+26 = 35. When Vicky challenged Paul, she only had to challenge the computation that involved the first part of the computation (i.e. open the logic gate) because they agreed that the second part of the computation was exact ((5+6)+(7+8)) = 26.

3. Build a Trust-Minimized Bridge with BitVM

The first actual implementation of BitVM is likely to be a program that represents the least-trust Bitcoin Bridge. By analyzing the implementation details of the bridge, we can better understand the additional complexity of implementing the BitVM program. Below, we summarize the proposal of Alexei Zamyatin, co-founder of BoB. First, you need to create a way for Bitcoin full nodes to operate a sidechain bridge using only Bitcoin Script, including a sidechain light client. Then, a federation/multi-sig network will need to be set up to facilitate the transfer of BTC and run a challenge-response game. The consortium must commit to running the bridge as part of the BitVM setup. The complexity of the initial setup of the alliance grows quadratically as the number of members increases, as each member of the alliance must interact with every other member, so there is a certain upper limit to the size of the alliance, and the researchers speculate that N=100 is feasible.

Unlike OP Rollup, which has no limit on the size of N, this scheme provides weaker security guarantees. However, this proposed working solution will most likely include a rotation of alliance members, so that N will be much greater than 100 over a longer time frame. At all times, as long as one of these 100 members is honest, the deposit will remain safe. Assuming there are malicious actors, they can be challenged at any time on-chain, and if proven cheating, they can be banned by the consortium.

The alliance has an Operators who are responsible for managing deposits and withdrawals and verifying the status of the sidechain at all times. Both operators and watchtowers are required to submit collateral to incentivize the right behavior and discourage fake challenges.

Another reason why this scheme does not meet the strictest definition of convolution is that users cannot unilaterally exit the sidechain and must instead request a withdrawal from a consortium that operates on the 1/N security assumption.

4. BitVM v2:BitVM能支持无需许可的验证(Permisionless Verification)吗?

On March 25th, Robin Linus introduced BitVM v2. The key change in the BitVM v2 proposal is that the prover needs to submit the output state and all intermediate results all at once, rather than opening the logic gates one by one during the challenge-verification process, as in v1. With this change, BitVM ensures that any challenge to these commitments must be backed up by cryptographic evidence. This mechanism filters out unfounded garbage challenges, as the challenger must provide a specific cryptographic proof to dispute the prover. By allowing unlimited participation in the verification and challenge process, BitVM 2 extends its security assurances beyond the limits of multisig federations and brings BitVM closer to the security assumptions of optimistic convolution. However, the construction of the bridge still requires a coalition multisig to facilitate it, which means that coalition members can cause liveness issues, and in the worst-case scenario, they try to extort ransom from users to unfreeze their funds. This is an additional safety assumption that does not exist for optimistic convolution, because in optimistic convolution, the user can exit to L1 without any intermediary approval.

Additional security assumptions on the underlying chain

5. Limitations of BitVM

As we discussed above, the best solution that BitVM can offer is a security assumption that is close to optimistic convolution. In addition to the complexities of managing the federation responsible for insuring deposits and the issues of their activism, some additional complexities unique to BitVM include:

• While BitVM is theoretically capable of executing complex off-chain procedures, in practice, the fees associated with executing fraud proofs on Bitcoin increase rapidly as the complexity of these off-chain procedures increases. Excessively large programs may require multiple chunks to execute, further complicating the process.
• Mining pools with the most hash power can steal from BitVM (similar to the Lightning Network's problem) because they can collude to review the challenger's proof, or malicious actors can bribe them to ignore the challenger.
• Due to the interactive nature of BitVM proofs, malicious procers can manipulate the system and steal from validators. An attack can be constructed with the following assumptions:
• The prover begins the verification sequence by initiating the transaction
• Validators who doubt the validity of the prover's actions initiate a challenge that includes a response fee paid to the prover
• Procertors choose to collect fees while ignoring the challenge and not fulfilling part of their responsibility for the verification process
• Finally, BitVM is currently a conceptual framework and a virtual computer concept that can do almost nothing. BitVM's "convolution" is still far from the application level, and the optimistic estimate is that we may see some BitVM programs put into use as early as 2025. The technical risks of executing BitVM should not be underestimated.

6. Conclusion

Considering the valuation of Ethereum's scaling solutions, which currently account for around 15-20% of Ethereum's market capitalization – the potential market cap of Bitcoin's layer-2 solutions could be huge. Although BitVM is still in its early stages – essentially an unlanded virtual computer concept – it has already sparked a lot of interest and statements from various projects that are eager to capitalize on its potential. Many projects unrelated to the BitVM team are scrambling to make grand announcements, hoping to take their place in what they see as a promising new area of Bitcoin.

However, closer scrutiny reveals a more sober reality: BitVM's GitHub account has only a handful of contributors, and only a handful of Bitcoin 'L2' projects are actually involved in the BitVM Builders Telegram group. A key principle that any Bitcoin scalability solution must adhere to is that Bitcoin's core architecture should remain the same (according to the principle of predictability). Adhering to this principle, BitVM became the first pioneer solution to provide a programmable layer on top of Bitcoin without changing its core. This article was written in the very early stages of BitVM's development, and given its rapid development, the information here may quickly become outdated. For example, until recently, the idea of implementing ZK convolution on Bitcoin seemed as impractical because the foundational capabilities required – such as Bitcoin's ability to verify ZK proofs – did not exist. Recently, however, BitVM researchers shared the progress of Bitcoin Script, which could lead to the implementation of the STARK validator on Bitcoin. The implementation of a Bitcoin scaling solution goes beyond purely technical challenges and includes factors such as community support, user experience, and timing. While the current moment presents a unique window of opportunity for these innovations, the rapid inflation of project numbers and the significant risks posed by misleading claims and marketing could undermine the prospects for more legitimate projects. With the ecosystem at this crossroads, the question of whether Bitcoin scaling solutions can replicate Ethereum's success is not only technical, but deeply rooted in the broader dynamics of the blockchain community. After all, the core Ethereum community has chosen L2 as a key part of Ethereum's scaling roadmap, and the Bitcoin community can't say the same yet.