Bitcoin bridge
Alpen's orchestration layer Strata has an enshrined bitcoin bridge that enables the transfer of BTC between the bitcoin and Alpen blockchains. The Strata bridge is run by a federation of operators who co-sign transactions to move BTC into and out of the bridge. The bridge is based on BitVM2, which unlike other multisignature-based bridges that need an honest majority to keep the funds safe, requires a single functional operator to guarantee the safety and liveness of the bridge. Operators stake a bond that could be forfeited, in order to disincentivise them from deviating the protocol.
This document gives a high-level overview of the bridge design and operation. A fully detailed description will be added at a later stage.
Overview
At a high level, we can divide the bridge operations into three stages:
A setup stage where operators stake the bond
A deposit stage where operators process a user request to deposit BTC into the Alpen blockchain, and
A withdrawal stage where funds are withdrawn from the bridge after a user initiates a request to withdraw BTC from Alpen to the bitcoin blockchain.
Deposit UTXOs are indexed chronologically by order of arrival, and subsequently withdrawals are processed by the first-in-first-out method. That is, the withdrawal transaction input is the UTXO for the lowest deposit index that the bridge currently possesses.
Similarly, the stakes "moves" with withdrawals such that it is always 'attached' to the lowest index UTXO — this guarantees that the bond remains at risk if the operator is dishonest, while allowing the operators to stake only once, instead of per UTXO. To read more on this, see "stake chains" in our blog post.
The deposit flow is composed of a Deposit Request Transaction (DRT) which is fulfilled by the bridge federation using a Deposit Transaction (DT). The user must provide an Alpen address to receive their deposit on Alpen.
Later, when a user wants to withdraw their BTC from Alpen, the user's withdrawal request is assigned to an operator. The operator fulfills the request by sending the user an equivalent amount of BTC from the operator’s own address (i.e. not directly from the bridge), minus a pre-determined fulfillment fee. After this fulfillment transaction is finalized on bitcoin, the operator is eligible to request a reimbursement by creating a transaction spending BTC from the bridge address to the operator's own address. This withdrawal reimbursement transaction is subject to the BitVM2-based challenge-response game to ensure correct bridge operations. An operator does not need cooperation from other operators at the time of a withdrawal.
Deposit
The deposit process is initiated by the user with a Deposit Request Transaction. This transaction sends BTC to a P2TR address, where:
The script path spend has two paths:
"Deposit path", an N-of-N multisig path, where N is the number of bridge operators. Note that this uses Schnorr key aggregation, hence the signature is aggregated into a single signature that validates all N operators' signatures.
"Take back path", which allows the user to take back their funds if the bridge fails to move funds from the Deposit Request Transaction into the bridge address within 144 blocks, i.e. it is time-locked and the user can spend it by providing a signature approximately 1 day after their initial request.
Apart from the previous Taproot output, the Deposit Request Transaction has some metadata attached to it, in the form of an OP_RETURN output, that must be the second output of the transaction in order for the Alpen sequencer to be able to detect the transaction. The OP_RETURN output can be up to 80 bytes long (according to bitcoin standardness policy), and is composed of the following data:
Magic bytes. These take 4 bytes and are used to identify the bridge.
Depositor public key (X-only). This takes 32 bytes and are used to validate the Deposit Request Transaction, while also necessary for the control block required to spend the P2TR output via the N-of-N Tapscript.
Execution Layer address. The EL address is the Alpen address where the user wants to receive the BTC on Alpen. It is a 20-byte Ethereum Virtual Machine (EVM) address.
In addition to the previous outputs, the user can add a third output for change.
The bridge monitors the bitcoin blockchain for incoming transactions, which can be detected by the OP_RETURN output. Once the bridge detects the Deposit Request Transaction, it verifies the TapLeaf hash, the multisig pubkey path, and the full Taproot commitment.
If the Deposit Request Transaction is valid, the bridge operators fulfill the deposit, via the "deposit path", with a Deposit Transaction that transfers the BTC to the bridge (that is, to the bridge-owned UTXO set), and the user is minted the same amount of BTC to the EL address provided in the Deposit Request Transaction. The BTC is minted after the Deposit Transaction has sufficiently many block confirmations on bitcoin. The "finality depth" is currently set to six confirmations.
After the Deposit Request Transaction and before the Deposit Transaction, the BitVM2 transaction graph for the deposit is generated and signed by each operator and then distributed (offchain) to all operators. The full details on the transaction graph are out of scope for this doc and will be shared in future documentation. An operator will not sign the Deposit Transaction before they have the transaction graph signed by all other operators.
The flow of a user deposit is depicted by the following diagram:
Withdrawal
The withdrawal process is initiated by the user with a withdrawal request on Alpen. The full withdrawal process has two stages, where the second can start only after the first ended:
The user requests a withdrawal on Alpen and an operator is assigned to fulfill the request on bitcoin — the operator 'fronts' the user BTC out of the operator's own address with a Withdrawal Fulfillment Transaction.
The assigned operator makes a Claim Transaction to the bridge to claim back the BTC corresponding to the Withdrawal Fulfillment Transaction.
The user withdrawal
The user initiates a withdrawal request, which can only be made for the bridge's preconfigured BTC denomination. This is done by sending 10 BTC to the bridge precompile address on Alpen, and as a result the BTC is 'burned' on Alpen.
After the burn is finalized, the assigned operator creates a Withdrawal Fulfillment Transaction on bitcoin that sends the user their BTC minus an agreed-upon fee. Finalization of the burn transaction means that the corresponding checkpoint appears on bitcoin and has a sufficient number of confirmations. The current "finalization depth" is the same as above, set to six blocks. The relevant checkpoint is the batch checkpoint that contains and proves the burn transaction (read more on batch checkpoints here).
The operator claim
The operator creates a Claim Transaction on bitcoin. This transaction commits to the Withdrawal Fulfillment Transaction TXID in which the operator paid the user, and it includes a single input from the operator's stake chain, with the correct deposit index — this input connects the operator's stake to the claim. Confirmation of the Claim Transaction starts a challenge period, during which anyone can submit a Challenge Transaction (described in more detail in the next section). On testnet, the challenge period is 36 blocks, or approximately 6 hours.
If there is no challenge to the Claim Transaction, the operator can process the bridge payout directly.
If a Challenge Transaction is confirmed — a Challenge Transaction can be submitted by anyone, and must be accompanied with the required amount of — the challenge-response game starts, which allows the protocol to determine who is at fault. If the challenge is correct (the operator submitted a false claim), the operator will not get the bridge payout and is eligible to lose their stake; if the challenge is incorrect (the operator submitted a true claim), then the operator can spend the Payout Transaction at the end of the challenge period.
The withdrawal flow is depicted by the following diagram:
Strata's challenge-response game
In BitVM2, a withdrawal initiates an on-chain challenge-response game. In the following diagram we give a high-level description of the withdrawal state machine, where challenges are made by the “Challenger” or the “Disprover” and the response is given by the “Operator”. The operator needs to make a true claim, otherwise the challenger can challenge the Claim Transaction using a Challenge Transaction. The operator must then respond to the challenge with an Assert Transaction. Finally, a disprover can disprove the operator's Assert Transaction using a Disprove Transaction. If the operator's claim was false and the challenger and disprover were correct, then the disprover will slash the operator's stake and keep part of the stake as a reward.
Last updated