Quelle est l’importance des fonctions de retrait forcé et de capsule d’évacuation pour la couche 2 ?

Auteur : Faust, Geek Web3

Dans le monde réel, presque tous les grands immeubles ont un ingrédient indispensable : une sortie de sécurité. En cas d’urgence comme les incendies et les tremblements de terre, les issues de secours sont une bouée de sauvetage pour assurer la sécurité de la vie des gens. Dans le système de plateforme de garde de couche 2 d’Ethereum, qui transporte des dizaines de milliards de dollars d’actifs, la fonction de « retrait forcé », qui permet aux utilisateurs de retirer des actifs en toute sécurité vers la couche 1, est devenue une installation indispensable et nécessaire.

Dans son récent article « Différents types de couche 2 », Vitalik a également souligné que la capacité des utilisateurs à retirer en douceur des actifs de la couche 2 à la couche 1 est un indicateur de sécurité très important.

Cependant, la question du « retrait en douceur » ne semble pas avoir reçu beaucoup d’attention de la part de la plupart des gens dans le passé, et même de nombreux projets de couche 2 n’ont pas lancé la fonction de « retrait forcé » ou de « capsule d’évasion ». À l’ère où l’écosystème L2 ne bat pas son plein, ignorer les « retraits sans autorisation » ne semble pas être un problème. Mais maintenant que Layer 2 a plus de 12 milliards de dollars d’actifs, c’est devenu un bâtiment « trop gros pour faire faillite ». Si un tel gratte-ciel n’a pas d’issue de secours, les conséquences sont tout simplement inimaginables.

Dans le but d’attirer l’attention des lecteurs sur les risques de sécurité de la couche 2, « Geek Web3 » prendra Loopring Protocol V3 et Arbitrum comme exemples ci-dessous pour expliquer pourquoi les « fonctions de retrait sans permission » telles que le tirage forcé et la trappe d’évacuation sont une partie indispensable de la couche 2.

(Selon le navigateur L2BEAT dYdX, la fonction de transaction/retrait forcé de dYdX a été utilisée 152 fois jusqu’à présent, et il y a eu 7 retraits importants de plus d’un million de dollars.)

La résistance à la censure est le gros problème : que faire si le séquenceur rejette délibérément votre demande ****

Dans le passé, les articles de vulgarisation scientifique sur la couche 2 avaient souvent un problème, c’est-à-dire que la plupart du temps, ils se concentraient sur la « sécurité » et la « facilité d’utilisation » en surface, mais ignoraient la « résistance à la censure ». Même lorsqu’il s’agit de solutions de séquenceur décentralisées, beaucoup de gens prêtent attention à la question de savoir si MEV est décentralisé, et non à la résistance à la censure.

En d’autres termes, la plupart des gens ont tendance à se concentrer sur la validité des transitions d’état de la couche 2, sur la possibilité pour le séquenceur de voler des pièces et sur l’utilisation du système de preuve de validité de la fraude/validité, mais ils ignorent un risque qui ne doit pas être négligé : que se passe-t-il si le séquenceur continue de rejeter vos demandes de transaction, ou échoue simplement pendant une longue période, ou même tombe en panne ? **

Vous savez, pendant la panne de Solana, il y avait des gens qui n’ont pas été en mesure de couvrir leurs positions à temps parce que leurs actifs étaient menacés de liquidation, mettant en péril des millions de dollars d’actifs. **Une fois qu’un tel rejet de la demande de l’utilisateur se produit, la perte économique causée n’est pas négligeable.

Même si seulement quelques personnes pouvaient être dans cette situation, si elle tombait sur une baleine avec beaucoup d’argent, l’ensemble du marché pourrait en souffrir (disons que quelqu’un a des centaines de millions de dollars d’actifs sur un protocole de prêt Defi sur Ethereum qui pourrait être liquidé en une semaine, mais qu’il est sur la liste des sanctions de l’OFAC pour avoir utilisé Tornado). La plupart des fonds de cette personne sont sur l’OP, et le séquenceur OP travaille avec l’OFAC pour rejeter sa demande)

Autant projeter ce problème sur des chaînes publiques comme avalanche ou polygon, qui sont indépendantes d’Ethereum. Si plus des 2/3 des nœuds de consensus des validateurs sur Avalanche décident de censurer vos transactions, ils peuvent refuser d’inclure votre Txn dans un bloc, ou ne pas reconnaître le bloc qui contient votre Txn. À l’heure actuelle, votre argent est essentiellement enterré dans cette chaîne et ne peut pas en sortir :**

À moins que vous ne puissiez coopter certains validateurs de manière à ce que moins des 2/3 des validateurs soient impliqués dans l’attaque de censure, ou que vous puissiez demander à certaines personnes de forker Avalanche par le biais d’un consensus social. Évidemment, à ce stade, vous avez encore un moyen de retirer rapidement des fonds d’Avalanche, et nous devons considérer que plus de 2/3 des validateurs unissent leurs forces pour initier une révision de transaction d’une certaine adresse, ce qui prend lui-même un certain temps à réaliser, ce qui laissera suffisamment de temps aux utilisateurs censurés pour « s’échapper ».

Mais sur la couche 2, la situation peut être très différente. Le séquenceur de couche 2 est généralement géré par l’officiel lui-même, et si le séquenceur veut lancer une attaque de censure contre vous, il peut « geler votre argent dans la couche 2 », c’est-à-dire rejeter complètement votre demande de transaction pour passer des actifs de L2 à L1. Évidemment, selon le mécanisme de fonctionnement de L2, si vous ne pouvez pas contourner le séquenceur pour effectuer une opération de retrait, il est tout à fait possible que le séquenceur gèle les actifs en L2 et ne puisse pas être transféré.

Alors comment résoudre ce genre de problème ? En fait, pour le dire crûment, comment mettre en œuvre la fonction de retrait « sans permission », afin que les utilisateurs puissent retirer leurs ressources vers la couche 1 sans aucun dommage lorsqu’elles sont examinées par les parties du projet Sequencer ou Layer 2 ? Il y a quelques projets qui ont proposé un séquenceur décentralisé, mais ce n’est pas une solution palliative, et si un nombre très limité de séquenceurs s’associent pour vous examiner, vous pouvez toujours « geler » vos actifs, et l’anti-sorcière des nœuds POS est également un problème délicat (voir Événements multichaînes).

Le moyen le plus efficace de le faire est de mettre en place une « sortie » directement sur la chaîne L1, permettant aux utilisateurs de retirer des fonds de L2 via une sortie dédiée sur L1 s’ils n’obtiennent pas de réponse de Sequencer pendant une longue période. **

Modèle de retrait forcé et de liquidation de faillite Loopring Protocol V3

Ici, nous prenons l’exemple de la version V3 du protocole Loopring, qui répertorie deux scénarios différents pour les retraits forcés initiés par l’utilisateur, le premier cas étant :

Les utilisateurs peuvent initier un retrait forcé directement sur la couche 1 via la fonction forcedWithdrawal dans le contrat ExchangeV3, et déclarer quel compte L2 ils ont dans le protocole Loopring et quel type de jeton ils souhaitent retirer. Après cela, le contrat ExchangeV3 lance un événement on-chain pour indiquer que quelqu’un a initié une demande de retrait forcé. Étant donné que tous les nœuds du protocole Loopring (y compris Sequencer) exécutent des clients Geth, on sait d’après le bloc Ethereum que quelqu’un a initié un retrait forcé et déclenché l’événement on-chain correspondant.

Il est important de noter que les retraits forcés ne sont pas traités immédiatement, mais sont placés dans la file d’attente pendingForcedWithdrawals et sont en attente. **Le séquenceur a remarqué qu’après que quelqu’un a initié un retrait forcé à la couche 1, la fonction Processus du contrat ExchangeV3 est déclenchée dans les 15 jours pour transférer le jeton à l’initiateur du retrait sur la chaîne Ethereum (à partir de l’adresse de dépôt de la partie du projet L2 sur la chaîne Ethereum pour transférer de l’argent au retrait).

Si Sequencer ne répond pas à la demande de retrait forcé de l’utilisateur dans les 15 jours, l’utilisateur peut appeler la fonction notifyForcedRequestTooOld pour que le contrat ExchangeV3 lève un événement appelé WithdrawalModeActivated pour informer l’intégralité du nœud du protocole Loopring que le mode de liquidation de faillite est activé. **

**Si le mode liquidation est activé, Loopring V3 cessera de recevoir de nouveaux blocs L2 soumis par Sequencer, ce qui signifie que l’ensemble du protocole Loopring cessera de fonctionner. Ce processus dure au moins 30 jours.

Cependant, dans le 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/statut d’actif, qui peut être vérifié sur l’arbre d’état L2. (Prouvez que le solde de vos actifs dans la couche 2 correspond au montant que vous avez déclaré lorsque vous avez initié le retrait)

Ce modèle de liquidation de faillite du protocole Loopring est également connu sous le nom de mécanisme Escape Hatch sur L2BEAT. Ce mode est déclenché si le séquenceur ne répond pas à la demande de retrait forcé de l’utilisateur dans le délai spécifié, ou si le séquenceur a une panne ou un temps d’arrêt à long terme. À ce stade, l’utilisateur peut déclencher manuellement le contrat de cumul en mode gel/arrêter l’exécution. Ensuite, les utilisateurs peuvent construire des preuves de merkle pour prouver leurs actifs sur la couche 2 et retirer leurs propres actifs de l’adresse de dépôt de la partie du projet L2 dans L1. **

Dans la documentation de StarkEx, un diagramme schématique dédié de ce processus est également dessiné. Si l’utilisateur L2 ne reçoit pas de réponse du séquenceur à la fin de la fenêtre de 7 jours lorsqu’il soumet une demande de retrait forcé sur L1, l’utilisateur L2 peut appeler la fonction de demande de gel pour que L2 entre dans la période de gel. Dans ce cas, le séquenceur L2 ne pourra pas mettre à jour l’état de L2 sur L1, et il faudra 1 an après le gel de l’état L2 pour être dégelé. Après cela, les utilisateurs peuvent soumettre une preuve Merkle et retirer de l’argent.

Cependant, pour construire une preuve de Merkle, vous devez d’abord connaître l’arborescence d’état L2 complète, c’est-à-dire que vous devez trouver un nœud complet L2 pour demander des données, et en même temps, vous avez besoin d’un morceau de code pour générer la preuve de Merkle, ce qui nécessite évidemment un certain seuil technique. Pour la commodité de la majorité des utilisateurs, L2BEAT a précédemment déclaré que la couche 2 devrait mettre en place un certain nombre de nœuds complets avec des autorisations ouvertes et un code source ouvert pour aider les utilisateurs à connaître l’état de tous les comptes sur L2 (y compris le solde, le nombre de transactions, etc.). Cette décision illustre également l’importance des retraits obligatoires et des mécanismes des capsules de sauvetage.

La fonctionnalité « Forced Include Transactions » d’Arbitrum

Mais les retraits forcés ne semblent pas être la seule solution résistante à la censure. Par exemple, Arbitrum utilise la méthode de « forcer l’inclusion des transactions », l’utilisateur peut d’abord soumettre le Txn/retrait qui doit être traité par le séquenceur dans le contrat de boîte de réception différé sur L1, et si le séquenceur ne l’a pas traité depuis plus de 24 heures, l’utilisateur peut appeler la fonction d’inclusion forcée du contrat de boîte de réception du séquenceur sur L1. Laissez Txn être inclus directement dans la séquence de transaction d’Arbitrum** (lancez un événement on-chain pour informer les nœuds complets d’Arbitrum que Txn avec quelques enregistrements de boîte de réception retardés doivent être inclus dans le registre L2).

En revanche, l’approche d’Arbitrum est plus simple, mais elle est encore un peu lacunaire : elle ne lance qu’un événement on-chain indiquant au nœud Arbitrum qu’il y a quelques transactions que le séquenceur ignore et qui doivent être incluses dans la chaîne la plus longue de L2, plutôt que de permettre aux utilisateurs de retirer de l’argent directement sur L1 comme le font Loopring Protocol et le mode faillite/capsule d’échappement de StarkEx. Si les nœuds challengers d’Arbitrum s’unissent pour lancer une attaque de censure, il semble qu’il serait toujours possible de geler l’argent des utilisateurs à L2. **

Ainsi, la force Inclusion d’Arbitrum n’est pas assez sans permission, et bien qu’il soit agréable de dire que le séquenceur a ignoré la demande forceInclusion d’un utilisateur tant qu’il y avait un nœud honnête prêt à poster une preuve de fraude, cela introduit toujours un certain degré d’hypothèse de confiance, bien que dans une moindre mesure.

Plus précisément, les « transactions qui doivent être obligatoirement incluses » doivent être reconnues par au moins un nœud challenger ARB, qui compte actuellement 9 nœuds qui ont le droit de décider quels messages inter-chaînes L2-L1 autoriser, et désormais eux seuls peuvent émettre des preuves de fraude. **Tant que ces 9 nœuds sont de connivence, théoriquement la « transaction forcée » de l’utilisateur peut toujours être invalidée. **

Par conséquent, l’inclusion obligatoire actuelle des transactions/retraits dans Arbitrum n’est pas comme le modèle de liquidation de faillite de Loopring et StarkEx qui ne nécessite pas l’autorisation du nœud L2. Cependant, L2BEAT a tout de même attribué une note élevée à Arbitrum pour cette solution. Parce qu’à l’avenir, Arbitrum lancera un mécanisme de libération à l’épreuve de la fraude sans permission appelé BOLD, et il sera difficile, voire impossible, pour les nœuds challengers de s’entendre à ce moment-là (il est en fait difficile de s’entendre maintenant).

Selon L2BEAT, la TVL actuelle est supérieure à 50 millions de dollars, et il n’y a pas de réponse à l’une des défaillances du séquenceur ou du proposant : **OP Mainnet, Base, zkSync Era, Mantle, Starknet, Linea, Polygon zkEVM, Metis. Ces L2 peuvent entraîner le gel des ressources utilisateur dans L2 dans des cas extrêmes. **

Alors évidemment, le modèle de retrait forcé ou de liquidation de faillite a sa nécessité, bien qu’à l’heure actuelle il ne repose que sur l’utilisateur-séquenceur comme jeu de contrepartie pour fonctionner, ** n’est pas vraiment « prêt à se retirer » ** (Arbitrum a un délai de 24 heures et peut échouer, Loopring a un délai maximum de 15 jours, StarkEx a un délai maximum de 7 jours), mais il est clair que « quelque chose vaut mieux que rien ». De plus, le problème des retards dans les retraits forcés est censé être résolu correctement à l’avenir avec une conception de mécanisme plus sophistiquée** (à l’heure actuelle, il est principalement dû au fait que certains scientifiques MEV peuvent utiliser forceInclusion pour initier des transactions en amont, il est donc nécessaire d’introduire des retards). Pour plus de détails, veuillez vous référer aux documents officiels des principales parties au projet L2).

Avec l’inclusion de Sequencer décentralisé dans de plus en plus de feuilles de route L2, et la Fondation Ethereum dirigée par Vitalik continue d’éduquer les gens sur la sécurité de la couche 2, les fonctionnalités de transaction résistantes à la censure, telles que les retraits forcés, feront l’objet d’une attention croissante, ce qui rapprochera le système de couche 2 d’Ethereum d’un système d’infrastructure financière résistant à la censure et sans confiance. Si la couche 2 met en œuvre un accès sans confiance aux fonds, on pense que davantage de teneurs de marché et de fournisseurs de liquidités entreront dans l’infrastructure L2, et que l’adoption massive de l’ensemble du web3 sera poussée encore plus loin.