How Bitcoin verification works
PreviousTransaction Processes and Execution Layers in RuneraNextRunera's Approach to Verifying Computations on Bitcoin
Last updated
Last updated
In the context of Runera, understanding the significance and function of Commitment is crucial. Commitment plays a pivotal role in ensuring the integrity of off-chain transactions and state transitions. If a transaction or state transition processed off-chain is disputed, the involved parties may need to temporarily upload part of the data to the Bitcoin blockchain for verification, with Bitcoin nodes acting as arbiters.
In Runera, the Proposer sends the Zero-Knowledge (ZK) circuit execution results to the Bitcoin blockchain for verification by the Verifier. A challenge arises in ensuring that the data temporarily uploaded by parties is relevant and not random or junk data. Thus, a mechanism must be designed to allow Bitcoin nodes to independently verify that the off-chain data submitted is pertinent to the dispute, leveraging specific properties of Commitment.
The Proposer periodically publishes a Commitment on the Bitcoin blockchain, associating it with a series of off-chain state transitions and transaction processes. This Commitment effectively maps a large volume of off-chain data, serving as a compact representation. Essentially, it functions like a hash of extensive off-chain data.The Proposer periodically publishes a Commitment on the Bitcoin blockchain, associating it with a series of off-chain state transitions and transaction processes. This Commitment effectively maps a large volume of off-chain data, serving as a compact representation. Essentially, it functions like a hash of extensive off-chain data.
In blockchain scenarios, it is common to use a hash of the original data as a Commitment, publishing it on a designated platform. For instance, some Ethereum Layer2 projects process transactions off-chain and then publish a hash of the new data (datahash) on-chain. If the original data corresponding to the datahash is requested and not provided off-chain, the Sequencer must disclose it on the Ethereum blockchain. The previously published datahash serves to verify the authenticity of the disclosed data.
In Runera and other mainstream Ethereum Layer2 solutions, the Proposer aggregates a large batch of off-chain transactions and state changes, generates a Commitment, and publishes it to the Bitcoin blockchain. This process significantly reduces the size of data uploaded to the chain.
After submitting a Commitment, verification is necessary. For Ethereum Layer2, complex smart contracts on the Ethereum blockchain can verify the ZK Proof associated with the Commitment. Valid Commitments update the Layer2 State root, while invalid ones are rejected.
The Bitcoin blockchain lacks a Turing-complete smart contract system, making direct verification of ZK Proofs infeasible. Instead, a trigger-based challenge mechanism is employed. The Proposer publishes the state change Commitment to the Bitcoin blockchain, assuming it is correct unless challenged. Anyone can question the Commitment and its associated data.
A challenge involves presenting evidence on-chain to prove that the Commitment-related data is problematic. In Runera, the Proposer can locate the complete dataset corresponding to the Commitment in off-chain storage and selectively upload the relevant data indicated by the Challenger to the Bitcoin blockchain.
Runera simplifies the verification process by requiring only one round of interaction to complete verification, unlike the multiple rounds needed in BitVM and Arbitrum. If a Commitment remains unchallenged, it becomes finalized, and the associated off-chain data also becomes irreversible. This ensures that Runera’s ledger data shares the same irreversibility as the Bitcoin mainnet.
Generally, after a Commitment is submitted, it needs to be verified. For Ethereum Layer2, the Ethereum blockchain can run complex smart contracts that can verify the ZK Proof associated with the Commitment through smart contracts, determining whether the newly submitted Commitment is valid. If valid, the smart contract updates the recorded Layer2 State root. If the submitted ZK proof fails the smart contract's verification, we consider this state update invalid, reject this Commitment, and refuse to update the State root.
Challenge-Response Protocol
The challenge-response protocol allows users to question and challenge the correctness of a Commitment. If a Commitment is successfully challenged, it is annulled on the Bitcoin blockchain, and Runera’s off-chain Proposer node submits a new state commitment. This mechanism ensures that transaction order remains unchanged even if a Commitment is challenged and annulled.
New nodes joining the Layer2 network can review historical data on the Bitcoin blockchain, parse transaction data and state hashes processed in Layer2 history, and synchronize with other Rollup nodes. This effectively uses Bitcoin as a comprehensive log for Layer2’s historical data, ensuring all past records are irreversible once a state hash/Commitment is finalized on the Bitcoin chain.
