Written by: Haotian
A white paper titled "BitVM: Compute Anything On Bitcoin" has sparked heated discussions among developers, seemingly implying that the Bitcoin network has achieved Turing-complete contracts and can execute any computable function?
Does this mean that the Bitcoin network can reproduce all the narratives of Ethereum and other ecosystems? And there is no need to change the existing Bitcoin consensus, or even any upgrades. Just relying on the current Bitcoin basic op_code can give the Bitcoin network "complex" programmable capabilities, allowing the Bitcoin network to Turing-completely calculate everything?
Wait, don’t start dreaming, let’s first discuss the concept path of BitVM. How does the Script space perform complex programming? What does the Optimism Rollup idea refer to? What is the principle of Fraud Proof? What are the obstacles to the implementation of BitVM? Next, I will analyze its general logical framework step by step to facilitate your popular understanding. (I will not discuss the specific technical implementation details in detail.)
How to implement complex programmable features?
Since Bitcoin’s programming capabilities are very limited and only support simple logic and limited opcodes on scripts, it is impossible to develop complex smart contracts on the Bitcoin network. The core idea of the BitVM proposal is that various program instructions similar to binary circuits are implemented through the taproot address matrix or taptree, which together are equivalent to complete contract execution.
Specifically, we can regard the UTXO spending conditional instructions in each Script as the smallest unit of a program. A script execution can only have two results: true and false. If a certain code is entered in the taproot address, a deterministic 0 or 1 can be obtained. If a large number of taproot addresses are combined into a matrix, an ordered taptree can be formed. The result of the execution will have a large number of binary circuit text effects such as 011001, which can be regarded as an executable binary program. The complexity of the program depends on the number of combined taproot addresses. The more addresses there are, the richer the instructions preset in each Script within the scope of the Bitcoin framework, and the more complex the program that can be executed by the entire taptree. Maker Sense, right?
This is a really wild idea. However, according to this logic, the smallest unit instruction is indeed completed by the Bitcoin full node, and the infinite superposition of taproot addresses and the infinite combination of possibilities can superimpose many complex calculations. To some extent, it is not an exaggeration to say that it is a Turing complete machine. However, the infinite superposition of taproot addresses will only increase the cost consumption. In theory, it is possible to achieve everything in a Turing complete way, but it is impractical.
Therefore, the Turing completeness mentioned in the white paper is only a statement under extremely ideal circumstances, which is a bit of a "concept substitution". Even Ethereum, which claims to be a supercomputer, cannot fully achieve Turing completeness, let alone the Bitcoin network that only relies on scripts?
A Brief Analysis of Some Complex Concepts
Based on the above understanding of the core framework, let’s look at the Optimism Rollup, Fraud Proof, Bit commitment, and Logic Gate mentioned in the white paper. Since a single taproot space and executable code logic are limited, executing complex programs off-chain and only putting key verification links on-chain is not a kind of Rollup idea?
Fraud Proof can be understood in this way. The Prover and the verifier first compile a huge binary circuit. When the Bitcoin network executes the circuit, there is a prerequisite that the Prover must pre-sign and pledge a certain amount of Bitcoin assets. If the Verifier verifies that the Prover is suspected of doing evil, it can send a transaction to the chain to trigger the UTXO unlocking condition of the taptree "program" on the chain. If successful, the verifier can confiscate the prover's collateral assets, which is equivalent to a fraud proof process.
From this logic, it is not difficult for us to understand why BitVM is only applicable to two parties with agreed consensus, that is, the total circuit diagram must be shared before execution, the fraudster proof procedure must be executed within the validity period, and a certain amount of assets must be pledged and pre-signed. If both parties do not cooperate to reach a set of agreed consensus off-chain, it is difficult to facilitate a real "contract" execution relying only on the limited on-chain execution environment of the Bitcoin network.
What obstacles will there be in the implementation of BitVM?
1) BitVM is currently only suitable for on-chain operations between two parties that have reached a consensus. The on-chain environment is only a process of openly and transparently executing contracts. Currently, it can only be implemented between two agreed parties. If N-N is to be implemented, more complex technical logic design is required.
2) How does BitVM use the script of a single taproot address to implement the minimum programming unit? It cannot exceed the execution logic framework of Bitcoin, such as hashlock, timelock, etc., and cannot exceed the limited storage conditions. In the optimistic case, a taproot address can program hundreds of logic gates, and more addresses must be combined to build taptree. The problem is that the execution of the preset unlocking conditions of the taproot address requires a miner fee, and the more address combinations, the greater the cost. In the future, the bidirectional channel technology of the lightning network may reduce costs, but in general, relying on the Bitcoin network to execute logic gate circuits is not only slow, but also expensive.
3) BitVM ideally supports very limited scenarios and is more suitable for heavy chain computing. Only some consensus and asset transfers need to rely on on-chain scenarios, such as asset disposal in games.
In general, BitVM is a creative and imaginative idea, but according to its implementation technical framework, it is likely to be limited to the white paper conception stage in the short term. Long-term application scenario exploration and implementation still face great challenges. Let me use a very common example to illustrate: BitVM is like building a giant computer larger than a room in an era where everyone can use mobile terminals.
