Forward the Original Title‘IOSG Weekly Brief|BitVM: 比特币可编程性的曙光 #220’
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:
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:
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.
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:
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 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::
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.
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.
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.
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
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:
* 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
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.