bitpro가 원문에서 글자만 모은 내용이에요. 표·그림·수식은 빠지거나 깨질 수 있어요. 전체 5쪽 중 3쪽
ntifier ( BlockNumber), and the commitment to the
program used to generate this proof ( CodeCommitment).
4.2.4 Stage 2: Batch Aggregation
This stage aims to aggregate the Single Block Proof from multiple consecutive blocks within a
batch into a single proof. It performs two core functions:
1. V erifying State Continuity: It checks and ensures that the state transitions between
adjacent block proofs are continuous. That is, the ToState of block N must be identical to
the FromState of block N + 1.
15
2. Recording Program Commitments : It extracts the CodeCommitment from each input
proof and records it. A key feature of this stage is that it only records the commitments;
verification against the CodeControlGroup is deferred to the next stage.
The output of this stage is a Batch Aggregated Proof , which represents the correctness of the
entire batch’s execution. This proof encapsulates the overall state transition of the batch, including
the block height range of the batch (starting BlockNumber and ending BlockNumber), the initial
state root of the first block in the batch (FromState), the final state root of the last block (ToState),
and a complete list of the program commitments (CodeCommitment) recorded from all proofs within
the batch.
4.2.5 Stage 3: Batch Recursion
This is the core recursive step of the pipeline, designed to compress the ever-growing chain of proofs
into a proof of constant size.
The inputs for this stage consist of two parts:
1. The Batch Aggregated Proof of the current batch (from Stage 2).
2. The Batch Recursive Proof from the previous batch (from the previous run of Stage
3). For the system’s first batch, this input does not exist; instead, the initial state root
(FromState) of its aggregated proof is checked directly against the protocol’s GenesisState
to anchor the beginning of the entire proof chain.
The core task performed by the zkVM in this stage is to comprehensively verify the authorization
history of all executed program versions against the CodeControlGroup. This verification is based
on the specific context ( BlockNumber) in which each program was executed, as reflected in the
following checks:
• V erifying Block Execution Programs: For each Single Block Proof in the batch, its
CodeCommitment is verified against theCodeControlGroup using its corresponding BlockNumber
as the Index.
• V erifying Aggregation Program: The CodeCommitment of the current aggregation logic
(Stage 2) is verified against the CodeControlGroup to its execution context.
• V erifying Recursion Program: The CodeCommitment of the program used for the pre-
vious recursive proof is also verified against the CodeControlGroup using its corresponding
historical context.
In this way, the chain of trust is correctly propagated from the GenesisState through each recur-
sion. The output of this stage is a new, updated Recursive Proof that encapsulates the history
of all processed batches to date.
4.2.6 Stage 4: Proof W rapping
This stage is the endpoint of the pipeline of the batch proving, with the core objective of converting
the recursion proof from the previous stage into a highly optimized wrapped proof suitable for final
verification on the Bitcoin network.
It takes the latest recursive proof and ”wraps” it into a wrapped Groth16 proof. The Groth16
proving system is chosen for its ability to generate proofs of extremely small size and support excep-
tionally fast verification, which is crucial for achieving efficient verification under the computational
and cost constraints of Bitcoin Script.
16
During the generation of this wrapped proof, the program version of the input recursive proof is
verified against the CodeControlGroup. The complete CodeControlGroup is also compressed into
its Merkle root, the CodeControlRoot, which is included as a public input in the wrapped proof.
As the top-level program in the trust hierarchy, the wrapping program itself is not contained within
the CodeControlGroup; its integrity is instead guaranteed by having its CodeCommitment directly
hard-coded into the on-chain verification script.
4.3 On-Chain Verification via Bitcoin Script
The on-chain verification script template serves as the final arbiter of trust. As a result of the
governance and pre-signing process synchronized with the Epoch lifecycle (as described in Section
4.4.1.1), a set of immutable trust anchors are hard-coded into the script for each Epoch. These
anchors include:
• The GenesisState, which anchors the starting point of the state.
• The CodeControlRoot, which commits to the entire authorization history of all upgradable
programs for that Epoch.
• The CodeCommitment of the non-upgradable wrapping program (Stage 4), which serves as the
ultimate verifier.
During verification, the wrapped proof itself and its public inputs (including FromState, ToState,
and CodeControlRoot) are provided as dynamic data. The core logic of the on-chain script is to
check whether the CodeControlRoot provided as a public input in the proof exactly matches the
CodeControlRoot hard-coded in the script for that Epoch.
Based on this, the script combines these dynamic inputs with the static anchors to form a
comprehensive ClaimHash. Subsequently, the BitVM protocol optimistically invokes the ZK proof
verification logic. If the verification succeeds, it confirms the following facts:
1. The state transition from FromState to ToState is computationally valid according to the
rules enforced by the zkVM programs.
2. All programs within the recursive proof were authorized by the CodeControlRoot.
3. The wrapped proof was generated by the authorized wrapping program.
4. The entire computational history can be traced back to the GenesisState.
5 Bridging Bitcoin and Bitlayer Network
A secure rollup requires a correspondingly secure mechanism for asset transfers between the L1 and
L2. This chapter details the Bitlayer Asset Bridge, the mechanism for transferring assets between
Bitcoin and the Bitlayer Network. The bridge is built upon the same BitVM paradigm as our
settlement protocol, ensuring a unified security model for both state validity and asset custody.
5.1 Roles
The bridge protocol involves several key roles:
1. Users: Asset holders who initiate transfers between Bitcoin and Bitlayer Network.
17
2. Broker: Assists users in preparing deposits and withdrawals, including constructing initial
transaction graphs and obtaining signatures from Attesters. Brokers directly interface with
users, abstracting the complexity of the BitVM protocol and enabling seamless interaction.
3. Attesting Committee: This is the same validator set from the rollup protocol. The com-
mittee elected for a specific Epoch N is responsible for pre-signing the transaction graphs for
all bridge requests initiated within that epoch.
4. W atcher: Permissionless observers who monitor the protocol and challenge malicious be-
havior.
5.2 Asset Cross-Chain Flow
Below we use BTC as an example to introduce the complete process of asset deposit and withdrawal.
Figure 6: Asset Cross-Chain Flow
5.2.1 Asset Deposit (Peg-in)
The peg-in process moves assets from Bitcoin to Bitlayer and is initiated by the user in several
steps:
1. Initiate Request: The user submits a PeginRequest to all brokers, specifying the UTXOs
for deposit, the target Bitlayer Network address, and a Bitcoin address for transaction change.
2. Preparation: Each broker responds with a complete Pegin transaction and the associ-
ated transaction graph. The user must carefully verify all received transaction graphs for
correctness, ensuring their parameters meet all expectations.
3. Broadcast & Mint: After verification, the user issues thePegin transaction on the Bitcoin
network. Once the Pegin transaction is confirmed on L1, it is detected by the Bitcoin Light
Client on the Bitlayer Network (as described in Chapter 4), which in turn triggers the Bitlayer
protocol to automatically generate an intrinsic transaction. This transaction then calls the
Bridge contract to mint the equivalent amount of BTC to the user’s specified address.
5.2.2 Asset Withdrawal (Peg-out)
The standard peg-out process is designed for efficiency, relying on Brokers to provide upfront
liquidity for a fast user experience:
18
1. Initiate Burn: The user initiates a Burn transaction to the Bridge contract on the Bitlayer
Network. This transaction burns a specific amount of BTC on the L2 and, crucially, includes a
Partially Signed Bitcoin T ransaction(PSBT) which defines the intended L1 withdrawal.
The difference between the amount burned on L2 and the amount specified in the PSBT’s
output constitutes the fee for the Broker.
2. Broker F ronts F unds:Brokers monitor the Bridge contract for these Burn transactions.
A Broker who accepts the implied fee can fulfill the request by taking the user’s provided
PSBT, adding their own inputs and signature to complete it, and issuing the final transaction
on the Bitcoin network. This mechanism ensures that only one Broker’s front transaction can
be successfully confirmed on-chain.
After fronting the funds, the Broker needs to reclaim their capital from the protocol through
the security mechanism detailed below.
5.3 Broker Funds Reclamation
To recover their fronted funds, the Broker initiates a verification process by submitting a KickOff
transaction to the protocol. This submission serves as an assertion that the Broker has legitimately
fulfilled a valid Burn transaction. The verification follows the same optimistic, challenge-response
game used for state settlement in Chapter 3, where the Broker’s assertion is assumed correct unless
challenged.
• Challenge Process: Watchers verify the legitimacy of this Reclaim Claim. If any invalidity
is found (e.g., the corresponding Burn transaction does not exist or is invalid), a Watcher will
publish a Challenge transaction.
• Assertion and Penalty: Upon being challenged, the Broker must respond within a specified
time with an Assert transaction, which must contain a Groth16 ZKP. If a Watcher can
verify that this proof is invalid, they can publish a Disprove transaction to penalize the
Broker and receive a portion of their bonded collateral as a reward. This game-theoretic pro-
cess is mechanically identical to the Single Claim Verification Protocol described in Chapter
3.
This reclaim verification mechanism relies on the Bitlayer Light Client and depends on the
Bitcoin mainnet for the finality of Bitlayer Network transactions. Therefore, a Burn transaction
is considered valid only after it has been included in a Batch and achieved Hard Finality on Bitcoin.
If challenged, the Groth16 proof provided by the Broker must contain a complete verification chain
from the Bitlayer Network’s Genesis State to the current state to prove the validity and authenticity
of the Burn transaction.
5.4 Escape Hatch
The bridge includes an escape hatch to guarantee user sovereignty over their assets, even if the
L2 protocol halts. A halt can occur if the Operator repeatedly fails to submit new claims or if
a submitted claim is successfully challenged. In this scenario, while the Operator’s collateral is
slashed and the L2 state is protected from further invalid updates, user funds could become locked.
The escape hatch provides a new path for withdrawal, which also relies on Brokers for liquidity.
The process unfolds as follows:
19
1. User-Initiated F orced Withdrawal: A user initiates an emergency withdrawal by broad-
casting a force-inclusion withdrawal transaction directly to the Bitcoin L1. This transaction
contains a signature proving ownership of the L2 account and specifies the L1 address for
receiving the funds. While this L1 transaction cannot be fully processed by the stalled rollup,
it serves as an immutable, on-chain withdrawal request.
2. Broker F ronts F unds: Brokers monitor the Bitcoin L1 for these forced withdrawal requests.
After aggregating a sufficient number of requests to meet a predefined threshold, a Broker can
choose to front the liquidity, sending the funds directly to the users’ specified L1 addresses.
3. Broker F unds Reclamation: To reclaim their fronted capital, the Broker submits a reclaim
claim to the bridge protocol, accompanied by a single Groth16 proof. This proof must validate
three distinct conditions:
(a) Proof of L2 Halt : Evidence that the rollup protocol is stalled. This is confirmed
either by showing a CommitBatchTimeout transaction (indicating the Operator’s failure
to submit a new batch) or a successful slash transaction (indicating the last submitted
batch was fraudulent).
(b) Proof of V alid User Request: Evidence that the user’s withdrawal request is legiti-
mate. This requires proving the existence of the force-inclusion transaction on L1 (via
the Bitcoin Light Client) and confirming the user had a sufficient balance in the last
correctly finalized L2 state.
(c) Proof of F ulfillment: Evidence that the Broker has already sent the corresponding
funds to the user on L1, also confirmed via the Bitcoin Light Client.
This escape hatch mechanism ensures that users always retain control of their assets, relying only
on the security of the Bitcoin L1 and the economic incentives of the Broker network. We will
explore using account abstraction to define more intelligent withdrawal logic and extending this
mechanism to support the emergency withdrawal of assets held within smart contracts.
6 Security Analysis
This chapter presents a comprehensive analysis of the security that underpins the Bitlayer Rollup.
We begin by introducing a general security model for BitVM-style smart contracts, followed by
definitions and proofs of their safety and liveness properties. We then conduct a detailed analysis
of the Bitcoin settlement security properties discussed in Chapter 3. Finally, we briefly described
the inherent censorship resistance provided by decentralized networks.
6.1 BitVM-Style Smart Contract Security
BitVM-style smart contracts follow a universal transaction graph structure. In this section, we
provide a general security analysis applicable to all BitVM-style contracts, including the Bitlayer
settlement protocol.
6.1.1 System Model & Assumptions
In a BitVM-style smart contract, at least three roles are required to collaborate:
20
• T ransaction Graph Proposer: The Proposer is responsible for initiating a contract in-
stance. To do so, the Proposer must stake a predefined amount of BTC, serving as both a
commitment and collateral against misbehavior.
• Attesters: We assume there are n Attesters, among whom m are honest. The remaining
n−m are semi-honest, meaning that they follow the protocol and collaborate to construct the
pre-signed signature but may behave unpredictably off-protocol, such as retaining keys after
pre-signing, which may allow them to attempt signing additional unauthorized transactions
after the pre-signing is completed. Each pre-signing requires the participation of at least
n − m + 1 Attesters.
• W atchers:Watchers monitor the on-chain state submitted by the Proposer to ensure correct-
ness. If misbehavior is detected, they can issue a Challenge transaction to hold the Proposer
accountable by invoking penalties on the staked BTC. The model assumes the existence of
at least one rational, honest, and active Watcher.
Additionally, we assume asynchronized network, where all communications between participants
and the Bitcoin network occur within a known bounded time ∆. All participants are assumed to
be rational and polynomial-time bounded, meaning all cryptographic tools used in the BitVM-style
smart contract are secure.
6.1.2 T ransaction Graph Model
The transaction graph serves as the backbone of the BitVM-style smart contract, structured as
a directed acyclic graph (DAG). This model provides clarity and enforceability to the contract’s
execution.
• Preceding T ransactions: The transactions provide the initial outputs necessary for the
contract’s execution, which include the Proposer’s stake reserve and the Watcher’s reserve.
The Attesters must validate the existence and correctness of these transactions before pre-
signing.
• Pre-signed T ransactions: The transactions that Attesters need to pre-sign, which deter-
mines the logic of the BitVM-style contract.
• Sink T ransactions:The transactions, lacking outgoing edges in the DAG, signify the release
of funds.
6.1.3 Design Principles
• Stake: The Proposer must stake a specified amount of BTC to initiate the contract. ( d BTC
in the graph).
• Slashable: Incorrect STF submitted by the Proposer can result in the slashing of their staked
BTC.
• T ermination: All outputs containing amounts in the pre-signed transactions must have
a time lock path (which may involve multiple transactions) leading to Sink transactions,
ensuring the contract eventually terminates.
21
Figure 7: Transaction Graph DAG Model
6.1.4 Safety
Safety Goals
• V alidity:Every transaction in the transaction graph must be valid after pre-signing.
• Integrity: No new transactions can be added to the transaction graph after pre-signing.
• Flexibility: The BitVM-style smart contract can accommodate different security assump-
tions, depending on the application scenario.
Lemma 1. Let {tx1, ..., txn} be the pre-signed transactions spending utxoa. No transaction tx′ /∈
{tx1, ..., txn} can spend utxoa.
Proof. We prove this important lemma by contradiction. Assume a committee{attester0, ..., attestern−m}
performed the pre-signing. If tx′ exists, it indicates that the Attesters have performed additional
signing outside of the pre-signing process, which implies that these n − m + 1 Attesters are semi-
honest. This contradicts the assumption.
Lemma 2. Each pre-sign committee must include at least one honest Attester.
Theorem 1 (Validity). If a valid pre-signed signature δ is produced for a transaction tx, then tx
is valid.
Proof. By Lemma 2, at least one honest Attester si participated in the pre-signing and contributed
partial signature σi for tx. Hence, tx received by si must be valid. Since the validity of δ relies on
all Attesters contributing partial signatures to tx, it must be valid.
Theorem 2 (Integrity).
Proof. Except for Sink transactions, all outputs must require a multi-signature from the pre-sign
committee. By Lemma 1, we can conclude that all participants can only spend the UTXOs in
the transaction graph along the predefined path, ensuring the integrity of the BitVM-style smart
contract.
Theorem 3 (Flexibility).
22
Proof. We can dynamically adjust the security assumptions of the Attesters based on the require-
ments of the application scenario, as long as the pre-sign committee ultimately includes at least one
honest node. Based on Lemma 1 and Lemma 2, validity and integrity can then be deduced.
6.1.5 Liveness
Liveness Goal
• F unds Liquidity:Funds involved in the contract’s Preceding transactions must not remain
indefinitely locked.
Theorem 4 (Funds Liquidity).
Proof. Since the time lock duration is known and finite, the Termination principle of the transaction
graph ensures that all funds will eventually be unlocked and flow to Sink transactions within a finite
time.
6.2 Bitcoin Settlement Security
This section focuses on proving the Bitcoin settlement security properties introduced in Chapter
3.4.4.
Theorem 5 (Completeness). An honest Operator who correctly follows the protocol and submits
valid state claims will never be unjustly penalized.
Proof. An honest operator publishes valid claims and sub-program results within the required time
windows, ensuring no inconsistencies arise. As a result, no watcher can unlock a Disprove Script,
and the operator is not penalized. To save space, the details are omitted here.
Theorem 6 (Soundness). A dishonest Operator who submits a fraudulent claim cannot avoid being
penalized, as an honest Watcher will always be able to construct a valid Disprove transaction.
Proof. If the dishonest operator does not publish Φ within ∆ claim, the operator will be penalized.
During the Claim Phase, the dishon프로젝트로 돌아가기
