Author: Simon Shieh
Prelude Recap
In the previous article, "Scaling Solutions for BTC Ecosystem: Where Do Inscriptions Go?", we discussed the technical principles of popular inscription ecosystems and potential security issues, as well as mentioned the possibility of implementing smart contracts using recursive inscriptions. However, due to Luke's restrictions on Taproot scripts, recursive inscriptions seem to face some obstacles. So, are there other possibilities for implementing smart contracts on the Bitcoin network?
Robin Linus, co-founder of blockchain development firm ZeroSync, published a paper titled "BitVM: Compute Anything on Bitcoin" on October 9, 2023, proposing a plan to bring smart contracts to the Bitcoin blockchain.
The paper introduces a fascinating idea: using Taproot to perform nearly any arbitrary computation and leveraging these computations to verify off-chain events occurring on Bitcoin. The key trick is placing all logic off-chain and challenging incorrect results on-chain through only a few computational steps when someone asserts dishonest outcomes.
In other words, place a Verifier’s logic within the Bitcoin network, leverage Bitcoin’s strong consensus security as a trusted third party for any Turing-complete computing layer, and use the principles of Optimistic Rollups to verify off-chain computation results.
So how can we implement such a Verifier logic on the Bitcoin network? To echo the previous section's concept of "inscription," I would call this technique “etching” circuits onto the Bitcoin network.
Logic Gate Circuits
Inside your computer or smartphone, electric currents transmit a series of 1s and 0s to enable all computing functions. This is achieved via millions of tiny components—logic gates—that serve as the fundamental building blocks of computer chips.
Each logic gate receives one or two bits of information, each being either 1 or 0. Then, according to predefined rules, the logic gate performs a simple logical operation such as AND, OR, or NOT. The result of these operations is also a single bit—either 1 or 0—which is then passed on to the next logic gate.
This system based on simple logical operations reveals an important insight: even the most complex computations and functionalities can be realized by combining vast numbers of basic logical operations. The combination and coordination of these logic gates form the foundation that enables modern computers and electronic devices to execute complex tasks. Through these fundamental logical operations, computers can handle complex arithmetic calculations, data storage, image rendering, and more.
The figure below shows a special type of logic gate called a NAND gate, which can be used to construct any kind of logic circuit. While it may not be as efficient as dedicated-purpose gates, it is still capable. BitVM’s logic circuits are composed entirely of NAND gates.
How to Etch NAND Gates onto Bitcoin
Constructing a NAND gate (NAND gate) on existing Bitcoin scripts can be done by combining hash locks with two lesser-known opcodes: OP_BOOLAND and OP_NOT.
First, a hash lock can be used to create a branched script that can be spent in one of two ways: satisfying hash lock A or hash lock B. Path A outputs 1 to the stack, while path B outputs 0.
By satisfying a specific hash lock, you can "unlock" a bit, serving as one of the inputs to the NAND gate we're constructing. Since only one path can be satisfied at a time, this method allows users to submit only one bit at a time.
The logic of a NAND gate takes two bits as input and produces one output bit. If both input bits are 1, the output is 0; otherwise, the output is 1. Using the two-hash-lock technique, both inputs can be submitted and the correctness of the output verified—this is where OP_BOOLAND and OP_NOT come into play.
OP_BOOLAND behaves opposite to a NAND gate: if both inputs are 1, the output is 1; any other input combination yields 0. OP_NOT simply outputs the inverse of its input. Therefore, by combining these two opcodes, you can take two inputs from the script stack and perform a NOT-of-AND operation. Finally, OP_EQUALVERIFY along with the hash lock technique can be used to verify the asserted output. If the actual NAND operation result on the stack does not match the user’s claimed output, the script fails verification.
Thus, a NAND gate circuit has been effectively "etched" into Bitcoin scripts—essentially enforcing virtual NAND gate operations through Bitcoin scripting.
How to Etch Large-Scale Circuits
While the idea of implementing circuit etching via Taproot scripts is exciting, let alone achieving PC-level large-scale circuits—even implementing arbitrary computations requires thousands or millions of NAND gates. Given Bitcoin’s limited Taproot script space, how can complex computations be accommodated?
BitVM proposes the method of Taproot Script Trees. To realize complex computational processes in Bitcoin scripts, people can build computational circuits by connecting logic gates in series. In this scheme, hash locks bind individual gates together, enabling sequential logical execution. Specifically, if a gate’s script produces different outputs C1 or C2 depending on different hash preimages (plaintext values), the subsequent gate uses the corresponding matching hash lock value as its input.
This approach enables a penalty mechanism: attempting to falsely report the result of a prior gate forces the revelation of another hash lock’s preimage. This mechanism supports interactive computation between two users who pre-agree to participate in a specific computational task, decomposing the process into a circuit made solely of NAND gates. They must select appropriate hash locks for each gate in the circuit and encode them into the script tree of a locked UTXO.
Then, by forming a matrix of multiple addresses into a Taproot address and using the Taproot Tree structure, the logic circuit is etched into the Taproot scripts of a series of tree-connected UTXO transactions, ultimately forming a "contract-like" logic circuit capable of handling certain computational tasks.
Fraud Proofs
Fraud proofs are central to OP (Optimism Rollup) technology (though never truly implemented yet). The idea is that before a batch of transactions is submitted collectively, challengers can initiate fraud challenges (staking bets) against transactions they believe are incorrect. A Verifier contract on the main chain examines changes in the state root after execution to determine whether the submitter acted maliciously, then allocates the staked assets accordingly.
In BitVM, the script tree is designed with two circuits—not only allowing provers to submit to one circuit but also enabling challengers to challenge the prover’s claims. This can be achieved by pre-signing a series of transactions connected in a "challenge → response → challenge → ..." pattern. If one party stops responding after a period, the other party wins the challenge and recovers both deposits.
The above diagram illustrates a series of pre-signed transactions:
-
Challenge: Vicky (the challenger/verifier) releases a preimage within the script path (known only to the challenger), acting as a challenge to the proof;
-
Response: Paul (the prover) executes the corresponding logic gate and sends funds back to the original script;
After several rounds of queries, any inconsistent claim can be quickly refuted. If the prover ceases cooperation with the challenger off-chain, the challenger can force on-chain collaboration: each time the challenger unlocks a hash lock, the Taproot leaf node corresponding to each NAND gate in the prover’s UTXO can only be spent if the prover knows a preimage held by the challenger. The prover can prove correct execution of a given Taproot leaf node by revealing its inputs and outputs. The prerequisite is that the challenger unlocks it by revealing the preimage of the corresponding Tapleaf hash. Using binary search, the challenger can identify the prover’s error within a finite number of rounds (O(log n)) of challenges and responses.
This entire process involves multiple rounds of interaction to ensure correct contract settlement. The challenger can continuously challenge the prover until the prover verifies the correct result of every gate, or—if the prover fails to respond—the challenger can withdraw funds after a specified time. Ideally, all operations occur off-chain with collaborative settlement, but if cooperation breaks down, both parties can rely on an on-chain challenge game to ensure correct resolution of the contract.
Implementation Barriers and Security Issues
This proposal involves handling and generating an enormous volume of data. The Taproot script trees used could contain billions of leaf nodes, and processing related pre-signed transactions might take at least several hours to ensure accurate settlement. Each preset unlock condition of a Taproot address incurs miner fees, so the greater the number of address combinations, the higher the cost.
A major limitation of this scheme is that it currently only works for interactions between two participants: one acting as the prover, verifying the accuracy of their execution, and the other as the verifier, challenging the former’s assertions. While future research may find ways to include more participants, no clear solution exists at present.
In cooperative settlement scenarios, all participants must remain online, posing limitations on protocol usability and convenience.
Regarding security, the following risks exist:
1. Due to cost constraints, a significant amount of computation must necessarily occur off-chain, introducing common security risks associated with centralized services.
2. Storing large amounts of data off-chain raises concerns about data availability and data security.
3. Potential logical vulnerabilities in the etched circuits themselves represent another security risk. Due to the poor readability of circuits, higher auditing costs or formal verification efforts are required.
Metatrust previously assisted Uniswap with comprehensive formal verification and has extensive experience in ZK circuit audits and formal verification, offering robust support for the secure deployment of the BitVM ecosystem.
The schemes covered in the last two articles are newly emerging technologies this year. In the next article, we will introduce a more established and “orthodox” solution—an upgraded version of the Lightning Network: Taproot Assets.
