Est-ce que l'application d'un plan de tri spécifique peut vraiment résoudre tous les problèmes ?

robot
Création du résumé en cours

Auteur: Pavel Paramonov Source: X, @paramonoww Traduction: Shanooba, Golden Finance

Beaucoup de gens pensent que "ASS est tout ce dont vous avez besoin", qu'il est une solution complète et qu'il n'a presque pas besoin d'être amélioré. Cependant, ASS ne peut pas résoudre tous les problèmes et il existe également certaines hypothèses de confiance.

1. Les dApp de sérialisation automatique sont une partie des constructeurs de blocs

Lorsqu'un bundle de transactions entre dans le Bloc, les dApp ont le droit d'extraire leur MEV (valeur extractible maximale) de celui-ci, en obtenant leur valeur des autres "membres" de la chaîne d'approvisionnement MEV tels que les proposants, les chercheurs et les constructeurs. Cependant, ce concept n'est pas parfait (rien dans le monde du chiffrement n'est parfait) et peut également comporter certaines hypothèses de confiance.

4y2I6dyw50Wob26kVMuyRqYGKio4tyZfa4Avqm5J.png

2. Jeu inclusif

Les défis auxquels sont confrontées les dApps de désérialisation automatique sont les suivants : plus la valeur liée est élevée, plus les exigences à inclure dans le bloc sont grandes. Si les transactions capturant le MEV ne sont pas incluses dans le bloc, elles peuvent devenir totalement non rentables, ce qui nuit non seulement aux autres transactions qui ne peuvent pas générer de MEV, mais aussi aux utilisateurs.

Voici un scénario de réflexion intéressant :

  • dApp est capable de capturer tous les MEV qu'elle génère
  • Mais si vous perdez non seulement la chance de MEV, mais aussi les utilisateurs qui apportent de la valeur à la plate-forme (par exemple, si AMM continue à échouer, qui l'utilisera encore), cela n'a aucun sens.

Le plus intéressant, c'est que le proposant a également besoin de réaliser des profits, créant ainsi une situation de double perte :

  • Les dApps de désérialisation automatique perdent la MEV car elles ne sont pas incluses dans le Bloc.
  • Les proposants perdent MEV parce qu'ils ne peuvent pas déballer et réorganiser les transactions atomiquement liées (bien qu'ils puissent choisir d'autres transactions)

3. Les applications décentralisées ASS ne devraient pas nuire aux utilisateurs ordinaires et aux fournisseurs de liquidité (LPs) en extrayant la MEV.

Il est bien connu que la MEV est principalement générée et extraite à partir de trafic malveillant. Les LPs perdent la plupart de leurs revenus provenant du trafic non informé en raison de la MEV. Attirer la Liquidité sur la plateforme est l'un des défis les plus difficiles dans le domaine du chiffrement, et les AMM devraient suivre une répartition équitable de la MEV pour les LPs, ce qui pourrait aider à réduire la Perte impermanente.

Dans la réalité actuelle, la gestion active des positions LP (même plusieurs positions LP) peut être considérée comme un travail à temps plein. En cas d'attaque sandwich, la valeur est restituée aux traders ; en cas d'arbitrage entre une plateforme d'échange centralisée et une plateforme d'échange décentralisée, la valeur est restituée aux LP. Alors, la question est combien de rendement ils devraient obtenir et combien de valeur le dApp devrait conserver ?

4. Que faire si la taille de la liaison est en conflit avec la taille du bloc de la chaîne sous-jacente ?

Il est évident que toutes les dApp ne se sérialisent pas automatiquement (du moins pas dans un avenir proche). La taille des blocs (ou des lots de transactions) est limitée ; sans restriction, il n'y aurait pas de chaîne de blocs ou de "blocchain". Supposons qu'un bloc puisse contenir au maximum 100 transactions, les situations suivantes pourraient se produire :

  • Le dApp a envoyé un ensemble de 100 transactions, remplissant tout le Bloc. Quel est l'espace de profit pour les autres "membres" de la chaîne d'approvisionnement MEV en l'incluant, en proposant le Bloc et en l'exécutant ?
  • Le dApp a envoyé un paquet contenant 99 transactions liées, il reste une place. Le proposant a-t-il suffisamment d'incitation pour inclure ce paquet? (À moins qu'ils ne coopèrent d'une manière ou d'une autre, comme une pré-confirmation)
  • Deux dApp ont envoyé des transactions groupées. Le premier groupe contient 60 transactions, le deuxième en contient 50. Apparemment, un seul groupe peut être inclus.

uQkGOPSiFFvNWFGafshKpV5TrjxUm8OLMcv3B7jp.png

L'accent est mis sur le fait que le premier bundle génère plus de MEV que le deuxième, mais d'un autre point de vue, l'inclusion du deuxième bundle est plus avantageuse car les 50 transactions non sérialisées d'autres dApps combinées au bundle peuvent créer plus de valeur pour le Bloc.

**Alors qui devrait être inclus? Qui est le plus rentable dans le Bloc, et pas seulement lié à l'intérieur?

La solution réalisable est FCFS (First Come First Served), mais cela ne garantit pas la précision car la latence persiste.

Comment s'assurer que la sérialisation est bénéfique pour tous et non pas seulement pour un participant, au détriment de la valeur des autres participants (LP, utilisateurs) ?

La solution potentielle consiste à définir des règles de sérialisation spécifiques, et seules les combinaisons respectant ces règles peuvent être autorisées. C'est très important car une sérialisation inappropriée peut entraîner des failles de sécurité.

Pour les paires de trading AMM, l'utilisation de règles de validation gourmandes permet de prévenir les attaques sandwich dans des pools AMM spécifiques. Cependant, la plupart des échanges DEX sont des échanges à plusieurs étapes, ce qui nécessite d'autres moyens pour garantir la résistance à l'exploitation de la valeur marginale (MEV).

Toujours au stade précoce !

Il existe actuellement plusieurs façons de sérialiser automatiquement, et je suis inspiré par l'approche de @SorellaLabs sur ce sujet. Nous en sommes encore aux premiers stades de la mise en œuvre de la sérialisation automatique (ou ASS, comme l'a dit @ballsyalchemist), et différentes infrastructures impliquent différents compromis.

73jFauRk5Nd5bDHdIIAbZFzziozxmWNLxzim84DR.png

L'objectif de ASS est de permettre aux dApp d'être responsables de leur sérialisation, sans se soucier de l'exécution (gérée par la chaîne). Bien que sur L1, ASS soit relativement clair, il est plus attrayant sur L2 car il suffit de gérer un sérialiseur et L2 peut apporter plus de contenu en mettant en œuvre des règles de sérialisation locales.

L'espace de hausse est énorme z! (À l'exception de l'espace Bloc)

Voir l'original
  • Récompense
  • 2
  • Partager
Commentaire
0/400
Aucun commentaire
Trader les cryptos partout et à tout moment
qrCode
Scan pour télécharger Gate.io app
Communauté
Français (Afrique)
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • ไทย
  • Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)