Bitlayer 백서 전문

Bitlayer Network: The Computational Layer for Bitcoin 2.0 Bitlayer Research Team July 9, 2025 Abstract Bitcoin’s limited transaction throughput and programmability hinder its potential in De- centralized Finance (DeFi). Existing Layer 2 solutions often introduce new trust assumptions, failing to anchor their security directly to Bitcoin’s consensus. This paper introduces Bitlayer, a Layer 2 network that solves this challenge using the BitVM paradigm. Our core contribution is a novel, recursive verification protocol that, for the first time, enables a continuous chain of Layer 2 state transitions to be verifiably settled on Bitcoin. This moves beyond mere data inscription to achieve security rooted in Bitcoin’s proof-of-work. Furthermore, we deeply integrate BitVM bridge with our rollup protocol to enable secure transfers of Bitcoin assets. Finally, we designed a modular and Turing-complete execution engine, which, powered by a fast consensus mech- anism, provides users with sub-second soft finality. Bitlayer unlocks Bitcoin’s vast, untapped capital for a new generation of decentralized applications, laying a foundational infrastructure for the Bitcoin DeFi ecosystem. 1 Introduction Bitcoin [1] holds immense potential for Decentralized Finance (DeFi), but its core design limits transaction throughput and programmability. Activating Bitcoin’s vast, untapped capital thus depends on secure and scalable Layer 2 solutions. However, existing approaches to scaling Bitcoin fall short. Sidechains that rely on federated multisignatures introduce centralized trust, fundamentally undermining Bitcoin’s security model. Meanwhile, early rollup designs for Bitcoin can post transaction data to the L1 but lack a mechanism to enforce the validity of state transitions on-chain. This leaves them vulnerable, as their security is not fully guaranteed by Bitcoin’s consensus. This raises a critical question: is it possible to build a Bitcoin L2 that achieves scalable com- putation while ensuring state validity is enforced by the Bitcoin mainnet itself, without new trust assumptions? This paper introduces Bitlayer, a Layer 2 network that provides an affirmative answer through rollup architecture [7] and the BitVM paradigm [2]. overcoming the limitations of both the Bitcoin and existing Layer 2 solutions by enabling scalable computation while anchoring its security to the underlying Bitcoin blockchain. Our primary contributions are as follows: • A Modular and T uring-Complete Execution Layer: We design and implement a mod- ular execution layer that enables Turing-complete smart contracts, leveraging a meticulously designed blockchain protocol to achieve sub-second soft finality and provide a responsive experience ideal for demanding applications like DeFi and gaming. 1 • A Recursive Bitcoin Settlement Protocol for Rollups : We design and formalize the first rollup protocol that uses a recursive BitVM-based framework to settle a continuous claim chain of Layer 2 state transitions on Bitcoin. This provides security by anchoring the L2’s validity directly to the L1. • A Synergistic Integration of Bridge and Rollup : We design and implement a secure asset bridge inspired by the BitVM bridge architecture. The core innovation is its deep integration with our rollup protocol, which ensures that asset security and rollup validity are governed by a unified trust model, enabling seamless and secure asset transfers. 2 Network Architecture Bitlayer operates on a dual-level architecture that combines a Proof-of-Stake (PoS) consensus for fast block production with a rollup framework that anchors its security to the Bitcoin network. The PoS layer allows validators to sequence transactions and produce blocks rapidly, providing a high-throughput, EVM-compatible environment. The rollup layer then periodically commits and settles the state of this L2 chain onto the Bitcoin blockchain. This design leverages Bitcoin as the ultimate layer for security and data availability, while Bitlayer Network serves as a scalable and efficient computational layer. 2.1 Network Participants and Roles The network is maintained by two key participants: Validators, and Full Nodes. Figure 1: Network Architecture • V alidators: Validators form the backbone of the PoS consensus. They are responsible for producing and validating L2 blocks, ensuring the network’s safety and liveness. To join the 2 validator set, a candidate must stake BTR tokens, and their influence in the consensus is proportional to their total stake, which can include tokens delegated by other BTR holders. – Rollup Operator : The Rollup Operator is a specialized, rotating role assigned to a sin- gle validator from the set. This operator is responsible for bundling L2 state transitions into batches, generating cryptographic proofs, and submitting them for settlement on the Bitcoin L1. To ensure accountability and disincentivize fraud, the operator must lock a significant amount of BTC as collateral on L1. The operator role rotates periodically to prevent censorship and centralization. • F ull Nodes: Full nodes maintain a complete copy of the Bitlayer Network blockchain, inde- pendently verifying all transactions and state transitions without trusting validators. They play a crucial role in enforcing the protocol rules and ensuring network transparency. 2.2 Dual-Level Transaction Finality Bitlayer offers a dual-level finality model, giving users and applications a choice between speed and Bitcoin-level security. • Soft Finality: A transaction achieves soft finality in sub-second once the block containing it is confirmed by Bitlayer’s PoS consensus. This provides a fast and responsive user experience, with security backed by the economic stake of the validator set. • Hard Finality: Hard finality is the highest security guarantee, achieved when the L2 state containing the transaction is settled and finalized on the Bitcoin blockchain. Due to the optimistic rollup’s challenge period, this takes approximately seven days. The security for hard finality relies on only a single honest party to challenge fraud, making it nearly equivalent to Bitcoin’s own security. In the rare event of a successful L1 challenge that creates a discrepancy between the L2 state and the settled L1 state, the protocol is designed to halt. The network’s recovery would then be guided by social consensus among stakeholders to ensure the integrity of user assets. 3 Settling L2 State on Bitcoin As a Layer 2 rollup, Bitlayer derives its security from Bitcoin. This chapter details the core mechanism that underpins this relationship: settlement. Settlement is the process by which L2 state transitions, executed in Bitlayer’s high-throughput environment, are committed to and finalized on the Bitcoin L1. This allows Bitlayer to inherit Bitcoin’s security guarantees. The challenge, however, is achieving this on Bitcoin’s constrained, non-Turing-complete script environment. Our solution is a novel settlement protocol inspired by the BitVM paradigm. This chapter systematically deconstructs this protocol. We first define the concepts of a state claim and explain our hybrid verification approach. After introducing the necessary cryptographic primitives, we detail the protocol for settling a single state claim. Finally, we show how this is extended into a recursive protocol that settles a continuous chain of L2 claims, forming the backbone of the entire rollup. 3 3.1 Defining the L2 State Claim At its core, a blockchain is defined by a State T ransition F unction (STF), denoted as Υ. This deterministic function dictates how the network’s State ( s) evolves. A state, which includes all account balances and contract data, is represented by a 32-byte Merkle root. The STF takes the current state st and a batch of L2 T ransaction Batch (T ) to produce the next state st+1: st+1 = Υ(st, T) where t is the index of transaction batch. The entire history of the blockchain unfolds from an initial genesis state ( s0). A State Claim ( Φ) is a formal assertion submitted by a Rollup Operator to a smart contract on the Bitcoin L1. Its purpose is to commit to a new L2 state that has resulted from processing a specific transaction batch. This claim acts as the anchor, linking L2 activity to the L1 and enabling Bitlayer Network to inherit Bitcoin’s security. Φ = {st−1, st, T} 3.2 Cryptographic Primitives The settlement protocol relies heavily on two advanced cryptographic primitives: Succinct Non- interactive Arguments (SNARGs) and Hash-based One-Time Signature scheme. 3.2.1 Groth16 SNARG Following the Groth16 paper [4], a SNARG for a relationR consists of three probabilistic polynomial- time algorithms ( Setup, Prove, Vfy): • δ ← SNARG.Setup(R): A setup algorithm that produces a common reference string δ for a given relation. • π ← SNARG.Prove(R, δ,Φ, ω): A prover algorithm that, given the common reference string δ, a claim Φ, and a witness ω, generates a proof argument π. • 0/1 ← SNARG.Vfy(R, δ,Φ, π): A verification algorithm that accepts or rejects the proof. The SNARG satisfies perfect completeness, computational soundness, and what we define as full succinctness. Definition 1 (Full Succinctness). A protocol (Setup, Prove, Vfy) is fully succinct if the verifier Vfy runs in time polynomial in the security parameter λ, and the size of the proof π is also polynomial in λ. 3.2.2 Hash-based One-Time Signature (HOTS) The Bitcoin script language, with its OP CHECKSIG opcode [6], is designed to verify signatures for transactions, not for arbitrary off-chain messages. While proposals like BIP348 exist to extend this functionality, they require a network consensus change. To overcome this limitation, We utilize a Hash-based One-Time Signature scheme ( HOTS) [5, 8]. This approach is particularly advantageous as hash functions are native and computationally inexpensive operations within Bitcoin script. Our variant of HOTS consists of four algorithms: 4 • (sk, pk) ← HOTS.setup(λ): Generates a secret key and public key pair from a security pa- rameter. • s ← HOTS.publish(pk, b): Publishes a commitment to the Bitcoin script, preparing it to verify a signature for a message of length b. • w ← HOTS.sign(sk, m): Signs a message m with the secret key to produce a witness w. • (0/1, m) ← HOTS.verify(pk, w): Verifies the witness w. If valid, it returns ‘1‘ and reveals the original message m on the stack for further on-chain processing. This final property—the on-chain revelation of the signed message—is a critical component for linking consecutive state claims, as will be detailed in Section 3.5. 3.3 Protocol Overview The entire settlement protocol is embodied in a BitVM-style smart contract, which is not a single, monolithic contract but rather a complex graph of pre-signed Bitcoin transactions. Participants must jointly pre-sign this transaction graph and are bound to interact strictly according to its predefined pathways. Whereas the original BitVM protocol focused on settling claims about events on both external chain and the Bitcoin for bridging purposes [3], Bitlayer’s protocol is more intricate. It must settle a continuous sequence of claims, each representing a discrete change in the L2 state, and guarantee that this sequence is consecutive and unbroken. The protocol can be conceptualized as a recursive structure. In Section 3.4, we will first elaborate on the sub-protocol for settling a single state claim. Then, in Section 3.5, we will detail how this single-claim verification mechanism is recursively embedded within a broader protocol that settles a continuous chain of claims. By combining these two components, we construct the complete rollup protocol for settling the Bitlayer Network state on Bitcoin. 3.4 Settling a Single Claim 3.4.1 The BitVM2 Paradigm The on-chain verification of a claim is conducted optimistically. The verifier program in our case is expressed in Bitcoin script. However, as demonstrated by the groundbreaking work of the BitVM Alliance on a Groth16 verifier, a monolithic implementation of such a verifier is far too large to execute directly within a single Bitcoin transaction. Therefore, the BitVM2 paradigm [2] splits the large verifier program into a chain of smaller sub-programs, or ”chunks.” The protocol then proceeds as a fraud-proof game, where it is assumed the operator’s claim is correct unless a challenger can pinpoint an incorrect computation step between two specific chunks. 3.4.2 Protocol Roles The BitVM smart contract for claim settlement involves a well-defined set of participants: 1. Attesting Committee: Rather than forming a new entity, the existing validator set of the Bitlayer Network serves as the attesting committee. This committee is collectively responsible for pre-signing the transaction graph that defines the protocol. 2. Protocol Participants: The active participants in the settlement game include a single, des- ignated Operator responsible for submitting claims and any number of W atchers. Watch- ers can be anyone, including other validators, and their role is to monitor the operator and challenge fraudulent claims. 5 3.4.3 Single Claim V erification Protocol The protocol for verifying a single claim unfolds as a timed challenge-response game governed by Bitcoin time locks. It ensures that both the Operator and any Watcher must act within specified time bounds or face penalties. The protocol can be broken down into three primary stages, which correspond to a series of interconnected Bitcoin transactions pre-signed by the Attesting Committee. Figure 2: Single Claim Verification Protocol 1. Setup Stage Before the game begins, a trusted public setup generates the necessary scripts. The STF (Υ) is used to create a common reference string δ via SNARG.Setup. The verifier program f (π) = SNARG.Vfy(R, δ,Φ, π) is split into a set of smaller sub-programs {fi(Ii)}. Three types of locking scripts are created: a Claim Script to initiate the process, an Assert Script for the Operator to post results of all fi, and a set of Disprove Scripts, one for each sub-program, which Watchers can use to prove fraud. The Claim Script and Assert Script are composed of multiple HOTS, which force operator to post signed claim and results of all sub-programs. The Disprove Scripts include all sub-programs and are organized within a Taproot address. These scripts are then embedded into the outputs of the pre-signed transaction graph. 2. Claim Stage The Operator initiates the process by publishing a Claim transaction, which spends from a previous UTXO and locks their collateral (e.g., d BTC). To unlock this input, the Operator must use their HOTS key to sign and reveal the state claim Φ t. This action starts a timer, ∆ challenge. Watchers observe this claim and can run the STF locally. If they find the claim to be invalid, they can issue a Challenge transaction before the timeout. If no challenge occurs, the Operator reclaims their collateral via an Optimistic Acceptance transaction, and the claim is considered settled. 3. Challenge and Resolution Stage If a Watcher issues a Challenge transaction (which may require them to post a smaller collateral, c BTC, to deter frivolous challenges), the pessimistic path is taken. The Operator is now compelled to execute an Assert transaction. In doing so, they must run the chunked verifier program locally and use their HOTS key to sign and publish the results of all sub-programs {fi}. This action starts another timer, ∆ disprove. The Watcher now examines the sequence of results published by the Operator. If the Watcher can find a single sub-program fi where the Operator’s published output is inconsistent with the 6 execution of fi on the Operator’s published inputs, they have found fraud. The Watcher can then construct a Disprove transaction. This transaction spends the output corresponding to the fraudulent sub-program, executing that small chunk of logic on-chain to prove the inconsistency. A successful Disprove transaction forfeits the Operator’s collateral, a portion of which ( a BTC, where a > c) is awarded to the Watcher. If the Operator correctly publishes results of all fi, and the Watcher fails to submit a valid Disprove transaction in time, the Operator can finalize the claim via an Acceptance transaction and recover their collateral. 3.4.4 Security Properties This protocol is designed to be secure under the assumption of at least one honest Watcher. Its security rests on three key properties, which are analyzed in detail in Chapter 6.2. • Completeness: An honest Operator who correctly follows the protocol and submits valid state claims will never be unjustly penalized. • Soundness: A dishonest Operator who submits a fraudulent claim cannot avoid being pe- nalized, as an honest Watcher will always be able to construct a valid Disprove transaction. • Efficiency: The entire claim verification process, whether it results in acceptance or rejection, is guaranteed to terminate within a bounded timeframe defined by the protocol’s time locks. 3.5 Settling a Chain of Claims The protocol described above is sufficient for settling a single, isolated claim. However, a rollup requires the continuous settlement of a sequence of claims that represents the ongoing evolution of the L2 state. This is achieved by extending the protocol to recursively chain claims together. 3.5.1 Linking Claims with HOTS The key to chaining claims lies in the transaction graph’s structure. Each Claim transaction, in addition to its other outputs, creates a special UTXO called a claim connector . To submit the next claim (Claim N + 1), the Operator must spend the claim connector UTXO created by the transaction for Claim N . The locking script for this connector requires the Operator to use their HOTS key to sign and reveal the data package for ClaimN +1. This design naturally links adjacent claims into a chronological and unforgeable chain, as each claim transaction can only be created by consuming an output from its direct predecessor. Bitcoin time locks are used to enforce a regular cadence, preventing the Operator from submitting claims either too quickly or too slowly. 3.5.2 The T runk T ransaction Graph and Parallel V erification This recursive structure results in a transaction graph with a primarytrunk that links the sequence of claims. At each claim on the trunk, a complete sub-graph for single-claim verification (as described in Section 3.4) branches off. A critical feature of this design is that the submission of the next claim does not need to wait for the final resolution of the previous claim’s verification sub-protocol. The Operator can submit Claim N + 1 while the challenge window for ClaimN is still open. This parallelism is efficient but requires a mechanism to handle cascading failures. If Claim N is successfully challenged, the protocol ensures that its state is invalid, which automatically invalidates the premise of all subsequent claims ( N + 1, N+ 2, . . .). A rational Operator, upon having a claim successfully challenged, 7 is economically incentivized to cease submitting further claims, as each would require posting collateral that is doomed to be forfeited. The trunk would then terminate via a ClaimTimeout transaction. Figure 3: The Trunk Transaction Graph 3.5.3 T ransaction Graph Reconfiguration and Epochs Constructing, pre-signing, and storing a transaction graph intended to last for the entire lifecycle of the rollup (e.g., 100 years) is computationally and logistically infeasible for validators. It would also require an impossibly large amount of BTC to be locked as collateral upfront and would preclude any future protocol upgrades. To solve these problems, we introduce Reconfiguration. The protocol’s timeline is divided into discrete epochs, with each epoch consisting of a fixed number of claims (e.g., lasting for two weeks). At the transition between epochs, a reconfiguration event occurs. For each attesting ceremony, the validator se