BitVMX: A CPU for Universal Computation on Bitcoin

TL;DR

BitVMX tackles the challenge of verifiably executing arbitrary programs on Bitcoin by introducing a general-purpose CPU whose state is captured with hash-chain traces. It replaces Merkle-tree based traces with a hash-chain mechanism and uses a message-linking protocol over pre-signed transactions to propagate state across a dispute graph, enabling an n-ary, multi-round verification game. The key contributions include the hash-chain trace representation, a flexible CPU model for common architectures, and a comprehensive on-chain challenge suite (trace, input, read, last-step, PC, opcode, and execution challenges) that localizes and proves faults without excessive on-chain computation. The framework aims to balance transaction costs, verifier/prover costs, and precomputation versus round complexity, with potential applications in bridges, aggregators, and SNARK/STARK verifiers on Bitcoin, while leaving room for future generalization to multiple verifiers and economic incentivization.

Abstract

BitVMX is a new design for a virtual CPU to optimistically execute arbitrary programs on Bitcoin based on a challenge response game introduced in BitVM. Similar to BitVM1 we create a general-purpose CPU to be verified in Bitcoin script. Our design supports common architectures, such as RISC-V or MIPS. Our main contribution to the state of the art is a design that uses hash chains of program traces, memory mapped registers, and a new challenge-response protocol. We present a new message linking protocol as a means to allow authenticated communication between the participants. This protocol emulates stateful smart contracts by sharing state between transactions. This provides a basis for our verification game which uses a graph of pre-signed transactions to support challenge-response interactions. In case of a dispute, the hash chain of program trace is used with selective pre-signed transactions to locate (via $n$-ary search) and then recover the precise nature of errors in the computation. Unlike BitVM1, our approach does not require the creation of Merkle trees for CPU instructions or memory words. Additionally, it does not rely on signature equivocations. These differences help avoid complexities associated with BitVM1 and make BitVMX a compelling alternative to BitVM2. Our approach is quite flexible, BitVMX can be instantiated to balance transaction cost vs round complexity, prover cost vs verifier cost, and precomputations vs round complexity.

Figures (4)

• Figure 1: Simplified illustration of using one-time signatures and pre-signed templates to link messages across transactions
• Figure 2: n-ary search mechanism with 64 hashes ($m=64$, $n=4$, $l=3$). The concatenation of the interval identifiers selected produces $011001_b = 25$.
• Figure 3: First stage of the challenge-response protocol used to identify the first conflicting step in the sequence of stepHash hashes.
• Figure 4: Read value and last step hash challenges. See Figure \ref{['fig:step-search']} for the detailed search process.

Theorems & Definitions (3)

• definition thmcounterdefinition
• definition thmcounterdefinition
• definition thmcounterdefinition