tl;dr
- L2s should have the same censorship resistance as the L1s they are based on
- On BOB, users can already force withdraw their assets from BOB to Ethereum via an Ethereum transaction
- For its BitVM bridge, BOB is working on integrating Bitcoin as a way for users to enforce transactions on BOB
- Bitcoin users will be able to withdraw their BTC from BOB without having to send a transaction to BOB
One of the core properties of L2s is that their state needs to progress even when the sequencer is offline. L2s achieve this by reading and writing their state from a Data Availability (DA) layer that can be updated independently of the L2 being online. This way, users can force the inclusion of their transactions even when the sequencer is offline, or the sequencer does not accept their transactions directly.
For BOB's BitVM bridge, this poses an interesting problem. BOB currently uses Ethereum EIP-4844 blobs as its DA layer. Users on Ethereum can easily trigger withdrawals back to Bitcoin via the BitVM bridge. However, it requires users to have ETH on Ethereum.
This is not good enough for us: Bitcoin users should only need BTC on Bitcoin to force a withdrawal of their BTC from BOB back to Bitcoin. We are working on a hybrid solution: defaulting to Ethereum as DA while allowing users to force include transactions on BOB via a special transaction on Bitcoin. We are excited to share our work in progress in this blog post.
A Background on DA and Derivation
The process of derivation is quite important for L2s: the entire L2 state of BOB needs to be constructed from the L1 and the DA layer. It allows L2s to enjoy the same censorship resistance as the DA layer, in our case, Ethereum.
Simplified, in rollups (specifically OP Stack chains), we have two types of data on the L1:
- Deposit transactions made to the “OptimismPortal” contract. These are the transactions that are made by users on Ethereum typically to deposit their assets into BOB. These deposit transactions can also be used to execute other transactions on BOB.
- Batches submitted by the sequencer (or op-batcher to be more precise) from L2 transactions. These include all transactions made directly by users on BOB and are eventually included back to Ethereum blobs.
Bitcoin as DA Layer
If we want Bitcoin as a DA layer, why not fully switch to using Bitcoin completely as a DA layer? The answer is mostly cost. Bitcoin has very little storage available (about 4MB roughly every 10 minutes), and thus, storage cost is high.
However, in our case, BOB can still use Ethereum as its "main" DA layer where it posts its entire transaction data, but add Bitcoin as a highly censorship-resistant fallback layer if Ethereum DA is unavailable. Essentially, Ethereum becomes the optimistic DA layer while Bitcoin becomes the expensive but fault-tolerant last resort.
Hybrid Derivation Pipeline
The basic solution is to add Bitcoin to BOB as a part of the derivation pipeline, such that BOB (and specifically the “op-node”) processes inputs in this 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)
Let's jump into a possible solution to encode the Bitcoin-forced withdrawal transactions into the BOB derivation pipeline. Note that this is still being researched, so changes are possible.
Bitcoin Forced Withdrawal Transactions
We will need three parts to create a forced withdrawal transaction:
- Construct the forced withdrawal transaction on Bitcoin.
- Store the forced withdrawal transaction on Bitcoin within the size limits of Bitcoin.
- Handle gas costs for the forced withdrawal transaction on Bitcoin.
1. Construct the Forced Withdrawal Transaction
An OP stack deposit transaction has the following structure:
- bytes32 sourceHash: the source-hash, uniquely identifies the origin of the deposit.
- address from: The address of the sender account.
- address to: The address of the recipient account, or the null (zero-length) address if the deposited transaction is a contract creation.
- uint256 mint: The ETH value to mint on L2.
- uint256 value: The ETH value to send to the recipient 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 calldata.
A forced withdrawal transaction requires including the encoded withdrawal transaction in the data field of the deposit transaction. This is done by creating the transaction on BOB that triggers the withdrawal from BOB to Bitcoin and would work exactly the same as if the transaction was sent from Ethereum.
We can then store a (compressed) version of the forced withdrawal transaction on Bitcoin that includes all the above data.
2. Store the Forced Withdrawal Transaction on Bitcoin
As the data for the forced withdrawal transaction is larger than what typically should be stored in an OP_RETURN output, we will likely use a Taproot output to store the data.
While it's easy to identify a deposit transaction (that may include a withdrawal) on Ethereum due to it being sent to BOB's OptimismPortal contract, it's not as easy to identify a forced withdrawal transaction on Bitcoin.
Data Serialization: The forced withdrawal transaction is serialized using Taproot scripts within an "envelope" structure. These are noops on the Bitcoin network and are used, e.g., for Ordinals as well. We adjust the structure to fit 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:
As with Ordinals, users will have to submit two transactions to Bitcoin:
- Commit Transaction: Creates a Taproot output committing to the script containing the inscription content. This transaction does not yet reveal the data and we’ll need the second transaction for BOB full nodes and sequencers to include the withdrawal transaction.
- Reveal Transaction: Spends the output from the commit transaction, revealing the inscription on-chain, i.e., revealing the user’s withdrawal transaction for inclusion in BOB.
3. Handle Gas Costs for the Forced Withdrawal Transaction
This is the most open problem yet, with two options currently under consideration:
- Set gas to 0 for the forced withdrawal transaction on Bitcoin and deduct the gas costs from the user's ETH balance on BOB. That way, only users who have ETH on BOB can force withdrawals. However, this is not a good option as it would require users to have ETH on BOB to force withdrawals, i.e., users that have BTC on Bitcoin cannot force withdrawals.
- Gas is paid by users in BTC on Bitcoin. The BOB network would need to have an address on Bitcoin that can receive BTC and would effectively exchange the BTC received by the user to ETH on BOB to pay for the L1 part of the gas costs plus execution costs. This option is likely by using BOB Gateway and setting the BOB DAO's EVM address as the BTC recipient.
We are also experimenting with more ideas, so stay tuned for more updates!
Putting it all Together
Anyone can determine the state of BOB by only having to check the data on Bitcoin and Ethereum:
- Read all withdrawal transactions from Bitcoin. These are encoded as two transactions for each withdrawal, i.e., one commit and one reveal transaction. This is the addition we are making to the OP Stack and where we enhance the derivation pipeline.
- Read all transactions made to BOB’s OptimismPortal contract on Ethereum. This is already part of the standard OP Stack derivation pipeline.
- Read all transactions made directly on BOB and integrated as part of batches on Ethereum. Importantly, full nodes don’t read directly from the sequencer to receive confirmed transactions but they read 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 presence 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. The solution requires implementing validation logic inside op-node (or other consensus layer implementations) that first verifies if a transaction results in a valid state change before accepting it.
Fraud Proofs and Validity: The fraud proof system for both BitVM and Ethereum need to be enhanced to handle data from both chains, which could make dispute resolution more complex. To address this, we need to accurately account the possible transactions from Bitcoin and Ethereum as part of the BitVM bridge and BOB's settlement on Ethereum.
Storage Increase: Additionally, BOB nodes in the network face increased storage and bandwidth requirements since they need to process and store data from Bitcoin and Ethereum. However, we could mitigate this by requiring that BOB transactions made on Bitcoin need to be included in Ethereum blobs with a reference to the latest Bitcoin blocks. That way, nodes need only synchronize recent Bitcoin blocks.
Next Steps
We are excited to push the frontier of hybrid rollups combining Bitcoin’s security with Ethereum’s innovation. In this concrete problem, we are interested in having Bitcoin’s censorship resistance of transactions combined with BOB’s rollup stack. We will update this blog post with more information as we make progress.
