Last updated
original: https://medium.com/zkswap/brc-layer2-design-43dfe54b9448
author: ZKBase
The primary objective of this design is to establish a Layer 2 network tailored specifically for the Bitcoin blockchain. The Layer 2 network for BTC is strategically crafted to meet the surging demand for faster and more efficient transactions within the Bitcoin ecosystem. This is achieved by offloading certain transaction processing tasks from the main blockchain, aiming to alleviate congestion and substantially reduce the time and resources required for transaction confirmations. Recognizing the inherent limitations in the computing capabilities of the Bitcoin Virtual Machine (VM), our design uses BitVM, which demonstrates the potential for executing smart contracts between two parties. Leveraging a challenge and response scheme, BitVM showcases a novel approach to enhance the programmability of the Bitcoin network, overcoming traditional constraints. To enhance the security and integrity of the Layer 2 network, state verification is facilitated through the integration of Zero-Knowledge Proof technologies. These advanced cryptographic techniques allow Layer 1 to efficiently verify the states of the Layer 2 network without compromising the privacy and confidentiality of the underlying transactions.
0. Architecture The Layer 2 blockchain adopts an account model. The entire blockchain’s status is proven through zkVM, based on the Halo2 proving system. The Layer 2 state is synchronized with the Bitcoin network, and all Layer 2 states are verified by the Zero-Knowledge Proof (ZKP) verifier implemented by BitVM. One UTXO is used to trace all Layer 2 states. Additionally, a trusted oracle is employed to ensure that only the lock/unlock scripts of input/output UTXOs follow the Layer 2 protocol.
1. Layer 2 Committee & Trusted Oracle A selected group of users forms the Layer 2 committee responsible for monitoring the overall health of the Layer 2 network. In case of protocol issues, the committee can intervene to stop the protocol and safeguard all users’ assets. The trusted oracle is crucial for validating the correctness of input/output UTXOs and scripts
2. Layer 1 to Layer 2 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 effectively ‘moved’ from Layer 1 to Layer 2. Protocol or committee accounts exclusively handle the ‘transfer’ of all ‘deposited’ UTXO assets.
3. Blocks Syncing to Layer 1 All Layer 2 network states are synced to Layer 1 in the form of blocks. For one block, the following information should be provided: transactions in one specific block new accounts’ state with those applied transactions new UTXOs for the current block state (always ready even if protocol is broken) block information of Bitcoin network zero-knowledge proof (proving the state transition from last block to current block is correct) All those states in Layer 1 is recorded in one UTXO transaction history.
3.1 More about proof Zero-knowledge proof is employed to verify the correctness of the Layer 2. The proof tries to prove: Block Transactions of Layer 2 are signed correctly. New state of all accounts are handled correctly. All deposits until one specfic block of Layer 1 are handled correctly. For the current state, all UTXO distributions are created correctly.
3.2 Block information Challenge To ensure the correctness of specified block information in Layer 1, a challenge and response scheme is utilized. Provers can demonstrate the accuracy of block information by indicating the presence of N more blocks after a specific block within a locked time period.
3.3 ZKP Circuit and BitVM Enhancement As illustrated in BitVM paper, ZKP proof verfication can be expressed as one binary circuit, which can be challenged by two parties. With pre-signed transactions, challenges can be sent to get bit commitments of the circuit. If 0 and 1 are exposed by challenges, challenger wins. To use BitVM to verify ZKP verification, two things should be paid attention to: same binary circuit commitments should be used once. That’s to say, if same circuit comments used for many blocks, 0 and 1 of one bit commitment may be exposed. For ZKP verificaion, beside circuit satisfaction, “public input” should be checked too. To handle these two shortcomings, for each block of Layer 2, one unique binary circuit is created and the “public inputs” are fixed. Bitcoin Scripts are used to handle Public Input hashing and checking. And the correct public input bit commitments are checked by trusted oracle In terms of circuit satisfaction, any member within the committee has the ability to raise challenges.
4. Layer 2 to Layer 1 Assets can be moved from Layer 2 to Layer 1 through two methods: withdrawal and force-withdrawal. Withdrawal transactions are triggered from Layer 2, and ZKP circuits ensure transaction handling as expected. Force-withdrawal transactions are initiated from the Bitcoin network.
4.1 Withdraw & Force-withdraw transaction Withdrawal transactions, triggered from Layer 2, are verified using ZKP circuits to ensure proper transaction handling. Force-withdraw transactions, initiated from the Bitcoin network, must be included in the next block state update. 4.2 UTXO distributions When the state of a block is updated, UTXO distribution is synchronized. In the event of a protocol stop, all UTXOs can be applied to ensure the safety of all user assets. And among those UTXOs, only withdraw or force-withdraw UTXOs are signed by protocol.
5. Layer 2’s Exit Once ZKP proof is NOT verified, committee must halt and exit the protocol. If protocol stops, committee signed all UTXO distributions specified in latest block state from Layer 2. With the signatures, a user can exit Layer 2 without any loss.
Reference
BitVM: https://bitvm.org/bitvm.pdf
Bitcoin Whitepaper: https://bitcoin.org/bitcoin.pdf
Halo2 explanation: https://electriccoin.co/blog/explaining-halo-2/
ZKBase Team
