A brief analysis of ZKByte: a Bitcoin Layer2 expansion solution based on ZK and BitVm

Words: ZKBase (formerly ZKSpace)

The main goal of this design is to build a specially customized Layer 2 network for BitcoinBlockchain. The Bitcoin Layer 2 network is designed to meet the growing demand for faster and more efficient transactions within the Bitcoin ecosystem. By freeing up certain transaction processing tasks from the Mainnet, it aims to alleviate congestion in the BitcoinMainnet and drastically reduce the time required for transaction confirmation.

Given the inherent limitations of the computing power of the Bitcoin Virtual Machine (VM), our design uses BitVM, which demonstrates the potential of executing smart contracts between two layers of the network. By leveraging challenges and response scenarios, BitVM demonstrates a new approach to Bitcoin network Programmability that breaks down 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 encryption technologies allow BitcoinMainnet to effectively verify the state of the Layer 2 network without compromising the privacy and confidentiality of the underlying transactions. Zero-Knowledge Proof verifies information without revealing the specifics of the transaction, ensuring privacy while ensuring the integrity of the Layer 2 network.

Overall, the design aims to improve the scalability, speed, and efficiency of the Bitcoin network through a Layer 2 network, the adoption 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

Layer 2 Blockchain uses an account model. The state of the entire Blockchain is verified by zkVM based on the Halo2 proof system. The Layer 2 state is synchronized with the BitcoinMainnet network, and all Layer 2 states are verified by the Zero-Knowledge Proof (ZKP) validator implemented by BitVM. We use a UTXO to track all Layer 2 states. In addition, we use a trusted Oracle Machine to ensure that only the input/output of the lock/unlock script follows the Layer 2 protocol.

1, Layer 2 Council, and Trusted Oracle Machine

A Layer 2 committee, made up of a select group of users, oversees the overall health of the Layer 2 network. In the event of a problem with the protocol, the committee can step in and stop the protocol to protect the assets of all users. Trusted Oracle Machine is important for verifying the correctness of input/output UTXOs and scripts.

2, Layer 1 to Layer 2

Create a single TaprootAddress on the Bitcoin network to represent the Layer 2 protocol. When a UTXO is created and transferred to the TaprootAddress, the corresponding UTXO is actually “topped up” from BitcoinMainnet to Layer 2.

The protocol or commission account specifically handles the “transfer” permissions for all UTXO assets that are “deposited” to Layer 2. Only protocols, trusted Oracle Machines, or committee accounts can change ownership of deposited UTXOs. Trusted Oracle Machine ensures that the correct output UTXO script is included in the ownership transfer transaction.

3. The Block synchronized to the BitcoinMainnet

The status of all Layer 2 networks is synchronized to the BitcoinMainnet in the form of a Block. For a Block, the following information should be provided:

· transactions in a particular block;

· the new account status after applying these transactions;

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

· Block information of the Bitcoin network;

· Zero-Knowledge Proof (justifies the state transition from the previous Block to the current Block) The status of all these BitcoinMainnet is recorded in a UTXO transaction history.

3.1 More about attestation

Zero-Knowledge Proof is used to verify the correctness of Layer 2. Attempt to demonstrate the following:

· Block transactions at Layer 2 are correctly signed.

· The new status of all accounts is handled correctly.

· All top-up transactions prior to a particular Block of the BitcoinMainnet 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 BitcoinMainnet, we use a challenge and response scheme. The prover can prove the accuracy of the Block information by pointing out that there are N more Blocks after a particular Block during 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 participants. With a pre-signed transaction, a challenge can be sent to get the bit promise of the circuit. If 0 and 1 are revealed, the challenge is successful. In order to use BitVM to verify ZKP, you need to pay attention to the following two points:

The same binary circuit promises to be used only once. That is, if the same circuit commitment is used for multiple blocks, it may reveal the 0s and 1s of one bit commitment.

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

To deal with these two drawbacks, for each block of Layer 2, a unique binary circuit is created, and a “common input” is fixed. Bitcoin scripts are used to handle hashing and checking of public inputs. The correct public input Bit commitment is checked by a trusted Oracle Machine. As far as circuit satisfaction is concerned, any member of the committee has the right to challenge it.

4. From Layer 2 to BitcoinMainnet

Assets can be moved from Layer 2 to BitcoinMainnet in two ways: withdrawal and force-withdrawal. Withdrawal transactions are triggered from Layer 2, and the ZKP circuit ensures that transactions are 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 validated using ZKP circuits to ensure that transactions are processed correctly. Forced 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 event that the protocol is stopped, all UTXOs can be applied to ensure the security of all user assets. Of these UTXOs, only the UTXOs that are withdrawn or forced to be withdrawn are signed by the protocol.

5. Layer2 exits

Once the ZKP is unverified, the committee must cease and withdraw from the protocol. If the protocol is stopped, the committee signs all UTXO allocations specified in the latest Block state of Layer 2. With these signatures, users can withdraw from Layer 2 without any loss.