Author: Haotian
A whitepaper titled “BitVM: Compute Anything On Bitcoin” has sparked discussions among developers, suggesting that the Bitcoin network has achieved Turing-complete smart contracts, which can execute any computable function.
This means that the Bitcoin network can replicate everything in the Ethereum ecosystem without changing the existing Bitcoin consensus or requiring any upgrades. By relying on the basic op_codes of Bitcoin, the network can be endowed with “complex” programmability, allowing it to compute anything Turing-complete.
But hold on, let’s first explore the concept of BitVM. How does it enable complex programming in the Script space? What does the Optimism Rollup concept refer to? What is the principle of Fraud Proof? What obstacles exist in the implementation of BitVM? Next, let’s analyze its general logical framework step by step for everyone to understand (without discussing specific technical implementation details).
- Conquest.eth Stake to Play mode, a perpetual and permissionless diplomatic strategy game.
- Tencent ShuZang suspends operations, players have no way to protect their rights
- New Project Outlook | Reserve Creating a Stable Asset-Backed Currency to Combat Inflation
How to achieve complex programmable features?
Due to the limited programming capabilities of Bitcoin, which only supports simple logic and a limited set of op_codes in script scripts, it is not possible to develop complex smart contracts on the Bitcoin network. The core idea proposed by BitVM is that, by using the taproot address matrix or taptree, various program instructions similar to binary circuits can be implemented, which, when combined, form a complete contract execution.
Specifically, we can consider each spending condition instruction in the Script script as the smallest unit of a program. The execution of a script can only result in either true or false. By inputting certain code into the taproot address, a deterministic 0 or 1 can be obtained. By combining a large number of taproot addresses, an ordered taptree can be formed, and the execution result will be a binary circuit text effect 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 pre-set instructions in each Script will be, and the more complex programs the entire taptree can execute. Makes sense, right?
This is indeed a very innovative idea. However, according to this logic, the smallest unit instructions are indeed completed by the Bitcoin full node, and the possibility of infinite combinations by adding taproot addresses can lead to a lot of complex calculations. To some extent, it can be said to be Turing complete. But the infinite addition of taproot addresses will only increase cost consumption, and theoretically, it is possible to achieve Turing completeness and implement everything, but it is not practical.
Therefore, the claim of Turing completeness mentioned in the whitepaper is only valid in extreme ideal situations and can be seen as a “conceptual shift.” Even Ethereum, which claims to be a supercomputer, cannot fully achieve Turing completeness, let alone the Bitcoin network that relies solely on script.
An Analysis of Several Complex Concepts
Based on the understanding of the core framework mentioned above, let’s take a look at the Optimism Rollup, Fraud Proof, Bit commitment, and Logic Gate mentioned in the white paper. Due to the limited space and executable code logic of a single taproot, executing complex programs off-chain and only putting the key verification process on-chain, isn’t this a kind of Rollup idea?
And Fraud Proof can be understood in this way: the Prover and verifier compile a huge binary circuit, and when the Bitcoin network executes the circuit, one premise is that the Prover must pre-sign and pledge a certain amount of Bitcoin assets. If the Verifier detects any suspicion of cheating by the Prover, they can similarly send a transaction to trigger the unlocking condition of the on-chain taptree “program”, and if successful, the verifier can confiscate the Prover’s pledged assets, which is essentially a process of fraud proof.
In this logic, it is not difficult to understand why BitVM is only suitable for two LianGuairties with agreed consensus, meaning they must share the overall circuit diagram before execution, execute the fraud proof program within the validity period, and pledge certain assets and pre-sign. If both parties do not cooperate off-chain to establish a set of agreed consensus and rely solely on the limited on-chain execution environment of the Bitcoin network, it is difficult to achieve a true “contract” execution.
What obstacles will BitVM face in its implementation?
1) Currently, BitVM is only suitable for implementing on-chain operations between two LianGuairties with agreed consensus, and the on-chain environment is only the process of executing contracts in a transparent manner. It currently only supports interactions between two agreed parties, and implementing N-N requires more complex technical logic design.
2) How does BitVM apply the script of a single taproot address to implement the smallest programming unit? It must not exceed the execution logic framework of Bitcoin, such as hashlock, timelock, etc., and must not exceed the specified storage conditions. In an optimistic scenario, a taproot address can program hundreds of logic gates, but more addresses are needed to construct a taptree. The problem is that the execution of preset unlocking conditions for taproot addresses requires miners’ fees, and the more address combinations, the higher the cost. In the future, the cost may be reduced through the bi-directional channel technology of the Lightning Network, but overall, relying on the Bitcoin network to execute logic gate circuits is not only slow but also costly.
3) In an ideal scenario, BitVM has limited support for on-chain scenarios, and only a few consensus and asset transfer scenarios depend on the on-chain environment, such as asset disposal in games.
In summary, BitVM is an imaginative and creative idea, but based on its implementation technical framework, it is likely to be limited to the concept stage of the white paper in the short term. Exploring long-term application scenarios and implementing them will still face great challenges. To use a simple analogy, BitVM is like building a giant computer larger than a room in an era where everyone can use mobile terminals.
Note: The above interpretation is only applicable for understanding the general technical framework of BitVM, in order to facilitate everyone’s understanding of the underlying technical logic. The specific implementation may have some deviations. If there are technical experts who have conducted in-depth technical research, they can correct and supplement in the comments.
Like what you're reading? Subscribe to our top stories.
We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!
