Ir para o conteúdo
Financial Context Wiki

O que fazer quando um sequenciador L2 fica fora do ar

Plano prático para indisponibilidade do sequenciador L2: verificar o incidente, evitar transações duplicadas, conferir a rota alternativa em L1 do rollup e considerar riscos de recuperação e liquidação.

Atualizado

Somente para fins educacionais; não constitui aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

Trate a indisponibilidade do sequenciador como perda do acesso normal à L2, não como prova de falha do rollup ou dos seus ativos. Interrompa ações urgentes, confirme o incidente na página oficial de status da rede e com dados independentes de RPC ou explorador, e identifique a rota alternativa exata em L1 daquele rollup antes de assinar qualquer coisa.

  1. Registre a rede, o endereço da carteira, os hashes pendentes, o último bloco observado e o horário da falha.
  2. Não reenvie repetidamente nem aumente taxas enquanto o estado da transação for desconhecido.
  3. Verifique se o unsafe head avança enquanto o safe ou finalized head está parado; isso pode indicar falha na publicação de lotes, não paralisação total.
  4. Use uma rota de transação forçada ou saque em L1 apenas com documentação oficial e endereços de contrato verificados.
  5. Após a recuperação, aguarde a normalização da fila, do oráculo, da ponte e do período de carência do aplicativo antes de aumentar alavancagem ou considerar uma transação final.

Como funciona

Normalmente, o sequenciador recebe, ordena e confirma rapidamente transações L2, depois publica na camada de disponibilidade de dados as informações necessárias para derivar a rede. Uma indisponibilidade pode impedir o envio RPC comum. Em outra falha, o sequenciador pode continuar produzindo blocos unsafe enquanto a publicação em L1 e, portanto, os heads safe e finalized param. Esses estados têm riscos distintos de reorganização e recuperação.

A alternativa depende da implementação. Em redes OP Stack, o usuário pode enviar uma transação L2 pelo OptimismPortal verificado da rede em L1; a janela padrão de sequenciamento é de 12 horas, mas pode variar. O Arbitrum Nitro usa uma Delayed Inbox em L1, e seu projeto publicado descreve inclusão forçada após um limite de 24 horas. Esses mecanismos garantem inclusão futura, não uma saída imediata ou universal, e ainda exigem Gas em L1 e os contratos corretos da rede.

Os aplicativos também precisam de controles próprios. Um feed de disponibilidade do sequenciador pode sinalizar a falha, mas é diferente de um feed de preço. Protocolos de empréstimos e derivativos podem pausar operações sensíveis durante a falha e impor um período de carência na recuperação, evitando que atualizações do oráculo e transações enfileiradas causem liquidações injustas imediatamente.

Exemplo

Um tomador mantém ETH como garantia em um protocolo de empréstimo L2. O sequenciador fica indisponível por 2 horas enquanto o ETH cai 15%, impedindo o reforço da garantia pelo RPC normal. O protocolo detecta a falha, pausa liquidações e mantém a pausa por um período configurado de 1 hora após o feed de disponibilidade informar a recuperação.

O tomador registra o hash pendente, confere o aviso oficial e o safe head do rollup e não confia em mensagem de suporte com link de “desbloqueio”. Se ainda precisar agir, segue a rota oficial em L1 e verifica o endereço do portal ou inbox. Após a recuperação, espera a transação forçada, o feed de preço e a saúde da conta aparecerem em um bloco safe antes de confiar no resultado.

Riscos

  • Liquidações na recuperação: transações e preços enfileirados podem ser processados quase juntos; sem carência, usuários impedidos de agir durante a falha podem ser liquidados imediatamente.
  • Reorganização do estado unsafe: um RPC pode mostrar blocos recentes ainda não publicados em L1, sujeitos a reorganização se a janela de publicação expirar.
  • Sinais desatualizados ou divergentes: um feed de preço em movimento não prova que usuários possam operar, e um feed de disponibilidade não prova que o preço esteja atual.
  • Risco de execução da rota forçada: chamadas diretas em L1 são mais técnicas e caras; rede, contrato, calldata, nonce ou limite de Gas errados podem falhar ou prender fundos.
  • Atrasos em sistemas dependentes: pontes, corretoras, keepers, indexadores e frontends podem se recuperar em ritmos diferentes mesmo após o retorno do sequenciador.

Equívocos comuns

  • “O sequenciador caiu, então os ativos sumiram.” O estado do rollup imposto por L1 pode permanecer íntegro mesmo sem acesso normal.
  • “Todo rollup tem o mesmo atraso de inclusão forçada.” Janelas, contratos e ações compatíveis variam conforme a implementação e configuração.
  • “Uma transação forçada executa imediatamente.” O envio em L1 cria uma rota para inclusão futura; não elimina atrasos de sequenciamento, prova ou saque.
  • “Quando os blocos voltam, acaba o risco de liquidação.” Filas, atualizações do oráculo e keepers podem tornar a recuperação a fase de maior risco.
  • “Um link de status enviado pelo suporte é seguro.” Verifique separadamente domínio e contrato; nunca revele frase-semente ou chave privada.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...