Dans le monde réel, presque tous les gratte-ciel ont un élément indispensable : une sortie de secours. Lors d'événements imprévus tels que des incendies ou des tremblements de terre, ces sorties sont des sauveurs de vies pour la sécurité des personnes. De même, dans l'écosystème Ethereum Layer 2, qui détient des milliards de dollars d'actifs, la fonction de "retrait forcé" qui permet aux utilisateurs de rapatrier en toute sécurité les actifs vers la couche 1 est devenue une installation essentielle.

Vitalik a également souligné dans son article récent "Différents types de couches 2" que la capacité pour les utilisateurs de retirer facilement des actifs de la Couche 2 vers la Couche 1 est un indicateur de sécurité très important.

Cependant, la question des "retraits en douceur" semble avoir été négligée par la plupart des gens par le passé, et de nombreuses équipes de projet de Layer 2 n'ont pas mis en œuvre de fonctions de "retrait forcé" ou de "trappe de secours". À une époque où l'écosystème Layer 2 n'était pas encore mature, ignorer les "retraits sans permission" semblait être sans importance. Mais maintenant, avec Layer 2 gérant plus de 12 milliards de dollars d'actifs, c'est devenu un gratte-ciel "trop gros pour échouer". L'absence d'une sortie de sécurité dans un tel bâtiment imposant est inimaginable.

Dans le but de sensibiliser les lecteurs aux risques de sécurité de la couche 2, “Geek Web3” utilisera le protocole Loopring V3 et Arbitrum comme exemples dans le texte suivant pour expliquer pourquoi les “fonctions de retrait sans autorisation” telles que le retrait forcé et l'échappatoire sont des composants indispensables de la couche 2.

(Selon le navigateur L2BEAT dYdX, jusqu'à présent, la fonction de trading/ retrait forcé de dYdX a été utilisée un total de 152 fois, avec de gros retraits dépassant un million de dollars pour un total de 7 cas) La résistance à la censure est un gros problème : Et si le Séquenceur refusait délibérément votre demande ?

Les anciens articles populaires de vulgarisation scientifique sur la couche 2 avaient souvent un problème : ils mettaient surtout l'accent sur la « sécurité » et la « convivialité » superficielle, mais négligeaient la « résistance à la censure ». Même lorsqu'ils discutaient des solutions de séquenceurs décentralisés, ce que beaucoup de gens ont remarqué, c'est si le MEV est décentralisé, plutôt que les améliorations de la résistance à la censure.

En d'autres termes, la plupart des gens ont tendance à se concentrer sur l'efficacité des transitions d'état dans la couche 2, sur la possibilité que les séquenceurs puissent voler des pièces, et sur l'utilisation des preuves de fraude/systèmes de preuves de validité. Cependant, ils ignorent un risque qui ne devrait pas être négligé : et si le séquenceur refusait continuellement vos demandes de transaction, ou s'il dysfonctionnait simplement pendant une période prolongée, voire s'éteignait ?

Il convient de noter qu'au cours de l'arrêt de Solana, il y a eu des cas où les gens n'ont pas pu ajouter de garantie à temps en raison des risques de liquidation d'actifs, entraînant des millions de dollars d'actifs en danger. De tels scénarios de refus des demandes des utilisateurs peuvent entraîner des pertes économiques significatives.

Même si seules quelques personnes peuvent rencontrer de telles situations, si cela arrive à certains 'baleines' détenant de grosses sommes de fonds, l'ensemble du marché pourrait en souffrir. Par exemple, supposons que quelqu'un avec des centaines de millions de dollars d'actifs dans un protocole de prêt DeFi sur Ethereum soit confronté à une liquidation dans une semaine mais soit sanctionné par l'OFAC pour avoir utilisé Tornado. La plupart de leurs fonds sont sur Optimism (OP), et le séquenceur OP, conforme à l'OFAC, refuse leurs demandes.

Projetons ce problème sur des blockchains indépendantes comme Avalanche ou Polygon, séparées d'Ethereum. Si plus des deux tiers des nœuds de consensus des validateurs sur Avalanche décident d'effectuer un examen des transactions à votre encontre, ils peuvent refuser d'inclure vos transactions dans un bloc ou refuser la reconnaissance d'un bloc contenant vos transactions. Dans ce cas, vos fonds sont essentiellement bloqués dans cette chaîne et ne peuvent pas être retirés :

À moins que vous ne puissiez convaincre certains validateurs pour que moins des deux tiers participent à l'attaque de contrôle, ou que vous puissiez rallier les gens pour forker Avalanche par consensus social. De toute évidence, à ce stade, vous avez encore des moyens de retirer rapidement vos fonds d'Avalanche. Cependant, nous devons considérer qu'il faut du temps pour que plus des deux tiers des validateurs s'unissent et lancent un contrôle de transaction contre une adresse spécifique, offrant à l'utilisateur contrôlé suffisamment de temps pour 's'échapper'.

Mais la situation pourrait être tout à fait différente sur la couche 2. Les séquenceurs sur la couche 2 sont généralement gérés par l'équipe officielle. Si un séquenceur souhaite lancer une attaque de vérification contre vous, il peut « geler votre argent sur la couche 2 », refusant ainsi efficacement vos demandes de transfert d'actifs de L2 à L1. Selon le mécanisme opérationnel de L2, si vous ne pouvez contourner le séquenceur pour exécuter un retrait, il est tout à fait possible que le séquenceur gèle vos actifs sur L2, empêchant leur transfert.

Alors, comment résoudre ce problème? En d'autres termes, comment mettre en œuvre une fonction de retrait 'sans permission' qui permet aux utilisateurs de récupérer en toute sécurité leurs actifs vers la couche 1 même sous la surveillance d'un Séquenceur ou d'une équipe de projet de la couche 2? Certaines équipes de projet ont proposé l'idée de Séquenceurs décentralisés, mais il s'agit d'une solution superficielle. Si ces Séquenceurs en nombre limité se mettent d'accord pour vous surveiller, ils peuvent quand même 'geler' vos actifs. De plus, le problème des attaques anti-Sybil dans les nœuds de Preuve d'Enjeu (PoS) est également problématique (comme on l'a vu dans l'incident de Multichain).

La solution la plus efficace consiste à mettre en place une 'sortie' dédiée sur la blockchain de Layer 1, permettant aux utilisateurs de retirer leurs fonds de Layer 2 via cette sortie L1 dans les cas où ils ne reçoivent pas de réponse du Séquenceur sur une période prolongée.

Dans le contexte de la version 3 du protocole Loopring, il décrit deux scénarios différents pour les retraits forcés initiés par l'utilisateur. Le premier scénario est le suivant :

Les utilisateurs peuvent initier directement un retrait forcé sur Layer 1 en utilisant la fonction forcedWithdraw dans le contrat ExchangeV3. Ils doivent déclarer quel est leur compte Layer 2 dans le protocole Loopring et quel Token ils souhaitent retirer. Ensuite, le contrat ExchangeV3 émet un événement blockchain, signalant que quelqu'un a initié une demande de retrait forcé. Comme tous les nœuds dans le protocole Loopring, y compris le Séquenceur, exécutent le client Geth, ils seront informés du retrait forcé et de l'événement blockchain correspondant à partir des données de bloc Ethereum.

Il est important de noter qu'un retrait forcé n'est pas traité immédiatement, mais est plutôt placé dans la file d'attente des retraits forcés en attente de traitement. Lorsqu'un retrait forcé est initié sur la couche 1, le Séquenceur déclenche généralement la fonction Process dans le contrat ExchangeV3 dans les 15 jours. Cette fonction exécute le transfert des jetons sur la chaîne Ethereum vers l'initiateur du retrait (de l'adresse de dépôt du projet Layer 2 sur la chaîne Ethereum au retraitant).

Si le Séquenceur ne répond pas à la demande de retrait forcé de l'utilisateur dans les 15 jours, l'utilisateur peut appeler la fonction notifyForcedRequestTooOld. Cette action incite le contrat ExchangeV3 à émettre un événement nommé WithdrawalModeActivated, informant tous les nœuds du protocole Loopring que le mode de liquidation de faillite a été activé.

Si le mode de liquidation de faillite est activé, le protocole Loopring V3 cessera de recevoir de nouveaux blocs L2 soumis par le séquenceur, ce qui signifie que l'ensemble du protocole Loopring cessera de fonctionner à ce moment. Ce processus durera au moins 30 jours.

Cependant, en mode de liquidation de faillite, les utilisateurs peuvent toujours retirer leurs actifs sur la couche 1, mais ils doivent soumettre une preuve de Merkle pour prouver leur statut d'actif, qui peut être vérifié sur l'arbre d'état L2. (Prouver que votre solde d'actifs en couche 2 est cohérent avec le montant déclaré lorsque vous avez initié le retrait.)

L'article décrit le modèle de liquidation de la faillite du protocole Loopring, également connu sous le nom de mécanisme de "Passerelle de secours" sur L2BEAT. Ce modèle est déclenché dans certaines conditions, telles que lorsque le séquenceur ne répond pas à une demande de retrait forcée d'un utilisateur dans un délai spécifié, ou si le séquenceur rencontre un dysfonctionnement ou une interruption à long terme. Dans de tels cas, les utilisateurs peuvent déclencher manuellement un processus qui place le contrat Rollup dans un état gelé ou arrêté. Les utilisateurs peuvent ensuite construire une preuve de Merkle pour démontrer leur situation d'actif sur la couche 2 et retirer leur partie d'actifs de l'adresse de dépôt du projet de couche 2 sur la couche 1.

Dans la documentation StarkEx, il y a un diagramme spécifique illustrant ce processus. Si une demande de retrait forcé d'un utilisateur de la couche 2 soumise sur la couche 1 n'est pas répondue par le séquenceur dans une fenêtre de 7 jours, l'utilisateur peut invoquer la fonction de demande de gel pour initier une période de gel pour la couche 2. Pendant cette période, le séquenceur de la couche 2 ne peut pas mettre à jour l'état de la couche 2 sur la couche 1. L'état gelé de la couche 2 dure un an avant de pouvoir être dégelé. Ensuite, les utilisateurs peuvent soumettre une preuve de Merkle et retirer leurs fonds.

Mais pour construire une preuve de Merkle, il est nécessaire d'abord d'obtenir l'arbre d'état complet L2, ce qui signifie acquérir des données à partir d'un nœud complet L2. De plus, un morceau de code spécifique est nécessaire pour générer la preuve de Merkle, présentant clairement un certain niveau de barrière technique. Pour faciliter cela pour la majorité des utilisateurs, L2BEAT avait précédemment déclaré que la couche 2 devrait mettre en place un lot de nœuds complets à accès ouvert et open-source, pour aider les utilisateurs à acquérir le statut de tous les comptes sur L2 (y compris le solde, le nombre de transactions, etc.). Cette démarche souligne également l'importance des mécanismes de retrait forcé et d'évasion.

La fonction 'Inclusion de transaction forcée' d'Arbitrum

Cependant, les retraits forcés/pods de secours ne semblent pas être la seule solution anti-censure. Par exemple, Arbitrum utilise une méthode d'« inclusion forcée des transactions », où les utilisateurs peuvent d'abord soumettre les transactions/retraits qui doivent être traités par le Séquenceur au contrat de Boîte de réception retardée sur la Couche 1 (L1). Si le Séquenceur ne parvient pas à les traiter dans les 24 heures, les utilisateurs peuvent appeler la fonction d'inclusion forcée sur le contrat de Boîte de réception du Séquenceur L1, permettant à la transaction d'être directement incluse dans la séquence de transactions d'Arbitrum (en déclenchant un événement on-chain informant les nœuds Arbitrum que plusieurs transactions enregistrées dans la Boîte de réception retardée doivent être incluses dans le grand livre L2).

Le passage traite des approches des différents protocoles blockchain dans le traitement des transactions, en mettant particulièrement l'accent sur Arbitrum par rapport à Loopring et StarkEx. Voici la traduction :

"Comparé aux autres, la méthode d'Arbitrum est quelque peu plus simple, mais elle a encore des défauts. Il se contente d'émettre un événement on-chain pour informer les nœuds Arbitrum que plusieurs transactions ignorées par le séquenceur doivent être incluses dans la chaîne la plus longue de L2, contrairement au protocole Loopring et au mode de faillite/pod d'évasion de StarkEx, qui permettent aux utilisateurs de retirer directement leurs fonds sur L1. Si les nœuds contestataires d'Arbitrum collaborent pour lancer une attaque de censure, il semble possible de geler les fonds des utilisateurs sur L2."

Par conséquent, le mécanisme d'inclusion forcée d'Arbitrum n'est pas entièrement sans permission. Bien qu'un seul nœud honnête puisse publier une preuve de fraude pour signaler une demande d'inclusion forcée ignorée par l'ordonnanceur, cela introduit toujours un degré d'hypothèse de confiance, même mineur.

Plus précisément, les 'transactions nécessitant une inclusion forcée' doivent être reconnues par au moins un nœud challenger ARB. Actuellement, il y a neuf de ces nœuds, et ils ont l'autorité pour décider quelles messages entre L2 et L1 approuver, et ils sont également les seuls à pouvoir émettre des preuves de fraude. Si ces neuf nœuds complotent ensemble, ils pourraient théoriquement invalider une 'transaction forcée' d'un utilisateur.

Par conséquent, les transactions d'inclusion ou de retrait de force actuelles dans Arbitrum ne sont pas aussi sans permission que le mode de liquidation de faillite de Loopring et StarkEx. Cependant, L2BEAT note toujours vivement cette approche d'Arbitrum. À l'avenir, Arbitrum lancera un mécanisme de publication de preuve de fraude sans permission appelé BOLD, ce qui rendra difficile, voire impossible, la collusion des nœuds challengers (ce qui est déjà difficile maintenant).

Selon les données de L2BEAT, actuellement, les plateformes de couche 2 (L2) dont la valeur totale verrouillée (TVL) dépasse 50 millions USD, et qui n'offrent pas de mesures pour résoudre les pannes de séquenceur ou de proposant, comprennent OP Mainnet, Base, zkSync Era, Mantle, Starknet, Linea, Polygon zkEVM et Metis. Ces plateformes L2 pourraient, dans des cas extrêmes, entraîner le gel des actifs des utilisateurs et les rendre impossibles à retirer de la L2.

Il est donc évident que la nécessité de mécanismes tels que les retraits forcés ou les modes de liquidation en cas d'insolvabilité existe. Bien qu'actuellement, ils reposent principalement sur la théorie des jeux entre les utilisateurs et les trieuses (producteurs d'ordres), et ne peuvent pas être considérés comme vraiment "retirables à tout moment" (Arbitrum a un délai de 24 heures qui pourrait échouer, Loopring a un délai allant jusqu'à 15 jours, StarkEx a un délai maximum de 7 jours), avoir ces mécanismes est manifestement préférable à ne pas les avoir du tout. La question du retard dans les retraits forcés pourrait potentiellement être résolue à l'avenir avec des conceptions de mécanisme plus sophistiquées. Les conceptions actuelles prennent en compte l'exploitation potentielle de la valeur extractible maximale (MEV) à travers forceInclusion, nécessitant l'introduction de retards. Pour plus de détails, la documentation officielle de divers projets L2 devrait être consultée.

Avec l'inclusion croissante des séquenceurs décentralisés dans de nombreux roadmaps de la couche 2 et les efforts continus des entités comme la Fondation Ethereum, dirigée par Vitalik Buterin, pour sensibiliser les gens à la sécurité de la couche 2, des fonctionnalités telles que les fonctions de transaction anti-censure dans les retraits forcés gagneront probablement plus d'attention. Cela rapprochera l'écosystème de la couche 2 d'Ethereum d'une infrastructure financière résistante à la censure et minimisant la confiance. Si la couche 2 parvient à un moyen minimisant la confiance de déplacer des fonds à l'intérieur et à l'extérieur, il est prévu que davantage de teneurs de marché et de fournisseurs de liquidité entreront dans l'infrastructure de la couche 2, faisant ainsi un pas de plus vers l'adoption massive du web3.

Disclaimer：

1. Cet article est repris de [ Faust, Web3 geek]. Tous les droits d'auteur appartiennent à l'auteur original [Faust, Web3 geek]. Si des objections sont formulées à cette réimpression, veuillez contacter le Porte Apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont réalisées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.