Validating Zero-Knowledge Proofs on Bitcoin

Bitroot inherits the security of Bitcoin by recording zero-knowledge proof verification commitments on Bitcoin, allowing arbitrary observers to challenge the data against the commitments with a mechanism that allows for consensus rollups on Bitcoin.

The design aims to improve the scalability, speed, and efficiency of the Bitcoin network by integrating zero-knowledge proof technology between the Bitroot Layer2 network and the Bitcoin network for bi-directional state verification, while maintaining the privacy and security of underlying transactions.

Architecture

Bitroot's Layer2 blockchain uses an account-based model. The state of the entire blockchain is verified by zkVM, which is based on the Halo2 proof system.The Bitroot state is synchronised with the Bitcoin main network, and all Bitroot state is verified by the Zero Knowledge Proof (ZKP) verifier implemented in BitVM. We use a UTXO to track all Bitroot state. In addition, we use a trusted predicate to ensure that only the input/output of the lock/unlock scripts follow the Bitroot protocol.

1. Bitroot Committee and Trusted Prophecy Machine

The Bitroot Committee, composed of a group of selected users, is responsible for overseeing the overall operation of the Bitroot network. In case of protocol problems, the committee can intervene and stop the protocol, protecting the assets of all users. The Trusted Predictor is important for verifying the correctness of input/output UTXOs and scripts.

1. Layer 1 to Layer 2

A single Taproot address is created to represent the Bitroot protocol on the Bitcoin network. When a UTXO is created and transferred to the Taproot address, the corresponding UTXO is actually "recharged" from the main Bitcoin network to Bitroot.

The protocol or committee account specifically handles the "transfer" of all UTXO assets that are "funded" to Bitroot. Only the Protocol, Trusted Prophet or Commission account can change the ownership of deposited UTXO. The Trusted Seer ensures that the correct output UTXO scripts are included in the ownership transfer transaction.

1. Blocks Synchronised to the Main Bitcoin Network

The status of all Bitroot networks is synchronised to the main Bitcoin network in the form of blocks. For a block, the following information should be provided:

Transactions in a particular block

The new account status after applying those transactions

The new UTXO in the current block state (always ready even if the protocol is broken)

Block information for the Bitcoin network

Zero-knowledge proofs (proof that the state transition from the previous block to the current block is correct) All of these states of the main Bitcoin network are recorded in a UTXO transaction history.

3.1 More information about the proof

Zero-knowledge proofs are used to verify the correctness of Bitroot. An attempt is made to prove the following:

Bitroot's block transactions were signed correctly.

The new state of all accounts was processed correctly.

All top-up transactions prior to a specific block on the main Bitcoin network were processed correctly.

For the current state, all UTXO allocations were created correctly.

3.2 Block Information Challenges

To ensure the correctness of block information specified in the Bitcoin Mainnet, we use a challenge-and-response scheme. A prover can prove the accuracy of block information by pointing out that there are N more blocks that exist after a specific block during the lock time period.

3.3 ZKP Circuit and BitVM Enhancement

As shown in the BitVM paper, ZKP verification can be represented as a binary circuit that can be challenged by two participants. With a pre-signed transaction, a challenge can be sent to obtain a bit commitment for the circuit. If 0 and 1 are revealed, the challenge succeeds. In order to use BitVM to verify ZKP, the following two points need to be noted:

The same binary circuit promise can only be used once. That is, if the same circuit commitment is used for more than one block, it may reveal 0s and 1s for a bit commitment.

For ZKP verification, in addition to circuit satisfaction, the "common input" should be checked.

To deal with these two shortcomings, for each block of Bitroot, a unique binary circuit is created and the "public input" is fixed. Bitcoin scripts are used to handle the hashing and checking of public inputs. Correct public input bits are promised to be checked by a trusted prediction machine. Any member of the committee has the right to challenge the circuit's fulfilment.

1. From Bitroot to the Main Bitcoin Network

Assets can be moved from Bitroot to the main Bitcoin network in two ways: withdrawals (withdrawal) and force-withdrawals. Withdrawal transactions are triggered from Bitroot and the ZKP circuitry ensures that the transaction is processed as expected. Force-withdrawal transactions are initiated from the Bitcoin network.

4.1 Withdrawal and Forced Withdrawal Transactions

Withdrawal transactions triggered from Bitroot are validated using the ZKP circuitry to ensure that the transaction is processed correctly. Mandatory withdrawal transactions initiated from the Bitcoin Network must be included in the next block status update.

4.2 UTXO Allocation

UTXO allocations are synchronised when a block's status is updated. In the case of a protocol halt, all UTXOs can be applied to secure all user assets. Among these UTXOs, only the UTXOs for withdrawals or mandatory withdrawals are signed by the protocol.

1. Bitroot withdrawal

Once ZKP is unverified, the committee must stop and exit the protocol. If the protocol is stopped, the committee signs all UTXO allocations specified in the latest block state of Layer2. With these signatures, users can withdraw their funds from Layer2 without any loss.

References:

1. BitVM: https://bitvm.org/bitvm.pdf

2. Bitcoin Whitepaper: https://bitcoin.org/bitcoin.pdf

3. Halo2 explanation: https://electriccoin.co/blog/explaining-halo-2/