🌉 Bridge Spec (Pre-release)

Historical note: this pre-release bridge spec describes an earlier bridge design and should not be used as the current source of truth for Alpen's mainnet bridge. Alpen's current bridge direction is Strata using Glock / garbled locks.

Introduction

The Bridge is the gateway for users to transfer their BTC to and from the rollup, code-named Vertex. Vertex is an EVM blockchain that uses bitcoin for data availability and consensus. The Bridge has three major components:

• Bridge Federation, which is composed of N bridge operators. Each operator participates in the deposit process and handles withdrawal requests assigned to them by the Rollup Bridge Program.
• Rollup Bridge Program, a rollup program that mints and burns Vertex BTC during deposits and withdrawals respectively, and assigns operators to process users’ withdrawal requests.
• Bridge Address, an N:N multisig address on bitcoin that holds the BTC deposits that provide 1:1 backing for Vertex BTC. At least 1:N operators must be functional¹ to prevent theft of funds from this address. The 1:N trust model is enforced by the Bitcoin Bridge Program, a set of transactions pre-signed by the Bridge Federation that authorize spending from the Bridge Address only under certain conditions.

Vertex Bridge Overview

The following is an outline of how the Bridge facilitates deposits and withdrawals:

Deposit Overview

1. A user (Alice) sends D BTC to the Interim Deposit Address which has two spend paths:

   i. requiring signatures from all of the operators as well as Alice herself
   (N+1:N+1), and

   ii. requiring only Alice’s signature but with a timelock of d weeks.

2. Alice prepares a Deposit Transaction that spends D BTC from the Interim Deposit Address to the Bridge Address using spending path i. She partially signs the transaction with her signature signaling her commitment to the deposit, and submits it to the Bridge Federation.

3. The operators then participate in a Bitcoin Bridge Program setup process in which transactions are pre-signed to enable withdrawals by functional operators and punish invalid reimbursement claims. After the setup is complete, the operators add their signatures to the Deposit Transaction sent by Alice and broadcast the transaction to the bitcoin network.

4. Once the Deposit Transaction sent by Alice is confirmed on bitcoin, an equivalent amount of Vertex BTC is minted in the rollup via the Rollup Bridge Program.

Withdrawal Overview

1. A rollup user (Bob) submits a Withdrawal Request Transaction for D BTC to the Rollup Bridge Program. The Rollup Bridge Program then assigns Bob's withdrawal request to an operator (the "assigned operator") for fulfillment.
2. After Bob's Withdrawal Request Transaction reaches a sufficient confirmation depth, the assigned operator creates a Withdrawal Fulfillment Transaction that transfers the appropriate amount of BTC from the assigned operator's Reserve Address to the withdrawal address specified by Bob in his Withdrawal Request Transaction.
3. After Bob’s withdrawal request is fulfilled, the assigned operator creates a Withdrawal Reimbursement Transaction that transfers the full amount of Bob's withdrawal request from the Bridge Address to the assigned operator's Reserve Address. If all other operators cooperate to co-sign the Withdrawal Reimbursement Transaction, then the assigned operator will immediately receive their reimbursement. If one or more operators is uncooperative, then the assigned operator can use a pre-signed transaction from the setup process to reimburse themselves. As long as the assigned operator's reimbursement claim is valid, they will eventually receive their reimbursement. If their claim is invalid, then any other operator can challenge the claim to prevent the invalid claim from being processed.

Features

The Bridge has the following core features:

• Deposits and withdrawals are allowed in a denomination of D BTC where D is a set of values (such as 0.1 BTC, 1 BTC, 10 BTC) predefined by the Bridge Federation.
• Deposits and withdrawals can be processed at any time. For example, there is no pre-set time interval or checkpoint enforced for deposits and withdrawals.
• Multiple deposits and withdrawals can be processed simultaneously.
• During normal operation of the Bridge, i.e. all operators are functional, an operator who has liquidity of D BTC (plus fees) can process multiple withdrawal requests in the same bitcoin block (many multiples of D), only constrained by the bitcoin mempool's limitation on the number of the dependent transactions.
• In the worst case, a functional operator who has liquidity of D BTC can process a user withdrawal within 5 challenge-response rounds. This is enabled by using the SNARKNado protocol, which achieves a 90% reduction in the number of challenge-response rounds as compared to conventional BitVM.
• Operators are incentivized to behave optimally for the best user experience (eg. maximizing liveness, contributing liquidity for withdrawals, processing user withdrawals in a timely fashion, etc.).
• A user's deposit is automatically returned back to them if the Bridge Federation cannot process the deposit within the allotted time.

Guarantees

The Bridge provides the following guarantees. All guarantees assume that at least 1:N operators is functional.

• The BTC deposited in the Bridge Address and the Vertex BTC minted in the rollup are always maintained at a 1:1 ratio.
• A user can eventually redeem their Vertex BTC for mainchain BTC. In practice, the assigned operator is incentivized to process withdrawals within a certain time window rather than “eventually”.
• A valid withdrawal claim by an assigned operator is guaranteed to succeed.
• An invalid withdrawal claim by an assigned operator is guaranteed to fail and results in burning of their bond and revocation of their ability to process further withdrawals.

Security and Liveness Assumptions

1. All N operators must be functional to ensure a successful deposit.
2. All N operators must be functional to ensure a cooperative withdrawal.
3. At least 1:N operators must be functional to ensure an uncooperative withdrawal.
4. The bitcoin blockchain is re-org resistant after a certain confirmation depth.

Deposit Details

Now, we’ll take a deep dive into all the razzmatazz that takes place when Alice makes a deposit to the rollup using the Bridge.

Deposit Request Transaction (DRT)

The deposit process begins with a Deposit Request Transaction. This transaction transfers Alice's D BTC to an Interim Deposit Address. The Interim Deposit Address has two spend paths:
i. an (N+1):(N+1) path requiring signatures from all of the operators as well as Alice herself, and
ii. requiring only Alice’s signature but with a timelock of d weeks.

To prevent Alice from reusing her input UTXO(s) in any other transaction, we require that the Deposit Request Transaction be confirmed on bitcoin before minting an equivalent amount of BTC in the rollup. Conversely, to prevent faulty operators from holding Alice's deposit hostage, a timelock is also added to the transaction output that allows Alice (and only Alice) to spend the output after some set amount of time.

Deposit Transaction (DT)

The next step is to create a Deposit Transaction DT that spends from the Interim Deposit Address. For this, Alice first pre-signs a transaction on the (N+1):(N+1) path of the Interim Deposit Address, transferring D BTC to the Bridge Address. This transaction is a bit special in that she adds a zero-value output script starting with OP_RETURN which specifies her rollup address. This address is where she expects to receive the Vertex BTC that are minted against her DT.

While minting an equivalent amount of Vertex BTC in Alice’s rollup address should be enough, we also need to provide her an exit strategy i.e. we need to provide assurances that any user who wishes to withdraw their BTC should be able to.

The withdrawal workflow (as outlined in the Introduction) implies that the only way to ensure that a user’s withdrawal request is serviced in due time is to also ensure that an assigned operator who has fulfilled the withdrawal request and submitted a valid reimbursement claim will actually be reimbursed. This is because an operator will only be willing to fulfill withdrawal requests if they have a guarantee that they will be reimbursed for the expense. To provide this guarantee, it is not enough to have only the setup shown in Figure 2.

Pre-signed Transactions

Once DT is confirmed on bitcoin, its BTC output will become part of the Bridge Address’s UTXO set. In a future withdrawal reimbursement, 1:N bridge operators should be able to withdraw this UTXO from the Bridge Address. As such, it is necessary to set up some pre-signed transactions that open up pathways for any operator to withdraw any UTXO from the Bridge Address, but only under certain conditions.

The pre-signed transactions required to provide these guarantees are best explained via diagram (or several, such as in Figure 3). For the sake of simplicity, this diagram shows only one of the operators making a withdrawal reimbursement claim.

To make a withdrawal reimbursement claim, the operator² requires signatures from all N operators. But some of the other operators might not cooperate to co-sign the reimbursement transaction, mainly for two reasons:

• The operator's withdrawal reimbursement claim is invalid, or
• The uncooperative operator is faulty

In either case, we want the functional party to win i.e. if the operator's reimbursement claim is valid, their claim should be serviced, and if their claim is invalid, it should be possible to challenge the invalid claim and penalize the faulty operator. While the exact nature of the Challenge-Response Game (CRG) is encoded in the Bitcoin Bridge Program setup that we explain later, some transaction machinery must be devised during the deposit process itself so as to ensure that the functional party wins while respecting the 1:N trust assumption. We’ll go through each of the transactions in detail:

1. Kickoff Transaction (KT):

   The first step is to create a Kickoff Transaction KT that will be used by the operator to initiate an uncooperative withdrawal reimbursement claim. This has the following structure:

   Input	Output/Redeem Script
   Dust UTXO of the operator	Operator in T weeks or N:N immediately

   Here, T weeks is the duration of the CRG in the worst case, which is around 4 weeks. If the output is spent by a challenger before the end of this time frame, the operator forfeits their claim, and if the output is redeemed by the operator after T weeks, their claim will be serviced. As such, whether an operator will be reimbursed depends entirely on the state of this output. The rest of the transactions are pre-signed in such a way that the output can only be spent by a challenger if the operator is faulty.

2. T-weeks-later Withdrawal Transaction (TWT):

   The next transaction is the actual transaction that reimburses the operator. This has the following structure:

   Input	Output/Redeem Script
   Output from KT	D BTC to the operator
   D BTC from Bridge Address (pre-signed)

   Since the second input is pre-signed by all the operators, all of them must be alive for the deposit to go through. This also means that the only thing preventing the operator from accessing these funds is the output from KT, which only matures after T weeks. If this KT output is spent by the challenger, this transaction will no longer be valid and the operator won’t be able to receive a reimbursement with this transaction. This should only happen when the operator loses the CRG, which means we need to create a transaction that uses up the KT output if the challenger wins. However, this is less than straightforward.

Consider a case where there is only one functional operator (consistent with our 1:N trust assumption). One of the faulty operators will initiate multiple invalid reimbursement claims concurrently. This means that multiple CRGs will be initiated at the same time. While the sole functional operator is busy challenging the claimant in one of the games, the rest of the operators can collude with the faulty operator and steal the BTC in the Bridge Address. So, our 1:N trust assumption quickly devolves into a 1:(N-k) trust assumption for (k + 1) CRGs running simultaneously. In fact, all functional operators would get occupied in the first CRG itself (because each functional operator is obligated to start a challenge if the assigned operator's claim is invalid). This would mean our trust assumption collapses even if there are just two CRGs running in parallel!

A trivial solution to maintaining a 1:N trust assumption is to enforce that each operator must only initiate one claim at a time. The resulting CRG should then conclude before another claim can be initiated. At best, this approach can adversely affect how quickly withdrawal requests can be fulfilled and at worst, it can halt the withdrawal process (if there are more contentious withdrawal requests than there are available operators).

Since this trivial approach has significant downsides, we need a better alternative. Essentially, we need a way for the functional challenger to spend not only the KT output for the CRG that they are part of but also all other KT outputs linked to the faulty operator. This means losing one CRG should be equivalent to losing all CRGs!

To accomplish this, we create a UTXO tree (which we call the Deposit Tree as this tree holds the KTs that provide access to all the deposits in the Bridge Address) in such a way that when any challenger wins, they have the ability to make all the other KT outputs instantly spendable (see Figure 4).

Each operator-challenger pair in the Bitcoin Bridge Program has a CRG setup that yields an Initiate Burn UTXO (IBU) if the challenger wins. The root of the Deposit Tree takes this UTXO as an input so that when the IBU is created, all other kickoff outputs can be spent. The leaves of the tree are made up of transactions that receive the KT output as the input. As new kickoff transactions are created (with each new deposit), the output of the kickoff transaction is linked to the leaves of the Deposit Tree and pre-signed by N:N operators. This, in itself, is not sufficient for the UTXO to be spent as each such leaf is transitively dependent on the root of the Deposit Tree, which will be “unlocked” only if the challenger actually wins and the IBU is created. As such, it is perfectly safe and, in fact, necessary to publish this tree so that when an IBU is created, anybody is allowed to commit the leaves thereby, making the KT output spendable. Once this happens, the faulty operator will effectively lose every CRG. The exact nature and creation process of the IBU will be discussed later.

In practice, if there are N operators, there will be a total of N(N-1) CRGs that can be played, and so that many Deposit Trees that need to be setup, which means that each operator will have to store a total of N(N-1) Deposit Trees so as to be able to penalize any faulty operator. Each such tree will have a predefined breadth and depth to support as many deposits as feasible.

For the sake of simplicity, Figure 4 shows the case where there are only three operators, handling just two deposits so far on a binary Deposit Tree. Each deposit results in the creation of a kickoff transaction. For each operator, a Deposit Tree is set up with each of the challengers . Notice that the two upper leaves are connected to the KT outputs of the two deposits while the two bottom leaves in the tree are empty. These will be filled when new deposits arrive and hence, new KTs are created. If e.g. the first challenger wins, IBU-1 becomes available which opens up the root of the Deposit Tree and so, the corresponding kickoff e.g. KT-2 can be spent. In the future, if the faulty operator tries to initiate another kickoff via KT-1, any challenger is free to spend its output and deny the claim.

There is one more component to all of this — the Operator Bond (OB). As all nodes in the Deposit Tree are just transactions, some amount of BTC is needed to operate it. The operator is responsible for creating a Bond that gets used in each of the transactions in the Deposit Tree. Ultimately, this Bond gets divided into the n leaves in the Deposit Tree evenly. As making all the kickoff outputs spendable only requires unlocking one of the Deposit Tree roots, the same Bond can be shared across all the Deposit Trees.

The DRT as shown in Figure 5, also has two more outputs: one output that sends some BTC to the challenger as a reward for their valid challenge (paid from the Operator Bond), and a connector UTXO which is basically a Dust UTXO that connects this transaction with other transactions that depend on the fact that the operator lost.

The number of leaves in the tree corresponds to the number of deposits that an assigned operator can handle. This number should be as high as possible since this number represents the number of deposits that the Bridge Federation can handle. Therefore, the Operator Bond is setup in such a way that when it is evenly divided into the leaf transactions, all that’s left are Dust UTXOs! To support 17 million deposits, the Bond amount needs to be 100 BTC (assuming a Dust UTXO value of 576 satoshis). Since the Bond also pays for the challenger that wins, some additional amount also needs to be added to the original Bond value.

Note that the actual Deposit Trees are set up only once when the CRGs are set up between each operator-challenger pair. During the deposit process, the only extra setup required is to connect the KT output to a leaf of each of the Deposit Trees for the given operator that is assigned to the deposit UTXO.

Once the KT output is linked to a UTXO leaf and pre-signed, DT is then submitted to the bitcoin network and confirmed in a bitcoin block. The rollup full nodes then scan for this transaction in the blockchain. Once the transaction is found, it will execute a contract in the rollup that mints an amount of Vertex BTC equivalent to the amount of BTC specified in DT, then transfers the newly-minted Vertex BTC to the rollup address specified in the DT OP_RETURN output.

This completes the deposit story.

Summary

Withdrawal Details

So far, we’ve looked at how a deposit is set up to not only enable deposits but also to enable withdrawals. Now, we look at the intricacies of the withdrawal process itself.

All withdrawals take place through the Bridge Address. This address contains a set of UTXOs produced via different deposit transactions. During the deposit process explained above, a pathway is created that essentially “unlocks” these UTXOs for withdrawal. Each UTXO will have D BTC associated with it. This means that every withdrawal request can only be denominated in chunks of D BTC.

Withdrawals can proceed in two ways:

Cooperative Path

In the cooperative path, the assigned operator creates an unsigned Withdrawal Fulfillment Transaction (WFT) where they spend BTC from their own bitcoin address, called their Reserve Address. The assigned operator then links the WFT to a Withdrawal Reimbursement Transaction (WRT) that transfers D BTC from the Bridge Address to their Reserve Address, and requests the other N-1 operators to sign WRT. If all of the other operators cooperate to sign WRT, then the assigned operator adds their own signature to this WFT-WRT transaction chain and submits the transaction chain to the bitcoin network. Once the transaction chain is confirmed, the withdrawal request is fulfilled and the assigned operator is reimbursed.

Uncooperative Path

On the other hand, if one or more of the other operators are uncooperative and do not sign the WRT, the assigned operator is forced to take the uncooperative path which involves the following steps:

1. The assigned operator preemptively fulfills the user's withdrawal request using D BTC from the assigned operator's Reserve Address.
2. Then, the assigned operator settles the KT associated with D BTC (from the deposit UTXO).
3. If no challenge is received for T weeks, the operator can spend the pre-signed TWT to get their reimbursement (as shown in the Deposit story).
4. Otherwise, one of the other operators spends CKT, which starts the CRG.
5. If the assigned operator wins the CRG or the CRG is not resolved within T weeks, they can still spend the TWT and get their reimbursement.
6. Otherwise, if the challenger wins the CRG, they will spend the input to the TWT (thereby preventing the assigned operator from getting reimbursed) and then proceed to burn the assigned operator’s Deposit Tree as well to get their reward (see Figure 3 and Figure 4). At this point, the assigned operator loses access to all the deposit UTXOs, their stake in the CRG is burned, and they are evicted from the Bridge Federation.

Rollup Bridge Program

Another component in the Bridge is the Rollup Bridge Program. This program controls the rollup side of the Bridge and performs two main functions:

• When a deposit is received, this program is responsible for minting an equivalent amount of Vertex BTC to the depositor's specified rollup address.
• When a withdrawal request comes in, this program assigns the request to a predefined priority queue of operators. The operator with the highest priority must fulfill the withdrawal within a preset time frame. If they are unable to fulfill the withdrawal request within this time frame, the second in line takes over for the next preset time frame. Note that withdrawals are assigned to a specific deposit UTXO. The assigned operator can use the setup created during that deposit to process the withdrawal. The program keeps a mapping of Deposit_i to Withdrawal_i to list of assigned operators. As for how to decide priority, the protocol could be a simple round-robin algorithm or more sophisticated (based on stake, availability, etc.)

The algorithm used in this program can be optimized further to incentivize assigned operators to process withdrawal requests in a timely manner (more on this is explained in the Extensions section).

The Bitcoin Bridge Program Details

The bitcoin side of the bridge is controlled by the Bitcoin Bridge Program, which is created by the operators with every deposit. To create the Bitcoin Bridge Program, the N operators in the Bridge Federation perform an initial setup between every possible pair of operators. Various transactions are constructed, some of which are spent during setup, and some which are pre-signed and stored offchain. This is to enable CRGs in case of a future fault by an operator. If the operator loses the CRG, the funds staked by the faulty operator are either burned or transferred to the challenger, and the faulty operator is evicted from the Bridge Federation.

2-of-2 multisig setup (settled onchain)

Each operator O_i constructs two 2:2 multisigs with every other operator O_j, forming a basis for two CRGs. One CRG is set up with O_i as the challenger and O_j as the responder, and another is set up with the roles reversed. Each multisig is the starting UTXO in a chain of challenge-response transactions, and the multisig contains at least enough BTC to settle all the transactions of the CRG onchain. The leftover goes to the winner of the game. These multisigs, a total of N \times (N-1), are settled onchain.

CRG transactions (stored offchain)

The following series of transactions are pre-signed and stored by the operators offchain. The transactions are only ever spent onchain if an operator is faulty.

1. Challenger Kickoff Transaction (CKT)
2. Challenge Response Transaction (CRT)
3. SNARKnado transactions

CKT spends from the 2:2 multisig using as witness the "challenger ZK Proof", detailed in later sections. This proof essentially represents the challenger's claim that the assigned operator is faulty and did not process the assigned withdrawal correctly. CKT creates a CRG UTXO, which can be spent by the operator responding to the challenge (the "responder"), or by the challenger after a response window has passed (set as one week). CKT is pre-signed by the responder and stored by the challenger offchain, so that the challenger can add their signature and spend when needed.

CRT spends the CRG UTXO created by CKT by using as witness the "operator ZK proof". This proof responds to the challenger's claim, and claims that the responder is in fact functional. CRT creates the CRG UTXO, which can be spent by the challenger by kicking off the SNARKnado bisection protocol. CRT is pre-signed by the challenger and stored by the responder offchain to spend when challenged.

SNARKnado transactions are a chain of challenge-response transactions of the nature similar to CKT and CRT i.e. the transaction spent by a party produces a UTXO that then has to be spent properly by the counterparty within a given time frame to continue the CRG and not lose access to the multisig funds. The difference is in the nature of witnesses that spend the UTXOs, determined by the SNARKnado protocol. Details of this protocol are out of the scope of this document, but the CRG ends with one of three types of transactions: 1) the transaction spent by the challenger in which the operator didn’t respond within one week, 2) the final transaction of the CRG where the challenger can penalize the faulty responder ("equivocation transaction"), or 3) the transaction settled by the responder in which the challenger didn’t respond within one week. In scenarios (1) and (2), the challenger is the winner, and a UTXO is created in each case that can be spent unilaterally by the challenger. In scenario (3), the UTXO created can be spent unilaterally by the responder.

Burn setup multisig (onchain)

The challenger can win the CRG in five different ways — either in one of the four intermediate rounds if there is no response from the responder or via equivocation. To allow the challenger to burn the Deposit Tree (also shown in Figure 4) regardless of how they win, additional transaction circuitry is required.

First, a transaction called the Initiate Burn Transaction (IBT) is created by the challenger. The UTXO from this transaction is an input to the Deposit Tree Root. It is via this UTXO that the burn process is initiated. This UTXO should only be activated when the challenger wins. The output from IBT is either spendable by the challenger in C weeks or by a multisig of both the challenger and the responder. As such, this transaction is not signed by the challenger until they are sure that it can only be used to burn the Deposit Tree.

Conversely, it should be possible to burn this UTXO if the responder wins. For this, a 2:2 pre-signed Burn IBT transaction (BIBT) is created that takes the IBU as an input. Again, it should not be possible to create BIBT if the challenger wins. So, finally we create two more 2:2 pre-signed transactions namely, the Protect Burn Transaction (PBT) and the Enable Burn Transaction (EBT).

The UTXO from PBT is the second input to BIBT. So, for the responder to prevent their Deposit tree from being burnt, they need IBT and PBT to be available so that they can spend them in BIBT. Inversely, the challenger needs to prevent BIBT from being created. For this, the output from PBT is connected to EBT, which spends the Challenger Won UTXO (CWU) created from the CRG. As there can be five CWUs, there are five EBTs as well, any one of which can consume the output from PBT, provided that CWU is available.

The end result is that regardless of which round the challenger wins in, PBT is burned thereby rendering BIBT useless. The challenger is then free to sign and commit IBT. After C weeks, IBU can be used to burn the Deposit Tree. On the other hand, if the responder wins, PBT remains unused and their Deposit Tree remains protected. If at any point in the future, the challenger signs and commits IBT, it can be immediately spent in BIBT while the challenger waits for the C weeks to elapse.

Challenger and Responder Proofs

The operator who starts the CRG by spending CKT is the “challenger” for that game. To spend CKT, the challenger must produce a witness containing the “challenger ZK proof”. The operator who is challenged in a CRG is the "responder" for that game. In response to CKT, the responder must produce a “responder ZK proof”. The details of these proofs are as follows:

Challenger ZK Proof

Public Inputs: pow , kickoff_txid

Private Inputs: header_chain, kickoff_spv_proof

Claim: header_chain is a valid bitcoin header chain with the total proof-of-work (pow)\sum_{i=0}^{N} (\text{difficulty}_i). The chain contains the assigned operator’s withdrawal kickoff transaction.

Program Pseudocode:

function (pub, priv) { //pub - public inputs, priv - private inputs
 // verify the header chain and pow
 verify_header_chain(BITCOIN_GENESIS_BLOCK, pub.pow,
  priv.header_chain)

 // verify spv proof of the withdrawal kickoff transaction
 verify_spv_proof(pub.kickoff_txid, priv.header_chain,
  priv.kickoff_spv_proof)
}

Responder ZK Proof

Public Inputs: c_proof

Private Inputs: header_chain, pow, S_n, S_n_incl_proof, withdrawal_assignment, payment_spv_proof, kickoff_spv_proof

withdrawal_assignment contains info about the deposit Tx, operator ID, bitcoin withdrawal address, and time window to fulfill the withdrawal request.

Claim:

1. There’s a rollup state with root S_n in the bitcoin chain, and I have been assigned to process a withdrawal request corresponding to the DT that is associated with my KT.
2. I fulfilled the withdrawal request by transferring D BTC to the associated bitcoin address within the required time frame. I spent KT after WFT.
3. My header_chain is valid, and has total proof of work greater than a threshold t compared to that of the challenger.

Program Pseudocode (SNARKnado CRG takes place for this computation)

function (pub, priv) {
  verify_header_chain(BITCOIN_GENESIS_BLOCK, priv.pow,
   priv.header_chain)
  verify_withdrawal_assignment(priv.S_n_incl_proof, priv.S_n,
   priv.header_chain, priv.withdrawal_assignment)
  verify_kickoff_after_payments(priv.payment_spv_proof, priv.header_chain,
   priv.kickoff_spv_proof)
  if (!is_valid(pub.c_proof) {return true // Responder wins}
  if (priv.pow - c_proof.pow > t) { return true // Responder wins}
  else { return false // Challenger wins}
}

Challenge-Response Timeline

We need to properly parameterize the amount of time to be given to the challenger and responder to prepare their challenges and responses such that the functional party always wins the CRG. This involves an analysis assuming the faulty party can prepare a private fork to compete with the canonical bitcoin chain in order to try to cheat. Even in this scenario, we need to make sure that the difference between the responder’s pow and the challenger’s pow is greater than t only if responder's claim is valid.

Let’s assume that the faulty party has x% of the hashpower of the entire bitcoin network, with which to privately build blocks in an alternative private chain. Let’s also assume that the challenger gets p time to prepare CKT (which includes the challenger’s ZK proof) after the operator spends KT and d additional time to spend CKT. Then, the responder gets q time to prepare CRT (which includes the responder’s ZK proof) after CKT is confirmed, and d additional time to spend CRT.

With the analysis detailed in challenge-response-timeline-parameterization.md, we conclude that we can use a threshold condition of t > q where t = PoW_O - PoW_C, and relation q > \frac{2dx}{1-x} - p allows us to parameterize the checks inside SNARKnado to adjudicate the claim.

If x = 50 \%, i.e. the faulty party has hashpower equal to 50% of the entire bitcoin network,

Taking the middle row, if we allow the challenger and responder the duration of d blocks each to prepare their transactions and then additional d blocks to settle the transactions, a functional responder will have enough time to accumulate a bitcoin chain with cumulative proof of work greater than that of the challenger by d, while a faulty operator, making a private fork of the bitcoin chain including fake WFTs and KTs, cannot meet that threshold. All possible scenarios where either the challenger or responder are faulty are detailed in challenge-response-timeline-parameterization.md.

Extensions to the core design

Flexible Denominations

While our core design focuses on a single denomination for deposits and withdrawals, it can be easily extended to support any denominations either through third-party services or in the core protocol itself.

Third-party Services

An example of a third party service that can be used for flexible denominations is atomic swaps. A user who wishes to deposit some BTC will arrange an atomic swap with a swap counterparty. This counterparty receives BTC from the user and atomically transfers an equivalent amount of Vertex BTC from the counterparty's rollup address to the user's specified rollup address.

Core Protocol

Incorporating flexible denominations into the core protocol is more involved and requires user experience tradeoffs relative to the fixed denomination implementation. This involves creating buckets for deposits and withdrawals. Let’s consider the withdrawal case.

Consider the following scenario:

If Alice wants to withdraw in this scenario, we need to allow an operator to withdraw 1 BTC but there exists no single UTXO with that amount in the Bridge Address and so, there is no withdrawal path associated with it. To solve this issue, we use the concept of withdrawal buckets. To demonstrate this, let’s consider a second scenario with Alice, Bob, and Charlie transacting with each other in the rollup:

The above table shows the state of the withdrawal bucket(s) over a set of events in the rollup. Each user can independently request withdrawals. However, this does not guarantee an immediate fulfillment of this request. Any operator who wishes to fulfill the request needs to be able to withdraw an equivalent amount of BTC from the Bridge Address. This is only possible if a withdrawal bucket is full. And so, the user has to wait for their bucket to fill before their withdrawal request can be fulfilled. In the above table, this happens after event 5. At this stage, the first bucket reaches the required threshold. Any number of BTC may overflow this bucket and spill into another bucket. Once a bucket is full, the rollup code is responsible for assigning the bucket to an operator. Once a bucket is assigned to an operator, they are responsible for fulfilling the associated withdrawal requests. However, the operator must be assured that they will be reimbursed afterwards. This reimbursement can proceed in one of two ways:

Cooperative Path

In this scenario, the withdrawal process involves the following steps:

1. The operator creates a Withdrawal Fulfillment Transaction (WFT) where they fulfill all withdrawal requests associated with the bucket assigned to them. These withdrawal requests are fulfilled using BTC from the operator's Reserve Address. This transaction is then connected to another transaction, the Withdrawal Reimbursement Transaction (WRT) where a UTXO from the Bridge Address is transferred to the assigned operator's Reserve Address. WFT must be unsigned so as to prevent any other operator from broadcasting the transaction. If WFT were signed and broadcast at this stage, it would transfer away the assigned operator’s BTC without a guarantee of the assigned operator being reimbursed.
2. If WRT is signed by rest of the operators, WFT is then signed and spent by the assigned operator. Once WFT and WRT are confirmed, the withdrawal requests are fulfilled and the assigned operator is reimbursed from the Bridge Address. It may also be the case that a single bitcoin transaction is not enough to service all the withdrawal requests, due to limits in the bitcoin protocol related to transaction sizes. In this case, a chain of transactions can be created that ultimately links to the final WRT that reimburses the assigned operator with BTC from the Bridge Address. Figure 14 shows what this looks like.

Uncooperative Path

The process of reimbursement via the uncooperative path remains mostly the same as in the core design. The only difference being that instead of fulfilling only one withdrawal request, the assigned operator fulfills all withdrawal requests associated with the bucket assigned to them, before spending KT.

Bucket assignment

As both deposits and withdrawals are quantized by a fixed denomination, with every deposit, a fresh (empty) bucket is created. And with every withdrawal request, one of these buckets is populated. Trivially, buckets would be filled one at a time. However, given the constraints imposed by the bitcoin protocol in terms of number of transactions, size, cost, etc., we need to consider a few different factors as well. For example, consider the following case:

• Max bucket size (denomination): 1 BTC
• Current bucket size: 0.5 BTC

In the above case, if a withdrawal request of 1 BTC comes in, do we create a new bucket that can be serviced immediately or continue filling the current bucket thereby splitting the user’s request into two separate buckets?

In essence, the bucket filling and assignment criteria may include but is not limited to:

• Number of transactions per bucket

  It is generally better to have fewer transactions per bucket as this impacts the transaction size and hence, the cost of WFT.

• Waiting time

  From an end-user’s perspective, it makes for a better user experience if a user’s withdrawal request can be serviced as soon as possible.

• Fragmentation

  Similarly, it is better for the user if their single withdrawal request is fulfilled in a single bucket rather than wait for separate buckets to be filled and receive their withdrawal in chunks.

Summary

Data storage requirements for Operators

TBD

Operator exit mechanism

TBD

Incentives

TBD

Diagram Conventions

• Transactions

  A Transaction is represented by a container in green. This container contains inputs in the upper box and outputs in the lower box. As inputs “flow into” the outputs, an arrow (in a lighter shade of green) pointing from the upper box (input) to the lower box (output) helps clarify this relationship.

• UTXOs

  There may exist multiple inputs in a transaction i.e., the input to the transaction may be composed of output UTXOs from other transactions (that may not be shown for the sake of simplicity). Such UTXOs are represented via another container in purple. Sometimes, the input box within the transaction may contain additional information (such as the signer).

• Dependencies between transactions

  Dependencies between transactions are represented with another set of arrows. If a transaction (say, B) depends on the output UTXOs of another transaction (say, A), then this relationship is represented via white arrow(s) pointing from A to B (i.e. A → B).

• A 0 BTC input when present, represents a Dust UTXO based on the rules set forth in the bitcoin protocol.
• Almost all transactions are given names and abbreviations in the diagram.
• Groups of transactions have also been “containerized” to distinguish logical separation between transaction flows. For example, the blue container in Figure 3 houses the transactions in the fallback path.

Glossary

Assets

Terminologies

Entities

Transactions, UTXOs and related structures

FAQ