Rollback

Overview

This document outlines the procedures for executing a rollback sync on a Minitia upon detecting malicious activities. The rollback sync starts from the genesis block and proceeds up to the last finalized block before the occurrence of the malicious activity. This type of sync, distinct from standard procedures, employs block batches submitted via the Batcher fetched from Batch info on Layer 1.

Tutorial

Step 1: Change the Output Proposer (Output Submitter)

To ensure the integrity of submissions to Layer 1, a challenger can monitor the output submissions of the Layer 2 operator. Upon detection of any malicious activity, a proposal can be made through Layer 1 governance to elect a new output proposer.

// MsgUpdateProposer is a message to change a proposer
type MsgUpdateProposer struct {
	// authority is the address that controls the module (defaults to x/gov unless overwritten)
	// or the current proposer address.
	Authority   string `protobuf:"bytes,1,opt,name=authority,proto3" json:"authority,omitempty" yaml:"authority"`
	BridgeId    uint64 `protobuf:"varint,2,opt,name=bridge_id,json=bridgeId,proto3" json:"bridge_id,omitempty" yaml:"bridge_id"`
	NewProposer string `protobuf:"bytes,3,opt,name=new_proposer,json=newProposer,proto3" json:"new_proposer,omitempty" yaml:"new_proposer"`
}

Step 2: Register Executor Change Plan on L2

Once the proposal to change the output proposer is approved, the new Minitia operator will roll back the chain to the last finalized block before the malicious activity and initiate a new Minitia chain. The registration of the new executor at the specified target height plus one follows this action.

Getting Validator Address:

minitiad keys show $KEY_NAME --bech=val

Getting Consensus PubKey:

minitiad comet show-validator

// commonly in app/executor_change.go

func (app *MinitiaApp) RegisterExecutorChangePlans() error {
	err := app.OPChildKeeper.RegisterExecutorChangePlan(
		1,   // passed Layer 1 proposal ID
		361, // executor upgrade height
		"initvaloper158x0dpu5f4x703fhtseg5kpytsj02hw04qyw0t", // next validator (operator)
		"init158x0dpu5f4x703fhtseg5kpytsj02hw0p9ahpm",        // next executor
		"op2", // moniker
		"{\"@type\":\"/cosmos.crypto.ed25519.PubKey\",\"key\":\"GTJEksmVK7gkzPXdj+YIJxipfJ+yYUlc6jzIuh9s2t0=\"}", // consensus pubkey
		"", // info string (currently not used)
	)

	if err != nil {
		return err
	}

	return nil
}

Step 3: Set up Rollback Sync Config at config.toml

Configuration settings for rollback sync are defined in the $HOME/.minitia/config.toml file to facilitate proper synchronization parameters.

[rollupsync]
enable = {{ .RollupSync.Enable }}

# The bridge id of the rollup chain, which is registered in l1's bridge config.
bridge_id = {{ .RollupSync.BridgeID }}

# When we sync from the batch chain, we need to limit the fetch size to avoid
# overwhelming the node with a large number of batch data.
#
# Normally the batch submitter will split the batch into chunks of a certain size
# due to the limitation of the batch chain's block size.
#
# The maximum size of a batch chunk.
max_batch_chunk_bytes = {{ .RollupSync.MaxBatchChunkBytes }}
# The maximum number of batch chunks of a batch data.
max_batch_chunk_num = {{ .RollupSync.MaxBatchChunkNum }}

# The interval to fetch the batch data from the batch chain in milliseconds.
fetch_interval = {{ .RollupSync.FetchInterval }}

# The number of txs per page when fetching txs from the batch chain.
txs_per_page = {{ .RollupSync.TxsPerPage }}
# The number of blocks per page when fetching blocks from the l1 chain
# to search batch updates.
blocks_per_page = {{ .RollupSync.BlocksPerPage }}
# The range of batch chain heights to search batch data.
batch_chain_query_height_range = {{ .RollupSync.BatchChainQueryHeightRange }}

# The chain RPCs to fetch the batch data.
# You should provide l1 RPC info for rollup sync, event your batch chain is not l1.
#
# supported chains:
# - l1
# - celestia
rpc_servers = [
{{- range .RollupSync.RPCServers }}
  { chain="{{ .Chain }}", address="{{ .Address }}" },
{{- end }}
]

Step 4: Flush Blockchain Data & Start From Genesis

Finally, to implement the rollback, all existing blockchain data must be purged, and synchronization must begin anew from the genesis block.

minitiad comet unsafe-reset-all
minitiad start 

Conclusion

This procedure is crucial for maintaining the integrity and security of the blockchain infrastructure, particularly in scenarios where a Minitia operator's actions compromise the system's trust. By implementing a structured rollback sync process, the blockchain can recover from malicious activities effectively, ensuring continuity and security for all network participants.