Commitment and Verification on Bitcoin
Here, it's important to emphasize the meaning and role of Commitment. In the technical schemes of BitVM, the Commitment is a significant element. For instance, suppose someone questions a transaction/state transition processed off-chain, demanding direct inspection of the disputed transaction/state transition result on the Bitcoin blockchain. This requires the parties involved to temporarily upload part of the data to the Bitcoin blockchain, where Bitcoin nodes act as "judges" to adjudicate the dispute. Within SatoshiVM, however, the Proposer sends the ZK circuit execution results to the BTC chain at once, further verified by the Verifier. However, the issue lies in how we ensure that the data temporarily uploaded by the parties is what the SatoshiVM Verifier needs, rather than random gibberish or other forms of junk data. To address this, a mechanism needs to be designed to allow Bitcoin nodes to independently determine whether the off-chain data submitted to the chain is relevant to the dispute at hand. This relies on some specific properties of Commitment.
The function of Commitment is as follows: The Proposer can periodically publish Commitment on the Bitcoin blockchain, which is associated with a series of state transitions/transaction processes that occur off-chain. In other words, the Commitment maps a large volume of off-chain data. Despite this, the Commitment itself is concise; even if associated with thousands of transactions/state transitions, the size of the Commitment can be very small. It can be roughly understood as a hash of a large batch of off-chain data (the actual situation is more complex than this analogy).
In blockchain-related scenarios, it's common to hash original data and use the hash value as a Commitment, publishing it on a designated platform. Taking some Layer2 projects in the Ethereum ecosystem as an example, after processing a batch of transactions off-chain, the Sequencer might not directly send the transaction data to the Ethereum blockchain. Instead, the Sequencer publishes the hash value of the new data (datahash) on-chain as a commitment, while the raw data corresponding to the datahash is published off-chain.
If someone cannot obtain the original dataset corresponding to the datahash from off-chain, they will request the Sequencer to disclose the data directly on the Ethereum blockchain. The datahash previously published on-chain as a Commitment then serves its purpose: after the Sequencer publishes the data on-chain, smart contracts or third-party observers can immediately determine whether the data corresponds to the datahash. This example illustrates a simple case of how a Commitment becomes effective. Light nodes or cross-chain bridge projects often use Merkle Proof and Merkle root, another form of Commitment, which has a broader range of applications. This will not be elaborated on here.
In the design of SatoshiVM and mainstream Ethereum Layer2, the Proposer periodically aggregates a large batch of transactions and state change data processed off-chain, generating a Commitment and then publishing this Commitment to the Bitcoin blockchain. This is equivalent to publishing a summary compression value of a large batch of off-chain data to the Bitcoin blockchain, significantly reducing the size of the data uploaded to the chain.
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.
On the Bitcoin (BTC) blockchain, it's not possible to implement a Turing-complete smart contract system, so many scenarios cannot be directly realized. For example, it's currently not feasible for programs on the Bitcoin blockchain to directly verify the validity of ZK Proofs. This would require forking the Bitcoin mainnet to support new opcodes. Under the current circumstances, if Layer2 is to inherit the security of Layer1, or for Layer1 to guarantee the validity of Layer2 state updates, it would rely on an on-chain, trigger-based challenge mechanism.
As mentioned earlier, the Proposer will publish the state change Commitment to the Bitcoin blockchain. Generally, we optimistically assume that the Commitment submitted by the Proposer is correct, and the associated off-chain data is also without issues. However, we also allow anyone to question if there are problems with the Commitment and its associated data. The process of initiating a challenge and presenting evidence on-chain to prove that some data associated with the Commitment is problematic is known as a challenge.
In the BitVM scheme, a user challenging a particular Commitment needs to initiate a Challenge against the result of an off-chain state transition. The Proposer can find the complete dataset corresponding to the Commitment in the off-chain storage layer and select the data indicated by the Challenger to be sent on-chain.
Of course, both parties can determine which Commitment value is problematic through multiple rounds of interactive communication, then through on-chain and off-chain interaction and communication, pinpoint the extremely small data fragment associated with the problematic Commitment. The Proposer can then disclose this small piece of data on the Bitcoin blockchain, thus avoiding the need to disclose too much data at once.
Once both parties have determined which specific data is problematic, the next step involves using Bitcoin scripts to directly verify the newly submitted data on the Bitcoin blockchain to determine if there are any issues. If issues are found, it indicates that the node which published the Commitment released an incorrect commitment, demonstrating fraudulent behavior, and should be penalized.
If a Commitment remains unchallenged, it will inevitably be finalized. Once a Commitment is finalized, the large batch of off-chain data associated with it will also be finalized and become irreversible. Through this method, SatoshiVM can ensure that the ledger data has the same irreversibility as the Bitcoin mainnet.
Unlike BitVM, SatoshiVM significantly simplifies the process of "multiple rounds of interaction to confirm which small piece of data is problematic," requiring only one round of interaction to complete the verification process. In BitVM and Arbitrum, this process could last several hours.
The scheme where users initiate challenges and question the correctness of a Commitment is known as challenge-response protocol. When a Commitment is successfully challenged, it will be annulled on the Bitcoin chain, and SatoshiVM's off-chain Proposer node will propose a new state commitment, submitting it to the chain. Since the submission of state commitments is unilaterally determined by the Proposer and not bound to the transaction data published off-chain and on-chain by the Sequencer, even if a State Commitment is challenged and annulled, the transaction order already determined off-chain by SatoshiVM will not change. As long as the transaction order observed by each node remains unchanged, their local record of the current state will not change.
This is analogous to the Sequencer informing everyone in advance that the next transaction will calculate “1+1=?”. After receiving this transaction, each Rollup Node directly computes the correct result = 2. If a Proposer declares a hash on the Bitcoin chain, claiming this hash corresponds to the result of 1+1, but in reality, this hash corresponds to the number 3, then a node will initiate a challenge.
However, the Commitment published on the Bitcoin chain does not affect the Rollup node's own judgment. It merely means that the system will periodically disclose the current state hash (Commitment) on the Bitcoin chain, using Bitcoin as a log for Layer2's history. Once the state hash/Commitment is finalized on the Bitcoin chain, all past historical records are assumed to be irreversible.
A new node joining the Layer2 network only needs to review the historical data on the Bitcoin chain, parse out the transaction data and state hashes processed in Layer2 history, and can then catch up with the pace of other Rollup nodes, knowing the latest Layer2 state without relying on other Rollup Nodes to provide historical data. This essentially uses Bitcoin as a large bulletin board.
Last updated
