BitVM's new proposal seeks to match Bitcoin's smart contract capabilities with those seen in networks such as Ethereum and Turing Complete derivatives.
In a recent post on the social network X, Robin Linus, a well-known developer of Bitcoin and the protocol ZeroSync, has published an interesting paper in which he presents a new proposal: BitVM.
With this development, Linus seeks to bring Ethereum-like smart contract functionality to the Bitcoin ecosystem, enabling the Bitcoin network to be capable of running advanced Turing-complete smart contracts. This development has the potential to reshape the decentralized finance (DeFi) landscape and open up new opportunities for innovation on the Bitcoin blockchain.
Bridging the gap between Bitcoin and Ethereum
Bitcoin is the world's oldest and most established cryptocurrency, but its programming language, Bitcoin Script, is relatively limited and lacks support for complex smart contracts. Ethereum, on the other hand, is a newer blockchain platform that was specifically designed to support smart contracts. However, Ethereum has been criticized for its high transaction fees and scalability issues.
BitVM aims to bridge the gap between Bitcoin and Ethereum by providing a method to generate a virtual machine that allows developers to write and deploy smart contracts using NAND logic (logical stacks on Bitcoin) and Tapscript, the scripting language enabled by Taproot. BitVM would thus allow contracts to be executed on the Bitcoin blockchain. All this, without modifying the protocol, using Taproot and the security capabilities of Bitcoin's UTXOs, to bring these smart contracts to the Bitcoin network. And even to the sidechains of this network, such as Lightning Network or Ark, which means that the entire ecosystem could benefit from this project.
BitVM Technical Aspects
While BitVM is still in early development, there is no doubt that it has the potential to be a platform for smart contracts on Bitcoin. By making use of Taproot, UTXO, and Bitcoin’s native scripting capabilities, BitVM would not need a soft-fork or hard-fork to begin its construction, at least in its most basic parts. We are talking about reaching the smart contract capabilities of Ethereum and surpassing the security of this blockchain (and derivatives) thanks to the use of UTXO and the native capabilities of Bitcoin.
However, to achieve certain functions optimally, a complete soft-fork or hard-fork may be necessary to include new opcodes that help optimize BitVM's operation, in order to become Turing Complete. For example, building a smart contract with BitVM will require making a Taptree (a decision tree using Taproot). Thus, we can have from a hundred conditional options (each one activating a given output of the generated smart contract) to hundreds of billions. All of this depends on the complexity of the smart contract (Bitcoin is capable of accepting Taptrees with 2^127 leaves). This is in fact something that Linus himself has accepted:
And this is a problem, because it would make contracts take up huge amounts of data on the chain, which could easily take up the maximum 4 MB of a block in Bitcoin. Not only that, it would also make them slow and with a huge computational overhead, both at the time of generation (SHA256 preimages must be established for each leaf) and at the time of execution/confirmation of the same.
Huge technical challenges
But the technical challenge does not end here. BitVM relies on a fraud proof system, in which the participants of the smart contract must computationally verify compliance with the conditions inscribed in the smart contract, by means of commits. For this purpose, for example, zk-SNARKS proofs can be used, allowing these proofs to be computationally simple and very secure. These would be joined in a Taproot proof system that would verify the authenticity of the given proofs and give its final answer based on them.
However, Bitcoin currently does not have any primitives in Bitcoin Script that allow zk-SNARKs to be implemented directly. There are only two options left: including the opcode (a hard fork to include this capability in Bitcoin) or creating the code within Taptree itself using Tapscript. In fact, simpler operations such as multiplication, division of numbers in Bitcoin or the generation of conditional loops, must be solved so that BitVM can be practical and, above all, efficient when it comes to functioning.
Thus, the biggest potential challenge is to solve all these problems, plus what they may see in the future, including the possible fork of the Bitcoin protocol to optimize Bitcoin for this development. However, the benefits of BitVM are significant and it is likely that the Bitcoin community will support its implementation. It remains to be seen what the response of the community and developers will be, before we begin to see progress on this interesting proposal.
Continue reading: Polygon Miden, a solution that emphasizes privacy and scalability for Web3
