BitVM: The Dawn of Bitcoin Programmability

Forward the Original Title‘IOSG Weekly Brief｜BitVM: 比特币可编程性的曙光 #220’

TL;DR:

• Changes to Bitcoin Core are often met with resistance for reasons including: a) People prefer Bitcoin as a store of value rather than as a currency. b) Value stability and predictability over rapid innovation. c) Building consensus within a diverse community is difficult.
• Many projects claim to have ways to solve Bitcoin’s scalability issues without requiring changes to the Bitcoin chain itself. Recently we have witnessed hyperinflation in Bitcoin “L2s”.
  • While many of the claims were simply misleading marketing, we also recognized a new computing paradigm that could bring programmability to Bitcoin – BitVM.
• The best scaling solution that BitVM can support is close to OP-Rollup type security assumptions (albeit with some additional considerations).
• The success of BitVM and similar initiatives depends on technical feasibility, community support, and differentiation from other “over-marketing” projects.

Bitcoin is built as a transactional blockchain, and its scripting language is intentionally stateless to minimize the attack surface and ensure network security. Due to the lack of Turing-completeness, it is not possible to directly introduce smart contracts on the blockchain, except by forking and upgrading Bitcoin Core. The traditional Bitcoin community has been 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 intentionally focused on maintaining the network as a peer-to-peer payment system, prioritizing security and decentralization over rapid growth. As Michael Saylor, a prominent bitcoin holder, said, “No one is trying to buy a cup of coffee with a fraction of what they have in a building on Fifth Avenue.” This quote reflects the community’s preference for the use of Bitcoin as a store of value rather than an everyday currency.
  • Stability of the system trumps innovation: predictability is crucial for an asset that is seen as an excellent store of value. For example, even if there are only 10 major upgrades to the network, and each upgrade has a 90% success rate, the probability of a failure occurring is about 65%! According to Normal Accident Theory: “In complex systems, we should expect that small factors that can usually be ignored will occasionally lead to major events by chance,” so the goal of the Bitcoin community has always been to reduce the number of ways in which potential errors can occur.
• 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, further slowing the pace of innovation. To illustrate the diversity of the Bitcoin community, look at the community’s reaction to Inscriptions and Ordinals. While one part of the Bitcoin community celebrates the success of ordinal numbers as Bitcoin’s CryptoKitties moment, another part of the community believes it’s a vulnerability that should be patched.

1. The Rapid Expansion of Bitcoin’s Scaling Solutions

Given the above, why are there suddenly a plethora of new “L2” solutions for Bitcoin? Recently, we have observed a proliferation of Bitcoin “L2” solutions (already over 50 according to https://l2.watch/!), however, the community has been exploring different scalability methods for years:

1. Sidechains like Stacks offer smart contract capabilities and a wide range of applications, and although they have independent consensus mechanisms, these have struggled to gain widespread acceptance.
2. Client-side verification projects like RGB utilize the mainnet’s UTXO model for more complex transactions off-chain, but their interaction with the Bitcoin mainnet lacks stability.
3. State channels like the Lightning Network, which are closely associated with core Bitcoin developers, are seen as a more orthodox scaling method.

The first generation BTC expansion solution

What novelties do recent scaling methods bring compared to existing solutions? In our opinion, the most exciting innovations come from coding programs on top of Bitcoin (via BitVM) and trustless staking BTC (e.g. Babylon). This article will focus primarily on the former.

2. BitVM - An Overview

To explain what BitVM is, we should first introduce the Primitive that empowered and inspired it - the Bitcoin Taproot upgrade.Taproot is a major upgrade to the Bitcoin protocol, activated in November 2021.Taproot is the first major upgrade to the Bitcoin protocol. With Taproot, a script’s hash needs to be submitted on the chain by default. When executing a path of a script, only the scripts on that path need to be committed 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 that is the transaction is revealed, not the entire script). Recognizing the tremendous opportunity unlocked by the Taproot upgrade, Robin Linus spearheaded 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 altering the network’s consensus rules. It allows computations to be verified (rather than executed), similar to Optimistic Rollups.BitVM minimizes the on-chain footprint by submitting programs to Taproot addresses while enabling complex off-chain computations (which require on-chain execution only in the event of a dispute). This process involves submitting the program’s binary circuitry in the Taproot address and verifying it using a challenge-response mechanism. To summarize, 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 calculations are not performed on Bitcoin, but only verified using the Bitcoin network in the event of a Dispute.

Building binary circuits on Bitcoin

The construction of binary circuits is a method of representing calculations or programs in terms of binary logic gates (e.g., AND, OR, NOT) capable of executing any computable function.BitVM is like a complex analog of the passage of electric current through the logic gates of a computer chip (the tiny structures that determine whether or not a signal passes through them based on whether or not the current is present, i.e., on or off, open or closed), translated into the language of Bitcoin. Essentially, any computer program, from games to the full Linux operating system, is the result of a complex arrangement of these logic gates, and all things digital are essentially based on binary digits - 0s and 1s.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 basic technology allows us to write and execute programs to perform a wide range of tasks.

Source: Stepping Through Logic Gates; Basic logic gates (F represents 0, T represents 1)The premise of BitVM is to use Bitcoin Script to make commitments to off-chain computations (submitting a hash of a computation to the Taproot address) by deconstructing any program into a combination of binary circuits and enabling execution validation, a process that includes Bitcoin Script, but the script itself does not perform the entire computational logic. Bitcoin scripting enables bit-value commitments, which are critical to being able to demonstrate and punish ambiguous (Equivocation) behavior. It implements immutability because it allows individuals to submit values that no one else can modify. This approach involves the use of two hashes to represent each input bit: one hash for the number 0 and another for the number 1. When someone wishes to execute the 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 pre-image to the two hashes representing 0 and 1. If the input and output do not match, the verifier has the right to penalize the provider by confiscating the provider’s funds.

challenge-response mechanism

Challenge-Response Mechanisms

Verification is usually performed off-chain, with the optimistic assumption that the provers are honest. In the event of a dispute, the process is transferred to the chain and a challenge-response round is initiated. This mechanism ensures that in most cases, computation and validation can be performed efficiently and cost-effectively, and only in the event of a disagreement is it necessary to utilize the blockchain’s immutability and transparency for a final ruling. The dynamics of the challenge-response mechanism in BitVM involves a system in which participants (e.g., Vicky and Paul) conduct the verification process through the execution of programs on the blockchain. When a dispute arises, Vicky challenges Paul to prove the correctness of his program execution.Vicky selects a logic gate from a binary circuit, which Paul opens by revealing inputs and outputs.

This process is repeated until ambiguity is confirmed or Vicky exhausts the possibility of further challenges. Ambiguity means that Paul claims that a certain input X is 0 when one logic gate is opened, but 1 when another logic gate is opened.Paul needs to secure proof of his claim by depositing funds to the response address using pre-signed transactions. These transactions create a chain that allows funds to swing between the challenge and response addresses based on the ongoing interaction. 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 the funds after a certain period of time.
• If Vicky proves that Paul was inconsistent in his execution (equivocation occurred), she can claim those funds.
• If Vicky suspects that another part of the execution is incorrect, she can initiate another challenge to move the funds to the next responding address. To do so, she must reveal an original image of a specific tapleaf, which Paul then needs to use to unlock the funds and prove his correctness within a limited time frame.

This system provides a robust and transparent architecture for resolving disputes and verifying program execution on the blockchain. By incorporating financial incentives, it promotes the integrity and accuracy of execution and documentation of program results. Initially, the design supports a two-party challenge-response mechanism. However, as we will show later, BitVM contributors have found solutions that allow numerous participants to engage as challengers.

Bisection: Improving the Efficiency of Dispute Resolution

To improve the efficiency of on-chain verification, verifiers can utilize Bisection, an efficient search over pre-submitted logic gates to find the logic gates that should be challenged, which is a significant improvement over the random challenge process. By dividing the problem space in two, the Bisection method allows the verifier to quickly narrow down the scope of potential errors, thus reducing the number of steps and time required to resolve disputes. This approach provides a more efficient and direct path when dealing with complex verification processes, especially when the location of errors needs to be pinpointed. Below, we illustrate how the segmentation method works with a simplified example: Paul and Vicky are working on a math problem that involves calculating ((1+2)+(3+4))+((5+6)+(7+8)). The correct way to complete this calculation is ((1+2)+(3+4))+((5+6)+(7+8)) = (3+7)+(11+15) = 10+26 = 36. and Paul gives an answer of 35 because he calculates it in a way that ((1+2)+(3+4))+((5+6)+(7+8)) = (2+7)+(11+15) = 9 + 26 = 35. 26 = 35.When Vicky challenges Paul, she only needs to challenge the first part of the calculation involving the computation (i.e., opening the logic gates) because they agree that the second part of the calculation is accurate ((5+6)+(7+8)) = 26.

1. Use BitVM to Build a Trust-Minimized Bridge

The first practical implementation of BitVM is likely to be a program that represents a Trust-Minimized Bitcoin Bridge. By analyzing the implementation details of the bridge, we can better understand the additional complexity of implementing a BitVM program. Below, we summarize the proposal of BoB co-founder Alexei Zamyatin. First, there is a need to create a way for Bitcoin-wide nodes to operate a sidechain bridge program using only Bitcoin scripts, including a sidechain light client. Then, a federation/multi-signature (federation/multi-sig) network also needs to be created to facilitate the transfer of BTC and run a challenge-response game. The federation must commit to running a bridge program as part of the BitVM setup. The complexity of the initial coalition setup grows quadratically with the number of members, as each member of the coalition must interact with every other member, so there is an upper limit to the size of the coalition, which the researchers hypothesize

that N=100 is feasible.

Unlike OP Rollup, which has no limit on the size of N, this scheme provides weaker security guarantees. However, a working solution to this proposal would likely include a rotation of coalition members so that over a longer time horizon, N would be much larger than 100. at any given time, as long as one of those 100 members is honest, the deposit would remain secure. Assuming there are malicious actors, they can be challenged at any time on the chain, and if proven to be cheating, they can be banned from the alliance.

At any given time, the affiliate has an Operator who is responsible for managing deposits and withdrawals as well as verifying the status of the sidechain. Both Operators and Watchtowers (Watchtowers) are required to submit collateral to incentivize correct behavior and discourage false challenges.

Another reason why this scheme does not meet the strictest definition of convolution is that users cannot unilaterally withdraw from the sidechain, but must request withdrawals from a federation that operates under the 1/N security assumption.

4. BitVM v2: Can BitVM support permissionless verification (Permissionless Verification)?

On March 25, Robin Linus presented BitVM v2. The key change in the BitVM v2 proposal is that the prover would need to submit the output state and all intermediate results at once, rather than opening the logical gates one by one during the challenge-verification process as was the case in v1. With this change, BitVM ensures that any challenge to these promises must be supported by cryptographic evidence. This mechanism filters out unsubstantiated spam challenges, as the challenger must provide a specific cryptographic proof to dispute the prover. By allowing unrestricted participation in the verification and challenge process, BitVM 2 extends its security guarantees beyond the limits of multisignature coalitions and brings BitVM closer to the security assumptions of optimistic convolution. However, bridge building still requires federated multi signatures to facilitate, which means that federated members could cause active problems and, in the worst case scenario, attempt to extort ransom from users to unfreeze their funds. This is an additional security assumption that does not exist for optimistic convolutions, where users can exit to L1 without any intermediary approval.

Additional security assumptions on the base chain

5. Limitations of BitVM

As we discussed above, the best BitVM can offer is to approach the safety assumption of optimistic convolution. In addition to the complexity of managing the consortium responsible for insuring deposits and its liveness issues, some additional complexities unique to BitVM include:

• While BitVM is theoretically capable of executing complex off-chain programs, in practice, as the complexity of these off-chain programs increases, the fees associated with executing fraud proofs on Bitcoin rapidly increase. Overly large programs may require multiple blocks to execute, further complicating the process.
• Mining pools with a hashrate majority can steal from BitVM (similar to the problem with the Lightning Network) because they can collude to censor challenger proofs, or malicious actors can bribe them to ignore challengers.
• Due to the interactive nature of BitVM proofs, malicious provers may manipulate the system and steal from validators. The attack can be constructed based on the following assumptions:

    * The prover starts the verification sequence by initiating a transaction
    * A verifier who doubts the validity of a prover's actions initiates a challenge that includes a response fee paid to the prover
    * The prover chooses to collect fees while ignoring the challenge and not fulfilling their part in the verification process
  

• In the end, 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. Optimistic estimates are that we may see some BitVM programs put into use as early as 2025. The technical risks of implementing BitVM cannot be underestimated either.

6 Conclusion

Considering the valuation of Ethereum scaling solutions, which currently accounts for approximately 15-20% of Ethereum’s market capitalization – the potential market capitalization of Bitcoin’s second layer solutions could be huge. Although BitVM is still in its infancy - essentially an unfinished virtual computer concept - it has already sparked a lot of interest and announcements from various projects eager to take advantage of its potential. Many projects not affiliated with the BitVM team are scrambling to make grand announcements in hopes of carving out a niche in what they see as a promising new frontier for Bitcoin. However, closer examination reveals a more sobering reality: BitVM’s GitHub account has only a few contributors, and only a few Bitcoin ‘L2’ projects are actually participating in the BitVM Builders Telegram group.A key principle that any scalability solution for Bitcoin must adhere to is that Bitcoin’s core architecture should remain unchanged (according to the Predictability Principle). BitVM adheres to this principle and becomes 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 convolutions on Bitcoin seemed like a castle in the air because the required underlying capabilities—such as Bitcoin’s ability to verify ZK proofs—did not exist. However, recently BitVM researchersShared progress on Bitcoin Script, these developments could lead to the implementation of STARK validators on Bitcoin. Implementing a Bitcoin scaling solution goes beyond purely technical challenges; it encompasses factors such as community support, user experience, and timing. While the current moment offers a unique window of opportunity for these innovations, rapid inflation in the number of projects and the significant risks posed by misleading claims and marketing could undermine the prospects for more legitimate projects. As the ecosystem stands at this crossroads, the question about 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, while the same can’t be said for the Bitcoin community yet.

Disclaimer：

1. This article is reprinted from [IOSG Ventures]. *Forward the Original Title‘IOSG Weekly Brief｜BitVM: 比特币可编程性的曙光 #220’. All copyrights belong to the original author . If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.