Skip to main content

Integrating BTC Staking to Optimism L2 Chains

The following figure depicts the system architecture. The “→” arrow denotes data flow; for example, X→ Y means “Y queries data from X and the data flows from X to Y”.

The design involves the following main components:

Optimism L2 Integrations ArchitectureOptimism L2 Integrations Architecture;

  • Finality Provider: a daemon program that receives BTC stake and keeps submitting finality signatures over L2 blocks to the finality contract on Babylon.
    • It connects to a Babylon node to query its voting power.
    • It connects to the finality contract via the Babylon node for submitting finality signatures.
    • It connects to an RPC of the OP stack chain to get L2 block metadata.

Upon a new L2 block in the OP-stack chain, It:

  • Gets the L2 block metadata.
  • Queries Babylon Genesis to determine whether it has voting power at this L2 block height.
  • If yes, sign and submit a finality signature to the finality contract.
  • Finality contract: a CosmWasm smart contract that maintains all finality signatures submitted from OP-stack Finality Providers.
    • It will be deployed on Babylon Genesis.
    • It will query Babylon Genesis to determine the Finality Provider’s status and voting power.

Upon a finality signature, the finality contract verifies it and identifies equivocation:

  • If invalid, reject.
  • If valid and non-conflicting with any existing ones, accept.
  • If valid but conflicting with an existing finality signature, it emits an event so anyone can slash the Finality Provider and the BTC stake under it.
  • Finality gadget: a daemon program that keeps tallying all finality signatures for L2 blocks and serves RPC to allow querying the BTC-voting quorum of those blocks.
    • It connects to a Babylon node for querying the voting power of Finality Providers.
    • It connects to the finality contract via the Babylon node for querying finality signatures.
    • It connects to an RPC of the OP stack chain to get L2 block metadata.

Upon a new L2 block in the OP-stack chain, it:

  • Queries the finality contract to get all finality signatures over this L2 block.
  • Queries Babylon to get all Finality Providers’ BTC delegations for this chain and use the L2 block’s timestamp to determine the voting power distribution among all its Finality Providers at the time of this block.
  • Tallies finality signatures and determines whether the L2 block receives a quorum.
  • If this L2 block receives a quorum and its parent block is also BTC staking-finalized, marks it as BTC staking-finalized and stores it in the finality gadget’s local database.
  • OP node with finality gadget: a modified OP node that enforces BTC-voting quorum before finalizing L2 blocks.
    • It connects to the finality gadget for querying consecutive BTC-voting quorums to determine the finalization status of the L2 blocks.
    • It notifies OP-geth about the L2 blocks’ finalization status to move the L2 finalized block head.

Upon a new L2 block derived from L1 batch transactions, the OP node does the following:

  • Processes the block in its derivation pipeline and performs various validation checks.
  • Before the last step to mark the block finalized, it queries the finality gadget to check if the block is BTC staking-finalized.
  • If yes, marks this L2 block finalized and outputs it in the derivation pipeline.

Implementation​

We have finished the reference implementation. The codebases include:

  • babylon: Babylon node with BTC staking integration support to OP-stack
  • finality-provider: The Finality Provider program
  • btc-staker: The BTC Staker program
  • babylon-contract: The CosmWasm contracts, including the finality contract for OP-stack chains.
  • finality-gadget: The finality gadget program. It can be used by OP node or user as an SDK or run as a standalone daemon program.
  • optimism: The fork of OP Stack codebase that installs finality-gadget.

Local deployments​

We have developed local deployment scripts for the OP stack integration.