Aller au contenu
Financial Context Wiki

Que faire lorsqu'un séquenceur L2 est en panne

Plan pratique face à une panne du séquenceur L2 : vérifier l'incident, éviter les transactions en double, contrôler la voie de secours L1 du rollup et anticiper les risques de reprise et de liquidation.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

Considérez une panne du séquenceur comme une perte de l’accès L2 normal, et non comme la preuve que le rollup ou vos actifs ont échoué. Suspendez les actions urgentes, vérifiez l’incident sur la page d’état officielle de la chaîne ainsi qu’avec des données RPC ou d’explorateur indépendantes, puis identifiez précisément la voie de secours L1 de ce rollup avant toute signature.

  1. Notez la chaîne, l’adresse du portefeuille, les hachages des transactions en attente, le dernier bloc observé et l’heure de la panne.
  2. Ne renvoyez pas plusieurs fois la transaction et n’augmentez pas les frais tant que son état est inconnu.
  3. Vérifiez si l’unsafe head avance tandis que le safe ou finalized head reste bloqué ; cela peut signaler une panne de publication des lots plutôt qu’un arrêt total.
  4. N’utilisez une voie de transaction forcée ou de retrait sur L1 qu’à partir de la documentation officielle et d’adresses de contrats vérifiées.
  5. Après la reprise, attendez la normalisation de la file d’attente, de l’oracle, du pont et du délai de grâce propre à l’application avant d’ajouter du levier ou de considérer une transaction comme finale.

Fonctionnement

Un séquenceur reçoit, ordonne et confirme normalement les transactions L2 rapidement, puis publie sur la couche de disponibilité des données les informations nécessaires pour dériver la chaîne. Une panne peut empêcher l’envoi RPC ordinaire. Lors d’une panne distincte de publication, le séquenceur peut continuer à produire des blocs unsafe tandis que la publication sur L1, et donc les heads safe et finalized, s’arrête. Ces situations présentent des risques de réorganisation et de reprise différents.

La voie de secours dépend de l’implémentation. Sur les chaînes OP Stack, un utilisateur peut envoyer une transaction L2 via l’OptimismPortal vérifié de la chaîne sur L1 ; la fenêtre de séquençage par défaut est de 12 heures, mais peut varier selon la chaîne. Arbitrum Nitro emploie une Delayed Inbox sur L1, et sa conception publiée décrit une inclusion forcée après un seuil de 24 heures. Ces mécanismes assurent une inclusion ultérieure, pas une sortie immédiate ou universelle, et exigent toujours du Gas sur L1 ainsi que les bons contrats propres à la chaîne.

Les applications ont aussi besoin de leurs propres contrôles. Un flux de disponibilité du séquenceur peut signaler une panne, mais il est distinct d’un flux de prix. Les protocoles de prêt et de dérivés peuvent suspendre les opérations sensibles pendant l’incident et imposer un délai de grâce à la reprise afin que les mises à jour de l’oracle et les transactions en attente ne provoquent pas immédiatement des liquidations injustes.

Exemple

Un emprunteur détient de l’ETH en garantie dans un protocole de prêt L2. Le séquenceur est indisponible pendant 2 heures alors que l’ETH baisse de 15%, empêchant l’emprunteur d’ajouter une garantie par le RPC normal. Le protocole détecte la panne, suspend les liquidations et les maintient suspendues pendant un délai de grâce configuré de 1 heure après que le flux de disponibilité signale la reprise.

L’emprunteur note le hachage en attente, vérifie l’avis officiel et le safe head du rollup, et ne fait pas confiance à un message d’assistance proposant un lien de « déblocage ». Si une action reste nécessaire, il suit la voie L1 officielle du rollup et vérifie l’adresse du portail ou de l’inbox. Après la reprise, il attend que la transaction forcée, le flux de prix et la santé du compte figurent dans un bloc safe avant de se fier au résultat.

Risques

  • Liquidations à la reprise : les transactions et mises à jour de prix en attente peuvent être traitées presque ensemble ; sans délai de grâce, les utilisateurs incapables d’agir pendant la panne peuvent être liquidés immédiatement.
  • Réorganisation de l’état unsafe : un RPC peut montrer des blocs récents non encore publiés sur L1, susceptibles d’être réorganisés si la fenêtre de publication expire.
  • Signaux obsolètes ou incohérents : un flux de prix actif ne prouve pas que les utilisateurs peuvent agir, et un flux de disponibilité ne prouve pas qu’un prix est actuel.
  • Risque d’exécution de la voie forcée : les appels directs sur L1 sont plus techniques et coûteux ; un réseau, contrat, calldata, nonce ou plafond de Gas erroné peut échouer ou bloquer des fonds.
  • Retards des systèmes dépendants : ponts, plateformes d’échange, keepers, indexeurs et interfaces peuvent reprendre à des rythmes différents même après le redémarrage du séquenceur.

Idées fausses courantes

  • « Le séquenceur est en panne, donc les actifs ont disparu. » L’état du rollup imposé par L1 peut rester intact même si l’accès normal est indisponible.
  • « Tous les rollups ont le même délai d’inclusion forcée. » Les fenêtres, contrats et actions prises en charge varient selon l’implémentation et la configuration.
  • « Une transaction forcée s’exécute immédiatement. » L’envoi sur L1 crée une voie vers l’inclusion ultérieure ; il ne supprime pas les délais de séquençage, de preuve ou de retrait.
  • « Dès que les blocs reprennent, le risque de liquidation disparaît. » Les files d’attente, mises à jour d’oracle et keepers peuvent rendre la reprise particulièrement risquée.
  • « Un lien de page d’état envoyé par l’assistance est sûr. » Vérifiez séparément le domaine et le contrat ; ne révélez jamais une phrase de récupération ou une clé privée.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...