NewsFlash Articles Data Fundraising BlockBeats Pro

What do experienced developers think of BitVM for computing anything on Bitcoin? [翻译]:

Jaleel加六and others2Authors

Read this article in 10 Minutes

Although there aren't many conclusions, these conversations are valuable to the community.

Last night, BitVM released a white paper that sparked discussion, claiming that BitVM can enable any computable function to be verified on Bitcoin. Within an hour of its release, the white paper had reached 110,000 views, and as of the time of writing, the number of views had reached 1.82 million.

In this white paper reviewed by Super Testnet and Sam Parker, it can be seen that BitVM is a new computing paradigm designed by Robin Linus at Zero Sync, which combines Optimistic Roll Up, Fraud Proof, Taproot Leaf, and Bitcoin Script.

BitVM allows for the expression of Turing-complete Bitcoin contracts without changing the Bitcoin network's consensus rules. It can execute any computable function and perform offline calculations without leaving any trace on the chain. The whitepaper also introduces BitVM's architecture, input/output, limitations, and prospects.

KOL Leonidas (@LeonidasNFT) believes this is an equally exciting innovation, so he engraved the BitVM paper on the Bitcoin inscription here, making it exist forever in a more native way.

Bitcoin developers, how do they evaluate?

BioniqMarket's CEO Bob Bodily (@BobBodily) has been building tools to help developers build on Bitcoin, currently focusing on the Ordinals marketplace and launchpad.

Bob Bodily said on his social media: "BitVM is not a one-stop solution. BitVM is not as good as EVM. It is slower, more expensive, and more complex. The core advantage of BitVM is that we can now get additional programmability on Bitcoin without upgrading. No need for new op_codes. No need for a soft fork. It can be used now."

BitVM's potential use cases that are easy to implement include decentralizing various applications that currently rely on centralized services, including DLC oracles, congestion control/coinjoin aggregators, and sidechain legal numbers. In addition, BitVM does not solve the problem of trustless bridging for sidechains, which may require contracts. BitVM is strictly superior to Greg Maxwell's 2016 ZKP conditional payment example. BitVM is very complex and difficult to understand and implement. The same thing can be achieved by upgrading Bitcoin through an op_code.

Bitcoin does not need any changes

Researcher Sam Parker also shared his views in a lengthy post, stating that "it should be emphasized again that Bitcoin, like any other chain, has Turing completeness, and this does not require any changes to Bitcoin. Some of the classic views of Bitcoin maximalists when they are "pointing the way" are: Turing completeness = bad, which I think is foolish.

First of all, due to the technical definition of Turing completeness actually requiring an unbounded runtime, nothing in our reality can truly achieve Turing completeness because we do not have infinite space and time to accommodate it.

During this process, a small group of script hackers, such as @robin_linus and @super_testnet, have figured out how to incorporate all the functionalities we want from general-purpose computers into Bitcoin's extremely limited set of operation codes. Therefore, the only thing preventing Bitcoin's virtual machine (VM) from having Turing completeness like Ethereum is not a matter of expressive power, but simply a matter of runtime, with the strictest limitation being the stack size.

BitVM's entire purpose is to allow us to spread the runtime of certain logic, which exceeds the scope of a single transaction, across multiple transactions. That's it. We haven't added any new semantic features, we've just exponentially increased the length of programs we can run. Therefore, by technical definition, Bitcoin is not actually more Turing complete than before, it has simply been given a runtime in programs that we can reasonably say are "Turing complete enough for any program we actually want to execute".

"This is voluntary. If you don't trust your coins being locked into a Turing-complete contract (which is completely reasonable), then don't lock them into a Turing-complete smart contract. One advantage of the UTXO system is secure sandboxing. If people do strongly feel that Bitcoin shouldn't have this feature, perhaps due to incentives or other issues, then it should be a topic worth discussing, but basically it would require getting rid of Taproot, which seems very foolish at this time," wrote Sam Parker.

"BitVM makes me feel cautiously excited"

As a strong supporter of Drivechains, another Bitcoin extension protocol, Simp DAO founder and senior cryptocurrency researcher Eric Wall was invited by community members to express his views on BitVM. Eric Wall said: "I just finished reading this white paper, and all the concepts are appropriate for me. I am not very interested in schemes that require a large number of pre-signed transaction exchanges during the setup phase - I don't know what problems such schemes may cause. Cost and permissions are two big issues."

Now he maintains a cautious excitement towards BitVM, waiting to see what actual experimentation will bring. Perhaps there are elegant and insignificant solutions to the two-sided limitations of this approach, or perhaps not. Perhaps for specific types of computation, such as zk proofs, the costs are manageable. If BitVM operates well in verifying zk proofs, then it will be interesting - BitVM will play the role of the zkwasm layer he previously discussed.

"As a side note, I am curious about what will happen when people realize that the attack model is quite similar to Drivechains. Miners can steal all the balance of BitVM by colluding with verifiers and reviewing challenges, and this situation may last for a shorter time than in Drivechains." wrote Eric Wall.

Although there are not many conclusions, these conversations are valuable to the community. Narratives and topics similar to BitVM's white paper have sparked in-depth discussions about the design and evolution of Bitcoin, prompting us to think more deeply about the future form of Bitcoin that we want. Should Bitcoin add more "native" programmability or should it continue to maintain simplicity, security, and immutability?