July proved to be a banner month for efforts to scale Bitcoin using zero-knowledge proofs.

First, StarkWare demonstrated a STARK verifier on Bitcoin’s Signet test network on July 17.

Then last week at the Bitcoin 2024 conference in Nashville, two competing teams behind BitcoinOS and BitVMX verified zk proofs on Bitcoin mainnet. Both make use of BitVM, or “Bitcoin Virtual Machine,” an approach to create Turing-complete Bitcoin contracts without the need for a soft fork.

Read more: Bitcoin research expands on design space for smart contracts

A key difference between the two approaches is the degree of trustless execution, according to L2 Iterative Ventures’ Weikeng Chen, who worked on the STARK verifier with StarkWare.

“BitVM has a trust assumption that still requires [a multisignature scheme],” Chen told Blockworks. “This assumption can be removed if we have OP_CAT.”

The distinction is similar to that between optimistic and zk, or validity rollups, on Ethereum.

Even though the BitcoinOS and BitVMX teams are verifying zk proofs, they’re doing so within a BitVM. Compared to a future version of Bitcoin with OP_CAT, they’re quite different trust models, Willem Schroe, Botanix Labs founder, agreed. Botanix Labs is building a decentralized proof-of-stake layer-2 using BTC, called Spiderchain.

“BitVM allows you to run any type of code, and the trust assumption to run any type of code is optimistic,” Schroe told Blockworks. “So now you can say, ‘With an optimistic fraud proof assumption of the BitVM, we can verify a zk proof in the BitVM.’”

Rootstock Labs worked with Sovereign Labs on BitVMX. BitcoinOS, of which Sovryn — not to be confused with Sovereign Labs — is one implementation, is a framework for interoperable rollups.

There’s “no clear winner,” according to Chen, because even if OP_CAT gets added to Bitcoin, “the BitVM approach is much cheaper to do onchain.” One potential tradeoff is that “the challenge-response can lead to a long settlement period,” he said.

Read more: Bitcoin’s zero-knowledge future gets a test

For example, 52 small transactions were conducted on the Bitcoin mainnet to demonstrate BitcoinOS’ BitSnark verification protocol.

The setup involves two parties: the Prover, who wants to access funds locked in a Taproot address, and the Verifier. The protocol begins with both parties co-signing all transactions. If the Prover is honest, the protocol completes following the initial transaction, and the Prover can access the funds after a set lock time.

However, if the Verifier detects a dishonest proof, they can challenge, initiating a series of transactions where each party takes turns — challenge and response — up to 26 iterations, according to the BitcoinOS team.

It’s too early to tell how scalable this approach will be in practice, according to Matt Black, co-founder and chief technology officer at Atomic Finance.

“Everyone likes to talk about unlimited scalability with optimistic rollups, but in reality there are significant limits,” Black said in the BitVM Builders telegram group.

Black points out the trust assumptions are only 1-of-n, meaning “there must be one honest party out of n, or funds can be stolen,” he told Blockworks — better than your typical Ethereum multisig.

Robin Linus, one of the authors of the BitVM white paper, has stressed that when designing a bridge using BitVM, the expectation was that it would only be used infrequently for dealing with large amounts of bitcoin, such as wrapping BTC for use on another network.

In the BitcoinOS demonstration, the final transaction that sought to execute one CPU instruction onchain on block 853626 involved the Prover performing a specific arithmetic operation in the virtual machine, which when validated, allowed the Prover to access the funds as expected.

But Chen would like to see more information about how to challenge the proof, noting that posting the proof “is the easy part.”

“Challenging a proof is probably the most difficult part in the BitVM landscape,” Chen explained. “The problem of their construction is that they aren’t supporting fraud proofs in memory — a malicious prover can modify the state to get an invalid proof passed — it is easy to break.”

This is a general issue with BitVM, Chen said. “We do not have a clear answer on how to do the state passing between the challenge-response units efficiently.”

Both of these solutions are a ways off from being production-ready. It’s not even clear how exactly, let alone when, Bitcoin Core could be upgraded to make use of OP_CAT.

Black thinks it may be awhile. “Personally, I doubt this will be activated anytime soon,” he said.

In theory, the use of StarkWare’s Circle STARKs enhances the proving process’s efficiency, positioning StarkWare’s solution as a highly scalable and secure alternative for zk proof implementation on Bitcoin.

Still, by enabling proof verification — in this case a SNARK proof — without altering the Bitcoin protocol, BitVMX and BitcoinOS open up the potential for advanced applications like Ethereum-style smart contracts which were previously infeasible on Bitcoin and therefore related to sidechains.