Bitlayer 백서 전문

est operator publishes Φ. SNARG.Vrfy will fail locally for watchers, they raise a challenge within ∆ challenge, moving the protocol to the Challenge Phase. If the operator does not publish the result of all sub-programs within time ∆ assert, the operator will be penalized. If there is a disproved algorithm allowing watchers to unlock a Disprove Script with inputs and outputs published by the operator that contradict the sub-program execution, then a dishonest operator cannot escape penalties. We prove the existence of the disprove algorithm as follows. First, since the inputs and outputs published by the operator contradict the local sub-program execution, there must be at least one inconsistent output produced by the sub-program, saying f ′. Then, we check the consistency of the inputs of f ′. If all inputs are consistent, we select f ′ as the challenged sub-program, otherwise recursively run the first step for one of the inconsistent inputs. So, the disprove algorithm must successfully select a sub-program to challenge. Theorem 7 (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. 23 Proof. Each phase of the protocol has a bounded time. If both the Operator and Watcher are honest in following the protocol, the optimistic time bound is ∆ claim + ∆challenge. If either the Operator or any Watcher tries to destroy the protocol, the time-bound will become ∆ claim + ∆assert + ∆disprove. Thus, the maximum time bound to confirm is ∆ claim + max{∆challenge, ∆assert + ∆disprove}, so that the protocol terminates regardless of whether the claim is accepted or rejected. Thus, the protocol guarantees efficiency by design. Figure 8: Bitcoin Settlement Security 6.3 Censorship Resistance Unlike traditional L2 architectures that rely on a single sequencer, our design employs a rotating manner among validators to produce blocks. This decentralized sequencing mechanism ensures that no single party can unilaterally censor transactions. As block production rotates among validators in a permissionless and stake-weighted manner, any attempt to exclude valid transactions can be bypassed in subsequent blocks, providing strong built-in censorship resistance and enhancing the neutrality of the network. 7 System Architecture A robust and well-engineered system architecture is paramount to achieving Bitlayer’s dual goals of high performance and trust-minimized security. At the heart of our design is a dual-subsystem model that cleanly decouples the L2’s high-throughput execution layer from its L1 settlement and security layer. This chapter details this architecture, starting with the core principle of decoupling, followed by a system-level overview of the data flow, and a detailed analysis of the components within both the Validator (Performance) Subsystem and the Rollup (Security) Subsystem. 7.1 Decoupling of L2 Execution and L1 Settlement The core design principle of the Bitlayer architecture is the decoupling of L2 execution from L1 settlement. This strategic partition divides the system’s functionalities into two distinct domains: a Validator (Performance) Subsystem and a Rollup (Security) Subsystem. • The V alidator Subsystem: This subsystem is a high-performance blockchain focused exclu- sively on processing L2 transactions (including L1 Forced Transactions), including transaction 24 ordering, smart contract execution, and state storage. It is designed for high throughput and low latency to provide users with sub-second soft finality. Its performance depends only on its own consensus and computation technologies, independent of L1 interaction. We therefore refer to this subsystem as the Performance Domain, as it is built for high-frequency state computation. • The Rollup Subsystem : This subsystem anchors the state and security of the Validator Subsystem to the Bitcoin network. It is responsible for all L1 interactions, including state commitments and the fraud-proof challenge-response protocol. Its security guarantees are cryptographically traceable to Bitcoin’s Proof-of-Work consensus. We therefore refer to this subsystem as the Security Domain, as its purpose is to ensure the integrity of the L1 settlement process. Similar to a microservices architecture, this separation of concerns allows each subsystem to be developed and optimized independently. For example, optimizations to the Validator Subsystem, such as upgrading the consensus engine, can proceed without altering the L1 interaction protocol. Conversely, the Rollup Subsystem can integrate new proving systems without re-architecting the core L2 execution layer. This modular design ensures the system is both robust and adaptable to future technological changes. 7.2 The Validator Subsystem The Validator Subsystem is engineered exclusively for performance. Its architecture is composed of three core components: a Decentralized Sequencer, a Parallel Execution Engine , and a High-Concurrency Data Store . These components are integrated via a proactive computa- tion pipeline, which collectively constitutes the primary driver of Bitlayer’s transaction through- put and low-latency characteristics, providing the capacity to support peak loads in the order of tens of thousands of transactions per second (TPS) . 7.2.1 Decentralized Sequencer The sequencer functions as the ordering and consensus core of the Bitlayer platform. It is imple- mented as a decentralized network of validators operating under a Proof-of-Stake (PoS) protocol. Its primary design objective is to furnish a trustless, credibly neutral mechanism for transaction ordering, thereby mitigating the risks inherent in centralized sequencers, such as single points of failure, malicious transaction reordering (e.g., MEV extraction), and censorship. The sequencer network receives transactions from across the network and utilizes a high-performance BFT con- sensus protocol to establish a canonical, global ordering for these transactions within a block, which then attains economic-stake-backed soft finality. 7.2.2 Parallel Execution Engine The execution engine is designed to overcome the performance limitations of the EVM’s sequential execution model. The principal challenge in parallelizing EVM execution is its interleaved state ac- cess pattern, which complicates dependency prediction. Our core innovation is a dependency analy- sis and state conflict resolution mechanism specifically optimized for this environment. It leverages principles from Optimistic Concurrency Control , adapted for the blockchain context. The engine speculatively executes transactions in parallel under the assumption of non-conflict, with coordination mechanisms engaged only upon detection of a data dependency. Advanced techniques, 25 Figure 9: High-level overview of the Dual-Subsystem Architecture. including operation-level conflict resolution and hint-based proactive scheduling, are em- ployed. This enables the engine to re-execute only the minimal set of conflicting operations, rather than entire transactions, thereby maximizing the utilization of multi-core processor architectures and significantly elevating the transaction processing capacity. 7.2.3 Blockchain-Native Storage Engine The data store is a high-performance persistence layer tailored to the access patterns of the parallel execution engine. It addresses the bottlenecks of general-purpose databases (e.g., Lev- elDB/RocksDB), such as state bloat and I/O contention. It is responsible for storing all canonical blockchain data, including the account state, smart contract code, and transaction receipts. Perfor- mance is achieved through asynchronous I/O interfaces and batched writes, which decouple execution from storage latency. Architecturally, it employs index and key-value (KV) sep- aration and semantics-aware data partitioning . This design minimizes lock contention and reduces write amplification, providing robust storage support for the high-concurrency demands of the parallel execution engine. 26 7.2.4 The Proactive Computation Pipeline The Validator Subsystem integrates its components into an asynchronous, multi-stage pipeline that implements a principle of proactive computation , analogous to out-of-order execution in modern CPUs. Instead of a rigid, sequential paradigm ( Consensus -> Execute -> Persist -> Checkpointing), our pipeline deconstructs these tasks to enable temporal overlapping. This allows the system to work on multiple blocks simultaneously at different stages; for example, the consensus process for ordering transactions in Block N+1 can run concurrently with the execution of Block N. This overlapping of consensus and execution is key to maximizing resource utilization and significantly reducing end-to-end transaction latency. 7.3 The Rollup Subsystem This section details the components that verifiably settle the computational results of the Validator Subsystem on the Bitcoin network, endowing the Bitcoin blockchain with the capability for active state verification and dispute resolution. 7.3.1 Recursive Proving System The cryptographic foundation of Bitlayer’s security is its Recursive Proving System . This system, implemented as an asynchronous Zero-Knowledge Proof (ZKP) generator, is tasked with producing a single, succinct, and irrefutable proof of validity for all state transitions within a set- tlement period. A key design innovation is its complete decoupling from the L2’s critical performance path . Proof generation operates as a background process, ensuring that L2 block production rates and transaction confirmation latencies are independent of the computationally intensive proving process. This architecture facilitates the future development of a permissionless Proving Market to further optimize proving efficiency and cost through market-based competi- tion. 7.3.2 Engineering Implementation of the L1 Finality Protocol The translation of the complex BitVM-based protocol into an automated and robust system rep- resents a core engineering challenge addressed by the Rollup Subsystem. A modular software design maps protocol roles to specific components, ensuring system maintainability, security, and extensibility. The implementation is centered around three primary software entities: the Operator, the W atcher, and the Attester. • Operator: The Operator is the primary agent responsible for advancing the protocol. It is an automated software suite comprising several internal modules: – Transaction Graph Builder: This module is the core implementation of the BitVM paradigm. It deterministically constructs a complex Bitcoin transaction graph from L2 state batches, in strict adherence to the Transaction Graph Specification. This involves programmatically generating Bitcoin Scripts for all challenge-response pathways and embedding the L2 state root via hash locks. – Batch Committer: This module optimizes L1 interaction costs by aggregating state com- mitments from multiple L2 batches into a singleClaimT ransaction, thereby amortizing the on-chain footprint. 27 – Challenge Responder: This defensive module monitors the L1 for challenges against its commitments. Upon detection, it retrieves the corresponding ZK proof from the Proving System and broadcasts the appropriate response transaction as defined in the specification. • W atcher: Representing the decentralized security mechanism, the Watcher is software that can be run by any full-node participant to audit the Operator. – Proof Verifier: This module independently fetches state commitments from L1 and corresponding L2 block data. It re-executes the state transitions to verify the integrity of the Operator’s submitted state root, serving as the first line of defense against fraud. – Challenger: If the Proof Verifier detects a discrepancy, the Challenger module is activated to construct and broadcast a challenge transaction on L1, thereby initiating the on-chain dispute resolution process and contesting the Operator’s staked collateral. • Attester: A set of highly-staked validators provide security for the validity of the transaction graph. – Transaction Graph Validator: Prior to signing, each Attester utilizes this module to independently validate the Operator-constructed transaction graph against the formal specification, ensuring it contains no exploitable or invalid paths. – Musig Signer: Upon successful validation, this module employs an advanced multi- signature scheme (e.g., MuSig2) to produce a single, aggregated signature for the trans- action graph. This engineering choice provides superior efficiency, privacy, and scalability over traditional CHECKMULTISIG operations. These components interface with the L1 via a Bitcoin Provider module (an RPC wrapper), forming an automated L1 finality system with a clear separation of duties. This modular imple- mentation enhances testability and maintainability while providing a solid foundation for future protocol upgrades. 7.4 Transaction Lifecycle • Sequencing: Users initiate transactions on the L2 network (Step 1a). These transactions are collected by the Sequencer component within the validator, while on-chain interactions (Step 1b), such as deposits and force inclusion transactions, are submitted to Bitcoin. The Bitcoin Listener component continuously monitors the Bitcoin network and synchronizes L1 transactions to the Sequencer. • Block Consensus: After collecting the transactions, one of the Sequencers is selected to pro- pose a set of transactions. All validators then reach an agreement on the ordering and content of the proposal through the consensus (Step 2). Once consensus is achieved, a sequenced L2 block is produced (Step 3). • Execution: Once a block is produced, it is immediately executed by the validator. The Executor performs parallel execution of the block’s transactions to compute the new world state. • Persistency: The new state is efficiently persisted. At this point, the L2 block achieves soft finality (Step 4). 28 Figure 10: Detailed Transaction Lifecycle • Inter-Subsystem Handoff: Upon reaching soft finality within the validator network, the state data of an L2 block is transmitted to the Rollup Subsystem via the internal asynchronous API. This asynchronous communication is critical for performance isolation, ensuring that the high throughput of the Validator Subsystem remains unencumbered by the proof-generation latency of the Rollup Subsystem (Step 5). • State Claim: The Operator’s Batch Committer component aggregates multiple block data, assembles rollup batch information, and starts the Bitcoin settlement process as described in Chapter 3 (Step 6). • Challenge Responder: When a Watcher challenges the state claim posted by the Operator on Bitcoin (Step 7), the Operator responds by generating a zero-knowledge proof (ZKP) to defend the correctness of the claimed state (Step 8). The Prover generates a ZKP based on the execution trace and state transition, which is then submitted by the Operator to Bitcoin (Step 9) as evidence supporting the validity of the rollup state. 7.5 Conclusion Ultimately, the Bitlayer V2 architecture establishes a clear blueprint for scaling Bitcoin: it leverages Bitcoin as the ultimate decentralized trust and settlement layer, while Bitlayer Network functions as a high-throughput, verifiable computation layer built atop it. This design provides a viable pathway to unlock the vast, dormant capital in the Bitcoin ecosystem, laying a foundational infrastructure for a secure, scalable, and vibrant decentralized finance ecosystem on Bitcoin. 8 Limitations and Future Directions This chapter reflects on the current design of the Bitlayer Network, discussing its inherent trade- offs and the promising research avenues they inspire. We first outline the primary limitations of 29 our current protocol and then detail future work aimed at addressing these challenges and further advancing the capabilities of Bitcoin L2s. 8.1 Limitations While the Bitlayer Network provides a robust framework for a Bitcoin computational layer, its current design involves several trade-offs: 1. Dependency on V alidator Set’s Honesty: The security of the bridge and settlement protocol currently relies on an honest majority assumption within the active validator set, which serves as the Attesting Committee. While this security is cryptographically enforced, it represents a trust assumption beyond Bitcoin’s own proof-of-work. Eliminating this reliance on an external honest-majority through future Bitcoin protocol upgrades remains a key goal for achieving a more fully trustless system. 2. Centralized Operator and Liveness: The current model uses a single, rotating Rollup Operator for sequencing and settlement. While this is efficient, it presents a potential single point of failure for liveness if the operator goes offline. This motivates the development of a multi-operator mechanism. 3. Reliance on Broker Liquidity: The fast withdrawal and emergency escape hatch mecha- nisms depend on an active network of third-party Brokers to provide upfront liquidity. The system’s user experience and capital efficiency could be further improved by protocol-native solutions that reduce this reliance. 8.2 Future Directions We are actively researching several enhancements to address these limitations and expand the network’s capabilities: 1. Leveraging F uture Bitcoin Upgrades (Covenants): Upcoming potential Bitcoin pro- tocol upgrades, such as those introducing new covenant opcodes (e.g., OP CTV [10], OP CAT, or similar proposals), could pave the way for more trustless smart contract functionalities directly on Bitcoin. We are closely monitoring these developments and plan to integrate such features, if and when they become available and stable. This could allow for: • Elimination of Attesting Committees: Potentially removing the need for an attest- ing committee for certain verification processes, moving towards a more fully trustless model. • Enhanced Permissionlessness: Reducing reliance on pre-signed transactions or spe- cific roles in the dispute resolution protocol, making the system even more open. • On-Chain Operator Election: Managing Rollup Operator election and rotation more directly on-chain, further enhancing liveness and decentralization. • Optimized Collateral Management: Enabling more sophisticated collateral reuse mechanisms within the same epoch without compromising security, thereby reducing the capital costs for operators. 2. Advanced Proving Systems: Continuously evaluating and integrating advancements in zero-knowledge proof systems and other cryptographic techniques to improve proof generation efficiency, reduce on-chain verification costs, and enhance overall system performance. 30 9 Conclusions In this paper, we have introduced Bitlayer, a scalable and EVM-compatible computational layer for Bitcoin, whose security is based on an honest majority assumption. Bitlayer is built upon the BitVM paradigm to enable complex, general-purpose computation while anchoring its security directly to the Bitcoin network. Our core contribution is a novel recursive settlement protocol, the first of its kind to allow for the continuous, verifiable settlement of Layer 2 state transitions on Bitcoin. This protocol, combined with a synergistic asset bridge sharing the same security model and a fully EVM-compatible execution layer, creates a complete and practical platform for decentralized applications. We view Bitlayer as a foundational step towards building the premier infrastructure for the BTCFi ecosystem. By demonstrating a clear architecture where Bitcoin acts as the ultimate settle- ment layer and Bitlayer as an efficient, verifiable computational layer, our work provides a practical blueprint for unlocking Bitcoin’s vast potential. We hope that our design, which prioritizes low transaction costs and strong censorship resistance, enco