Optimistic Merged Mining

[nud3l]

Abstract

Add optimistic merged mining to the BOB OP stack rollup to allow Bitcoin miners to validate the rollup.

Goals

Plain OP stack depends only on Ethereum security for the rollup. With optimistic merged mining, we allow Bitcoin miners to verify the rollup sequencer and, in return, receive parts of the sequencer fees. This adds Bitcoin security to the roll-up, such that Bitcoin-centric apps (ordinals, BTC, BRC20, Runes, …) can offset the trust in Ethereum and the centralized sequencer.

Our goal is to make the changes for merged mining as non-invasive as possible to the OP stack with the long-term goal of being Superchain compatible. The pitch is: to add the ability to condition settlement of the OP rollup on another smart contract. This contract can implement a straightforward interface like allowSettlement() and return a boolean. We will use this for Bitcoin PoW security but other use cases (institutional, re-staking for rollup validation, offsetting centralized sequencer trust) could also be helpful.

How does it work?

• The OP proposer submits data to Ethereum as in other OP stack chains.
• Bitcoin miners take a range of block hashes from the BOB L2 and include a single hash of the BOB L2 into the Bitcoin block (as part of the coinbase transaction). Miners perform PoW until they find a Bitcoin block that matches the BOB L2 difficulty.
• Bitcoin miners submit the Bitcoin block with the BOB L2 hash to Ethereum when it meets the PoW difficulty of the BOB L2.
• A smart contract on Ethereum verifies that the submitted Bitcoin block with the BOB L2 hash reference meets the required difficulty and includes a valid BOB L2 hash.
• The next time the proposer submits the BOB L2 state to Ethereum:
  • In the current OP stack (pre-fault proof contract adjustments), the L2OutputOracle smart contract checks that the last confirmed BOB L2 block is not older than a specific timeout, e.g., Bitcoin miners need to verify/merge mine the BOB L2 every 4 hours.
    • If the last merged mined BOB L2 block was less than 4 hours ago, the proposer can submit the state.
    • If the last merged mined BOB L2 block was older than 4 hours, the proposer cannot submit the new state. This is a critical consensus failure that needs to be resolved.

Long-form of optimistic merged mining here: https://docs.gobob.xyz/docs/learn/bob-stack/merged-mining

Required Changes

We need to look into the fault-proof smart contract adjustments. In the current set of contracts, we’d change the L2OutputOracle contract to add a call to another smart contract in the proposeL2Output function that checks the presence of the PoW for BOB. The function interface would remain untouched.

We are going to write an additional component, e.g., op-merged-mining, that exposes RPC APIs for the miner. However, these are in parallel to the existing op-node, op-geth, op-proposer, and op-batcher. We don’t modify the existing components.

Use Cases

The primary use case is to add Bitcoin security to an OP stack rollup. We are launching BOB as a rollup with the OP stack, but we imagine that successful apps on BOB will eventually want to have their own block space environment, either as an L3 or an L2. Making the PoW checking compatible with the standard OP stack would thus be great.

We think that there are other possible use cases where an external validator could verify the correctness of the sequencer/L2.