ZKByte: A Bitcoin Layer 2 scaling solution based on zero-knowledge proofs and BitVm
The main goal of this design is to establish a specially customized Layer2 network for the Bitcoin blockchain.Author: ZKBase
The main goal of this design is to establish a custom Layer2 network for the Bitcoin blockchain. The Bitcoin Layer2 network aims to meet the growing demand for faster and more efficient transactions within the Bitcoin ecosystem. By offloading certain transaction processing tasks from the mainnet, it aims to alleviate congestion on the Bitcoin mainnet and significantly reduce the time required for transaction confirmations.
Given the inherent limitations of the Bitcoin Virtual Machine (VM) computational capacity, our design utilizes BitVM, which demonstrates the potential for executing smart contracts across two-layer networks. By leveraging a challenge-response scheme, BitVM showcases a new approach to programmability on the Bitcoin network, breaking traditional constraints.
To enhance the security and integrity of the Bitcoin Layer2 network, this design implements state verification through the integration of zero-knowledge proof (ZK) technology. These advanced cryptographic techniques allow the Bitcoin mainnet to effectively verify the state of the Layer2 network without compromising the privacy and confidentiality of the underlying transactions. Zero-knowledge proofs can validate information without revealing specific details of the transactions, thereby ensuring the integrity of the Layer2 network while protecting privacy.
Overall, this design aims to improve the scalability, speed, and efficiency of the Bitcoin network through a Layer2 network, the execution of smart contracts using BitVM, and the integration of zero-knowledge proof technology for state verification, all 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 through a zkVM based on the Halo2 proof system. The Layer2 state is synchronized with the Bitcoin main network, and all Layer2 states are validated by zero-knowledge proof (ZKP) validators implemented by BitVM. We use a UTXO to track all Layer2 states. Additionally, we employ a trusted oracle to ensure that only the inputs/outputs of locked/unlocked scripts adhere to the Layer2 protocol.
1. Layer2 Committee and Trusted Oracle
The Layer2 committee, composed of a group of selected users, is responsible for overseeing the overall operation of the Layer2 network. In the event of protocol issues, the committee can intervene and halt the protocol to protect the assets of all users. The trusted oracle is crucial for validating the correctness of input/output UTXOs and scripts.
2. From Layer1 to Layer2
A single Taproot address is created on the Bitcoin network to represent the Layer2 protocol. When a UTXO is created and transferred to the Taproot address, the corresponding UTXO is effectively "recharged" from the Bitcoin mainnet to Layer2.
The protocol or committee account specifically handles the "transfer" authority of all UTXO assets "recharged" 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 scripts are included in ownership transfer transactions.
3. Blocks Synced to the Bitcoin Mainnet
The states of the entire Layer2 network are synchronized to the Bitcoin mainnet in the form of blocks. For a block, the following information should be provided:
- Transactions within a specific block
- New account states after applying these transactions
- New UTXOs under the current block state (always prepared even if the protocol is compromised)
- Block information from the Bitcoin network
- Zero-knowledge proof (proving that the state transition from the previous block to the current block is correct) All these states of the Bitcoin mainnet are recorded in a UTXO transaction history.
3.1 More Information on Proofs
Zero-knowledge proofs are used to verify the correctness of Layer2. The following needs to be proven:
- The block transactions of Layer2 are correctly signed.
- The new states of all accounts are correctly processed.
- All recharge transactions prior to a specific block on the Bitcoin mainnet are correctly processed.
- For the current state, the allocation of all UTXOs is correctly created.
3.2 Block Information Challenge
To ensure the correctness of the specified block information in the Bitcoin mainnet, we use a challenge-response scheme. The prover can demonstrate the accuracy of the block information by pointing out that there are N additional blocks after a specific block within the locked time period.
3.3 ZKP Circuit 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. By pre-signing transactions, challenges can be sent to obtain the Bit commitment of the circuit. If 0 and 1 are revealed, the challenge is successful. To use BitVM for ZKP verification, the following two points must 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 a 0 and 1 of a Bit commitment.
For ZKP verification, in addition to the satisfiability of the circuit, the "public inputs" should also be checked.
To address these two shortcomings, a unique binary circuit is created for each block of Layer2, with fixed "public inputs." Bitcoin scripts are used to handle the hashing and checking of public inputs. The correct public input Bit commitment is checked by the trusted oracle. Regarding circuit satisfiability, any member within the committee has the right to raise a challenge.
4. From Layer2 to the Bitcoin Mainnet
Assets can move 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 transactions are processed as expected. Force-withdrawal transactions are initiated from the Bitcoin network.
4.1 Withdrawal and Force-withdrawal Transactions
Withdrawal transactions triggered from Layer2 are verified using the ZKP circuit to ensure proper processing. Force-withdrawal transactions initiated from the Bitcoin network must be included in the next block state update.
4.2 UTXO Allocation
When the state of a block is updated, the UTXO allocation is synchronized. In the case of protocol halting, all UTXOs can be applied to ensure the safety of all user assets. Among these UTXOs, only the UTXOs for withdrawal or force-withdrawal are signed by the protocol.
5. Layer2 Exit
Once the ZKP is not verified, the committee must stop and exit the protocol. If the protocol halts, the committee will sign for all UTXO allocations specified in the latest block state of Layer2. With these signatures, users can withdraw from Layer2 without any loss.
References:
- BitVM: https://bitvm.org/bitvm.pdf
- Bitcoin Whitepaper: https://bitcoin.org/bitcoin.pdf
- Halo2 explanation: https://electriccoin.co/blog/explaining-halo-2/
