Aller au contenu
Financial Context Wiki

Retrait forcé d'un L2

Guide par protocole sur l'inclusion forcée, le retrait forcé et l'issue de secours : garanties, dépendances et vérification du parcours de sortie.

Mis à jour

Contenu éducatif uniquement ; ce n’est pas un conseil financier ou de sécurité. Les mécanismes de sortie, délais, frais, pouvoirs des contrats et hypothèses de disponibilité des données varient selon le L2 et peuvent changer après une mise à niveau.

Réponse directe

Un retrait forcé d’un L2 est un parcours du protocole qui permet de commencer ou d’achever une sortie sans l’accord de l’opérateur L2. Le terme n’est pas normalisé. Dans certains systèmes, il désigne l’envoi direct d’une demande de retrait à un contrat L1 ; dans d’autres, la seule primitive offerte est l’inclusion forcée, qui garantit uniquement qu’une transaction issue de L1 entre dans la file d’exécution L2. Il faut ensuite suivre le retrait et la finalisation ordinaires du pont canonique.

Une issue de secours est un parcours d’urgence plus fort quand les mises à jour normales de l’état s’arrêtent. Elle peut geler l’application et permettre aux utilisateurs de prouver leur solde par rapport à une racine d’état engagée. Aucun mécanisme ne garantit une sortie immédiate, une valeur d’actif donnée ou l’absence de risque lié aux bogues et aux pouvoirs de gouvernance. La garantie effective vient du code déployé, de la configuration courante, des données d’état disponibles et de la capacité à construire et soumettre les transactions ou preuves requises.

Fonctionnement

  • Identifier la primitive. Inclusion forcée, retrait forcé et mode d’évacuation répondent à des problèmes différents. L’inclusion contourne un séquenceur qui censure ou qui est indisponible. Une demande de retrait oblige le protocole ou l’opérateur à traiter la sortie ou à prouver son invalidité. Le mode d’évacuation est souvent le dernier recours : les mises à jour normales cessent et les retraits utilisent des preuves d’état.
  • Entrer par L1. L’utilisateur envoie une transaction à l’inbox, au portail ou au contrat de règlement L1 indiqué par le protocole. Dans OP Stack, les dépôts L1 sont dérivés en blocs L2 durant la fenêtre de séquençage. Dans Arbitrum Nitro, un message entre dans la Delayed Inbox et peut être forcé dans l’inbox principale après le délai configuré si le séquenceur ne l’a pas inclus.
  • Attendre le traitement. La confirmation L1 n’est que le premier contrôle. La demande devra peut-être intégrer la chaîne L2 canonique, s’exécuter, apparaître dans un état prouvé ou confirmé, franchir un délai de contestation ou de grâce, puis être finalisée sur L1. Une transaction forcée peut encore échouer à cause d’un nonce erroné, d’un Gas insuffisant, de calldata incorrectes, de restrictions du token ou d’un état L2 modifié.
  • Satisfaire les conditions de sortie. StarkEx Spot illustre un véritable retrait forcé avec évacuation. L’utilisateur soumet fullWithdrawalRequest ; l’application doit satisfaire la demande ou prouver son invalidité. Si elle reste en attente après FREEZE_GRACE_PERIOD, un gel peut être demandé. L’évacuation exige un chemin de Merkle contre la racine du coffre gelé, la vérification de la preuve, un appel escape et l’appel on-chain normal withdraw.
  • Vérifier la disponibilité des données. Une racine d’état est un engagement, pas les soldes ou chemins de Merkle sous-jacents. Si les données nécessaires à la reconstruction sont publiées sur L1, un tiers indépendant peut en principe produire une preuve de sortie. Dans Validium ou d’autres modèles off-chain, l’utilisateur peut dépendre de la publication des données par un comité ou opérateur. Validité des preuves et disponibilité des données sont deux garanties distinctes.
  • Vérifier pouvoirs et outils. Examiner les pouvoirs de pause, gel, mise à niveau et gouvernance ; les adresses exactes et implémentations proxy ; les actifs pris en charge ; les clés ; le Gas L1 et L2 ; le logiciel de preuve ; et l’existence d’une interface indépendante. Un mécanisme correct en théorie peut être impraticable sans données, outils ou fonds suffisants sur L1.

Exemple

Supposons que le séquenceur et l’interface officielle d’un Rollup soient indisponibles, mais que L1 continue à finaliser. L’utilisateur vérifie d’abord l’identifiant de chaîne et les contrats L1 canoniques dans la documentation officielle. Si seule l’inclusion forcée existe, il envoie une transaction de L1 vers L2 qui appelle la fonction de retrait L2 du pont canonique. Il suit séparément l’envoi L1, l’inclusion forcée, l’exécution L2, l’engagement d’état, la phase de contestation ou de preuve et la finalisation L1. Un envoi L1 réussi ne prouve pas la réussite de l’appel de retrait.

Dans un système de type StarkEx, la séquence diffère : soumettre la demande forcée documentée, attendre le délai de grâce configuré, vérifier si elle a été satisfaite ou déclarée invalide, puis n’utiliser le gel et l’évacuation que si les conditions du contrat sont remplies. L’identifiant du coffre, la clé et le chemin de Merkle doivent correspondre à l’état gelé. Copier la procédure d’Arbitrum ou d’OP Stack serait une erreur, même si les trois sont parfois appelées « retraits forcés ».

Avant de dépendre d’un parcours, le répéter avec une petite somme lorsque le système fonctionne. Noter adresses, signatures de fonctions, événements attendus, minuteurs et hachages de transactions. Vérifier l’état avec un autre RPC ou explorateur fiable. Ne jamais saisir de phrase de récupération ou de clé privée sur un site de « retrait d’urgence », ni envoyer de paiement de « déblocage » à un compte d’assistance ou par message privé.

Risques

  • Le protocole offre l’inclusion forcée, mais pas de fonction directe de retrait forcé.
  • La demande L1 est confirmée, mais l’appel L2 a échoué ou n’est pas exécuté.
  • Un délai de contestation, preuve, grâce ou finalisation retarde l’accès aux fonds.
  • Les données d’état ou le chemin de Merkle manquent, surtout avec les données off-chain.
  • La mauvaise chaîne, le mauvais contrat, proxy, appel ou identifiant de coffre est utilisé.
  • Le contrat de sortie est en pause, mis à niveau, mal gelé ou touché par un bogue.
  • La gouvernance, un conseil de sécurité ou un autre acteur privilégié peut modifier la sortie.
  • L’actif n’est pas pris en charge, est non standard, illiquide ou soumis à des règles de marge.
  • Un pic de Gas L1 ou l’absence de Gas natif empêche l’envoi ou la finalisation.
  • Les interfaces, RPC, indexeurs ou outils de preuve sont indisponibles au besoin.
  • Une fausse interface, publicité ou assistance vole les identifiants ou les fonds.
  • La valeur peut baisser pendant l’attente ; la possibilité de sortir ne protège pas le prix.

Idées reçues

  • Le « retrait forcé » suit un parcours universel. Noms et garanties sont propres au protocole ; consulter les contrats et documents de la version déployée.
  • L’inclusion forcée renvoie immédiatement les fonds sur L1. Elle garantit surtout l’accès à l’ordonnancement ou à l’exécution ; le retrait du pont garde son propre cycle.
  • Un hachage L1 prouve la réussite de la sortie. Il prouve seulement l’inclusion L1 ; l’exécution L2 et la finalisation L1 se vérifient séparément.
  • Une preuve de validité garantit la disponibilité des données de sortie. Correction de la preuve et disponibilité sont distinctes ; les données off-chain ajoutent des dépendances.
  • Le parcours d’urgence est sans confiance puisqu’une fonction existe. Son usage dépend aussi des pouvoirs, de la configuration, des données, du logiciel, du Gas et des clés.
  • Une issue de secours élimine le risque financier. Elle traite une panne de disponibilité ou une censure, pas les risques de prix, liquidité, contrat ou compromission de clé.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...