Written by: ZKBase (formerly ZKSpace)
The main goal of this design is to build a custom Layer 2 network for the Bitcoin blockchain. The Bitcoin Layer 2 network is designed to meet the growing demand for faster and more efficient transactions within the Bitcoin ecosystem. By releasing certain transaction processing tasks from the main network, it aims to alleviate the congestion problem of the Bitcoin main network and significantly reduce the time required for transaction confirmation.
Given the inherent limitations of the Bitcoin Virtual Machine (VM) computational power, our design uses BitVM, which demonstrates the potential for executing smart contracts between two layers of the network. By leveraging a challenge and response scheme, BitVM demonstrates a new approach to Bitcoin network programmability that breaks through traditional limitations.
To enhance the security and integrity of the Bitcoin Layer 2 network, the design implements state verification by integrating zero-knowledge proof (ZK) technology. These advanced cryptographic techniques allow the Bitcoin mainnet to effectively verify the state of the Layer 2 network without compromising the privacy and confidentiality of underlying transactions. Zero-knowledge proofs can verify information without revealing the specific details of the transaction, thereby ensuring the integrity of the Layer 2 network while protecting privacy.
Overall, the design aims to improve the scalability, speed and efficiency of the Bitcoin network through the Layer2 network, the use of BitVM for smart contract execution, and the integration of zero-knowledge proof technology for state verification, while maintaining the privacy and security of the underlying transactions.
0. Architecture
The Layer2 blockchain adopts an account model. The state of the entire blockchain is verified by zkVM based on the Halo2 proof system. The Layer2 state is synchronized with the Bitcoin main network, and all Layer2 states are verified by the zero-knowledge proof (ZKP) verifier implemented by BitVM. We use a UTXO to track all Layer2 states. In addition, we also use a trusted oracle to ensure that only the input/output of the locking/unlocking script follows the Layer2 protocol.
1. Layer 2 Committee and Trusted Oracle
The Layer2 committee, composed of a group of selected users, is responsible for overseeing the overall health of the Layer2 network. In the event of a protocol problem, the committee can intervene and stop the protocol to protect the assets of all users. Trusted oracles are very important for verifying the correctness of input/output UTXO and scripts.
2. From the first floor to the second floor
A single Taproot address is created on the Bitcoin network to represent the Layer 2 protocol. When a UTXO is created and transferred to the Taproot address, the corresponding UTXO is actually "recharged" from the Bitcoin mainnet to Layer 2.
The protocol or committee account specifically handles the "transfer" permission for all UTXO assets "deposited" to Layer2. Only the protocol, trusted oracle, or committee account can change the ownership of the deposited UTXO. The trusted oracle ensures that the correct output UTXO script is included in the ownership transfer transaction.
3. Synchronize to the Bitcoin mainnet block
The status of all Layer 2 networks is synchronized to the Bitcoin mainnet in the form of blocks. For a block, the following information should be provided:
Transactions in a particular block;
The new account state after applying these transactions;
New UTXOs in the current block state (always ready even if the protocol is broken);
Block information of the Bitcoin network;
Zero-knowledge proof (proving that the state transition from the previous block to the current block is correct) All of these states of the Bitcoin mainnet are recorded in a UTXO transaction history.
3.1 More information about proofs
Zero-knowledge proof is used to verify the correctness of Layer 2. It attempts to prove the following:
Layer2 block transactions are correctly signed.
The new state of all accounts is processed correctly.
All deposit transactions before a certain block on the Bitcoin mainnet are processed correctly.
For the current state, all UTXO allocations are created correctly.
3.2 Block Information Challenge
To ensure the correctness of the block information specified in the Bitcoin mainnet, we use a challenge and response scheme. The prover can prove the accuracy of the block information by pointing out that there are N blocks after a specific block within the lock time period.
3.3 ZKP Circuits and BitVM Enhancements
As shown in the BitVM paper, ZKP verification can be represented as a binary circuit that can be challenged by two parties. Through 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, two points need to be noted:
The same binary circuit commitment can only be used once. That is, if the same circuit commitment is used for multiple blocks, it may reveal both the 0 and 1 of a bit commitment.
For ZKP verification, in addition to the circuit’s satisfiability, the “common inputs” should also be checked.
To deal with these two shortcomings, for each block of Layer 2, a unique binary circuit is created and the "public input" is fixed. Bitcoin script is used to process the hash and check of the public input. The correct public input bit commitment is checked by a trusted oracle. In terms of circuit satisfaction, any member of the committee has the right to challenge it.
4. From Layer2 to Bitcoin Mainnet
Assets can be moved from Layer2 to the Bitcoin mainnet in two ways: withdrawal and force-withdrawal. Withdrawal transactions are triggered from Layer2, and the ZKP circuit ensures that the transaction is processed as expected. Forced withdrawal transactions are initiated from the Bitcoin network.
4.1 Withdrawal and Forced Withdrawal Transactions
Withdrawal transactions triggered from Layer 2 are verified using ZKP circuits to ensure that transactions are processed correctly. Mandatory withdrawal transactions initiated from the Bitcoin network must be included in the next block status update.
4.2 UTXO Allocation
When the state of a block is updated, the UTXO allocation is synchronized. In the event of a protocol stop, all UTXOs can be applied to ensure the safety of all user assets. Among these UTXOs, only the UTXOs for withdrawal or forced withdrawal are signed by the protocol.
5. Layer 2 Exit
Once the ZKP is not verified, the committee must stop and exit the protocol. If the protocol stops, the committee signs all UTXO allocations specified in the latest block state of Layer2. With these signatures, users can withdraw from Layer2 without any loss.
