A Deep Dive into BitVM

This research represents a collaborative effort between the Symbolic Capital and Nubit teams. Symbolic Capital is an investor in Nubit.

‍I. What Is BitVM?

Bitcoin has long been the gold standard for decentralized digital currency—a secure and robust system for managing digital assets. Its design prioritizes security and simplicity, which has been instrumental in its widespread adoption and trustworthiness. Over the years, Bitcoin's core code has remained relatively stable—a deliberate choice to maintain its integrity and resist changes that could introduce vulnerabilities. Bitcoin embodies stability and resistance to change, focusing on its clear purpose: facilitating reliable and secure transactions.

However, this conservative approach also means that Bitcoin's ability to handle complex applications is limited. Bitcoin's scripting language allows for basic operations like multi-signature setups and timelocks but doesn't support the complex logic required for applications such as decentralized finance (DeFi) or smart contracts. While this design philosophy reinforces Bitcoin's emphasis on security and decentralization, it also restricts its functionality compared to more programmable platforms.

As Bitcoin has remained steadfast in its commitment to simplicity, platforms like Ethereum have introduced advanced programmability, allowing developers to create "smart contracts" that automatically execute actions when specific conditions are met. These capabilities have given rise to a plethora of decentralized applications and services, expanding the potential use cases for blockchain technology.

BitVM emerges as a proposal to bridge this gap by expanding Bitcoin's functionality without altering its fundamental architecture. Instead of aiming for the full programmability offered by platforms like Ethereum, BitVM works within Bitcoin's existing framework to enable a limited form of smart contracts. By leveraging existing features like hashlocks and timelocks, BitVM provides a clever method to introduce programmability without compromising the simplicity and security that give Bitcoin its strength.It's about expanding Bitcoin's horizons while preserving the qualities that have made it successful—enhancing its capabilities without introducing undue complexity or compromising its core values.

How Bitcoin's Programming Works

To appreciate what BitVM brings to the table, it's helpful to understand how Bitcoin's programming currently works.

Bitcoin Script: The Basics

Bitcoin includes a built-in scripting language known as Bitcoin Script. This language allows users to create simple conditions for spending unspent transaction outputs (UTXOs)—the building blocks of Bitcoin transactions. A UTXO can be thought of as a "digital coin" that is locked by specific rules, and these rules must be satisfied to spend the coin. For instance, Bitcoin Script enables features like:

• Multisignature Transactions: Requiring multiple signatures to unlock and spend a UTXO.
• Timelocks: Restricting the spending of a UTXO until a certain time or block height.

These features function like programmable locks on a digital safe, ensuring that only the right keys or conditions can unlock the funds.

Limitations of Bitcoin Script

Importantly, Bitcoin Script is not a full-fledged programming language. It's intentionally limited to prevent complexity that could introduce security vulnerabilities such as denial-of-service (DOS). This introduces tradeoffs in the form of:

• No Complex Logic: You can't program intricate conditions or automate complex actions.
• Limited OpCodes: The set of operations (opcodes) available is minimal, focusing on transaction validation.

Again, these limitations reinforce Bitcoin's security but also mean that sophisticated applications—like those seen in DeFi—aren't possible natively on Bitcoin.

How BitVM Enhances Bitcoin's Functionality

BitVM doesn't alter Bitcoin's existing code; instead, it leverages what's already there. It's like using a limited set of tools in creative ways to build something new and impressive—much like constructing intricate structures from basic Lego blocks.

A key tool that BitVM leverages to achieve programmability on Bitcoin is a hashlock. A hashlock is like a digital lock that can only be opened with a specific key (a cryptographic preimage). In the context of BitVM, hashlocks can enable new features on Bitcoin like conditional transactions.

• Conditional Transactions: Funds can be locked in a UTXO that only becomes spendable when the correct cryptographic key is provided, acting like a digital lock that requires the right key to unlock and transfer the funds. This enables basic smart contracts where, for example, a payment is only released upon the revelation of a specific secret.

In addition to hashlocks, BitVM also makes use of timelocks, which allow programmers to set time-based conditions for actions like:

• Delay Transactions: Funds cannot be spent until after a certain time or block height.
• Security Measures: Timelocks can protect against certain types of attacks by delaying the ability to move funds.

By combining hashlocks and timelocks, BitVM can create programmable contracts that perform actions based on specific conditions, such as:

• Atomic Swaps: Enabling the exchange of assets between parties without intermediaries.
• Conditional Payments: Releasing funds only when certain conditions are met, within a specified time frame.

BitVM2: Bringing Computation to Bitcoin Through Off-Chain Execution

Although the original design of BitVM makes it technically feasible to perform complex computation on Bitcoin, the limitations of Bitcoin’s design—particularly its throughput, cost, and stateless architecture—make such an approach practically infeasible. To address these challenges, Linus et al. propose BitVM2, an enhancement of the original BitVM. BitVM2 inherits the computational power of the original BitVM design while offloading most computations off-chain, deferring only the verification to the Bitcoin blockchain. This dramatically reduces the burden on the Bitcoin mainnet, maintaining scalability and efficiency without sacrificing security.

An example can help make this more concrete. Imagine you and a friend want to bet on the outcome of a game. On platforms like Ethereum, a smart contract could manage the entire bet on-chain, tracking the game’s progress and maintaining a "state" as conditions change. This ongoing, stateful computation allows the contract to react as the game unfolds. Bitcoin fundamentally lacks this ability; it can't maintain stateful computations or track changes in real-time. This is where BitVM2 comes in. BitVM2 offers a clever workaround by allowing you and your friend to agree on the terms of the bet off-chain by creating a contract using tools like hashlocks and timelocks. Once the game concludes, you generate cryptographic proofs to verify the outcome, allowing Bitcoin to securely settle the bet in one final transaction. This approach respects Bitcoin’s stateless nature while enabling more complex interactions, all without modifying Bitcoin's basic design.

To maintain security, BitVM relies on cryptographic proofs, which enable verification of computations without revealing sensitive information. One common type of cryptographic proof used in this context is a Zero-Knowledge Proof (ZKP). Intuitively, a ZKP allows someone to prove that they know a secret (or that a computation was done correctly) without revealing the secret itself.

Let’s revisit the betting example to explain the usage of ZKPs in BitVM. Remember that you and a friend bet on the outcome of a game and the results are calculated off-chain. To settle the bet, one of you needs to prove to Bitcoin’s network that the computation determining the winner was done correctly offchain. Instead of submitting the entire game result or the computation details to the blockchain (which would be both expensive and time-consuming), you merely generate a cryptographic proof. This proof is a compact, mathematical representation that convinces the network the computation was correct—without requiring Bitcoin to reprocess the game data or calculation.

The Bitcoin network only needs to verify the proof, which is quick and efficient, and then executes the transaction (e.g., releasing the winnings to the winner’s UTXO). This way, BitVM ensures the integrity of complex computations while keeping Bitcoin secure, efficient, and scalable.

It’s important to highlight here that none of this requires changing the underlying structure of Bitcoin. One of BitVM's most significant advantages is that it doesn't necessitate any alterations to Bitcoin's code. By working within Bitcoin's existing rules and constraints, BitVM ensures full compatibility with the current network, avoiding the risks associated with changing the core software—such as the need for consensus, potential network splits, or the introduction of vulnerabilities.

Recap

Let's recap the core technical components that enable BitVM to bring enhanced functionality to Bitcoin:

1. Hashlocks: Digital locks opened with specific cryptographic keys, allowing conditional release of funds.
2. Timelocks: Time-based conditions that restrict when transactions can occur.
3. Off-Chain Computation: Performing complex logic outside the blockchain to keep the network efficient and secure.
4. Cryptographic Proofs: Verifiable proofs that ensure off-chain computations are accurate without overloading the blockchain.

By integrating these elements, BitVM introduces a level of programmability to Bitcoin, enabling more sophisticated applications while respecting the network's foundational principles.

‍II. Building Trust-Minimized Bridges

Historically, developers have tried to expand Bitcoin’s functionality with Layer 2 solutions. Stacks, for example, created a Bitcoin-tied token called sBTC, pegged 1:1 with Bitcoin. However, Stacks relies on a multi-signature committee to maintain the peg, meaning that trusted individuals hold the authority to manage sBTC’s value. This setup introduces a layer of trust that users must accept.

With BitVM, trust-minimized bridges are possible, reducing or even eliminating the need for trusted intermediaries. Instead of depending on a committee, a BitVM-based bridge could use an optimistic verification model where any Bitcoin user can act as a challenger to dispute fraudulent transactions.

Here’s how a BitVM-based trust-minimized bridge works:

• Peg-In: When Alice wants to use her BTC in a sidesystem, she deposits it into a BitVM instance on Bitcoin. This deposit is recorded on the Bitcoin side, and an equivalent amount is issued in the sidesystem, allowing Alice to use her BTC there.
• Peg-Out: When Alice wants to withdraw her BTC back to Bitcoin, she initiates a withdrawal request. If she tries to withdraw without following the correct steps, anyone can challenge her attempt and prevent fraud.

With this approach, bridges can transfer BTC without relying on centralized, trusted authorities.

Beyond the Lightning Network

The Lightning Network is one of Bitcoin's most prominent solutions for scaling, enabling fast and low-cost transactions through off-chain payment channels between users. While effective, the Lightning Network comes with notable limitations. First, both parties in a payment channel must remain online to monitor transactions and prevent fraud, leaving funds vulnerable if one party goes offline. Second, the channel-based structure restricts who can transact with whom; payments require a direct or intermediary connection, often pushing participants to rely on custodial third parties for channel management, which introduces risks of centralization.

BitVM presents a promising alternative with zkCoins, a system designed to combine the speed and efficiency of the Lightning Network with enhanced flexibility and security. Through a BitVM-powered bridge, users can convert BTC into zkCoins, enabling private, off-chain transactions fully backed by real Bitcoin on the main chain. Unlike the Lightning Network, zkCoins do not require both parties to stay online, ensuring funds remain secure even in the absence of active monitoring.

Moreover, zkCoins eliminates the channel-based limitations of the Lightning Network, allowing users to transact directly with anyone in the system without intermediaries or custodial dependencies. This approach not only enhances privacy and scalability but also reduces reliance on the main Bitcoin blockchain, making zkCoins a compelling solution for expanding Bitcoin's utility while preserving its decentralized ethos.

Sharing Bitcoin Security with Other Systems

In blockchain security, two primary models dominate: Proof-of-Work (PoW) and Proof-of-Stake (PoS). Bitcoin's PoW model stands out for its exceptional security, powered by an immense amount of computational energy distributed across a global network of miners. This robust economic security has made Bitcoin a benchmark in the industry, sparking interest from other blockchain systems seeking ways to leverage or integrate with its unparalleled resilience.

One innovative approach to leveraging Bitcoin's security is Stakechain, a Proof-of-Stake (PoS) model anchored to Bitcoin’s economic robustness. In Stakechain, participants lock Bitcoin as collateral to secure the PoS chain, accepting the risk of losing their stake if they engage in malicious activities. To enforce accountability, Stakechain employs one-time signatures, which penalize attackers by enabling slashing (i.e., confiscating staked Bitcoin) if private keys are reused. This mechanism effectively prevents double-signing attacks specific to the PoS system. However, while this approach mitigates certain risks, it falls short of addressing other forms of misbehavior within the ecosystem, leaving room for further security enhancements.

BitVM has the potential to expand slashing conditions beyond simple double-signing by enabling complex, verifiable computations. With BitVM, "programmable slashing" becomes possible. For example, it allows Stakechain to implement more sophisticated rules to penalize a wider range of malicious behaviors. This capability enables the enforcement of detailed and customizable staker behavior policies, enhancing the security and flexibility of the system. By leveraging BitVM, Stakechain could evolve into a powerful tool that extends Bitcoin’s security to other systems requiring decentralized validation models, such as data availability layers, unlocking new possibilities for secure and scalable blockchain applications.

Recap

Without requiring a soft fork, BitVM enables advanced programmability that respects Bitcoin's core values of security and decentralization. This breakthrough allows for innovations like trust-minimized bridges, non-custodial payment networks, and Bitcoin staking protocols. Next, we’ll transition from looking at applications of BitVM to how to actually build with this new technology.

III. BitVM Programming Paradigms

This section explores the practical construction of a BitVM, the challenges faced during the compilation process, the innovative solutions proposed by researchers, and remarks on the current state and future directions of BitVM development.

How to Construct a BitVM in Practice

Creating a BitVM program starts much like building any other program: by writing code in a high-level language that’s easy to understand and work with. However, to get this code to run on Bitcoin, we need a compiler. In programming, a compiler takes high-level code (written in a human-friendly language) and translates it into low-level code (machine-friendly instructions). For BitVM, the compiler must translate high-level code into Bitcoin’s own scripting language, which is extremely limited.

To implement something complex, like a Groth16 Verifier (a cryptographic tool that enables BitVM to verify proofs without requiring interaction with the off-chain prover, facilitating the verification of SNARK proofs within BitVM.), a developer might start by writing the verifier code in a higher-level language, e.g., a Rust-style DSL (domain-specific language). Here’s a simplified snippet of what this might look like:

// High-Level Code in Rust-style DSLfnverify_groth16(
    proof: Proof, public_inputs: &[Fr], vk: &VerifyingKey) -> bool {
// Step 1: Validate public inputsif !validate_inputs_length(public_inputs, vk) {
returnfalse;
    }
// Step 2: Prepare verifying keylet pvk = prepare_verifying_key(vk);
// Step 3: Compute linear combinationlet acc = compute_linear_combination(public_inputs, &pvk, vk);
// Step 4: Perform pairing checks    perform_pairing_checks(&proof, acc, &pvk)
}

‍

In this example, the verify_groth16 function verifies a Groth16 zk-SNARK proof by following four key steps. It first validates that the length of the public_inputs matches expectations based on the vk (verification key). Then, it prepares a processed verifying key (pvk) to optimize pairing operations. Next, it computes a linear combination of the public_inputs with the verifying key, aligning them with the proof structure. Finally, it performs cryptographic pairing checks to ensure the proof's validity against the zk-SNARK circuit. If all checks pass, it returns true; otherwise, false.

Now, BitVM needs a compiler to take this high-level code and transform it into something Bitcoin can actually run. This transformation involves breaking down each part of the code into basic steps that Bitcoin’s script language can process. For example, instead of running lhs == rhs directly, the compiler translates this into a series of small instructions that Bitcoin can interpret, one at a time. The team behind BitVM provides this compiler, which is essentially a translator that makes sure the original program can run on Bitcoin, even though Bitcoin’s language lacks flexibility.

The Challenges of Compiling for Bitcoin

Turning high-level code into Bitcoin script is particularly challenging. Bitcoin’s scripting language is not like typical programming languages; it;s not “Turing complete” (meaning it can’t handle all types of computations) and has strict limits on space. This makes translating even simple programs a lot more complex than it would be on other blockchains, like Ethereum.

For example, let’s revisit our Groth16 Verifier. In its high-level form, it’s just a few hundred lines of code. But when we compile it down to Bitcoin script, it explodes in size—potentially taking up millions of lines of Bitcoin script code and several gigabytes in memory! This is a huge problem, especially considering that Bitcoin’s blocks are limited to 4 megabytes each. Trying to fit something this large into Bitcoin’s script language is akin to trying to fit an elephant into a small car—the sheer size and complexity make it unfeasible under current network constraints. This size demand makes BitVM programs impractical without serious adjustments.

The Solution: Staging Compilation and Decomposition

To overcome these challenges, researchers from ZeroSync and Alpen Labs developed an innovative strategy called staging compilation. This approach tackles the size and complexity issues by breaking down the problem into manageable subtasks. Let’s go through the main steps in this staging compilation process:

1. Layout Process (i.e. Fitting the Elephant to the Car)
   • Imagine the original Rust-style program as a computational graph, which we’ll call G. This graph represents the flow of operations and data in the program.
   • The layout process rearranges this graph and transforms it into an equivalent graph G', which is optimized to work within Bitcoin’s constraints. The goal of this rearrangement is twofold:
     • Data and Subgraph Reuse: This step aims to identify parts of the graph that repeat or can be shared (reduce redundancy), compressing the program to make it smaller.
     • Fit within Bitcoin’s 4MB Block Size: By reshuffling the graph, layout creates small “chunks” of code that fit within Bitcoin’s block limits, ensuring deployability.
   • The result is a compressed version of the original program that’s been reorganized to fit Bitcoin’s size constraints.
   • Analogy: This process is similar to disassembling a large object into smaller, modular pieces that can fit into a series of containers. It's like dismantling the elephant and fitting its parts into several cars, ensuring each piece is within the size limit.
2. Optimization (i.e. Making the Elephant Thinner)
   • Now that we have our program broken down into manageable parts, the next step is to make each part as efficient as possible. Think of this step as “slimming down” each chunk to make it less resource-intensive.
   • Optimization here means rewriting parts of the computation to reduce the number of operations needed. This is similar to simplifying algebraic expressions in math class. For instance, if the program involves multiple multiplications, optimization might find ways to reduce them, drawing on cryptographic insights and tricks.
   • By minimizing the number of costly operations, optimization ensures each part of the program is not only smaller but also faster.
   • Analogy: This is akin to trimming excess weight from each part of the elephant, making them lighter and easier to transport.
3. Code Generation (i.e. Getting the Elephant on Board)
   • Finally, once the layout and optimization steps are complete, we need to convert our compacted graph G' into actual Bitcoin script code.
   • This step involves an algorithm that traverses every node in G', converting each optimized part into a sequence of low-level Bitcoin instructions.
   • The end result is a compact, Bitcoin-compatible version of the program that’s ready to be deployed on the Bitcoin blockchain.
   • Analogy: This step is like carefully loading the trimmed and disassembled parts of the elephant into the vehicles, ready for transport.

Together, these steps allow BitVM to take a program that was initially impractical and break it down until it’s manageable within Bitcoin’s space limitations.

Recap

The current staging compilation process is a brilliant workaround to a seemingly impossible problem. It makes something that initially seemed impractical—running complex programs on Bitcoin—into a workable solution. However, this approach is still in its early stages and faces a few key challenges:

• Fine-Tuning Required: Each step in the layout, optimization, and code generation processes needs careful tuning. Domain experts must continuously refine the layout algorithm and the optimization techniques to ensure they’re as efficient as possible. This is a labor-intensive task that requires deep knowledge of both cryptography and Bitcoin’s architecture.
• Difficulty in Adding New Versions: If we want to implement a new version of BitVM or add more features, the entire compilation process might need to be redesigned from scratch. Since Bitcoin’s scripting language is so limited, even minor updates require significant changes to the layout and optimization stages.

Despite these challenges, staging compilation represents an exciting step forward. By carefully rearranging, compressing, and simplifying programs, BitVM makes it possible to bring programmable functionality to Bitcoin without compromising the system’s integrity. This process shows the power of creative problem-solving in pushing the boundaries of what Bitcoin can achieve. Now that we’ve familiarized ourselves with how to build with BitVM, we’ll next move to identifying some of the teams at the forefront of this space.

IV. BitVM Builder Landscape

The Birth of BitVM

BitVM began as an idea to extend Bitcoin’s capabilities beyond simple transactions. The ZeroSync team, led by Robin Linus, recognized the limitations of Bitcoin’s scripting language, which wasn’t designed for complex computations. Instead of proposing changes to Bitcoin’s core protocol, they developed a way to perform advanced computations on top of Bitcoin while preserving its foundational design. This approach became the basis for BitVM.

The project started with a proof-of-concept written in JavaScript, demonstrating that complex computations could be verified using Bitcoin’s existing script. This early example proved the concept was viable and drew interest from the community. Encouraged by the response, ZeroSync advanced the project with a Rust implementation, inviting contributions from developers worldwide to refine and expand the system.

To coordinate efforts and encourage collaboration, ZeroSync established the BitVM Alliance, bringing together teams and contributors working on BitVM. Through meetups, conferences, and community discussions, the Alliance has created a platform to share progress, address challenges, and grow a community dedicated to exploring new possibilities for Bitcoin programmability.

Making BitVM Practical: The Push for Efficiency and Automation

With BitVM’s potential clear, the next challenge was to make it fast and cost-effective enough for real-world use—no easy task within Bitcoin’s existing limitations.

That’s where Alpen Labs (Strata) came in. They focused on optimizing BitVM’s cryptographic algorithms to reduce the heavy computational load and lower transaction costs. Their work made BitVM much more practical by trimming down the resources it needed to run.

But improving algorithms was only part of the solution. The structure of BitVM programs also mattered; initially, they were bulky and inefficient—like trying to read from a giant, disorganized textbook. Alpen Labs tackled this by manually reorganizing the code, cutting out redundancies, and compressing repetitive parts. This painstaking process shrunk the program size from a whopping 7 GB to just 1 GB, making BitVM far easier to work with.

However, doing this optimization work manually was slow and frustrating—each update meant starting from scratch. Nubit came up with an automated solution. They developed a synthesis-based compiler that optimizes BitVM programs on its own. Think of it like a digital assistant that takes your messy notes and turns them into a clean, organized summary—Nubit’s compiler does just that for BitVM, translating high-level code into low-level, optimized Bitcoin script automatically. On top of that, Nubit also provides formal verification for BitVM, a way to prove that the code performs exactly as intended mathematically. This is crucial for complex BitVM-based applications where a single error could lead to lost funds. Developers can trust that their code is not only optimal but also secure.

Real-World Applications: The BitVM Bridge

With BitVM’s technical foundation in place, the stage was set to build practical applications. One of the most important projects was the BitVM Bridge: a secure, trust-minimized way to connect Bitcoin with other blockchains.

Build on Bitcoin (BOB), alongside Robin Linus, helped lay the groundwork for the BitVM Bridge. They proposed a decentralized “1-of-n” security model, which means that as long as one out of n participants is honest, the system remains secure and functional. This approach was revolutionary, allowing a bridge to operate on Bitcoin without depending on third-party middlemen for the first time.

Making this vision a reality, however, was no small feat. It required precise engineering to balance security and functionality. This is where Element Labs made a crucial contribution. They worked out the complex sequence of transactions and conditions needed for the bridge, like drafting blueprints for a high-tech building where every piece has to fit just right. They also developed connectors to link each transaction and built a command-line interface to make the bridge easier for users to use, bringing it closer to actual deployment.

At the same time, Chainway Labs (Citrea) took a slightly different approach with their BitVM-based bridge called Clementine. They saw the challenge of a fully trust-minimized bridge and introduced a system with “authorized thresholds” for operators, adding an extra layer of economic incentives to keep the bridge secure. This setup sacrifices a bit of trustlessness for easier industry adoption.

Recap

BitVM stands as one of the most ambitious projects in Bitcoin’s history. Through the combined efforts of visionary teams, BitVM is moving from design to deployment, with applications like the BitVM Bridge showcasing Bitcoin’s new potential. Still, there remain numerous milestones in development of BitVm that are yet to be achieved. Our final section will outline some of the most pressing ones.

V. Future Work: Scaling BitVM in Production

As BitVM continues to evolve, there are several key areas that require attention to ensure its scalability, efficiency, and security in real-world applications. Addressing these challenges is essential for BitVM to fulfill its potential as a powerful extension of Bitcoin's capabilities.

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.

1. 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.
2. 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.
3. 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 excess of stack usage is one of the major reasons 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.

Automating the Compilation Pipeline

As discussed earlier, the current compilation pipeline for BitVM is semi-automatic and requires significant manual intervention. Tasks like constructing efficient layout algorithms and manually optimizing statements through rewrite rules are time-consuming and demand specialized expertise. Automating the pipeline for adopting a new verifier on BitVM is essential to scale exploration and innovation. By streamlining this process, we can significantly reduce the time required to evaluate the practicality of potential solutions, enabling faster iteration and implementation. Automation also increases the opportunity to discover and experiment with more effective alternatives, improving the likelihood of identifying optimal approaches. Furthermore, it provides greater flexibility to balance the fee costs between the prover and the challenger, paving the way for more efficient and equitable designs in the BitVM ecosystem.

• Automatic Layout Optimization: Designing algorithms to automatically restructure computational graphs for optimal data reuse while adhering to Bitcoin's block size constraints. This innovation is particularly valuable for exploring new verifier designs. Currently, assessing the feasibility of implementing a verifier demands over a month of manual effort by experts, who must carefully analyze the layout of hundreds of computational blocks and ensure each block stays within Bitcoin's 4MB size limitation. A single design flaw can result in several additional days of patching or even render the layout unviable. Automating this process would dramatically accelerate verifier evaluation and reduce the risk of design inefficiencies.
• Automated Code Optimization: Achieving a feasible layout is only the first step toward building a practical implementation; the subsequent challenge lies in optimizing it for maximum efficiency. Most effective optimizations are highly specific to individual SNARK verifiers, making manual tuning both time-consuming and error-prone. Automating this process by developing tools capable of applying rewrite rules and advanced optimization techniques would significantly streamline the workflow. Such tools could automatically identify and implement strategies to minimize computational costs, optimize resource allocation, and adapt to verifier-specific requirements. By reducing reliance on manual input, these tools would not only save time but also enhance consistency and scalability, enabling faster development and iteration of verifier designs while maintaining high performance.
• User-Friendly Interfaces for Protocol Design: The current design of BitVM focuses on establishing a permissionless bridge between Bitcoin and external systems. However, its foundational concept opens the door to designing a broader range of protocols on Bitcoin. To fully unlock this potential, user-friendly interfaces are crucial, including high-level programming languages or annotation frameworks that allow developers to easily describe and implement complex ideas. These interfaces should facilitate:
  • Defining relationships between Bitcoin UTXOs within a protocol, enabling seamless interactions between them.
  • Specifying the intended behavior and functionality through lock and unlock scripts associated with UTXOs.
  • Clearly articulating the computations and constraints embedded within each lock and unlock script.

With such tools in place, developers would gain the ability to prototype, experiment with, and deploy innovative protocols far beyond the original scope of a permissionless bridge. This could lead to the emergence of diverse applications, such as decentralized financial systems, enhanced privacy mechanisms, and scalable off-chain computation solutions, all while leveraging Bitcoin's robust infrastructure. By lowering the barrier to entry and making protocol design more accessible, these interfaces would catalyze a new wave of innovation on the Bitcoin network.

Enhancing Security Through Formal Methods

Introducing a new programming model with greater computational power inevitably expands the attack surface. Since BitVM applications may handle significant financial assets, ensuring their security is paramount. Developing advanced program analysis and verification techniques is essential to identify and mitigate potential vulnerabilities.

• Formal Verification: Leveraging mathematical methods to rigorously prove the correctness of BitVM programs is essential for ensuring their reliability and robustness under all conditions. This process is particularly critical in verifying the semantic equivalence between complex transformations introduced during implementation. Two key areas of focus include:
  • Semantic Equivalence in Pairing Operations: Proving that the chunked version of the multi-Miller loop pairing computation is semantically equivalent to the original, unchunked version. This transformation is vital for adapting cryptographic computations to Bitcoin's script limitations while preserving their correctness.
  • Optimized Chunk Verification: Establishing the equivalence between a standard chunk in the layout and its optimized counterpart, which incorporates auxiliary pre-known inputs. This step is crucial for enhancing efficiency while ensuring the optimized chunks maintain the intended behavior and constraints of the original design.

Formal verification of these transformations addresses the most complex challenges in BitVM's implementation. By providing mathematical guarantees of correctness, this approach reduces the risk of vulnerabilities, strengthens trust in the protocol, and lays the foundation for more secure and scalable applications built on top of BitVM. Additionally, formal verification supports modular development, enabling easier debugging, iterative improvements, and the creation of a robust framework for future protocol innovations.

• Runtime Security Mechanisms: Ensuring the safe and reliable execution of BitVM requires seamless coordination among multiple parties, including the committee responsible for signature generation, the operator maintaining liveness, and the challengers responding to disputes. To safeguard this ecosystem, a robust real-time security mechanism and framework must be developed to address key operational challenges. Key components include:
  • Real-Time Monitoring of Execution: Actively track and verify the correct behavior of all parties, with a particular emphasis on the integrity of the signature generation process. This ensures that committee actions adhere to protocol specifications and remain free of tampering or errors.
  • Suspicious Activity Detection and Alerts: Implement mechanisms to detect and flag any suspicious transactions or potentially malicious behavior by operators. Participants should receive timely alerts about such activities, enabling rapid response and mitigation of threats to the protocol's security and integrity.
  • Operator Liveness Monitoring: Continuously monitor the operator's activity to prevent downtime that could lead to locked funds. Proactive mechanisms should address operator inactivity by triggering predefined recovery or escalation processes, ensuring uninterrupted protocol functionality.

By implementing a comprehensive runtime security framework, the BitVM ecosystem can reduce the risk of vulnerabilities, foster greater trust among participants, and ensure the system remains resilient against malicious attacks or operational failures. These mechanisms would also contribute to the overall scalability and accessibility of BitVM by providing a safety net for both developers and users.

VI. Conclusion

As BitVM evolves, addressing key challenges in scalability, efficiency, and security is crucial for its success in real-world applications. Advancing Bitcoin-friendly cryptographic primitives, such as efficient commitment schemes, tailored hash functions, and low-bit-width pairing techniques, will lower costs and enhance decentralization. Automating the compilation pipeline with layout optimization, automated code rewriting, and user-friendly interfaces will streamline protocol design and unlock new possibilities beyond the original permissionless bridge concept. Formal verification and runtime security mechanisms will ensure the correctness, reliability, and safety of BitVM programs, safeguarding assets and fostering trust. These advancements position BitVM to fully realize Bitcoin's potential as a secure and versatile platform for decentralized innovation.

‍

^{Legal Disclosure: This document, and the information contained herein, has been provided to you by Hyperedge Technology LP and its affiliates (“Symbolic Capital”) solely for informational purposes. This document may not be reproduced or redistributed in whole or in part, in any format, without the express written approval of Symbolic Capital. Neither the information, nor any opinion contained in this document, constitutes an offer to buy or sell, or a solicitation of an offer to buy or sell, any advisory services, securities, futures, options or other financial instruments or to participate in any advisory services or trading strategy. Nothing contained in this document constitutes investment, legal or tax advice or is an endorsement of any of the digital assets or companies mentioned herein. You should make your own investigations and evaluations of the information herein. Any decisions based on information contained in this document are the sole responsibility of the reader. Certain statements in this document reflect Symbolic Capital’s views, estimates, opinions or predictions (which may be based on proprietary models and assumptions, including, in particular, Symbolic Capital’s views on the current and future market for certain digital assets), and there is no guarantee that these views, estimates, opinions or predictions are currently accurate or that they will be ultimately realized. To the extent these assumptions or models are not correct or circumstances change, the actual performance may vary substantially from, and be less than, the estimates included herein. None of Symbolic Capital nor any of its affiliates, shareholders, partners, members, directors, officers, management, employees or representatives makes any representation or warranty, express or implied, as to the accuracy or completeness of any of the information or any other information (whether communicated in written or oral form) transmitted or made available to you. Each of the aforementioned parties expressly disclaims any and all liability relating to or resulting from the use of this information. Certain information contained herein (including financial information) has been obtained from published and non-published sources. Such information has not been independently verified by Symbolic Capital and, Symbolic Capital, does not assume responsibility for the accuracy of such information. Affiliates of Symbolic Capital may have owned or may own investments in some of the digital assets and protocols discussed in this document. Except where otherwise indicated, the information in this document is based on matters as they exist as of the date of preparation and not as of any future date, and will not be updated or otherwise revised to reflect information that subsequently becomes available, or circumstances existing or changes occurring after the date hereof. This document provides links to other websites that we think might be of interest to you. Please note that when you click on one of these links, you may be moving to a provider’s website that is not associated with Symbolic Capital. These linked sites and their providers are not controlled by us, and we are not responsible for the contents or the proper operation of any linked site. The inclusion of any link does not imply our endorsement or our adoption of the statements therein. We encourage you to read the terms of use and privacy statements of these linked sites as their policies may differ from ours. The foregoing does not constitute a “research report” as defined by FINRA Rule 2241 or a “debt research report” as defined by FINRA Rule 2242 and was not prepared by Symbolic Capital Partners LLC. For all inquiries, please email [email protected]. © Copyright Hyperedge Capital LP 2024. All rights reserved.}