# Attempts to bring Programmability, Privacy and Composability to Bitcoin without any changes
When writing this article, my heart was beating very fast. Because I know I am describing something very new, I don't know if this plan is completely feasible, but I hope to write it down, discuss all of this with all blockchain enthusiasts, and put it into practice.

These ideas are completely based on my own ([xb](https://twitter.com/ocean_xiaobai)) and my teams ([Sin7y](https://twitter.com/Sin7y_Labs))accumulated experience in existing projects ([olavm](https://twitter.com/ola_zkzkvm))and inspired by the paper published by [Robin Linus](https://twitter.com/robin_linus) and his team: [BitVM: Compute Anything on Bitcoin](https://bitvm.org/bitvm.pdf). I have done some active discussions, research, and thinking, and proposed a solution that I think is better, which can mainly introduce two possibilities for Bitcoin.

## 1. Bitcoin has a real programmable Layer2 (zk proof + fraud proof + timelock)

In fact, the biggest difficulty in designing Layer2 for Bitcoin lies in how to verify the validity of a Layer2 on Bitcoin. Suppose the Layer2 solution is based on Zero Knowledge (ZK) technology, that is, ZKVM. In that case, the biggest difficulty lies in how to execute a STARK verification contract on Bitcoin (assuming the STARK zero-knowledge proof algorithm is used). If the Layer2 solution is based on Optimsitic (OP) technology, then the biggest difficulty lies in how to execute a smart contract transaction on Bitcoin.

In response to the above difficulties, [Robin Linus](https://twitter.com/robin_linus) presented a solution (** fruad proof + timelock **) in the white paper [BitVM](https://bitvm.org/bitvm.pdf), which draws on the fraud proof challenge mechanism in [Arbitrum](https://github.com/OffchainLabs/nitro/blob/master/docs/Nitro-whitepaper.pdf). The specific principles are shown in sections 6.1 & 6.2. In [BitVM](https://bitvm.org/bitvm.pdf), the program will be compiled into bytecode composed of opcodes supported by [BitVM](https://bitvm.org/bitvm.pdf). The paper gives OP_NAND. Since Bitcoin does not support this opcode natively, it needs to be implemented separately (see [Opcodes used in Bitcoin Script - Bitcoin Wiki](https://wiki.bitcoinsv.io/index.php/Opcodes_used_in_Bitcoin_Script) for the opcode currently supported by Bitcoin). The specific details are shown in the following figure:
[<p style="text-align: center">Fig1. Example in BitVM</p>](https://bitvm.org/bitvm.pdf)

According to the execution order of opcodes, these opcodes are formed into a program taptree, as shown in the following figure:

[<p style="text-align: center">Fig2. Example in BitVM </p>](https://bitvm.org/bitvm.pdf)

In this way, according to the bisection protocol, the challenge mechanism is as follows: only log2(n) numbers of challenges are needed to find the instruction that executes the error. As shown in the figure below, assuming that the prover is doing evil in NAND3.

[<p style="text-align: center">Fig3. Example in BitVM </p>](https://bitvm.org/bitvm.pdf)

The operating mechanism of BitVM is shown in the following figure:

[<p style="text-align: center">Fig4. Example in BitVM </p>](https://bitvm.org/bitvm.pdf)

Using Arbitrum's fraud proof principle, it is possible to determine whether a prover has committed wrongdoing without the need for a complete transaction replay on Bitcoin, but there are still several drawbacks:
1. At present, [BitVM](https://bitvm.org/bitvm.pdf) only supports one opcode, which, when compiling a complex program, drastically increases its size. Fixed in 10/15/2023, they support a few more opcodes now.
2. Based on point 1, the number of rounds of Bisection Protocol execution will be increased.
3. During the challenge, the verifier needs to re-execute the program to determine the location of the prover's wrongdoing.
4. Before the protocol is executed, the program taptree needs to be encoded between the prover and the verifier, and different programs need to be executed separately.

**Points 1 and 2 can be solved by increasing the amount of opcodes of the VM, points 3 and 4 can be solved by introducing ZK technology.
1. Prover generates a proof for the execution of a transaction, while a Challenger of a fraud proof only needs to perform the verification process of the STARK algorithm.
2. Regardless of the original program, the prover and verifier only need to build a verify program taptree and make a commitment, which is fixed and does not need to be executed repeatedly.**

That is, a ZKVM needs to be built on top of Bitcoin, not a VM. The new logic will be shown in the following figure:
<p style="text-align: center">Fig5. Process flows in ZKVM</p>

## 2. Bitcoin has real Programmable Privacy in Layer2 simultaneously

If we can build a programmable Layer2 on Bitcoin, then we can define more features on it, because The Challengers always challenge the verification program, so supporting more functions will not affect the entire mechanism.
In the articles [Sin7y Tech Review (35) Hybrid Rollup - The Next-Generation Infrastructure](https://hackmd.io/@sin7y/ByKMMcHwh) and [Hybrid Rollup - What do Aztec, Miden, & Ola Hold for the Future of Next-Generation Infrastructure?](https://hackernoon.com/hybrid-rollup-what-do-aztec-miden-and-ola-hold-for-the-future-of-next-generation-infrastructure), we introduced how to define a privacy-focused ZKVM. If we can introduce the Privacy feature into the second layer of Bitcoin, the new logic is shown in the following figure:
<p style="text-align: center">Fig6. Process flows in Privacy - first ZKVM</p>

This allows for building any privacy-free Dapps or any logical privacy Dapps on top of Bitcoin, entirely depending on the needs of the developer.

## 3. Others
As mentioned earlier, the above design is a new attempt based entirely on previous experience accumulation and inspiration from [BitVM](https://bitvm.org/bitvm.pdf). This article is mainly to stimulate more developers and researchers to further explore and iterate on potential solutions together.

## 4. References

1. [BitVM](https://bitvm.org/bitvm.pdf)
2. [MATT](https://hackmd.io/@salvatoshi/H11zrr4cq#MATT-General-smart-contracts-in-bitcoin-via-covenants)
3. [Bisection protocol in Arbitrum](https://github.com/OffchainLabs/nitro/blob/master/docs/Nitro-whitepaper.pdf)