Saltar al contenido
Financial Context Wiki

Qué hacer cuando falla un secuenciador L2

Plan práctico ante la caída de un secuenciador L2: verificar el incidente, evitar transacciones duplicadas, comprobar la vía alternativa en L1 del rollup y contemplar los riesgos de recuperación y liquidación.

Actualizado

Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

Respuesta directa

Trata una caída del secuenciador como una pérdida del acceso normal a L2, no como prueba de que el rollup o tus activos hayan fallado. Detén las acciones sensibles al tiempo, verifica el incidente en la página oficial de estado de la cadena y con datos independientes de RPC o del explorador, y averigua la vía alternativa exacta en L1 de ese rollup antes de firmar nada.

  1. Registra la cadena, la dirección de la billetera, los hashes de transacciones pendientes, el último bloque observado y la hora del fallo.
  2. No vuelvas a enviar repetidamente ni aumentes las comisiones mientras se desconozca el estado de la transacción.
  3. Comprueba si el unsafe head avanza mientras el safe o finalized head está detenido; puede indicar un fallo de publicación de lotes y no una parada total.
  4. Usa una vía de transacción forzada o retiro en L1 solo desde documentación oficial y direcciones de contratos verificadas.
  5. Tras la recuperación, espera a que se normalicen la cola, el estado del oráculo, el estado del puente y el periodo de gracia propio de la aplicación antes de añadir apalancamiento o dar una transacción por final.

Cómo funciona

Un secuenciador suele recibir, ordenar y confirmar rápidamente transacciones L2, y después publica en la capa de disponibilidad de datos la información necesaria para derivar la cadena. Una caída puede impedir el envío por RPC ordinario. En otro tipo de fallo, el secuenciador puede seguir creando bloques unsafe mientras se detiene la publicación en L1 y, con ella, los heads safe y finalized. Estos estados tienen riesgos distintos de reorganización y recuperación.

La alternativa depende de la implementación. En cadenas OP Stack, un usuario puede enviar una transacción L2 mediante el OptimismPortal verificado de la cadena en L1; la ventana de secuenciación predeterminada es de 12 horas, pero puede variar según la cadena. Arbitrum Nitro usa una Delayed Inbox en L1, y su diseño publicado describe inclusión forzada tras un umbral de 24 horas. Estos mecanismos ofrecen inclusión eventual, no una salida instantánea o universal, y aún exigen Gas en L1 y los contratos correctos para la cadena.

Las aplicaciones también necesitan controles propios. Una fuente de disponibilidad del secuenciador puede señalar la caída, pero no es una fuente de precios. Los protocolos de préstamos y derivados pueden pausar operaciones sensibles durante el incidente e imponer un periodo de gracia al recuperarse para que las actualizaciones del oráculo y las transacciones en cola no causen liquidaciones injustas de inmediato.

Ejemplo

Un prestatario tiene ETH como garantía en un protocolo de préstamos L2. El secuenciador no está disponible durante 2 horas mientras ETH cae un 15%, por lo que no puede añadir garantía mediante el RPC normal. El protocolo detecta la caída, pausa las liquidaciones y las mantiene pausadas durante un periodo de gracia configurado de 1 hora después de que la fuente de disponibilidad informe de la recuperación.

El prestatario registra el hash pendiente, comprueba el aviso oficial y el safe head del rollup, y no confía en un mensaje de soporte que ofrece un enlace para «descongelar». Si aún debe actuar, sigue la vía oficial en L1 del rollup y verifica la dirección del portal o inbox. Tras la recuperación, espera a que la transacción forzada, la fuente de precios y la salud de la cuenta aparezcan en un bloque safe antes de confiar en el resultado.

Riesgos

  • Liquidaciones al recuperarse: las transacciones y actualizaciones de precios en cola pueden procesarse casi juntas; sin periodo de gracia, usuarios que no podían operar durante la caída pueden ser liquidados de inmediato.
  • Reorganización del estado unsafe: un RPC puede mostrar bloques recientes aún no publicados en L1 que podrían reorganizarse si vence la ventana de publicación.
  • Señales obsoletas o discordantes: que una fuente de precios avance no prueba que los usuarios puedan operar, y una fuente de disponibilidad no prueba que el precio sea actual.
  • Riesgo de ejecución de la vía forzada: las llamadas directas en L1 son más técnicas y caras; una red, contrato, calldata, nonce o límite de Gas incorrectos pueden fallar o inmovilizar fondos.
  • Retrasos en sistemas dependientes: puentes, bolsas, keepers, indexadores y frontends pueden recuperarse a ritmos distintos incluso tras volver el secuenciador.

Errores comunes

  • «El secuenciador está caído, así que los activos desaparecieron». El estado del rollup impuesto por L1 puede seguir intacto aunque el acceso normal no esté disponible.
  • «Todos los rollups tienen el mismo retraso de inclusión forzada». Las ventanas, contratos y acciones admitidas varían según implementación y configuración.
  • «Una transacción forzada se ejecuta al instante». El envío en L1 crea una ruta de inclusión eventual; no elimina los retrasos de secuenciación, prueba o retiro.
  • «Cuando vuelven los bloques, termina el riesgo de liquidación». Las colas, actualizaciones del oráculo y keepers pueden hacer que la recuperación sea la fase más arriesgada.
  • «Un enlace de estado enviado por soporte es seguro». Verifica por separado el dominio y el contrato; nunca reveles una frase semilla ni una clave privada.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...