BOB has officially announced the "BitVM Forced Withdrawal Feature" on its official blog for the first time, marking a significant advancement in the specific functionality of "forced withdrawal" for BTC Layer2.
Summary:
Layer2 should have the same level of censorship resistance as the Layer1 public chain it is based on;
On BOB, users can already forcefully withdraw their assets from BOB to Ethereum through 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 transactions to BOB.
On February 4, 2025, the hybrid Layer2 project BOB announced the "BitVM Forced Withdrawal Feature" on its official blog for the first time, representing a substantial progress in the specific functionality of "forced withdrawal" for BTC Layer2, which is of primary significance to the Bitcoin ecosystem and the entire industry.
Vitalik has emphasized that whether users can smoothly withdraw assets from Layer2 to Layer1 is a very important security indicator. In emergencies, the "forced withdrawal" feature for Layer2 is as important as a "safety exit" in the real world. In the Ethereum Layer2 ecosystem, which holds billions of dollars in assets, the "forced withdrawal" feature that allows users to safely withdraw assets back to Layer1 has become an indispensable facility.
For Layer2 public chains using the EVM protocol, there are currently relatively complete forced withdrawal and escape pod features in the market to ensure that users can safely and timely withdraw their assets back to Layer1. Below, we can learn how BOB has achieved the forced withdrawal feature for BTC Layer2 through this Blog.
One of the core attributes of Layer2 is that even if the sequencer is offline, their state transitions need to continue. Layer2 achieves this by reading and writing its state from the data availability (DA) layer, which can be updated independently of Layer2 being online. Thus, even if the sequencer is offline or refuses to accept user transaction requests, users can still enforce their transactions. This is crucial because if the sequencer continuously rejects user transaction requests or experiences prolonged failures, it can lead to significant financial losses.
For example, during a Solana outage, some users were unable to timely replenish their positions due to asset liquidation risks, putting millions of dollars in assets at risk. Such scenarios of rejecting user requests can lead to considerable economic losses.
For BOB's BitVM bridge, an interesting question arises. BOB currently uses Ethereum EIP-4844 blobs as its DA layer. Users on Ethereum can easily bring their assets back to the Bitcoin network through the BitVM bridge; however, this process requires users to hold ETH on Ethereum for gas fees.
Therefore, the user experience is not friendly enough, as Bitcoin users only need BTC on the Bitcoin network to withdraw their BTC from BOB. BOB is exploring a hybrid solution: using Ethereum as the default DA layer while allowing users to forcefully include transactions on BOB through special transactions on Bitcoin.
Data Availability (DA) and Derivation Background
The derivation process is very important for Layer2 public chains: the entire Layer2 state of BOB needs to be constructed from L1 and the DA layer. It allows Layer2 to enjoy the same level of censorship resistance as the DA layer (in this case, Ethereum).
In simple terms, in rollups (especially for public chains using the OP Stack), we have two types of data on Layer1:
Deposit transactions made to the "OptimismPortal" contract. These are transactions made by users on Ethereum, usually depositing their assets into BOB. These deposit transactions can also be used to execute other transactions on BOB.
Batches submitted by the sequencer (or more accurately, the op-batcher) from Layer2 transaction processing. This includes all transactions directly made by users on BOB, which are ultimately included in the Ethereum blob.
Bitcoin as a DA Layer
If Bitcoin is to be used as a DA layer, why not fully switch to using Bitcoin as the DA layer? The main reason lies in cost. The available storage space on Bitcoin is very limited (about 4MB every 10 minutes), making storage costs high.
However, in this case, BOB can still use Ethereum as its "primary" DA layer to publish its entire transaction data, but if Ethereum DA becomes unavailable, Bitcoin can be added as a highly censorship-resistant backup layer. Essentially, Ethereum serves as the optimistic DA layer, while Bitcoin becomes an expensive but fault-tolerant last resort.
Hybrid Derivation Pipeline
The basic solution is to add Bitcoin to BOB as part of the derivation pipeline so that BOB (especially the "op-node") processes inputs in the following order:
Bitcoin forced withdrawal transactions (specifically added for BOB);
Ethereum deposits to BOB's OptimismPortal contract (OP Stack standard);
Ethereum batches from the op-batcher (OP Stack standard).
Here is a possible 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 needs three components to create a forced withdrawal transaction:
Construct the forced withdrawal transaction on Bitcoin.
Store the forced withdrawal transaction within Bitcoin's block size limit.
Handle the gas fees for the Bitcoin forced withdrawal transaction.
Construct the forced withdrawal transaction on Bitcoin
The OP Stack deposit transaction has the following structure:
bytes32 sourceHash: The source hash that uniquely identifies the origin of the deposit.
address from: The address of the sender's account.
address to: The address of the recipient's account; if the deposit transaction is a contract creation, this is an empty (zero-length) address.
uint256 mint: The ETH value minted on L2.
uint256 value: The ETH value sent to the recipient's account.
uint64 gas: The gas limit for the L2 transaction.
bool isSystemTx: If true, the transaction does not interact with the L2 block gas pool.
bytes data: The call data.
The forced withdrawal transaction needs to include the encoded withdrawal transaction in the data field of the deposit transaction. This is accomplished by creating a transaction on BOB that triggers the withdrawal from BOB to Bitcoin, and it works the same way as sending a transaction from Ethereum.
Then, we can store a (compressed) version of the forced withdrawal transaction on Bitcoin, which includes all the above data.
- Store the forced withdrawal transaction on Bitcoin
Since the data of the forced withdrawal transaction exceeds what is typically stored in the OP_RETURN output, BOB may use Taproot outputs to store the data.
While it is easy to identify deposit transactions on Ethereum (which may include withdrawals) because they are sent to BOB's OptimismPortal contract, identifying forced withdrawal transactions on Bitcoin is less straightforward.
Data serialization: The forced withdrawal transaction is serialized using a Taproot script within an "envelope" structure. These are no-ops on the Bitcoin network and can also be used for ordinal purposes, etc. We adjust the structure to meet our needs.
Unset
OPFALSE OPIF
OP_PUSH "bob"
OP_1
OP_PUSH "transaction"
OP_0
OPPUSH $WITHDRAWALTRANSACTION_DATA
OP_ENDIF
Two-phase commit/display scheme:
Similar to ordinals, users must submit two transactions to Bitcoin:
Commit transaction: Create a Taproot output that submits to a script containing the inscription content. This transaction does not yet reveal the data; we need a second transaction from BOB's full node and sequencer to include the withdrawal transaction.
Reveal transaction: Spend the output of the commit transaction, revealing the inscription on-chain, i.e., displaying the user's withdrawal transaction to be included in BOB.
- Handle the gas fees for the Bitcoin forced withdrawal transaction
Regarding the gas fee issue, BOB is currently considering two options:
Set the gas for Bitcoin forced withdrawal transactions to 0 and deduct the gas fees from the user's ETH balance on BOB. This way, only users with ETH on BOB can force withdrawals. However, this is not the optimal choice, as it requires users to have ETH on BOB to force withdrawals, meaning users who only have BTC on Bitcoin cannot force withdrawals.
Gas fees are paid by users in BTC on Bitcoin. The BOB network needs to have an address on Bitcoin that can receive BTC and effectively convert the BTC received by users into ETH on BOB to cover the gas costs for the Layer1 portion plus execution costs. This option could be implemented by using the BOB Gateway and setting the EVM address of BOB DAO as the BTC receiver.
Summary
Anyone can determine the status of BOB by simply looking at the data on Bitcoin and Ethereum:
- Read all withdrawal transactions on Bitcoin. Each withdrawal is encoded as two transactions, namely a commit transaction and a reveal transaction. This is our supplement to the OP Stack and where we enhance the derivation pipeline.
- Read all transactions to BOB's OptimismPortal contract on Ethereum. This is already part of the standard OP Stack derivation pipeline.
- Read all transactions directly conducted on BOB and integrate them as part of Ethereum batches. Importantly, full nodes do not read confirmed transactions directly from the sequencer but read from the Ethereum blob. This is already part of the standard OP Stack derivation pipeline.
Technical Challenges
Data Consistency: While ensuring data consistency between the Ethereum and Bitcoin chains is important, having only 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 verification logic within the op-node (or other consensus layer implementations) to first verify whether the transaction leads to a valid state change before accepting it.
Fraud Proofs and Validity: The fraud proof systems for BitVM and Ethereum need to be enhanced to handle data from both chains, which may complicate dispute resolution. To address this, BOB needs to accurately account for potential transactions from both Bitcoin and Ethereum as part of the BitVM bridge and BOB's settlement on Ethereum.
Increased Storage: Additionally, BOB nodes in the network face increased storage and bandwidth requirements as they need to handle and store data from both Bitcoin and Ethereum. However, we can mitigate this issue by requiring BOB transactions conducted on Bitcoin to be included in the Ethereum blob and reference the latest Bitcoin block. This way, nodes only need to sync the most recent Bitcoin blocks.
The debut of the "forced withdrawal feature" on BTC Layer2 led by BOB significantly advances the innovation of the hybrid L2 model that combines the security of Bitcoin with the innovation of Ethereum. In addressing the specific issue of "forced withdrawal," BOB integrates Bitcoin's censorship resistance with BOB's rollup stack, achieving the forced withdrawal functionality for BTC Layer2, thereby ensuring the safety of users' assets in extreme situations.
About BOB (Build on Bitcoin)
BOB (Build on Bitcoin) is a hybrid Layer-2 network that combines the advantages of Bitcoin and Ethereum, aiming to establish itself as the "home of BTC DeFi." The unique Hybrid L2 model merges the strengths of both ecosystems—Bitcoin's security and dormant BTC capital, along with Ethereum's DeFi innovation and versatility. By positioning BTC as a pillar of a new decentralized financial system, BOB can unlock new use cases and trillions of BTC liquidity. BOB perfectly inherits the security of the Bitcoin network through the BitVM protocol and creates trust-minimized bridges between BOB, Bitcoin, Ethereum, and other L1 networks. Therefore, the Hybrid L2 does not need to rely on third-party cross-chain bridges for interoperability, easily concentrating liquidity around the Bitcoin network rather than dispersing it across various chains.
BOB is supported by leading investment institutions such as Castle Island Ventures, Coinbase Ventures, Ledger Cathay Ventures, and IOSG.
Website | Twitter | Discord | Telegram
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
