Execution Limits Shape Bitcoin VM Design

Bitcoin's ~4MB block size limit and 10-minute block time create a hard throughput cap of ~7-10 TPS. This forces VM designs to be hyper-efficient, making every byte and opcode count.

• Constraint: Computation must fit within a single block's witness space.
• Consequence: Complex smart contracts are prohibitively expensive or impossible.

Projects like Stacks and Rootstock (RSK) use a two-layer model. Smart contracts execute off-chain in a separate VM, with only cryptographic proofs or state commitments posted to Bitcoin.

• Benefit: Enables EVM/Solidity compatibility and complex dApps.
• Trade-off: Introduces new trust assumptions or requires a separate validator set.

Protocols like BitVM and Covenants work within Bitcoin Script's limits by using clever cryptographic tricks (e.g., N-of-N multisig fraud proofs, Taproot trees). They treat Bitcoin as a verification layer, not a computation layer.

• Benefit: Maximal security inheriting Bitcoin's full PoW.
• Trade-off: Extremely constrained programming model; development is complex and gas-intensive.

Bitcoin Script lacks loops and is not Turing-complete by design. This prevents infinite loops but also makes general-purpose computation impossible, forcing VM logic into static, predetermined execution paths.

• Constraint: No native loops or dynamic jumps.
• Consequence: Every possible program state must be enumerated in advance, exploding in size for complex logic.

Architectures inspired by RGB and Client-Side Validation shift the burden of state computation and storage to users. Bitcoin secures ownership and finality, while users validate state transitions off-chain.

• Benefit: Enables scalable, complex assets (~1M+ TPS theoretical).
• Trade-off: Heavy client requirements; poor user experience for light clients.

Every Bitcoin VM design lands on a spectrum. BitVM maximizes security at the cost of expressiveness. Stacks/RSK maximize expressiveness by introducing new trust layers. The constraint matrix forces a clear choice: you cannot have Ethereum-level programmability with Bitcoin-level security without a fundamental breakthrough.

• Axis 1: Native Security (PoW) vs. Bridged Security (Federations/Pos).
• Axis 2: On-Chain Verification vs. Off-Chain Execution.

Native Bitcoin Script lacks loops and state, making complex DeFi or smart contracts impossible. This forces innovation to happen off-chain or in layers.\n- Key Constraint: No native loops or persistent on-chain state.\n- Result: Core protocol security is preserved, but functionality is severely limited.

Move execution and state off-chain, using Bitcoin solely as a judicial settlement layer. This preserves Bitcoin's security for finality while enabling complex logic.\n- Key Benefit: Enables Turing-complete smart contracts and scalable payments.\n- Trade-off: Introduces liveness assumptions and data availability challenges for users.

Embed a separate VM's state transitions into Bitcoin transactions via OP_RETURN or similar outputs. Bitcoin attests to VM state history.\n- Key Benefit: Inherits Bitcoin's immutable timestamping and consensus security.\n- Trade-off: Execution is not validated by Bitcoin miners, creating a separate security model for the VM.

Use Bitcoin's block space only to post data commitments and fraud proofs. All computation is verified off-chain in a challenge-response game.\n- Key Benefit: Enables trust-minimized computation without changing Bitcoin consensus.\n- Trade-off: High on-chain cost for fraud proofs and complex, multi-round challenge protocols.

The core constraint. Main block space is for settlement, not computation. Script is intentionally limited to prevent consensus attacks.

• Forces a clear separation between execution and settlement layers.
• Drives innovation in off-chain state channels (Lightning) and sidechains.
• Makes every opcode and byte of witness data a precious resource.

Upgrade the base layer for more expressive, yet still bounded, contracts. Taproot (Schnorr, MAST) enables complex logic with a single on-chain signature.

• Enables batched payments and sophisticated multisig without bloating the chain.
• Paves way for covenants (OP_CTV, APO) to create vaults and non-custodial protocols.
• Maintains Bitcoin's security model by keeping logic verifiable, not Turing-complete.

Move computation off-chain, post only commitments. Inspired by RGB and BitVM. The chain becomes a court of last resort.

• Shifts burden of execution to users and watchtowers, not miners.
• Allows for complex state transitions (DeFi, NFTs) without consensus changes.
• Requires a robust, always-online client assumption, trading liveness for scalability.

Ethereum L2s optimize for gas; Bitcoin L2s optimize for sovereignty. Every design choice preserves user exit rights.

• Rejects centralized sequencers in favor of federations or 1-of-N trust models.
• Accepts higher latency and complexity to avoid introducing new trust assumptions.
• Results in a slower, more deliberate ecosystem compared to alt-L1s and Ethereum rollups.

Forget account-based models. Bitcoin smart contracts model state as owned, spendable UTXOs with attached conditions.

• Enables parallel processing and better privacy via coinjoin-like techniques.
• Creates challenges for global state synchronization (e.g., an AMM's liquidity).
• Leads to designs like statechains and discrete log contracts (DLCs).

Ethereum added a VM, then scaled it. Bitcoin is scaling by minimizing the VM. This defines the builder's toolkit.

• EVM/Solana: Maximize on-chain compute, then scale via rollups/parallelism.
• Bitcoin VM: Minimize on-chain compute, scale via layers and client-side validation.
• Result: Bitcoin L2s (Stacks, Liquid) are more like sovereign chains than Ethereum rollups.