ColliderVM
Stateful Computation on Bitcoin
A new approach to complex smart contracts on Bitcoin without fraud proofs, eliminating capital inefficiency while maintaining security through presigned flows and hash collision puzzles.
The Problem
Bitcoin's scripting language is intentionally limited, making stateful computation challenging
No Native Statefulness
Bitcoin Script lacks loops, has size restrictions, and can't persist data across transactions
Capital Inefficiency
Existing solutions like BitVM2 require operators to lock capital during fraud proof windows
Trust Assumptions
Current approaches often require trusted setups or weaker security models
Bitcoin Script Limitations
Result: Complex applications like multi-step smart contracts, vault designs, and trust-minimized L2 bridges are extremely difficult to implement directly on Bitcoin.
The Solution
ColliderVM combines presigned transactions with hash collision puzzles to enable stateful computation without fraud proofs
Presigned Flows
Create 2^L parallel transaction flows during offline setup phase, each corresponding to a unique flow identifier
Hash Collision Puzzle
Operators find nonce r such that H(x,r)|_B matches a flow ID, ensuring input consistency across transactions
Immediate Settlement
No fraud proof windows or capital lock-up - operators are reimbursed immediately upon successful execution
Key Benefits
- Capital efficient - no fraud proof windows
- 1-of-n security model for safety and liveness
- No protocol upgrades required
- Immediate settlement without challenges
How It's Different
- No reliance on fraud proofs or challenges
- Uses cryptographic puzzles for security
- Operators don't need upfront capital
- Works with existing Bitcoin consensus
Research Disclaimer
Important information about the current state of ColliderVM
Research Project Notice
ColliderVM is currently a research project and should not be used in production environments. The protocol is in active development and exploration phase.
While the theoretical foundations are promising, it remains unclear whether ColliderVM will prove practical for meaningful real-world use cases. Significant research and development work is still required to determine its viability.
Current Status
- Research Phase: Exploring theoretical concepts and feasibility
- Toy Implementation: Demonstration and proof-of-concept only
- Practical Viability: Under investigation and evaluation
- Production Readiness: Not recommended for real-world use
Research Goals
- Validate theoretical security assumptions and guarantees
- Assess practical implementation challenges and limitations
- Explore potential optimizations and efficiency improvements
- Determine viability for real-world Bitcoin applications
About the Toy Implementation
The current ColliderVM implementation serves as a showcase and educational tool to demonstrate the core concepts. It acts as a stepping stone towards more comprehensive research on the practical aspects of the protocol. The implementation is intentionally simplified and should be viewed as a foundation for future development rather than a production-ready solution.
How ColliderVM Works
Understanding the core mechanics of achieving stateful computation without fraud proofs.
1. Logic Persistence via Presigned Transactions
To execute a complex function `f(x)` that's too large for a single Bitcoin transaction, ColliderVM splits it into smaller subfunctions: `f(x) = f₁(x) ∧ f₂(x) ∧ ... ∧ fₖ(x)`. The sequence of these subfunctions is enforced using presigned transactions.
During an offline setup phase, a **Signer** creates transaction templates for each subfunction. Each template `txᵢ` contains the logic for `fᵢ(x)` and an authorization (a signature check) for the specific next transaction `txᵢ₊₁` in the sequence. The Signer presigns these authorizations, effectively locking in the program flow. An **Operator** then receives these templates and presignatures.
// Offline Setup by Signer:
// Transaction 1 (tx_1) script:
// - Contains logic for f_1(x)
// - Checks for Signer's signature on tx_2 (spending tx_1)
// Transaction 2 (tx_2) script:
// - Specifies tx_1's txid as input
// - Contains logic for f_2(x)
// - Checks for Signer's signature on tx_3 (spending tx_2)
// ...and so on for f_k(x), etc.
// Signer presigns authorizations: tx_1 -> tx_2, tx_2 -> tx_3
// Operator receives templates and presigned authorizations.
// Online Execution by Operator (knowing x):
// 1. Broadcast tx_1 with witness (x, sig_spend_tx_1)
// 2. Broadcast tx_2 (spending tx_1) with witness (x, sig_spend_tx_2)
// 3. ... continue sequenceThis mechanism ensures that the Operator must follow the predefined sequence `f₁ → f₂ → ... → fₖ`. Any deviation would invalidate the presigned authorization for the next step.
Interactive Demo: Presigned Transaction Flow
✨ Interactive Presigned Transaction Flow ✨
2. The Inconsistent Input Problem
A critical challenge arises: standard Bitcoin signatures (pre-Taproot) do not cover witness data. This means a malicious Operator could provide different inputs (`x₁`, `x₂`, ...) to each transaction in the presigned sequence.
For example, the Operator might use `x₁` for `f₁(x₁)` (making it pass), then a different `x₂` for `f₂(x₂)` (making it pass), and so on. This could allow them to satisfy all subfunctions with varying inputs, even if no single input `x` exists for which the entire `f(x)` is true. This would break the integrity of the stateful computation.
3. Data Persistence via Hash Collision Puzzle
The presigned transaction flow alone is vulnerable to the inconsistent input problem. ColliderVM solves this by using a cryptographic hash puzzle that enforces input consistency across all transactions in a flow.
The Problem
Without additional constraints, a malicious operator could provide different inputsx₁, x₂, x₃to each transaction, such that each individual check passes but the overall computation is invalid.
TX₂: f₂(x₂) = ✓
TX₃: f₃(x₃) = ✓
But f(x) = f₁(x) ∧ f₂(x) ∧ f₃(x) ≠ ✓
The Solution
ColliderVM creates 2^L parallel flows, each tied to a unique value d. Every transaction in flow dverifies that H(x,r)|_B = d.
Forces same (x,r) across all TX
Guarantees input consistency
Security Guarantee
Finding a collision (two different inputs mapping to the same flow) is exponentially harder than finding a single valid mapping, creating a strong computational security gap.
Malicious: 2^(B-L/2) work
Gap: 2^(L/2) advantage
// Script for each transaction (e.g., tx_for_sub_function_in_flow_d) in a specific flow 'd':
// 1. Check Signer's signature (authorizing this step in flow 'd')
// 2. NEW CHECK: Verify Hash Commitment
// Input: current_input_x, nonce_for_input_r
// Operation: Compute H(current_input_x, nonce_for_input_r)
// Verification: First B bits of H(current_input_x, nonce_for_input_r) == d (hardcoded flow ID)
// 3. Execute subfunction (e.g., f_sub_function(current_input_x))To execute the computation for a given input `x`, the Operator must first find a nonce `r` and a flow identifier `d ∈ D` such that the first `B` bits of `H(x, r) = d`. Once found, the Operator is committed to using this specific flow `d`. Since every transaction in flow `d` verifies that the first `B` bits of `H(input, nonce) = d` using the *same* `d`, the Operator is forced to use a consistent input `x` (and `r`) for all subfunctions in that flow.
Interactive Demo: Hash Collision Puzzle
🔮 Interactive Hash Collision Puzzle 🔮
Presigned Transaction Flows
Hash Computation
4. Security & Computational Gap (Double Collision)
The security of ColliderVM (specifically the Double Collision Variant described) relies on a computational gap between an honest Operator and a malicious one.
- Honest Operator Work: To find a valid B-pair for *any* `d ∈ D`, the Operator expects to perform roughly `2^(B-L)` hash computations. This is because there are `2^L` valid `d` values out of `2^B` total possibilities for the first `B` bits of the hash.
- Malicious Operator Work: To cheat by using different inputs `(x, r)` and `(x', r')` within the *same* flow `d`, the attacker must find two pairs that hash to the *same* `d` (i.e., first `B` bits of `H(x, r) =` first `B` bits of `H(x', r') = d`). This is a targeted collision problem. The work required is approximately `2^(B - L/2)` hash computations.
By choosing `L` and `B` appropriately, a significant gap can be established. For instance, with `L=46` and `B=120`:
- Honest work: `2^(120-46) = 2^74` hashes.
- Malicious work: `2^(120 - 46/2) = 2^(120-23) = 2^97` hashes.
This makes it computationally much harder for an attacker to break input consistency than for an honest operator to perform the computation correctly. The system relies on the 1-of-n honesty of Signers (to correctly create the flows) and 1-of-m honesty of Operators (for liveness).
A Triple Collision Variant also exists, offering a different security/cost tradeoff by requiring attackers to find three distinct pairs hashing to the same `d`, further increasing malicious work at the cost of more complex on-chain transactions.
Technical Details
Deep dive into ColliderVM's implementation, security analysis, and optimization strategies.
Parameter Selection Strategy
Optimal Parameter Selection
Conservative (Research)
Balanced (Practical)
Demo (Testing)
Storage Requirements
Storage Analysis
Optimization Opportunities
- Compression: 70-90% reduction possible
- Lazy generation: Generate flows on-demand
- Delta encoding: Store only differences
- Distributed sharding: Split across operators
Scaling Challenges
- Exponential growth with L parameter
- Bandwidth requirements for distribution
- Synchronization across operators
Bitcoin-Friendly Hash Functions
BLAKE3 (Current)
Custom (Research)
Comparative Analysis
| Feature | ColliderVM | BitVM2 | Traditional |
|---|---|---|---|
| Capital Efficiency | Immediate settlement | Challenge period delay | Varies |
| Security Model | 1-of-n signers + computation | 1-of-n signers + fraud proofs | Multisig (n-of-m) |
| On-chain Complexity | Always full verification | Light optimistic, heavy pessimistic | Fixed complexity |
| Storage Overhead | 2^L flows per deposit | Winternitz signatures | Minimal |
| Computation Cost | Hash finding (2^(B-L)) | Proof generation | None |
| Protocol Changes | None required | None required | Depends |
| Fraud Proofs | Not required | Essential for security | Not applicable |
Optimization Strategies
Performance Optimizations
Cost Reduction Techniques
Future Research Directions
Open Problems
- •Optimal hash function design for Bitcoin Script constraints
- •Dynamic parameter adjustment based on network conditions
- •Formal security proofs for collision resistance requirements
- •Integration with existing Bitcoin infrastructure
- •Economic analysis of operator incentive structures
Implementation Priorities
- 1.Production-ready STARK verifier implementation
- 2.Comprehensive security audit and testing
- 3.Developer tooling and documentation
- 4.Cross-platform operator client implementations
- 5.Real-world application demonstrations
Mainnet Demo
Real Bitcoin transactions demonstrating ColliderVM's two-step range check computation: verifying that 100 < x < 200across separate on-chain transactions.
Range Check Computation
Transaction Flow
Initial funding transaction that provides the UTXO for the ColliderVM computation sequence.
First computation step: validates that the input value (114) is greater than the lower bound (100).
Second computation step: validates that the input value (114) is less than the upper bound (200). Larger due to hash collision verification.
ColliderVM Parameters
Cost Analysis
Key Insights
Proven Functionality
- • Stateful computation across multiple Bitcoin transactions
- • Input consistency enforced via hash collision puzzle
- • No fraud proofs or challenge periods required
- • Works on Bitcoin today without protocol changes
Current Limitations
- • High on-chain cost for hash verification (~$88 per TX)
- • Large transaction sizes (68kB+ for complex verifications)
- • Requires Bitcoin-friendly hash optimizations
- • Storage overhead for presigned transaction flows
Explore the Implementation
This demo showcases ColliderVM's potential for complex Bitcoin computations. While costs are currently high, ongoing research into Bitcoin-friendly hashes and optimizations could make this practical for real applications.