Analyzing Bitcoin Layer 2 Scaling Technologies: Validity Proofs and Fraud Proofs
TechFlow Selected TechFlow Selected
Analyzing Bitcoin Layer 2 Scaling Technologies: Validity Proofs and Fraud Proofs
There are many limitations under the Bitcoin paradigm, but various clever methods or techniques can be used to overcome these constraints.
Navigating Web3 tides with focused insightsAuthor: mutourend & lynndell, Bitlayer Labs
1 Introduction
For an algorithm f, two mutually untrusted parties Alice and Bob can establish trust in the following ways:
-
Alice inputs x, runs algorithm f, and obtains result y. Bob, using the same input x, also runs algorithm f and gets result y′. If y = y′, Bob accepts Alice's input x and output y. This is a special validity proof mechanism commonly used in blockchain consensus. Here, Alice is the node packaging blocks, and Bob is a consensus participant node.
-
Alice inputs x, runs zk.prove on algorithm f, and obtains result y and proof. Bob runs zk.verify using f, y, and proof. If the result is true, Bob accepts Alice’s result y; if false, Bob rejects it. This is a validity proof. Bob can be an on-chain contract.
-
Alice inputs x, runs algorithm f, and obtains result y. Bob, using the same input x, also runs algorithm f and gets result y′. If y = y′, nothing happens; if y ≠ y′, Bob challenges Alice, targeting program f. The interaction between Alice and Bob may occur once or multiple times. Arbitration is achieved through a challenge-response process. This is fraud proof. Bob acts as the challenger, monitoring off-chain and challenging on-chain.
-
Alice inputs x, runs zk.prove on algorithm f, and obtains result y and proof. Bob runs zk.verify using f, y, and proof. If the result is true, nothing happens; if false, Bob challenges Alice, targeting zk.verify. The interaction between Alice and Bob may occur once or multiple times. Arbitration is achieved through a challenge-response process. This is fraud proof. Bob acts as the challenger, monitoring off-chain and challenging on-chain.
For cases 2, 3, and 4 above, let x represent Layer 2 transactions and initial state, f represent the Layer 2 consensus program, and y represent the final state after transaction execution. These correspond to blockchain Layer 2 scaling solutions. Specifically:
-
Validity Proof: Based on a pessimistic assumption, a state transition must be proven valid before acceptance, and it takes effect immediately. A validity proof requires providing evidence that the L2 state transition is correct, reflecting a pessimistic view of the world—only accepting a state when its correctness is proven.
-
Fraud Proof: Based on an optimistic assumption, a state transition is accepted by default unless proven incorrect. It includes a challenge window period, during which the state only becomes finalized after the window expires. A fraud proof requires providing evidence that the L2 state transition is incorrect, reflecting an optimistic view of the world—a state transition is assumed correct unless proven otherwise.
Table 1: Trust Establishment Methods
Additionally, note the following:
-
The key distinction between fraud proofs and validity proofs does not lie in whether SNARK/STARK or other ZK proof systems are used. ZK proof systems refer to the type of proof technique employed, whereas "fraud" vs. "validity" refers to what is being proven. This explains why scenario 1 in Table 1 represents a form of validity proof.
-
Validity proofs offer better timeliness but have higher on-chain verification complexity; fraud proofs have lower on-chain verification complexity but poorer timeliness.
-
For scenarios 2 and 4 in Table 1, leveraging ZK recursion and composition techniques, multiple instances of f can be computationally compressed, significantly reducing the on-chain verification cost for off-chain computations.
Currently, thanks to Solidity's Turing-complete smart contracts, both fraud proofs and validity proofs are widely used in Ethereum Layer 2 scaling. However, under the Bitcoin paradigm, due to limitations such as Bitcoin's restricted opcodes and a stack limited to 1000 elements, these technologies remain in the exploratory stage. This article summarizes the constraints and breakthrough techniques under the Bitcoin paradigm for Bitcoin Layer 2 scaling, studies validity and fraud proof technologies, and outlines the unique script splitting techniques available under the Bitcoin model.
2 Limitations and Breakthroughs Under the Bitcoin Paradigm
The Bitcoin paradigm has many limitations, but various clever methods or techniques can overcome them. For example, bit commitment overcomes UTXO statelessness, Taproot overcomes script space limits, connector outputs overcome UTXO spending method limitations, and covenants overcome pre-signing restrictions.
2.1 UTXO Model and Script Limitations
Bitcoin uses the UTXO model, where each UTXO is locked within a locking script defining the conditions required to spend it. Bitcoin scripts have the following limitations:
-
Bitcoin scripts are stateless;
-
For P2TR output types, a single transaction can contain up to approximately 4 million opcodes, filling an entire block, while other output types allow only about 10,000 opcodes;
-
Spending methods for individual UTXOs are limited, with little exploration into composite spending methods;
-
Flexible covenant functionality is not supported;
-
The stack size is limited to 1000 elements (altstack + stack), and individual elements are capped at 520 bytes;
-
Arithmetic operations (e.g., addition, subtraction) are limited to 4-byte elements. They cannot be extended to longer elements like 20 bytes or more, which are necessary for cryptographic operations;
-
Op-codes such as OP_MUL and OP_CAT are disabled. Simulating them using existing opcodes is extremely costly—for instance, simulating one round of BLAKE3 hashing results in a script size of about 75KB.
2.2 Bit Commitment: Overcoming UTXO Statelessness
Current Bitcoin scripts are completely stateless. Each script execution environment resets after every script run. This prevents native support for constraining Script 1 and Script 2 to use the same value x. However, this issue can be circumvented by signing values in some way. If a value can be signed, stateful Bitcoin scripting becomes possible. By verifying the signature of x in both Script 1 and Script 2, consistency of x across scripts can be enforced. Conflicting signatures—two different values signed for the same variable x—can be penalized. This solution is known as bit commitment.
The principle of bit commitment is relatively simple. For each bit in the message to be signed, two distinct hash values are set: hash0 and hash1. If the bit value to be signed is 0, the preimage of hash0 (preimage0) is revealed; if the bit value is 1, the preimage of hash1 (preimage1) is revealed.
Take a single-bit message m ∈ {0,1} as an example. The corresponding bit commitment unlock script consists of just the preimages: if the bit value is 0, the unlock script is preimage0—"0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140"; if the bit value is 1, the unlock script is preimage1—"0x47c31e611a3bd2f3a7a42207613046703fa27496". Thus, bit commitment enables stateful Bitcoin scripting, unlocking various novel features.
OP_HASH160
OP_DUP
<0xf592e757267b7f307324f1e78b34472f8b6f46f3> // This is hash1
OP_EQUAL
OP_DUP
OP_ROT
<0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // This is hash0
OP_EQUAL
OP_BOOLOR
OP_VERIFY
// Now the value of the bit commitment is on the stack. Either "0" or "1".
There are currently two implementations of bit commitment:
-
Lamport One-Time Signatures: Simple in principle, requiring only hash functions, making it Bitcoin-friendly. For each bit in the message, two hash values must be committed, resulting in relatively large signature data. In other words, for a message of v bits, the public key length is 2v bits, and the signature length is v bits.
-
Winternitz One-Time Signatures: Compared to Lamport signatures, this approach significantly reduces signature and public key lengths but increases signing and verification complexity. The scheme allows flexible configuration of different hash chain lengths (d), enabling trade-offs between size and complexity. For example, setting d=15 reduces both public key and signature lengths by roughly 4x, but increases verification complexity by 4x. This essentially trades off Bitcoin stack space against script size. Lamport signatures are a special case of Winternitz signatures with d=1.
The BitVM2 library currently implements Winternitz signatures based on the Blake3 hash function. The signature length per bit is approximately 26 bytes. Therefore, introducing state via bit commitment is expensive. In BitVM2 engineering practice, the message is first hashed to produce a 256-bit hash value, then bit commitment is applied to this hash—reducing overhead—rather than directly committing each bit of the original long message.
2.3 Taproot: Overcoming Script Space Limits
The Bitcoin Taproot soft fork upgrade, activated in November 2021, included three proposals: Schnorr signatures (BIP 340), Taproot (BIP 341), and TapScript (BIP 342). It introduced a new transaction type—Pay-to-Taproot (P2TR). P2TR transactions leverage the advantages of Taproot, MAST (Merkle Abstract Syntax Trees), and Schnorr signatures to create more private, flexible, and scalable transaction formats.
P2TR supports two spending methods: key path and script path.
According to Taproot (BIP 341), when spending via script path, the corresponding Merkle path length must not exceed 128. This means the number of tapleaf nodes in a taptree cannot exceed 2^128. Since the 2017 SegWit upgrade, Bitcoin network block size has been measured in weight units, with a maximum of 4 million weight units (approximately 4MB). When a P2TR output is spent via script path, only a single tapleaf script needs to be revealed—meaning the block contains just that one tapleaf script. Thus, for P2TR transactions, the script size per tapleaf can be up to ~4MB. However, many nodes follow default policies limiting relayed transactions to under 400KB; larger transactions require coordination with miners to ensure inclusion.
The script space expansion enabled by Taproot makes it more viable to simulate cryptographic operations like multiplication and hashing using existing opcodes.
When building verifiable computation based on P2TR, the script size is no longer constrained by the 4MB limit. Instead, the computation can be split into sub-functions distributed across multiple tapleaf nodes, thereby overcoming the 4MB script space limitation. In fact, the Groth16 verifier algorithm implemented in current BitVM2 has a size of up to 2GB. However, it can be partitioned and distributed across approximately 1000 tapleaf nodes. Combined with bit commitment, consistency between inputs and outputs of sub-functions can be enforced, ensuring the integrity and correctness of the overall computation.
2.4 Connector Output: Overcoming UTXO Spending Method Limitations
Bitcoin natively supports two spending methods for a single UTXO: spending via script or via public key. As long as the correct public key signature is provided or script conditions are met, the UTXO can be spent. Two UTXOs can be independently spent, but there is no native way to impose constraints requiring additional conditions for their joint spending.
However, Burak, founder of the Ark protocol, ingeniously leveraged SIGHASH flags to implement connector outputs. Specifically, Alice can create a signature to send BTC to Bob. Because the signature can commit to multiple inputs, Alice can make her signature conditional: valid for the Take_tx transaction if and only if it consumes a second input. This second input is called a connector, linking UTXO A and UTXO B. In other words, Take_tx is valid only if UTXO B has not been spent by Challenge_tx. Therefore, destroying the connector output blocks the Take_tx transaction from becoming valid.
Figure 1: Illustration of connector output
In the BitVM2 protocol, connector outputs serve an if...else function. Once a connector output is spent by one transaction, it cannot be spent by another, ensuring exclusive usage. In practical deployments, to reserve time for challenge-response cycles, additional timelocked UTXOs are introduced. Furthermore, connector outputs can adopt different spending strategies as needed—for example, allowing anyone to spend the challenge transaction, while restricting the response transaction to the operator or allowing anyone to spend after a timeout.
2.5 Covenants: Overcoming Pre-Signing Limitations
Current Bitcoin scripts mainly restrict unlocking conditions but do not constrain how a UTXO can be further spent. This is because Bitcoin scripts cannot read the content of the transaction itself—they lack transaction introspection. If Bitcoin scripts could inspect any part of the transaction (including outputs), covenant functionality would become possible.
Current covenant implementations fall into two categories:
-
Pre-signing: Using existing Bitcoin script capabilities, limited predefined covenants are constructed via pre-signed transactions. All possible future transactions are designed and signed in advance, locking participants into specific private keys and fee rates. Some schemes even require participants to generate short-term private keys for all pre-signed transactions. After pre-signing, these short-term keys are securely deleted, preventing attackers from stealing funds. However, adding new participants or updating operations requires repeating the entire process, leading to high maintenance costs. For example, the Lightning Network implements two-party covenants via pre-signing and achieves routing through HTLCs, enabling minimally trusted scaling. But it requires pre-signing many transactions and is limited to two parties, making it cumbersome. In BitVM1, hundreds of transactions must be pre-signed at initialization; even in optimized BitVM2, dozens still need pre-signing. In both BitVM1 and BitVM2, only pre-signing operators are eligible for reimbursement. If n participants each pre-sign m transactions, the pre-signing complexity per participant is n × m.
-
Introducing Covenant Opcodes: Adding new covenant opcodes can greatly reduce communication and maintenance complexity among participants, enabling more flexible covenant implementations on Bitcoin. For example, OP_CAT concatenates byte strings. Though simple, it is powerful enough to drastically reduce BitVM complexity. OP_TXHASH enables finer-grained control over actions within covenants. Used in BitVM, it could support larger operator sets, improving security assumptions and minimizing trust. Moreover, pre-signing forces BitVM designs to rely on reimbursement workflows with poor capital efficiency. With new covenant opcodes, direct payments from peg-in pools to withdrawal users might be possible, further enhancing capital efficiency. Thus, flexible covenant models effectively break traditional pre-signing limitations.
3 Bitcoin Layer 2 Scaling: Validity Proofs and Fraud Proofs
Both validity proofs and fraud proofs can be used for Bitcoin L2 scaling. Their main differences are shown in Table 2.
Table 2: Validity Proof vs. Fraud Proof
Using bit commitment, Taproot, pre-signing, and connector outputs, fraud proofs can be built on Bitcoin. Using Taproot along with covenant opcodes like OP_CAT, validity proofs can be constructed on Bitcoin. Additionally, depending on whether Bob has access control, fraud proofs can be classified as permissioned or permissionless. In permissioned fraud proofs, only specific groups can act as challengers (Bob); in permissionless fraud proofs, any third party can challenge. Permissionless fraud proofs offer superior security by reducing collusion risks among permitted parties.
Depending on the number of interactions between Alice and Bob during challenge-response, fraud proofs can be categorized as one-round or multi-round, as shown in Figure 2.
Figure 2: One-Round vs. Multi-Round Fraud Proofs
As shown in Table 3, fraud proofs can be implemented using different interaction models, including one-round and multi-round models.
Table 3: One-Round vs. Multi-Round Interaction
Under the Bitcoin Layer 2 scaling paradigm, BitVM1 uses a multi-round fraud proof mechanism, BitVM2 uses a one-round fraud proof mechanism, and bitcoincircle stark uses validity proofs. BitVM1 and BitVM2 can be implemented without modifying the Bitcoin protocol, whereas bitcoin-circle stark requires introducing the new opcode OP_CAT.
For most computational tasks, Bitcoin signet, testnet, and mainnet cannot fully express scripts within 4MB and must use script splitting—dividing the complete computation script into chunks smaller than 4MB and distributing them across tapleaf nodes.
3.1 Multi-Round Fraud Proofs on Bitcoin
As shown in Table 3, multi-round fraud proofs are suitable for scenarios aiming to reduce on-chain arbitration computation or when pinpointing faulty computation segments in one step is impossible. As the name suggests, multi-round fraud proofs require multiple interactions between prover and verifier to locate the erroneous segment before arbitration.
Robin Linus’s early BitVM whitepaper (commonly referred to as BitVM1) used multi-round fraud proofs. Assuming a one-week challenge period per round and using binary search to locate errors, the on-chain challenge-response cycle for a Groth16 verifier could reach up to 30 weeks, resulting in very poor timeliness. Although teams are now researching more efficient n-ary search methods beyond binary search, they still lag far behind the two-week cycle of one-round fraud proofs in terms of timeliness.
Currently, multi-round fraud proofs under the Bitcoin paradigm use permissioned challenges, whereas one-round fraud proofs achieve permissionless challenges, reducing collusion risk and thus offering higher security. To this end, Robin Linus fully leveraged Taproot’s advantages to optimize BitVM1—not only reducing interactions to one round but also expanding challenges to permissionless mode, albeit at the cost of increased on-chain arbitration computation.
3.2 One-Round Fraud Proofs on Bitcoin
A single interaction between prover and verifier suffices to verify or refute a fraud proof. In this model, the verifier issues one challenge, and the prover provides one response. Within this response, the prover claims their computation is correct. If the verifier detects inconsistency in the evidence, the challenge succeeds; otherwise, it fails. Characteristics of one-round fraud proofs are shown in Table 3.
Figure 3: One-Round Fraud Proof
On August 15, 2024, Robin Linus released the technical whitepaper *BitVM2: Bridging Bitcoin to Second Layers*, implementing the BitVM2 cross-chain bridge using a one-round fraud proof mechanism similar to Figure 3.
3.3 Implementing Validity Proofs on Bitcoin with OP_CAT
OP_CAT was part of Bitcoin’s original scripting language but was disabled in 2010 due to security vulnerabilities. However, the Bitcoin community has discussed reactivating it for years. OP_CAT is now assigned opcode 347 and has been enabled on Bitcoin signet.
OP_CAT primarily concatenates two stack elements and pushes the result back onto the stack. This capability unlocks covenants and STARK verifiers on Bitcoin:
-
Covenants: Andrew Poelstra proposed "CAT and Schnorr Tricks I", using OP_CAT and Schnorr techniques to implement covenants on Bitcoin. Schnorr signatures are used for P2TR outputs; ECDSA-based equivalents exist for other output types ("Covenants with CAT and ECDSA"). OP_CAT covenants help split STARK verifier algorithms into multiple transactions for step-by-step verification of the full STARK proof.
-
STARK Verifier: A STARK verifier essentially involves concatenating data and hashing it. Unlike algebraic operations, hashing is a native Bitcoin script operation, saving significant overhead. For example, OP_SHA256 requires only one opcode natively, versus hundreds of thousands when simulated. Key hashing operations in STARKs include Merkle path verification and Fiat-Shamir transformations. Hence, OP_CAT is highly compatible with STARK verifier algorithms.
3.4 Bitcoin Script Splitting Techniques
Although SNARK/STARK proofs drastically reduce verification computation compared to running the original function f directly, converting the verifier algorithm into Bitcoin script still results in massive script sizes. Currently, even after optimization using existing Bitcoin opcodes, Groth16 and Fflonk verifiers still exceed 2GB in script size. However, Bitcoin blocks are limited to 4MB, making it impossible to execute the entire verifier script in a single block. Fortunately, post-Taproot, scripts can be executed per tapleaf, allowing the verifier script to be split into chunks, each serving as a tapleaf in a taptree. Bit commitment ensures consistency of values across chunks.
With OP_CAT covenants, STARK verifiers can be split into standard transactions under 400KB, enabling full STARK validity proof verification without miner coordination.
This section focuses on script splitting techniques under the current Bitcoin model without activating new opcodes.
When splitting scripts, the following dimensions must be balanced:
-
Each chunk script size must not exceed 4MB, accounting for input bit commitment scripts, transaction signatures, etc.
-
Each chunk stack size must not exceed 1000 elements. Chunks should retain only necessary elements on the stack, reserving space for script size optimization. Transaction fees do not depend on stack size used.
-
Bit commitment on Bitcoin is expensive (~26 bytes per bit). Minimize the number of bits passed between adjacent chunks.
-
For auditability, each chunk’s function should be as clear as possible.
Current script splitting approaches fall into three main categories:
-
Automatic Splitting: Finds splits around 3MB script size with minimal stack usage, independent of the verifier algorithm and applicable to arbitrary computations. Advantages: General-purpose. Disadvantages: (1) Logical blocks (e.g., OP_IF) cannot be split without breaking execution semantics; (2) Chunk outputs may involve multiple stack elements, requiring manual identification of which elements need bit commitment; (3) Poor readability and auditability; (4) Stack may contain unused elements, wasting space.
-
Functional Splitting: Splits based on functional subroutines, with clear inputs and outputs. Bit commitment scripts are generated alongside split scripts, ensuring total script size < 4MB and stack size < 1000. Advantages: Clear functionality, readable, auditable. Disadvantages: Optimal high-level logic does not guarantee optimal script-level performance.
-
Manual Splitting: Split points are manually defined, especially useful when a single subroutine exceeds 4MB. Advantages: Allows fine-grained splitting of heavy scripts (e.g., Fq12 computations); clear logic, good readability and auditability. Disadvantages: Dependent on manual tuning; previous split points may become suboptimal after overall optimizations, requiring re-adjustment.
For example, the Groth16 verifier, after multiple rounds of optimization, reduced its script size from ~7GB to ~1.26GB. Beyond global optimization, individual chunks can also be optimized to better utilize stack space—such as using lookup-table-based algorithms with dynamic loading/unloading to further reduce per-chunk script size.
Web2 programming languages differ fundamentally from Bitcoin scripts in cost and execution environment. Simply translating existing algorithms into Bitcoin scripts is ineffective. Therefore, Bitcoin-specific optimizations are essential:
-
Seek algorithms with optimal memory locality—even at the cost of extra computation—to minimize input/output bits between chunks, reducing data commitment size in BitVM2’s assertTx transactions.
-
Exploit commutativity of operations (e.g., logical AND: x&y = y&x) to save nearly half the lookup table size.
-
Given the large script footprint of Fq12 operations, consider leveraging Fiat-Shamir, Schwartz-Zippel, and polynomial commitment schemes to drastically reduce computational complexity in extension field arithmetic.
4 Summary
This article first outlined Bitcoin script limitations and introduced techniques to overcome them: bit commitment to bypass UTXO statelessness, Taproot to overcome script space limits, connector outputs to expand UTXO spending methods, and covenants to break pre-signing constraints. Then, it comprehensively reviewed and summarized the characteristics of fraud proofs and validity proofs, permissioned vs. permissionless fraud proofs, one-round vs. multi-round fraud proofs, and Bitcoin script splitting techniques.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@BitlayerLabs
