Developing Bitcoin-Friendly Cryptographic Primitives

Efforts to implement BitVM often focus on repurposing existing cryptographic primitives to conform to Bitcoin's technical constraints. However, Bitcoin's limitations hinder the efficient implementation of such primitives, highlighting the need to design cryptographic systems tailored specifically for Bitcoin's architecture.

Efficient Commitment Schemes: Bitcoin's UTXO model is inherently stateless, lacking the ability to transfer state variables directly from inputs to outputs. To address this, BitVM enforces a mechanism where the prover proposes commitments for state variables within a Bitcoin transaction's input. The verifier then retrieves these commitments, validates their authenticity, and utilizes them in further computations. However, existing commitment schemes are not designed with this scenario in mind. As a result, the size of commitments currently used in BitVM is substantial, driving up transaction fees due to the inclusion of each state variable. Developing a lighter and more efficient commitment scheme would significantly reduce these fees, lowering the barrier to operating BitVM and fostering greater decentralization among its participants.
Efficient hash function without enabling OP_CAT: Given the high cost of commitments, developers have adopted an alternative approach for managing state variables: packing them as elements in the Bitcoin script execution stack, hashing each one sequentially, and committing to the resulting hash. Ideally, a hash chain would concatenate the current hash with the next element, then hash the combined result, repeating until all elements are processed. However, this straightforward approach relies on the unavailable OP_CAT operation, making it infeasible under Bitcoin's current scripting constraints. As a workaround, BitVM implementations rely on extensive Bitcoin scripts that perform hashing through pure mathematical computations, which significantly increases complexity and costs. Designing a new, efficient hash function tailored for Bitcoin script would reduce the computational burden for both the prover and challenger. This innovation would bring similar benefits to those achieved by lighter commitment schemes, such as lower operational costs and broader accessibility.
Bitcoin-friendly pairing technique built on fewer bit-width: Currently, Groth16 with BN 254 is the only implemented verifier for BitVM. To represent one element on BN 254, 9 stack items are required: Each computable Bitcoin stack item has 32 bits and for overflow handling friendly, it could only represent 29 bits on BN 254. 29 bits * 9 > 254 bits. Due to the limitation of 1000 stack depth of Bitcoin script, the more stack items used for one element, the less elements could be handled in the program. The exceed of stack usage is one of the major reason to chunk the program. If a new pairing schema is designed on lower bit-width without sacrificing too much security, it would be a more efficient choice of verifier implementation and allows more flexible space to balance the fee cost between the prover and challenger.

Reducing the script size and unlocking witness cost brings several key advantages:

Lower Operational Costs for BitVM: BitVM relies on both the operator (prover) and the challenger to submit transactions to facilitate operations. By minimizing the space used by scripts and unlocking witnesses, transaction fees decrease, directly benefiting operators. This lowers the entry barrier, attracting more operators and fostering a broader and more competitive ecosystem.
Simplified and More Succinct Architecture: The current oversize of the verifier program necessitates complex designs to ensure soundness. Achieving significant optimizations—such as reducing the entire verifier's size to under 4 MB—could eliminate the need for a fraud-proof challenge scheme. Instead, a validity-proof approach could be employed, enabling the verification of SNARK proofs within a single transaction. This shift would streamline the architecture and enhance overall efficiency.

PreviousIntroduction NextAutomating the Compilation Pipeline

Last updated 6 months ago

Developing Bitcoin-Friendly Cryptographic Primitives

Efficient Commitment Schemes: Bitcoin's UTXO model is inherently stateless, lacking the ability to transfer state variables directly from inputs to outputs. To address this, BitVM enforces a mechanism where the prover proposes commitments for state variables within a Bitcoin transaction's input. The verifier then retrieves these commitments, validates their authenticity, and utilizes them in further computations. However, existing commitment schemes are not designed with this scenario in mind. As a result, the size of commitments currently used in BitVM is substantial, driving up transaction fees due to the inclusion of each state variable. Developing a lighter and more efficient commitment scheme would significantly reduce these fees, lowering the barrier to operating BitVM and fostering greater decentralization among its participants.
Efficient hash function without enabling OP_CAT: Given the high cost of commitments, developers have adopted an alternative approach for managing state variables: packing them as elements in the Bitcoin script execution stack, hashing each one sequentially, and committing to the resulting hash. Ideally, a hash chain would concatenate the current hash with the next element, then hash the combined result, repeating until all elements are processed. However, this straightforward approach relies on the unavailable OP_CAT operation, making it infeasible under Bitcoin's current scripting constraints. As a workaround, BitVM implementations rely on extensive Bitcoin scripts that perform hashing through pure mathematical computations, which significantly increases complexity and costs. Designing a new, efficient hash function tailored for Bitcoin script would reduce the computational burden for both the prover and challenger. This innovation would bring similar benefits to those achieved by lighter commitment schemes, such as lower operational costs and broader accessibility.
Bitcoin-friendly pairing technique built on fewer bit-width: Currently, Groth16 with BN 254 is the only implemented verifier for BitVM. To represent one element on BN 254, 9 stack items are required: Each computable Bitcoin stack item has 32 bits and for overflow handling friendly, it could only represent 29 bits on BN 254. 29 bits * 9 > 254 bits. Due to the limitation of 1000 stack depth of Bitcoin script, the more stack items used for one element, the less elements could be handled in the program. The exceed of stack usage is one of the major reason to chunk the program. If a new pairing schema is designed on lower bit-width without sacrificing too much security, it would be a more efficient choice of verifier implementation and allows more flexible space to balance the fee cost between the prover and challenger.

Reducing the script size and unlocking witness cost brings several key advantages:

Lower Operational Costs for BitVM: BitVM relies on both the operator (prover) and the challenger to submit transactions to facilitate operations. By minimizing the space used by scripts and unlocking witnesses, transaction fees decrease, directly benefiting operators. This lowers the entry barrier, attracting more operators and fostering a broader and more competitive ecosystem.
Simplified and More Succinct Architecture: The current oversize of the verifier program necessitates complex designs to ensure soundness. Achieving significant optimizations—such as reducing the entire verifier's size to under 4 MB—could eliminate the need for a fraud-proof challenge scheme. Instead, a validity-proof approach could be employed, enabling the verification of SNARK proofs within a single transaction. This shift would streamline the architecture and enhance overall efficiency.

PreviousIntroduction NextAutomating the Compilation Pipeline

Last updated 6 months ago