feat: allow FG to be opt-in

[bap2pecs]

Summary

we have a killswitch (i.e. the enabled state) in the CW contract but it's a problematic b/c it depends on having the FG running. we should also allow op-node to control turning the gadget on and off

instead of introducing another config param, we can use the existing cfg.BabylonFinalityGadgetRpc and allow it to be empty string (i.e. "" means it's disabled)

we also discussed this in https://linear.app/snapchain/issue/SNA-505

this also solves the issue we found during deploying our devnet. When we register FP before the L2 chain is up, it cannot find the L2 RPC so throws error.

after this PR, we will always deploy the devnet first and later restart op-node with the BabylonFinalityGadgetRpc set. this is also closer to the real-world integration where the chain already exists before the integration

this also solves the circular dependency issue where we had when deploying our devnet (i.e. FG depends on L2, L2 depends on FG)

Test Plan

make lint-go
cd op-node
make test

will e2e test soon in our devnet

[lesterli]

should we first run the FP op e2e test with this commit and FP commit?

make test-e2e-op

[SebastianElvis]

Suggested change

	if fi.babylonFinalityClient == nil {
	if fi.EnableBTCStaking() {

and we can wrap this logic inside the EnableBTCStaking function

[SebastianElvis]

Also what will happen if an OP node enables BTC staking and run OP node for a while, shuts down OP node, and restarts OP node with BTC staking disabled? Given that this function tries to write finalised block to DB, would it be possible that the finaliser needs to iterate over more blocks after the restart?

This seems to be another reason of keeping BTC stake finalised in a separate KV store, in parallel with unsafe/safe/finalised states of blocks in OP stack

[bap2pecs]

what will happen if an OP node enables BTC staking and run OP node for a while, shuts down OP node, and restarts OP node with BTC staking disabled

in this case, once it's restarted, it will continue to operate normally (e.g. fetch L1 data, derive L2 blocks). when it tries to finalise a block, it will simply skip the BTC quorum check.

would it be possible that the finaliser needs to iterate over more blocks after the restart

what do you mean by itereating over more blocks? after the restart, it won't call the gRPC of FG. it will become a vanilla op-node

This seems to be another reason of keeping BTC stake finalised in a separate KV store, in parallel with unsafe/safe/finalised states of blocks in OP stack

this data is already stored in the FG KV db. op-node connects with it via gRPC

[bap2pecs]

and we can wrap this logic inside the EnableBTCStaking function

@SebastianElvis do you mean to create a helper function like this?

func (fi *Finalizer) BTCStakingEnabled() bool {
	return fi.babylonFinalityClient != nil
}

this doesn't seem very useful

[SebastianElvis]

what do you mean by itereating over more blocks? after the restart, it won't call the gRPC of FG. it will become a vanilla op-node

Let's say block h is finalised in OP stack term + BTC stake finalised, and h+1 to h+5 are finalised in OP stack term but haven't been BTC stake finalised. Then upon retsart with BTC staking disabled, Op node starts iterating from h+1 but not h+5. However it's supposed to start from h+5.

[bap2pecs]

got it. it's fine to re-derive from h1. although there will be some wasted rpc calls to L1, it doesn't require any changes in the codebase and such restart should be rare

[SebastianElvis]

yep. not blocking for now but wdyt about having some doc / TODO for this?

[bap2pecs]

there isn't any TODO here as the optimization has low ROI. (i.e. it requires intrusive changes for marginally gain)

i'd say not adding any comments to avoid confusion

[bap2pecs]

should we first run the FP op e2e test with this commit and FP commit?

make test-e2e-op

will just test in our devnet since the test is broken