Verify on the Bitcoin Network
Using BitVM to verify certain state proofs on Zulu.
Last updated
Using BitVM to verify certain state proofs on Zulu.
Last updated
Regardless of the bridge or L2 design, the use of BitVM is imperative for verifying certain state proofs.
BitVM, essential for verifying state proofs on Bitcoin, acts as a Turing-complete virtual machine, enabling the composition of various program logics and ensuring the verification of Zulu’s state transitions directly on the Bitcoin Network.
Consequently, the crux of the verification process on Bitcoin lies in the BitVM design. BitVM is envisioned as a Turing-complete virtual machine equipped with its own collection of opcodes, facilitating the composition of various program logics.
In crafting the Instruction Set Architecture, the design adheres to the following key characteristics:
Support for Turing completeness: This necessitates the ability to handle arbitrary computations.
Simplified Instruction Set Architecture: Custom BitVM opcodes must be implemented using the opcodes currently supported by Bitcoin.
In the design of BitVM, Zulu will uphold these principles, drawing inspiration from similar designs found in projects like Starkware's Cairo VM and Ola's OlaVM. The Zulu team aims to build upon these foundations. The introduction of the Bisection mechanism allows both provers and challengers to contest the execution trajectory based on BitVM's Instruction Set Architecture. It involves identifying disputed opcodes and subsequently verifying the corresponding input, output, and current instructions on Bitcoin.
Concerning the challenge mechanism's design, following a concept similar to Robin's, Zulu will challenge all modules of BitVM. The figure below illustrates this design concept from Robin's framework (https://github.com/BitVM/BitVM/blob/main/docs/bitVM_graph_v2.svg).
As depicted in the illustration:
Paul and Vicky jointly undertake the challenge of a program. In Zulu, this challenging program involves ZKP verification, utilizing the STARK algorithm for the ZKP algorithm.
Both Paul and Vicky individually execute this program within the BitVM environment, meticulously recording a sequence of changes in the BitVM root.
Commencing from the initial root, with each execution, a new root is derived until all instructions are executed.
Given Vicky's identification of Paul's misconduct, there is a high likelihood that the root values obtained by Paul and Vicky will differ.
Through a continuous binary search approach, the goal is to persistently identify the instruction corresponding to the differing roots.
Since BitVM instructions encompass extensive information, including the instruction type, operands, and contextual information both upstream and downstream, it is imperative to challenge each of these aspects separately.