Hybrid data availability: Analyzing BitVM's forced withdrawal feature on BOB
TechFlow Selected TechFlow Selected
Hybrid data availability: Analyzing BitVM's forced withdrawal feature on BOB
BOB announced the "BitVM forced withdrawal feature" on its official blog, marking the first substantial progress among BTC Layer2 solutions regarding the specific functionality of forced withdrawals.
Navigating Web3 tides with focused insightsSummary:
-
Layer2s should have censorship resistance equivalent to the Layer1 blockchains they are built upon;
-
On BOB, users can already force withdraw their assets from BOB back to Ethereum via transactions on Ethereum;
-
For the BitVM bridge, BOB is working on integrating the Bitcoin network as a way for users to execute transactions on BOB;
-
Bitcoin users can withdraw BTC assets from BOB without sending any transaction to BOB.
On February 4, 2025, the hybrid Layer2 project BOB publicly announced its "BitVM forced withdrawal functionality" on its official blog. This marks the first substantial progress in the specific function of "forced withdrawals" for BTC Layer2s, holding primary significance for both the Bitcoin ecosystem and the broader industry.
Vitalik has emphasized that whether users can smoothly withdraw assets from Layer2 back to Layer1 is a critical security metric. In emergency situations, the "forced withdrawal" function is as vital to Layer2 as an "emergency exit" is in the real world. Within the Ethereum Layer2 ecosystem—a custodial platform system managing billions of dollars in assets—the ability for users to securely withdraw assets back to Layer1 via forced withdrawals has become an indispensable necessity.
For EVM-based Layer2 blockchains, the current market already offers relatively comprehensive forced withdrawal and escape hatch functionalities to ensure users can safely and promptly withdraw assets back to Layer1. Below, we can understand how BOB achieves forced withdrawal functionality for BTC Layer2 through this Blog.
One core property of Layer2s is that their state transitions must continue even if the sequencer goes offline. Layer2s achieve this by reading and writing their state to a data availability (DA) layer, which can be updated independently of the Layer2. This allows users to force-execute their transactions even if the sequencer is offline or refuses user transaction requests. Because if the sequencer continuously rejects user transactions, or simply fails or shuts down for extended periods, it could result in massive financial losses.
For example, during Solana's outage, some individuals faced liquidation risks because they couldn't timely top up collateral, putting millions of dollars at risk. The economic losses caused by such denial-of-service scenarios cannot be underestimated.
Regarding BOB’s BitVM bridge, an interesting question arises. BOB currently uses Ethereum's EIP-4844 blobs as its DA layer. Users on Ethereum can easily withdraw assets back to the Bitcoin network via the BitVM bridge, but this process requires users to hold ETH on Ethereum for gas fees.
Therefore, the user experience is not yet optimal. Bitcoin users should only need BTC on the Bitcoin network to withdraw their BTC from BOB back to Bitcoin. BOB is researching a hybrid solution: defaulting to Ethereum as the DA layer while allowing users to force-include transactions on BOB via special transactions on Bitcoin.
Data Availability (DA) and Derivation Background
The derivation process is crucial for Layer2 blockchains: BOB's entire Layer2 state needs to be constructed from L1 and the DA layer. It enables Layer2 to enjoy the same censorship resistance as the DA layer (in this case, Ethereum).
In simple terms, in rollups (especially OP Stack-based chains), we have two types of data on Layer1:
-
Deposit transactions to the “OptimismPortal” contract. These are transactions users make on Ethereum, typically depositing assets into BOB. These deposit transactions can also be used to execute other transactions on BOB.
-
Batches submitted by the sequencer (or more accurately, op-batcher) from Layer2 transaction processing. These include all transactions directly made by users on BOB and are eventually included in Ethereum blobs.
Bitcoin as a DA Layer
If we want Bitcoin to serve as a DA layer, why not fully switch to using Bitcoin exclusively as the DA layer? The main reason lies in cost. Bitcoin’s available storage space is very small (approximately 4MB every 10 minutes), making storage costs extremely high.
However, in this case, BOB can still use Ethereum as its “primary” DA layer to publish its full transaction data, while adding Bitcoin as a highly censorship-resistant fallback layer if Ethereum’s DA becomes unavailable. Essentially, Ethereum becomes the optimistic DA layer, while Bitcoin serves as a costly but fault-tolerant last resort.
Mixed Derivation Pipeline
The basic solution is to add Bitcoin into BOB’s derivation pipeline so that BOB (specifically the “op-node”) processes inputs in the following order:
-
Bitcoin forced withdrawal transactions (newly added specifically for BOB);
-
Ethereum deposits to BOB’s OptimismPortal contract (OP Stack standard);
-
Ethereum batches from op-batcher (OP Stack standard).
There is a potential solution to encode Bitcoin forced withdrawal transactions into BOB’s derivation pipeline. However, this is still under research and may change.
Bitcoin Forced Withdrawal Transactions
BOB requires three components to create a forced withdrawal transaction:
-
Constructing the forced withdrawal transaction on Bitcoin.
-
Storing the forced withdrawal transaction within Bitcoin’s block size limit.
-
Handling the gas fees for Bitcoin forced withdrawal transactions.
1. Constructing forced withdrawal transactions on Bitcoin
OP Stack deposit transactions have the following structure:
-
bytes32 sourceHash: Source hash uniquely identifying the origin of the deposit.
-
address from: Address of the sender account.
-
address to: Address of the recipient account; empty (zero-length) if the deposited transaction creates a contract.
-
uint256 mint: Value of ETH minted on L2.
-
uint256 value: Value of ETH sent to the recipient account.
-
uint64 gas: Gas limit for the L2 transaction.
-
bool isSystemTx: If true, the transaction does not interact with the L2 block’s gas pool.
-
bytes data: Call data.
A forced withdrawal transaction needs to include the encoded withdrawal transaction within the data field of a deposit transaction. This is done by creating a transaction on BOB that triggers a withdrawal from BOB to Bitcoin, functioning identically to sending a transaction from Ethereum.
We can then store a (compressed) version of the forced withdrawal transaction on Bitcoin, including all the above data.
2. Storing forced withdrawal transactions on Bitcoin
Since the data of a forced withdrawal transaction exceeds typical amounts stored in an OP_RETURN output, BOB may use Taproot outputs to store the data.
While deposit transactions on Ethereum (possibly including withdrawals) are easy to identify because they are sent to BOB’s OptimismPortal contract, identifying forced withdrawal transactions on Bitcoin is less straightforward.
Data serialization: Forced withdrawal transactions are serialized using Taproot scripts within an “envelope” structure. These are noops on the Bitcoin network and can also be used for ordinals, etc. We adjust the structure to meet our needs.
Unset
OP_FALSE OP_IF
OP_PUSH "bob"
OP_1
OP_PUSH "transaction"
OP_0
OP_PUSH $WITHDRAWAL_TRANSACTION_DATA
OP_ENDIF
Two-phase commit/reveal scheme:
Similar to ordinals, users must submit two transactions to Bitcoin:
-
Commit transaction: Creates a Taproot output committing to a script containing the inscription content. This transaction does not yet reveal the data—we require a second transaction from BOB full nodes and the sequencer to include the withdrawal transaction.
-
Reveal transaction: Spends the output of the commit transaction, revealing the inscription on-chain—i.e., revealing the user’s withdrawal transaction for inclusion in BOB.
3. Handling gas fees for Bitcoin forced withdrawal transactions
Regarding gas fees, BOB is currently considering two options:
-
Set gas fees for Bitcoin forced withdrawal transactions to 0 and deduct gas costs from the user’s ETH balance on BOB. This means only users holding ETH on BOB can initiate forced withdrawals. However, this is suboptimal because it requires users to hold ETH on BOB to force withdraw—even BTC holders on Bitcoin cannot force withdraw otherwise.
-
Gas fees are paid by users in BTC on Bitcoin. The BOB network needs an address on Bitcoin capable of receiving BTC and effectively converting received BTC into ETH on BOB to cover Layer1 gas costs plus execution costs. This option could be implemented using the BOB Gateway, setting the BOB DAO’s EVM address as the BTC recipient.
Conclusion
Anyone can determine BOB’s state simply by examining data on Bitcoin and Ethereum:
- Read all withdrawal transactions on Bitcoin. Each withdrawal is encoded as two transactions: a commit transaction and a reveal transaction. This supplements the OP Stack and enhances our derivation pipeline.
- Read all transactions on Ethereum sent to BOB’s OptimismPortal contract. This is already part of the standard OP Stack derivation pipeline.
- Read all transactions executed directly on BOB and integrated as part of Ethereum batches. Crucially, full nodes do not read confirmed transactions directly from the sequencer but from Ethereum blobs. This is already part of the standard OP Stack derivation pipeline.
Technical Challenges
Data Consistency: While ensuring data consistency between Ethereum and Bitcoin chains is important, the mere existence of transaction data on both chains does not guarantee validity. Transactions must represent valid state transitions according to the rollup’s state transition function to be considered legitimate. This solution requires implementing validation logic inside the op-node (or another consensus layer implementation) to verify that transactions lead to valid state changes before acceptance.
Fraud Proofs and Validity: Both BitVM and Ethereum’s fraud proof systems need enhancements to handle data from two chains, potentially complicating dispute resolution. To address this, BOB must accurately account for possible transactions from both Bitcoin and Ethereum as part of BitVM bridge operations and BOB’s settlement on Ethereum.
Increased Storage: Additionally, BOB nodes in the network face increased storage and bandwidth requirements as they need to process and store data from both Bitcoin and Ethereum. However, this can be mitigated by requiring BOB transactions on Bitcoin to be included in Ethereum blobs and referencing the latest Bitcoin block. This way, nodes only need to sync recent Bitcoin blocks.
This public debut of the "forced withdrawal functionality" on BTC Layer2 led by BOB significantly advances the innovation of hybrid L2 models combining Bitcoin’s security with Ethereum’s innovation. On this specific issue of "forced withdrawals," BOB integrates Bitcoin’s censorship resistance with BOB’s rollup stack to achieve forced withdrawal functionality for BTC Layer2, thereby ensuring user asset safety in extreme scenarios.
About BOB (Build on Bitcoin)
BOB (Build on Bitcoin) is a hybrid Layer-2 network that combines the strengths of Bitcoin and Ethereum, aiming to establish itself as the "home of BTC DeFi." Its unique Hybrid L2 model merges the advantages of both ecosystems—Bitcoin’s security and dormant BTC capital, along with Ethereum’s DeFi innovation and versatility. By positioning BTC as the cornerstone of a new decentralized financial system, BOB unlocks novel use cases and trillions of dollars in BTC liquidity. BOB perfectly inherits Bitcoin network security via the BitVM protocol and creates trust-minimized bridges among BOB, Bitcoin, Ethereum, and other L1 networks. As such, Hybrid L2 does not rely on third-party cross-chain bridges for interoperability, effortlessly concentrating liquidity around the Bitcoin network instead of fragmenting it across multiple chains.
BOB is supported by leading investment firms including Castle Island Ventures, Coinbase Ventures, Ledger Cathay Ventures, and IOSG.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@build_on_bob
