Bitlayer 백서 전문

t only needs to pre-sign the trunk transaction graph for the upcoming epoch. This makes the burden on validators manageable. The Exit Window Reconfiguration is also the point at which protocol upgrades or changes to the validator set can occur. These changes may alter the security assumptions or trust parameters of the system. To protect user sovereignty, Bitlayer provides a mandatory Exit Window . The configuration for Epoch N + 2 is proposed and finalized during Epoch N . This gives users the entirety of Epoch N + 1 to review the new validator set and transaction graph for Epoch N + 2. If a user does not approve of the upcoming changes, they have a full epoch to exit the system by withdrawing their assets (e.g., pegging-out BTC via the BitVM Bridge) before the new configuration takes effect. V alidator Incentives All validators are required to stake BTR tokens to participate. The pre- signing ceremony for each epoch’s transaction graph is coordinated through a system contract on the L2. Failure to participate in the ceremony in a timely manner results in the forfeiture of a portion of the validator’s staked BTR, strongly disincentivizing attacks designed to stall the protocol. 8 3.5.4 The Reconfiguration Process The reconfiguration process is orchestrated by the L2 system contract. The designated opera- tor prepares all necessary information for the next epoch’s transaction graph, and each validator independently generates it, signs it, and submits their signature to the L2 contract. Once a su- permajority ( N − f ) of valid signatures are collected, they are aggregated, and the attestation is complete. This process culminates in a Reconfiguration transaction on Bitcoin. This transaction locks the aggregate collateral required for all claims in the new epoch and records the updated configuration parameters, such as the verifier program commitment δ, the operator’s identity, and time lock values. Reconfiguration transactions must be issued immediately after pre-signing is completed to promptly announce configurations. The very first such transaction, the Epoch 0 Reconfiguration transaction, bootstraps the entire rollup protocol and records the genesis state s0 of the Bitlayer Network. Figure 4: Transaction Graph Reconfiguration 3.6 Summary In summary, the Bitlayer settlement protocol materializes as a perpetual, yet manageable, BitVM- style transaction graph on Bitcoin. This graph is cyclic, composed of per-epoch sub-graphs that are linked together through reconfiguration transactions. Each epoch’s sub-graph contains a trunk of chronologically linked state claims, and each claim is accompanied by its own verification sub- graph—a sophisticated challenge-response game that allows any single honest participant to enforce the correctness of the L2 state. This architecture enables Bitlayer to achieve a high degree of scalability and programmability while being securely anchored to Bitcoin’s unparalleled proof-of- work consensus. 4 State Transition Function and Batch Execution While Chapter 3 established the protocol for settling a state claim on Bitcoin, this chapter defines the computational process that a claim asserts to be valid: the Bitlayer STF. A correct state transition over a batch of L2 blocks is the fundamental unit of progress for the rollup. Here, we 9 specify the components of our unique, EVM-based STF and present the multi-stage, recursive proving pipeline that generates proofs for its execution. This entire computational process is what an Operator asserts with their claim and what any Watcher can challenge through the settlement game. 4.1 The Bitlayer Network STF The Bitlayer Network’s STF aligns with the battle-tested principles of the Ethereum EVM [9] to provide a familiar and powerful environment for developers. As a Bitcoin rollup, however, it extends the EVM with additional system-level logic and specialized contracts to address its unique requirements, such as handling bridged Bitcoin assets and processing messages from the L1. 4.1.1 Gas and F ees Transaction fees on the Bitlayer Network are paid exclusively in BTC. This design choice provides a seamless and consistent experience for Bitcoin users, as they can use the asset they already hold without needing to acquire a new, native token for network operations. While transactions are paid for in BTC, the fee rates are extremely low, reflecting the efficiency of the Layer 2 architecture. Bitlayer implements a multi-dimensional gas model that separates transaction costs into three distinct components: • Execution F ee: Covers the computational cost of executing the transaction in the EVM, similar to the standard Ethereum model. • Storage F ee: Accounts for the cost of modifying the L2 state, such as creating new accounts or updating contract storage. The Execution and Storage Fees are distributed among the validators who secure the network. This fee distribution mechanism creates a precise and sustainable economic model. 4.1.2 Protocol Contracts Protocol contracts are a set of special-purpose smart contracts that exist at genesis and form an integral part of the Bitlayer protocol. While their logic is central to the network’s operation, implementing them as smart contracts rather than native code provides a clear interface and allows for future upgrades through the established governance procedure. System Config Contract The System Config contract acts as the network’s central control panel, managing core protocol parameters as key-value pairs. Examples include the block gas limit (<block gas limit, 10,000,000>) and validator set size. • Reconfigurability: Most parameters can be updated via governance proposals. • Update Cadence: The timing of these updates depends on their impact. Some parameters, like certain fee multipliers, can be adjusted at any block boundary. Others that have deeper systemic effects, such as those related to the consensus engine, can only be modified at an epoch boundary to ensure a safe and orderly transition. • Security: Since many of these parameters are read directly by native protocol code, modi- fications must be carefully evaluated to ensure they do not compromise network stability or security. 10 V alidator Management Contract This contract governs the lifecycle of the Bitlayer Network’s validator set, which is crucial for both L2 block production and L1 attestation ceremonies. • V alidator Admission and Removal: – To become a validator candidate, a user must stake a minimum amount of BTR tokens in this contract. Candidates are promoted to the active validator set at the beginning of the next epoch. To maintain network stability, the number of new validators promoted from the candidate queue to the active set is capped in each epoch (e.g., at 10% of the total set size). – Voluntary exits by active validators are similarly subject to a per-epoch cap. – A validator whose stake falls below the required minimum due to slashing will be forcibly removed from the active set at the next epoch boundary. • Operator Election : – For each epoch, the protocol selects one Rollup Operator from the active validator set. The selected Operator is then required to submit a collateral deposit transaction on the Bitcoin L1 within a specified time frame. Failure to do so penalizes the non-compliant validator and triggers a new election to ensure the liveness of the settlement process. • Rewards and Penalties: – Validators are rewarded with BTR tokens for securing the network. Rewards are dis- tributed in proportion to each validator’s total stake. – The L2 block proposer receives transaction fee and a larger share of the block reward. – The designated Rollup Operator receives additional BTR rewards to compensate for the operational costs of settling state claims on Bitcoin L1. – Validators who participate in the pre-signing ceremony for each epoch’s transaction graph receive attestation rewards. – Failure to adhere to protocol rules (e.g., missing block votes, failing to participate in the pre-signing ceremony) results in penalties, where a portion of the validator’s staked BTR is slashed. Bitcoin Light Client (BLC) Contract The BLC contract serves as the network’s trustless gateway to the Bitcoin L1. It has two primary responsibilities: tracking the canonical Bitcoin chain and processing L1-to-L2 messages. • Canonical Chain T racking: The protocol relies on oracles to submit Bitcoin block headers to the BLC. By default, the Rollup Operator fulfills this role. However, if the Operator fails to do so, anyone can submit the block header, ensuring liveness. The BLC contract tracks all submitted headers, including those from ephemeral forks, and maintains the canonical chain by following the heaviest-chain rule. A submitted block is then considered finalized after accruing a number of subsequent confirmations defined by a threshold in the System Config Contract (e.g., six). • L1-to-L2 Message Processing : The BLC contract scans finalized Bitcoin blocks for spe- cific L1-to-L2 messages and translates them into executable L2 transactions called intrinsic transactions. These messages include: 11 – Bridge Deposit Events : When a user deposits BTC into the BitVM bridge contract on L1, they inscribe a Bridge Deposit Event. The BLC contract detects this event and generates a corresponding Bridge-Mint intrinsic transaction on L2 to credit the user with the equivalent wrapped asset. This automates the peg-in process without requiring a separate user action on L2. – F orced T ransactions: A user can force the inclusion of an L2 transaction by inscribing its data directly onto the Bitcoin blockchain. This provides a powerful censorship- resistance mechanism, ensuring that a user can always interact with the rollup even if the entire L2 validator set attempts to censor them. The protocol enforces the timely processing of these messages through both its consensus and rollup mechanisms: • Consensus Enforcement: Before proposing a new block, a validator must query the BLC contract to generate any pending intrinsic transactions. These transactions must be included at the very beginning of the proposed block, ahead of any regular user transactions. If the number of intrinsic transactions exceeds the capacity of a single L2 block, they are processed across multiple blocks in a deterministic order. • Rollup Enforcement: The STF definition requires that a state claim for a batch of L2 blocks must correctly process all L1-to-L2 messages from the corresponding finalized Bitcoin blocks. Any Operator who submits a claim based on a state that omits or incorrectly processes an L1 message has submitted a fraudulent claim and will be successfully challenged and penalized. Bridge Contract The Bridge Contract on L2 works in tandem with the BitVM bridge contract on L1 to facilitate the secure, bidirectional flow of assets. • Peg-In: The contract processes the Bridge-Mint intrinsic transactions generated by the BLC, minting the corresponding L2 wrapped assets to the user’s account. • Peg-Out: To withdraw assets, a user initiates a transaction on L2 that calls the Bridge Contract. The contract burns the user’s L2 assets and emits an L2 event. This event serves as a message that is later picked up by the L1 bridge mechanism to process the withdrawal. • Proof of Reserves (PoR) : The contract maintains a complete and transparent ledger of all bridged assets on Bitlayer, enabling anyone to generate a Proof of Reserves at any time. The detailed architecture of the bridge and the peg-out mechanism will be further explored in Chapter 5. 4.2 Proving Pipeline To verify the state transitions of this Rollup protocol, the protocol adopts a multi-stage, asyn- chronous, recursive proving system based on a zero-knowledge virtual machine (zkVM). The system is designed to generate a wrapped proof that is both compact and easy to verify on the Bitcoin network, while ensuring the entire proving system is secure and upgradable through a governed process. 12 4.2.1 Integrity and Upgradability via CodeControlGroup The integrity of the entire proving pipeline depends on the ability to ensure the validity and integrity of its core computation engine—that is, all programs running in the zkVM, including the block execution logic, batch aggregation logic, and recursion logic. The CodeControlGroup is the core security mechanism designed for this purpose. CodeCommitment: The Unique Fingerprint of a zkVM Program The zkVM generates an unique cryptographic commitment for each complete program suite, known as theCodeCommitment. This commitment serves as a unique and immutable fingerprint for a specific version of the program. Any change to the code, no matter how small, results in a completely different CodeCommitment. This holistic commitment is crucial, as it effectively prevents attack vectors where a fraudulent proof is generated by tampering with some components while others appear unchanged. CodeControlGroup: An Index-Based Authorization Registry The CodeControlGroup is a cryptographically enforced authorization list that records all valid CodeCommitments. Its core design is not a flat set, but rather an index-based structure. Throughout the proving pipeline, every program execution occurs within a specific context, which is marked by a unique Index (e.g., a block height). The CodeControlGroup maps each Index to a whitelist of valid CodeCommitments. Its data structure is a Hierarchical Merkle T rees with Merkle Mountain Range (MMR). This index-based mechanism is critical. It allows the system to precisely determine whether the program used was on the whitelist for that specific Index when verifying any historical proof. This ensures the integrity of all programs throughout the entire recursive chain, precluding the possibility of using unauthorized or outdated program versions to generate historical proofs. The root, the CodeControlRoot, serves as a commitment to the entire authorization history, making the registry itself tamper-evident. Secure Upgrade Path The system’s upgrade path is structured around discrete Epochs (as described in Section 3.5.3). Changes are introduced via an Epoch Reconfiguration event at each transition. This event defines the new set of system parameters, with the CodeControlGroup being a critical component, and this data is submitted to both Bitcoin and the L2. To simplify pipeline implementation and trust management, the proving pipeline does not scan blocks for this information. Instead, it receives the appropriate CodeControlGroup for a given context as a direct configuration input. The integrity of this entire process is guaranteed by the synchronization between the Epoch transition and the pre-signing mechanism. The new CodeControlGroup is finalized by governance, and its corresponding CodeControlRoot is locked in on-chain via the pre-signing mechanism before the new Epoch becomes active. This ensures that if a prover uses an incorrect CodeControlGroup, the resulting proof will be rejected during on-chain verification, as its CodeControlRoot will not match the pre-signed value for that Epoch. Therefore, the CodeControlGroup provides a transparent and secure governance framework for the evolution of the zkVM’s core logic. Its root, the CodeControlRoot, serves as the final com- mitment to the system’s complete authorized history, anchoring the validity of the entire recursive proof chain in a foundation of cryptographic certainty and governance consensus. 13 4.2.2 The F our-Stage Recursive Proving Pipeline Overview The protocol’s proving workflow is a sequential pipeline consisting of four distinct stages. Before delving into the stages, it is important to understand the basic data structures involved. Each Block has a unique Block Number , which serves as the Index for contextual verification within the CodeControlGroup. Blocks are grouped into a Batch for aggregation. The criterion for forming a batch is a key, governable system parameter, which can be either a fixed number of blocks or a specific time duration. Finally, the protocol’s timeline is organized into Epochs to manage system-wide reconfigurations. The four stages of the pipeline are: Single Block Proving, Batch Aggregation, Batch Re- cursion, and Proof W rapping. This structure operates as a nested pipeline: within each batch, proofs flow sequentially through the stages, while a higher-level pipeline links consecutive batches together through the recursive stage. Each stage receives specific inputs, performs computations within the zkVM, and generates outputs that either feed into the next stage or contribute to the wrapped proof. This recursive architecture enables the efficient aggregation and compression of proofs, thereby enhancing system scalability. The following diagram illustrates this nested pipeline structure. Figure 5: Architecture of the proving pipeline, illustrated with a batch size of three blocks. Pipeline Design Rationale The multi-stage pipeline design is a deliberate architectural choice made to optimize the trade-offs among proving efficiency, system complexity, and security. • Parallelization in Stage 1 for Efficiency : Proving the state transition of a single block is the most computationally intensive task in the entire process. By isolating the proving process for each block, the protocol can initiate proving tasks without waiting for a complete batch to be formed. This allows blocks to be processed in parallel as soon as they are generated, 14 maximizing the utilization of prover resources and significantly improving overall proving efficiency. • Timing in Stage 2 for Simplified Complexity : Compared to the first stage, the task of aggregating multiple block proofs into a single batch proof is far less computationally intensive and much faster. Therefore, the protocol chooses to initiate the aggregation stage only after all blocks within a batch have been proven, rather than adopting a more complex incremental aggregation approach. This design effectively reduces the management complexity of the CodeControlGroup, as the context for the aggregation operation is a well-defined, completed batch. • Separation of Duties in Stage 3 for Integrity : Batch recursion is the key to ensuring integrity and achieving recursive compression. Separating it from the aggregation process is intended to create a clear division of responsibilities. The aggregation stage focuses on ”intra- batch” state continuity, while the recursion stage handles ”inter-batch” linking, connecting the validity of the current batch to the entire history of the chain. Its proving task is also more advanced and does not need to be executed concurrently with aggregation. In summary, the entire system employs a pipelined execution of proofs not only within a single batch but also constitutes a higher-level pipeline across multiple batches. This nested pipeline design ensures high efficiency while keeping the verification logic of the CodeControlGroup within manageable limits, thereby guaranteeing the system’s security and the convenience of upgrades. 4.2.3 Stage 1: Single Block Proving The objective of this stage is to generate a validity proof for the execution of a single block. The process involves two steps: 1. Off-Chain Simulation: Before proof generation begins, the system first simulates the exe- cution of the block outside the zkVM. This step aims to acquire all necessary input data for the proof, including the read-write sets and their corresponding Merkle proofs . 2. Stateless Proof Generation: The input data obtained from the previous step is provided to a stateless zkVM instance. The zkVM re-executes the state transition in a closed environment and generates a zero-knowledge proof. The output of this stage is a Single Block Proof , which asserts the correctness of the block’s execution. Its core content encapsulates the state roots before and after the block’s execution (FromState and ToState), the unique block ide