[RFC] Babylon Finality Gadget For OP Stack

[bap2pecs]

Context

Babylon provides the Bitcoin staking protocol that allows Bitcoin holders to stake their BTCs natively on the Bitcoin chain to protect any PoS chains. The staking is trustless in the sense that the BTC resides in a self-custodian vault on the native Bitcoin network, without being bridged elsewhere. The litepaper and this thread provide more details.

OP-stack chains can benefit from the Babylon BTC staking protocol in the following aspects:

• Better economic security: There is native BTC staked to protect the rollup and improve its economic security. This is made more important for new OP-stack chains with fewer adoptions. In addition, the staked BTC achieves slashable safety, a strong security property that equivocations by L2 sequencers are held accountable and the BTC stake is slashable, even when equivocating L2 sequencers constitute a majority.
• Fast finality: The improved economic security will benefit the OP stack chains for fast finality. If the user is willing to trust the votes backed by the BTC stake, then the user can confirm transactions and make decisions without waiting for the lengthy challenging period in optimistic rollups.
• Reorg resistance of L2 transactions: Once a transaction is included in an L2 block signed by the majority of BTC-backed finality providers, the sequencer cannot publish a different L2 block at the same height on L1.

We are proposing this solution for all OP-stack chains, especially new ones that are still bootstrapping security, with slow batch submission interval and low trust. Imagine there is a new L2 that submits batches every 30 minutes. It’s very risky for the users to trust the sequencer and accept fast tx confirmation.

This blog post explained in detail how Bitcoin staking can be used to benefit rollups.

Design

How BTC staking works. In Babylon’s BTC staking protocol, finality providers (FP) are responsible for signing and submitting finality signatures over data that they want to finalize, e.g., L2 blocks. Stakers can delegate their native BTC to finality providers, such that finality providers will have voting power according to the amount of BTC delegated to them. Finality signatures are signed by using the extractable one-time signature (EOTS) algorithm. EOTS allows the signer to promise that he will only sign a single message under a certain context (i.e. block height related public randomness), otherwise, his private key can be extracted by anyone.

BTC staking for L2 blocks. The Babylon finality provider network will sign every L2 block. Each FP represents some amount of staked BTC thus having different voting power. Those signatures will be periodically sent to the Babylon Chain to verify. So instead of considering an L2 block finalized as soon as it can be derived from the currently finalized part of the L1 chain, the sequencer also needs to wait for the block’s EOTS signatures to be verified on the Babylon chain.

This requires changing the derivation logic to rely on some external data on the Babylon Chain. This also implies changes in the fault proof system to get the same data. All other parts of the system are external to OP Stack, to meet the modular and minimal design goals of the OP spec. The system in this proposal is deliberately designed as a finality gadget to work on any existing PoS systems.

How the system works:

• Alice sends an L2 tx and the sequencer includes it in the latest unsafe block.
• Each FP monitors the L2 network and signs this block using EOTS as soon as it’s created.
• Then the FPs submit the EOTS signatures to the Babylon Chain to be verified.
• Bob receives the unsafe block containing the tx from L2 RPC nodes. Then Bob queries the Babylon Chain to see whether the block has received votes of more than 2/3 voting power from the FP network. This happens very fast, likely in just a few seconds at most.
• When Bob sees the block receives enough voting power, knowing this unsafe block will eventually become finalized, Bob can accept the tx. Thus fast confirmation is achieved.
• Once the block is eventually sent to the L1 BatchInbox within a batch, the L2 nodes derivation pipeline will also query the Babylon chain to derive the L2 block and FCU (fork-choice update) the block.

In the diagram above, the red boxes represent OP-stack components and the yellow boxes represent Babylon components. The only changes we will make in the OP codebase are to let the derivation and fault proof depend on the data from the Babylon system. Thus, this finality gadget is minimally intrusive to the OP codebase.

Implementation

Per spec, an L2 block has three statuses:

• finalized: derived from the currently finalized part of the L1 chain
• safe: derived from the currently canonical L1 chain
• unsafe: not derived from L1

In our plan, we will change the finalized to be: derived from the currently finalized part of the L1 chain and the block is EOTS verified.

So we will fork the OP repo and add additional logic in the EngineQueue before marking a block as finalized:

• ask Babylon if the block at this height is finalized, skip if not
• if it’s finalized, get the block hash stored on Babylon and compare it with the local block hash
• finalize the block if the hash matches, otherwise skip

Draft implementation: babylonlabs-io/optimism#5

Fault proof will be modified at a later stage to incorporate similar checks. We will wait for the fault proof to be launched in mainnet and update the fault proof system later. Without the modification, our current change in the derivation pipeline will break the fault proof. op-program will be modified by then.

[bap2pecs]

I read about #221. thanks for sharing @tynes!

I am wondering how we can leverage it.

• in our current design, the FP network will EOTS sign every fresh unsafe block's hash. But the block hash is only calculated at the last step, i.e., EngineQueue. So such data isn't included in a batch, thus we cannot compare the hash to verify. This means we should find other data to EOTS sign, likely the entire batch data.
• does this also imply we will need to put the "verify EOTS" logic or at least relay the data from the Babylon chain onto the L1 so the smart contract batch inbox can call it?

[nlok5923]

Amazing RFC.

Does finality provider does some verification on blocks before signing EOTS signatures over the block ?

[bap2pecs]

great question. no it doesn't. but the system discourages sequencer from submitting invalid blocks to the FP network

imagine if the sequencer sends an invalid block to the FP network, those blocks will be signed. since the block is invalid, no valid batch can contain those blocks. and if a different block at the same height is included in a batch, it won't have EOTS signatures (because FPs won't sign two blocks at the same height) so the derivation pipeline will get stuck after a certain point (iiuc, there is a limit how many unsafe blocks can exist at max so it will not include any new more blocks until FCU)

thus the sequencer is enforced (sort of) to submit only valid and not forked blocks.

[nlok5923]

Got it, Make sense.

Thanks for explaining.

[threewebcode]

Is fast finality required for L2s ?

[bap2pecs]

no it's optional. it depends on what the L2 needs

[AmanRaj1608]

Hey @bap2pecs, had a doubt correct me if I am wrong.

If finality providers (FPs) sign blocks without validation, and the op stack sequencer is centralised, a malicious block could be included in a batch and posted on L1 (like Bitcoin) without fraud detection. In the absence of fraud proofs, this becomes a security risk.

However, adding fraud proofs would require to add a challenge period, which seems to defeat the purpose of fast finality?

[bap2pecs]

great question. FPs have limitations in that they cannot tell if a block is valid or not. It only prevents equivocation, to prevent double spend

if the sequencer broadcasts an invalid block N to the FPs, due to our changes in the derivations pipeline, the finalized head will stuck at block N because the consecutive quorum requirements.

Fault proof is a bit different b/c it only affect the output (i.e. state commitment). Fast finality is only about the input (i.e. the batches). So once a batch is posted and finalized on the L1, a canonical L2 is determined.

Challenger only challenges the output, which is the "view" of the L2 in the L1 contract.

[GrapeBaBa]

'if the sequencer broadcasts an invalid block N to the FPs, due to our changes in the derivations pipeline, the finalized head will stuck at block N because the consecutive quorum requirements.' I can't get this, FP signed the bloch without validation, wouldn’t they also sign illegal blocks, so illegal blocks also reach the majority?

[bap2pecs]

I can't get this, FP signed the bloch without validation, wouldn’t they also sign illegal blocks, so illegal blocks also reach the majority

FP cannot validate a block. so sequencer shouldn't sign illegal blocks in the first place. if the sequencer becomes adversarial, they will lose liveness of their own chain chain

[threewebcode]

This is OP side's design and implementation. By the way, where is the implementation of finality provider for OP ?

[bap2pecs]

https://github.com/babylonlabs-io/finality-provider