BitVM: Revolutionizing Bitcoin with Virtual Machine Technology
For numerous years, Bitcoin has maintained its position as the leading cryptocurrency. However, it has lagged behind other protocols when it comes to handling intricate and Turing-complete smart contracts.
Published by Bitcoin developer Robin Linus, the white paper entitled «BitVM: Compute Anything on Bitcoin» has attracted a lot of attention not only in the crypto community, but also beyond. By using the functions available after the Taproot update, verification of any complex smart contracts, that is, special conditions for issuing a certain amount of BTC, should be ensured. The peculiarity is that there is no need to change the consensus rules through a hard or soft fork. More complex calculations themselves do not occur directly on the Bitcoin network. Only a claim about the result of this complex calculation can be verifiably challenged online based on pre-agreed conditions.
This proposal holds tremendous promise for Bitcoin’s application development and network scalability. BitVM has the potential to enable almost any form of arbitrary computation on the Bitcoin platform.
Nevertheless, @super_testnet, a prominent contributor to BitVM and reportedly instrumental in creating the initial proof-of-concept version, emphasizes that the primary focus of BitVM is scaling Bitcoin, rather than incorporating decentralized finance (DeFi) applications like Ethereum.
Interestingly, BitVM achieves its objectives without necessitating modifications to the Bitcoin consensus. Instead, it relocates all computational logic outside the blockchain, while still allowing certain on-chain computational steps to be disputed in order to resolve contentious situations.
Regardless of the authors’ stated intent, BitVM effectively facilitates Turing-complete computing on Bitcoin today. But how does it accomplish this? Let’s delve into the details.
Turing completeness
A concept that is often widely used is that of «Turing completeness» or «Turing strength», which makes a statement about the power of a computer system or, in general, a language. Modern «general» programming languages such as C++, Java or Python are considered Turing complete. It is possible to carry out in these languages all the calculations that a Turing machine or any computer can perform. How easy this actually is is another question, but at least in theory these languages are powerful enough to do this. However, this is not the case for a small specialized language: Bitcoin Script. All outputs on the cryptocurrency network are powered by a small program whose output decides whether the corresponding BTC can be spent or not. Here they deliberately rely on a very limited set of commands and limited storage space so that network participants are not subject to utopian complex and time-consuming transaction verifications. BitVM will not change anything about this, since it will be used anywhere, primarily outside the Bitcoin network.
Understanding BitVM
BitVM, short for «Bitcoin Virtual Machine», can be envisioned as a secure sandbox seamlessly integrated into the Bitcoin ecosystem. Within this virtualized environment, users can interact with various computational programs and execute any desired smart contracts. However, instead of directly performing these computations on the blockchain, which can be costly and time-consuming, BitVM merely verifies their authenticity. It functions as a virtual testing laboratory, enabling program behavior simulation and result confirmation without burdening the main Bitcoin network. In most cases, it achieves this without requiring any modifications to the network, apart from recording the execution results through a transaction.
As an intermediary layer, BitVM enhances efficiency without imposing additional computational burdens on the Bitcoin blockchain. This feature proves particularly advantageous for operations involving intricate computations or smart contracts, as it enables their off-chain validation prior to irreversible on-chain actions. Consequently, this system plays a crucial role in preserving the integrity of the blockchain while furnishing a secure platform for executing complex operations.
Similar to the Ethereum Virtual Machine (EVM), BitVM provides support for smart contracts, but it distinguishes itself from the EVM and comparable systems in terms of approach and capabilities. While the EVM offers greater versatility in accommodating multi-party contracts and encompasses a broader range of computational tasks directly on the blockchain, it does so at the expense of escalated costs, often leading to network congestion and excessive blockchain expansion.
In contrast, BitVM primarily concentrates on two-party contracts and conducts the majority of computational tasks off-chain, resulting in a minimal impact on the main blockchain and a consequent reduction in average transaction costs. However, the current design of BitVM limits its applicability in complex multi-party systems, unlike the original intention of the Ethereum VM, which does not incorporate such constraints.
Explaining BitVM’s Functionality
In the realm of Bitcoin, it’s widely recognized that the spending rules for «coins» are determined by specific software expressions (scripts) assigned to each Unspent Transaction Output (UTXO). To access bitcoins associated with a script, the conditions outlined in the script must be satisfied. For instance, a script might include a public key, allowing execution only if the transaction is signed using the corresponding private key. To establish consensus, scripts need to adhere to Bitcoin’s scripting language, Script, which intentionally restricts flexibility to ensure security.
Linus proposed an ingenious solution to overcome some of these limitations by introducing a straightforward yet powerful architecture that involves two primary participants: the Prover and the Verifier. The Prover initiates computations or assertions, essentially stating, «Here is a program, and I affirm that its execution will yield this specific result». The Verifier, on the other hand, assumes the responsibility of verifying this claim. This two-role system establishes checks and balances for both participants, ensuring the accuracy and reliability of computation results.
What sets BitVM apart is its approach to handling computational loads. Unlike conventional blockchain operations, which impose significant computational burdens, BitVM conducts most complex computations off-chain, thereby significantly reducing the volume of data that needs to be directly stored on the blockchain. This approach enhances efficiency and reduces costs. The off-chain methodology also provides improved speed and overall system flexibility, as developers and users can run intricate programs or simulations without concerns over blockchain bloat.
Nevertheless, BitVM employs on-chain verification when deemed necessary, particularly in the case of disputes between participants. If the Verifier questions the truthfulness of the Prover’s claim, the system refers to the immutable decentralized ledger, the Bitcoin blockchain, for resolution. This is accomplished through the use of fraud proofs, which serve as evidence of fraudulent behavior.
Should the Verifier prove the Prover’s claim to be false, they can submit a concise fraud proof to the blockchain, thereby exposing the falsehood of the Prover’s assertion. This not only resolves the dispute but also upholds the overall integrity of the system. By combining off-chain computations with on-chain verification, BitVM strikes a balance between efficient computations and robust security.
As mentioned in the whitepaper, BitVM contracts bear resemblance to Optimistic Rollups in Ethereum. Optimistic Rollups represent layer-two scaling solutions that enhance computational efficiency and data storage by conducting most operations off-chain while maintaining the same level of security as on-chain transactions. The core concept is to consider all transactions correct (hence the term “optimistic”) unless proven otherwise. Only when a disputed situation arises, the corresponding data and computations are published and verified on the primary blockchain. This approach significantly reduces the data volume necessitating storage on the blockchain, thereby freeing up space and reducing transaction fees.
Optimistic Rollups can prove particularly advantageous within the BitVM framework. When a transaction is initiated, BitVM can leverage Optimistic Rollups to consolidate multiple off-chain transactions into a single on-chain transaction, further minimizing the footprint on the primary blockchain.
Furthermore, in situations of dispute, the use of fraud proofs in BitVM aligns well with the «challenge-response» mechanism inherent in Optimistic Rollups. If the Prover makes a false claim, the Verifier can promptly expose it by presenting a concise fraud proof. This proof of fraud is subsequently verified using the Optimistic Rollups scheme, and upon confirmation, the guilty party faces appropriate consequences.
To truly understand the mechanisms underlying the BitVM proposal, it is necessary to delve into the physical and logical foundations of computer computations.
It is widely known that “under the hood,” all computer operations are essentially the processing of sequences of zeros and ones. But what exactly does that mean, and how does it work? Each computer chip fundamentally consists of millions or billions of individual components called logic gates.
These elementary devices take in one or two bits of information — 1 or 0 — and perform a simple logical operation on them, resulting in an output of either 1 or 0, which is then passed to the next logic gate.
There are numerous types of logic gates, some of which simply take in one bit and output the same value they received (buffer gate). Others take in one bit and output the opposite value (inverter gate). Some take in two bits and output 1 only if both inputs are 1, with any other combination resulting in 0 (AND gate). Finally, there are gates that take in two bits and output 0 if both inputs are 1 and 1 for all other combinations (NAND gate).
The NAND gate is interesting because it can be used to construct any other type of logic gate. While it may not be as efficient as using a specialized gate, it can still fulfill the task. This means that with NAND gates, one can build circuits for arbitrarily complex computations.
So, to reproduce the logic of an arbitrary program, it is necessary to break it down into basic primitives — NAND gates — where each gate performs a logical operation, and the result is passed along the circuit. In our case, this requires exchanging a large amount of off-chain data — potentially several gigabytes even for a relatively simple arbitrary program— but only one on-chain transaction is typically required if the verifier agrees that the prover correctly executed the program. However, if the verifier disagrees with the result, they must be able to prove the error in a relatively small number of on-chain transactions.
After setting up such a payment «channel» between two parties, multiple programs can be executed sequentially or in parallel without any intermediate on-chain transactions, except for channel setup and closure transactions, which can be either cooperative or forced.
But how can the behavior of NAND gates be replicated on Bitcoin with the current capabilities of the Bitcoin script?
To replicate NAND gates on the Bitcoin network, we can utilize hashlocks along with two opcodes that might be unfamiliar to you: OP_BOOLAND and OP_NOT.
Let’s dive into hashlocks first. By creating a branching script, we enable spending in either of two ways: revealing the preimage for hashlock A or the preimage for hashlock B. Choosing option A places the number 1 on the stack, while option B places 0. The script can only execute with one preimage, not both. This feature allows users to fix individual bits sequentially for use in a script with a NAND gate.
An Actualized Approach to a 1-Bit Commitment. To gain access to this script, the prover is required to disclose either the preimage of hash0 or hash1. In this specific instance, the prover divulges hash1 and establishes the bit value as «1». Multiple replicas of this commitment can be employed to guarantee a predetermined value across diverse scenarios.
As a reminder, a logic gate takes two bits as input and produces one bit as output. For a NAND gate, if both inputs are 1, the output should be 0; any other combination of input bits yields 1. By employing a two-option hashlock, we can fix the inputs and output, with the only requirement being an ability to verify the output’s correctness. This is where OP_BOOLAND and OP_NOT come into play.
By carefully selecting input values and the output to compare against, an intriguing technique can be employed. OP_BOOLAND acts as the inverse of NAND: if both inputs are 1, the output will be 1; all other combinations result in 0. On the other hand, OP_NOT takes any input value and negates it, transforming 1 into 0 and vice versa. When used together, these opcodes enable the replication of the NAND gate’s logic for two input values. To finalize the process, we can utilize OP_EQUALVERIFY to compare the resulting output with the declared result fixed using the hashlock. The script fails verification if the actual output doesn’t align with the value declared by the proving party.
In this manner, we have successfully replicated a NAND gate using the capabilities of the Bitcoin script while ensuring its accurate operation.
NAND Logic Gate: Unveiling Bit Commitments A, B, and C to Fulfill A NAND B = C Requirement during Script Execution.
Where do arbitrary computations originate in this context?
What are the possibilities offered by the replication of this fundamental gate in Bitcoin script? It is feasible to construct a comprehensive tapleaf tree (tapleaf denoting a leaf within a tapscript tree) that encompasses every stage of any arbitrary computation, reminiscent of the logical gates found in computer processors.
To perform intricate computations, logical gates are interconnected sequentially in such a manner that the output of the initial gate, subsequent to processing the received data, serves as the input for the subsequent gate. In our scenario, a similar framework is replicated through the corresponding linkage of hash locks between gates. This means that if the script of one gate entails a choice between preimages for value C1 or C2 at the output, the subsequent gate in the sequence utilizes the same hash lock values at the corresponding input. Consequently, the only way for someone to manipulate the outcome obtained from the preceding gate is by revealing another hash lock C, which can be utilized within the penalty mechanism.
Example of an Arbitrary Circuit with 8 Distinct NAND Gates and 4 Inputs A, B, C, and D. With billions of gates, nearly any function can be determined.
Both users select any computation they wish to execute and break it down into a scheme of NOT-AND gates, with computations executed sequentially. Subsequently, they encode each gate within the scheme with the corresponding selection of hash lock for each step of the scheme, encode it into a tapleaf tree, which can be reduced to a single value and stored in a single UTXO (unspent transaction output). One version of the tree is designated for the user to substantiate the accurate execution of the program, while another version is utilized by the verifier to verify its execution. They then pre-sign a series of transactions for a «challenge-response» game, which can theoretically be performed on-chain, but ideally, all computations are executed and verified off-chain. The parties collaboratively carry out the calculation, transferring funds to the relevant party based on the computation results. If the prover ceases to cooperate, the verifier can contest their results on-chain.
In the case of each gate, the Taproot address associated with the prover encompasses a leaf containing a script representing the commitment specific to that gate. This functionality empowers the prover to designate the input values of the circuit (namely, A, B, C, and D) at any desired point in time.
The initial step involves loading funds into the scheme. One pathway within the script allows the prover to unilaterally claim the funds after a specific timelock period. Another pathway enables the verifier to immediately receive the funds if they can provide the preimages for both potential values of any input or output of the current gate. The subsequent pathway in the script allows the verifier to compel the prover to execute a specific gate contract on-chain (e.g., immediately upon termination of off-chain cooperation). This pathway necessitates the verifier to produce another hash lock preimage exclusively known to them, which functions as a lock for each gate’s task for the prover. This ensures that the prover can solely execute that particular gate. The verifier’s pre-signed transaction for this pathway spends it on a script with the following possibilities: the verifier claims the coins after the timelock, or the prover executes the gate and spends the coins back into a script similar to the initial one: the prover can claim the funds after the timelock, the verifier can claim them instantly if they present both preimages for any pair of hash locks, or the verifier can propose a new challenge to the prover.
A few iterations of this scheme guarantee the accurate computation as per the contract. Either the verifier exhausts their pre-signed transactions for issuing new challenges to the prover because the prover consistently demonstrates the correct execution of each gate and claims the funds, or the prover fails to respond to the challenge to evade penalties, and the verifier claims the funds after the timelock, or the prover incorrectly executes the gate on-chain, and the verifier instantly claims the funds. Ideally, all interactions occur off-chain and are resolved through cooperation. However, in the event of failed cooperation, after several on-chain iterations, the only possible outcome is the correct resolution of the contract.
Hence, these smart contracts do not imply on-chain step-by-step execution in a trustless manner. Nevertheless, any party violating the contract’s conditions can be directly penalized on the Bitcoin blockchain after demonstrating several stages of incorrectly executed contract components. The imposition of punishment simply requires time to take effect.
BitVM offers the opportunity for trustless interactions in scenarios involving two participants, Alice and Bob, who possess conflicting interests. For instance, when they wager funds on the outcome of a chess match between them. They can employ two nearly identical arbitrary programs that simulate the sequence of moves in a chess game. One program yields a true result if Alice wins, while the other yields true if Bob wins. Subsequently, one party can publish a transaction on the blockchain, asserting that their program evaluated to true, indicating victory. The opposing party can either accept this claim and acknowledge the loss of funds or provide evidence of deception to claim the funds if successful.
In situations where the participants are not naturally adversarial, one can incentivize the other to validate the accuracy of computations by offering funds as a reward if they can demonstrate that the computations were incorrect.
One of BitVM’s notable advantages lies in its ability to facilitate the creation of more intricate and sophisticated contracts. Unlike traditional Bitcoin contracts that primarily relied on basic operations such as digital signatures and timelocks, BitVM opens up a broader range of possibilities in this domain.
Linus, in his whitepaper, outlines a diverse set of new features that can be implemented through logical gates, extending beyond financial operations to encompass complex decentralized applications (DApps). The author mentions games like chess, Go, or poker, as well as the verification of contract validity proofs in Bitcoin. Additionally, the BitVM architecture allows for the development of truly decentralized prediction markets, bridges between BTC and other blockchains, and the emulation of new opcodes. While it may take time to develop and effectively implement smart contracts using this protocol for real-world applications, the existence of such a protocol itself is revolutionary.
A striking feature of BitVM is its minimal impact on the Bitcoin blockchain. By conducting a significant portion of computational work off-chain, BitVM reduces the volume of data that must be directly stored in the blockchain. This offers two primary advantages: firstly, it enhances overall network efficiency by requiring fewer resources for transaction verification, and secondly, it prevents blockchain congestion caused by unnecessary data, without compromising scalability and expansion possibilities.
Lastly, BitVM incorporates robust measures to protect against fraud, ensuring the integrity of transactions. By utilizing a fraud-proof system in combination with a challenge-response protocol, BitVM guarantees fairness and transparency in all transactions. If someone attempts deception or presents false data, the verifier promptly detects it within the system and exposes the dishonest party by submitting a concise proof of deception to the blockchain. This not only discourages fraudulent behavior but also fosters trust in the system as a whole, establishing BitVM as a secure and reliable platform for various use cases.
No system is flawless. What are the limitations of BitVM?
Despite its benefits, it is crucial to acknowledge the limitations of the BitVM protocol.
The primary limitation is its design for two-party interactions. As a result, the current version of BitVM is not well-suited for handling multi-party transactions and contracts, limiting its applicability in scenarios that involve complex interactions among multiple participants.
The evolving DeFi landscape with its increasingly intricate ecosystems and numerous participants may pose a challenge for BitVM to meet emerging needs and expectations.
Another significant limitation is the requirement for both parties to perform substantial off-chain computations. While this minimizes BitVM’s impact on the Bitcoin blockchain, it places a significant computational burden on participants. Users must have adequate computational resources to execute these tasks, which can be challenging for those using less powerful hardware or engaging in multiple BitVM contracts simultaneously.
BitVM generates and processes a substantial volume of data. It involves tapleaf trees with billions of leaves and a series of pre-signed transactions spanning multiple steps to ensure accurate computation. Managing off-chain data incurs significant costs, contrasting with the minimal footprint on the blockchain.
As mentioned in the BitVM whitepaper, the current model serves as an illustration that universal computation on Bitcoin is possible. However, the author recognizes the need for more efficient models for practical applications.
It’s important to note that BitVM is still in its early stages of development, with only a whitepaper available. As the technology progresses, solutions to address or overcome these issues may be discovered. Future iterations of BitVM could introduce advanced features to support multi-party interactions.
What lies ahead?
Deliberating on such a proposal can be a time-consuming process.
There are ongoing discussions on concepts like aggregating multiple two-party channels into a network similar to the Lightning Network. These discussions aim to expand the capabilities of BitVM. By evolving and adapting, BitVM has the potential to gradually overcome its existing limitations and become a more universal and efficient platform for Bitcoin-based transactions and contracts.
However, expanding the scheme to accommodate more participants is not currently clear, and even if resolved, the challenge of addressing the interactive nature of the protocol, which requires constant collaborative participation from all parties, remains. Nevertheless, BitVM serves as an intriguing demonstration of how complex programs can conditionally control changes in Bitcoin’s state.
Undoubtedly, there is room for optimization in terms of how much logic can be packed into a single leaf script and what can be achieved with different opcodes to enhance the overall efficiency of the scheme. Simplifying it to basic operations and game-theoretic balances can enable the execution of arbitrary computations with result commitment and control within Bitcoin.
While the recent hype surrounding BitVM in specialized media may seem exaggerated and detached from reality, it remains a significant milestone in Bitcoin’s history. Considering its efficiency challenges, such as the size of taproot trees and the number of required pre-signed transactions, the trade-off between efficiency and functionality is an open question. Nonetheless, the potential functionality achievable through this approach, without altering Bitcoin’s consensus, is truly immense.
Two specific concepts have been put forward that highlight how BitVM’s guaranteed level of assurance can rationalize the substantial expenses associated with off-chain transactions and taptree scripts.
Firstly, there is the innovative notion of a «sentry peg», a new form of two-way peg. It entails the establishment of a federated sidechain where the federation deposits bonds into a BitVM contract governing the sidechain’s logic. Upon fund withdrawal, the federation must furnish proof of the withdrawal’s legitimacy to BitVM. Failure to provide such proof empowers a network of verifiers to seize the federation’s deposited bonds in BitVM. This dynamic creates an intriguing scenario where the party holding funds in the sidechain must effectively substantiate the correctness of their actions to an external entity, or else face the confiscation of funds. Notably, compared to traditional schemes, this approach introduces a more intricate penalty rule logic that is verified directly during execution, without reliance on intricate cryptographic techniques or additional layers of trust.
Secondly, there is the concept of UTXOracle, which enables trustless computation of the Bitcoin price using solely a full node and a Python script. Previously, there was no viable means of obtaining such data within a Bitcoin script and utilizing it in smart contracts. BitVM provides the opportunity to implement this solution by constructing a logical gate scheme for verifying Bitcoin blocks (utilizing a simple proof-of-work). Genuine full blocks can be transmitted to BitVM, and with a sufficiently long sequence of these blocks, the UTXOracle logic can be employed within BitVM, linking the contract’s outcome to price data autonomously derived from the blockchain.
Implementing these ideas for high-value contracts or sidechains may necessitate substantial off-chain data, ranging from several hundred megabytes to even 1-2 gigabytes, considering the guarantees provided. While BitVM will not instantaneously transform Bitcoin into Ethereum and its development is expected to be gradual and experimental, it represents a gateway to an entirely new paradigm of utilizing Bitcoin.
The ability to support Turing-complete smart contracts directly on the Bitcoin blockchain underscores the distinctive decentralized and ever-evolving nature of Bitcoin, fully justifying its position as the world’s primary cryptocurrency. This does not imply that Ethereum and other altcoins should collapse overnight, especially considering BitVM’s early stage of development. Nevertheless, over time, Bitcoin gradually erodes any compelling reasons to opt for its «competitors». Recent market conditions have already demonstrated the shaky ground upon which these «competitors» stand, while Bitcoin emerges as a safer bet than ever before.
The drawback of BitVM is that complex computations occur outside the Bitcoin network. Even for simple smart contracts, a significant number of pre-calculated intermediate steps and signatures are required to ensure precise conflict resolution in an exceptional situation. BitVM represents an interesting technical concept, and in the future, more complex solutions and improvements in the efficiency of this approach are expected.