Future Upgrades: Bitcoin's On-Chain Fraud Proof Mechanism

Merlin Chain's Beta mainnet relies on a decentralized Oracle network to provide Data Availability (DA) and Zero-Knowledge Proof (ZKP) verification for its ZK-L2. However, due to the Turing incompleteness of the Bitcoin network, it's not feasible to perform zero-knowledge proof verification directly on the Bitcoin mainnet. Therefore, the traditional approach of verifying zero-knowledge proofs on the first layer blockchain network, as seen in ZK-Rollup solutions, is not applicable to Bitcoin.

Merlin Chain addresses this challenge by utilizing Taproot to write aggregated zero-knowledge proofs and Rollup data into the Bitcoin mainnet. This process ensures that ZK-Rollup data is anchored in Bitcoin and remains tamper-proof. However, this alone cannot guarantee the validity and correctness of transactions within ZK-Rollup or fully leverage Bitcoin's powerful consensus to ensure the security of Layer 2 ZK-Rollup.

In future upgrades, Merlin Chain plans to introduce a Bitcoin on-chain fraud proof mechanism: nodes in the decentralized Oracle network must stake BTC in advance on the Bitcoin network, forming the foundation for the Bitcoin on-chain challenge mechanism. Users can initiate challenges to ZK-Rollup based on compressed transaction data, ZK state roots, and ZK proofs on the Bitcoin mainnet. If the challenge proves inconsistency between data and proofs, users can claim their assets staked in advance on the Bitcoin mainnet, and ZK-Rollup will roll back to the last verified state.

Merlin Chain adopts the Bitcoin on-chain fraud proof mechanism to ensure the correctness of data and ZKP submitted by the decentralized Oracle network. In contrast to Optimistic Rollup, the Bitcoin mainnet no longer conducts fraud proofs for the entire transaction volume but focuses on verifying the security of ZK state roots and ZK proofs.

Prover and Verifier

Merlin Chain's Bitcoin chain fraud proof mechanism adopts a method similar to Optimistic Rollups, with two roles: prover and verifier. The prover compiles the program into a huge binary circuit and submits the circuit to a Taproot address with a leaf script for each logic gate. The prover and verifier pre-sign a series of transactions to enable the challenge-response mechanism between the two. In this form, without having to post all Rollup data, the decentralized Oracle network first publishes and stores it off-chain, and only the Commitment is stored on-chain.

NAND Logic Gate

Any computable function can be represented as a Boolean circuit, and the NAND gate (Negated AND gate) is a universal logic gate that can compose any Boolean function.

Under scripting language, the NAND gate is implemented through two BVCs, and a script that verifies ( A \ NAND \ B = C) is as follows:

// Reveal the preimage of hash c1 or c0 
// At this point, move the bit value of C to the ALT stack 
// Reveal the preimage of hash b1 or b0 
// At this point, move the bit value of B to the ALT stack 
// Reveal the preimage of hash a1 or a0 
// At this point, the bit value of A is in the main running stack, the stack is now A 
// Verify A NAND B == C
// Take out B from the ALT stack, the stack is now B, A 
// Perform the NAND bitwise operation, the stack is now B NAND A 
// Take out C from the ALT stack, the stack is now C, B NAND A 
// Check if they are equal, take out C and B NAND A, and check if they are equal 

Binary Circuit

By combining a series of NAND gates, any circuit can be expressed, with each step being committed under the Taproot leaf nodes, and finally merged into the same Taproot address, allowing the prover to execute any gate in the circuit. To execute a gate, the prover needs to open the corresponding NAND gate and set the input and output bit values. The binary circuit structure off-chain can be very large, but due to the characteristics of Taproot, it can occupy very little space on-chain.

The illustration above is a circuit with 8 different NAND gates, which has four inputs. The input script for such a gate circuit can be represented as

Such a script allows the prover to set the inputs of the gate circuit at any subsequent point in time.


Merlin Chain draws inspiration from the concept of BitVM, executing complex programs off-chain and then placing key evidence on-chain. It has designed the simplest "circuit unit" and leverages the composability of Taproot to combine these units, achieving the capability to implement any executable function on the Bitcoin blockchain. Most transactions that occur on Layer 2 do not need to be re-verified on the BTC chain. However, for any disputed data segment/opcode that is challenged, it must be replayed on Layer 1. If the detection conclusion is that the data previously released by the Proposer has a problem, then the Proposer's pledged assets will be slashed; if there is a problem with the Challenger, then the Challenger's pledged assets will be slashed. If the Prover does not respond to the challenge for a long time, it can also be slashed.

Last updated