Retroceder

Descripción general

Este documento describe los procedimientos para ejecutar una sincronización de reversión en un Minitia al detectar actividades maliciosas. La sincronización de reversión comienza desde el bloque de génesis y continúa hasta el último bloque finalizado antes de que ocurra la actividad maliciosa. Este tipo de sincronización, a diferencia de los procedimientos estándar, emplea lotes de bloques enviados a través del Batcher obtenidos de la información del lote en la Capa 1.

Tutorial

Paso 1: cambiar el proponente de resultados (remitente de resultados)

Para garantizar la integridad de los envíos a la Capa 1, un retador puede monitorear los envíos de salida del operador de la Capa 2. Tras la detección de cualquier actividad maliciosa, se puede realizar una propuesta a través de la gobernanza de Capa 1 para elegir un nuevo proponente de salida.

// 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"`
}

Paso 2: registrar el plan de cambio de ejecutor en L2

Una vez que se apruebe la propuesta para cambiar el proponente de salida, el nuevo operador de Minitia revertirá la cadena hasta el último bloque finalizado antes de la actividad maliciosa e iniciará una nueva cadena de Minitia. A esta acción le sigue el registro del nuevo ejecutor a la altura objetivo especificada más uno.

Obteniendo la dirección del validador:

minitiad keys show $KEY_NAME --bech=val

Obtención de PubKey de consenso:

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
}

Paso 3: configure la configuración de sincronización de reversión enconfig.toml

Los ajustes de configuración para la sincronización de reversión se definen en el $HOME/.minitia/config.tomlarchivo para facilitar los parámetros de sincronización adecuados.

[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 }}
]

Paso 4: Vacíe los datos de Blockchain y comience desde Génesis

Finalmente, para implementar la reversión, se deben eliminar todos los datos existentes de la cadena de bloques y la sincronización debe comenzar de nuevo desde el bloque génesis.

minitiad comet unsafe-reset-all
minitiad start 

Conclusión

Este procedimiento es crucial para mantener la integridad y seguridad de la infraestructura blockchain, particularmente en escenarios donde las acciones de un operador de Minitia comprometen la confianza del sistema. Al implementar un proceso estructurado de sincronización de reversión, la cadena de bloques puede recuperarse de actividades maliciosas de manera efectiva, garantizando la continuidad y seguridad de todos los participantes de la red.