État actuel et futur du MEV sur le réseau Sui : équilibre entre protection des utilisateurs, transparence et répartition de la valeur

État actuel et perspectives d'avenir du MEV sur le réseau Sui

La valeur extractible maximale MEV( est devenue un sujet important dans l'industrie de la blockchain, car elle est étroitement liée au tri des transactions et aux opportunités d'arbitrage. Afin d'assurer la transparence, de protéger les transactions des utilisateurs, de maintenir la santé du réseau et de récompenser les participants, le réseau Sui a continuellement mis en œuvre des propositions d'amélioration ciblées et d'autres mécanismes pour réglementer les activités MEV sur le réseau.

En plus des mécanismes existants, Sui prévoit également d'établir d'autres mécanismes pour garantir que ses principes fondamentaux puissent guider l'évolution du MEV sur le réseau.

![Comprendre la situation et l'avenir du MEV sur Sui en un seul article])https://img-cdn.gateio.im/webp-social/moments-75b9ec7f9e0935e241986e4bd6723347.webp(

Principes et considérations de conception

Chaque transaction sur le réseau Sui génère de nouvelles informations, créant ainsi des opportunités d'arbitrage potentielles. L'écosystème MEV sur Sui se forme par plusieurs mécanismes suivants:

  • Mécanisme de soumission des transactions MEV
  • Mécanisme de publication des opportunités MEV
  • Mécanisme de distribution des revenus MEV
  • Mécanisme de protection des transactions des utilisateurs

Les priorités globales de Sui sont les suivantes :

  • Protéger les transactions des utilisateurs est plus important que le montant de la valeur extraite. Prioriser les petits slippages plutôt que les grandes valeurs extraites. Éviter les enchères hors protocole qui augmentent les délais et n'ont pas d'option de sortie.
  • La transparence du réseau est supérieure aux transactions privées avec des nœuds de validation ou des relais.
  • Favoriser la concurrence par le biais d'enchères de gas prioritaires )PGA( pour réprimer les comportements indésirables qui conduisent à l'inefficacité du système : idéalement, la stratégie optimale pour les chercheurs est d'envoyer une transaction dont le coût prioritaire est déterminé par la valeur récupérable.
  • Encourager la distribution des récompenses aux participants alignés avec les intérêts de l'écosystème : nœuds de validation, stakers, applications et utilisateurs.

Soumission de la transaction

En raison de l'exécution séquentielle des transactions modifiant le même objet, les clients vont rivaliser pour augmenter leurs chances d'exécution. D'un point de vue systémique, le PGA est un moyen efficace d'allocation des ressources, permettant de prévenir les transactions indésirables tout en redistribuant les frais de gas entre les participants.

Le facteur clé de la vente aux enchères de gaz prioritaire est l'exécution quantitative :

  • Les transactions triées par consensus sont traitées dans le bloc. Les commerçants rivalisent pour l'ordre de priorité par le biais d'enchères de gaz, pouvant à la fois rivaliser en interne lors de la soumission et entre différentes soumissions.
  • Cela diffère des teneurs de marché des échanges centralisés, où la priorité d'exécution dépend entièrement de la vitesse, réalisée par un réseau à faible latence et des algorithmes.
  • Un taux de soumission de consensus plus élevé a réduit l'effet de quantification, rendant l'exécution des transactions décentralisées plus efficace, mais a également réduit la fenêtre PGA.
  • Actuellement, le PGA des objets non congestionnés est le plus important pour les chercheurs les plus rapides. À un taux de Sui de 15 soumissions par seconde, un avantage de vitesse de soumission de transaction de 70 millisecondes pourrait décider si la transaction peut être réalisée.
  • Les objets de congestion peuvent retarder l'exécution des transactions, ce qui amplifie davantage l'importance du PGA, car la fenêtre des transactions concurrentes peut être dix fois celle des soumissions de consensus régulières.

Il existe deux mécanismes pour diriger les transactions vers des soumissions Sui spécifiques à venir :

  1. Soumettre un lot de transactions par le biais d'un soft bundling : SIP-19
  • Les transactions soumises par un soft bundle ont une forte probabilité d'être incluses dans le même consensus que le bundle valide. La condition de validité du bundle exige que le prix du gaz de toutes les transactions soit identique.
  • Dans la pratique, ce mécanisme permet de réaliser des enchères hors chaîne pour les transactions originales et leurs transactions subséquentes.
  1. Amplification des transactions prioritaires par consensus : SIP-45
  • SIP-45 a résolu le problème de fluctuation potentiel dans la soumission de consensus, évitant ainsi que les transactions avec un prix de gaz plus bas soumises en même temps soient placées après celles avec un prix de gaz plus élevé.
  • Deux sources de fluctuations naturelles dans la soumission de consensus : )1( les nœuds de validation soumis sont en retard par rapport à plusieurs tours de consensus : les transactions soumises par un autre nœud de validation peuvent être triées en premier. )2( le leader du tour de consensus a un avantage sur les autres nœuds de validation.
  • SIP-45 amplifie au-dessus de k x RGP)k qui est un paramètre système, actuellement configuré à 5. RGP est le prix du gas de référence ( pour renforcer la soumission de consensus. Les transactions avec un prix du gas de n x RGP seront amplifiées par n fois.
  • L'application généralisée du SIP-45 créera un système plus efficace et compétitif de manière équitable. Il est important de noter que le SIP-45 ne modifiera pas les propriétés fondamentales du système telles qu'elles sont perçues du point de vue du client : il freine les comportements indésirables en offrant des alternatives plus efficaces.

Choisir le bon prix du gaz de transaction

Le client doit prendre en compte les principaux facteurs suivants pour déterminer le prix du gas pour soumettre une transaction :

  1. Vente aux enchères de gaz prioritaire

Dans la soumission de consensus, les transactions modifiant le même objet sont triées par prix du gaz, ce qui offre aux chercheurs une opportunité de concurrence équitable.

  1. Soumission de consensus amplifiée

Comme mentionné ci-dessus, les transactions avec un prix de gaz supérieur à 5 x RGP sont soumises à un consensus via n nœuds de validation pour amplifier la soumission du consensus. Tout prix de gaz dépassant le seuil d'amplification réduira le jitter des soumissions inefficaces. En pratique, un facteur d'amplification de 5 est suffisant pour éliminer le jitter, tandis qu'un prix de gaz de 100 x RGP aura une très forte probabilité de débloquer la soumission du leader du prochain tour.

  1. Éviter les retards et les annulations de congestion

Sui limite le temps d'exécution des points de contrôle en contrôlant le taux de transaction des objets partagés modifiés. Les transactions modifiant les objets en congestion sont triées par prix du gas, les transactions à prix plus bas seront retardées et finalement annulées, afin de limiter la chaîne d'exécution séquentielle la plus longue pour chaque point de contrôle, ce qui est un mécanisme appelé marché local de frais basé sur les objets. ) Notez que, bien que les objets partagés offrent de grandes opportunités d'arbitrage, le prix du gas peut exploser, tandis que d'autres parties du système restent inchangées. (

Le prix du gaz pour l'exécution et l'annulation des transactions suivies par des nœuds complets, en particulier celles impliquant des modifications des objets de congestion. Grâce aux résultats des transactions, il est possible d'obtenir le prix du gaz des transactions exécutées au prix le plus bas et celles annulées au prix le plus élevé. En utilisant ces informations, le client peut déterminer le prix du gaz requis, afin d'éviter avec une grande probabilité les retards de transaction. ) Notez que cette fonctionnalité n'est actuellement que partiellement mise en œuvre et devrait être publiée dans le cadre du SDK au cours des deux prochains mois. (

Publier des informations sur les transactions

Chaque transaction sur Sui introduit des opportunités de profit potentielles. Considérez le cycle de vie d'une transaction d'objet partagé, depuis le moment où le client soumet jusqu'à ce qu'un tiers observe ses effets.

  1. Le client soumet une transaction : le client soumet la transaction à un nœud RPC complet ) généralement choisi par l'application (.
  2. Diffusion des transactions par les nœuds RPC : Les nœuds RPC diffusent les transactions aux nœuds de validation, les nœuds de validation vérifient la validité des transactions et les signent, les nœuds RPC assemblent le certificat de transaction à partir des signatures collectives des nœuds de validation.
  3. Certificat de transaction diffusé par le nœud RPC : le nœud RPC diffuse le certificat de transaction aux nœuds de validation.
  4. Soumission des transactions par les nœuds de validation : un nœud de validation sélectionné de manière déterministe soumet la transaction au consensus. Le consensus Mysticeti diffuse le bloc entre les nœuds de validation ; dans un délai de 3 tours de consensus, le bloc contenant la transaction sera soumis. Exécution de la transaction : la transaction est exécutée sur chaque nœud de validation.
  5. Certificat d'effet de transaction envoyé au nœud RPC et au client : le certificat d'effet après l'exécution de la transaction sera renvoyé au nœud RPC et au client.
  6. Génération de points de contrôle : dans un à trois tours de consensus, chaque nœud de validation forme et signe un point de contrôle ). Un point de contrôle est un lot de plusieurs soumissions de consensus (.
  7. Diffusion de la signature de point de contrôle : La signature de point de contrôle sera diffusée entre les nœuds de validation, chaque nœud de validation formant un certificat de point de contrôle.
  8. Vérification des points de contrôle de la propagation du protocole de synchronisation d'état : Le protocole de synchronisation d'état est responsable de la propagation des points de contrôle certifiés de manière pair à pair. En général, chaque nœud de validation dispose d'un nœud pair direct qui ne fournit pas de requêtes RPC ------ un nœud complet de synchronisation d'état, qui reçoit les points de contrôle de ce nœud de validation.
  9. Téléchargement des points de contrôle par des nœuds tiers : Les nœuds complets tiers se connectent à un nœud complet de synchronisation d'état pour obtenir des points de contrôle et télécharger leur contenu. À ce stade, nous supposons que les tiers connectés directement au nœud complet peuvent traiter les effets des transactions et réagir.

) Diffusion des informations de transaction avant la soumission de la transaction

Comme mentionné précédemment, Sui a un système d'enchères hors chaîne pour soumettre des bundles souples, conformément à SIP-19. Ces enchères interceptent les soumissions de transactions via un protocole hors chaîne entre l'application et le système d'enchères.

Cette hypothèse de diffusion de l'information suppose que le système d'enchères fonctionne bien et peut protéger les transactions des utilisateurs contre les attaques potentielles de sandwich. Le système d'enchères est incité à protéger les transactions des utilisateurs pour maintenir son activité, c'est pourquoi il adopte certaines techniques d'enchères telles que ### des transactions leurres, des délais aléatoires ( pour diminuer les gains financiers apportés par les robots de sandwich potentiels.

Il est évident que cette diffusion d'informations se produit en dehors de Sui ) entre les applications et les enchères (, c'est un choix volontaire des applications et des utilisateurs, ne fournissant que des informations spéculatives, sans garantir que les transactions des utilisateurs originaux réussiront.

) transmission en flux de blocs de consensus

Pour permettre un accès aux transactions des utilisateurs à faible latence, Sui conçoit un système de diffusion directe des blocs de consensus. Dans l'ensemble, les nœuds complets pourront s'abonner directement aux blocs de consensus.

De cette manière, les nœuds complets peuvent notifier de manière spéculative les transactions qui ont une forte probabilité d'être soumises. La topologie du réseau utilise un protocole de découverte de pairs d'état ouvert standard.

Cette notification spéculative peut réduire considérablement le délai de propagation des transactions, ne prenant qu'environ 160 millisecondes ### deux tours de consensus (, c'est-à-dire après que les nœuds de validation ont soumis.

Le projet de transmission en flux de blocs de consensus est actuellement en phase de conception et devrait publier des propositions d'amélioration connexes dans les 1 à 2 mois à venir.

Protection des transactions des utilisateurs

Les transactions des utilisateurs doivent être protégées contre l'impact des transactions frontales, des attaques par étau et des délais de soumission involontaire.

) membre externe entraîné

La soumission de transactions Sui nécessite un moteur externe, généralement exécuté par des nœuds complets.

Si un nœud de validation reçoit une demande de soumission de la transaction t et souhaite initier une nouvelle transaction t', il sera à la traîne par rapport au pilote de membre d'origine durant le processus d'assemblage du certificat. À moins que le nœud complet soumis ne soit mal connecté aux membres de Sui, le nœud de validation sera à la traîne dans le processus d'assemblage du certificat de t' par rapport à t.

De plus, étant donné que la soumission de consensus de t est décentralisée, une fois que le certificat de t atteint le consensus, il ne peut pas être retardé de manière fiable. Par conséquent, si le certificat de t atteint le consensus de Sui avant t', t sera très probablement réglé avant t'.

Ainsi, la conduite des membres externes offre une protection préventive naturelle, en supposant que la confiance est responsable de la soumission des transactions par le nœud complet ###. Étant donné que les attaques préventives peuvent être facilement détectées sur la chaîne, ces attaques seront enregistrées par le client et nuiront à la réputation de l'opérateur RPC (.

) Chemin rapide Mysticeti

Sui est actuellement en train de réaliser un projet qui modifie la soumission des transactions selon le protocole de chemin rapide décrit dans le document Mysticeti. Selon ce protocole, les transactions des utilisateurs peuvent être soumises à un seul nœud de validation, qui utilisera Mysticeti pour collecter et exécuter les certificats de transaction. Bien que cela améliore considérablement l'efficacité du système, cela offre également aux nœuds de validation l'opportunité d'obtenir des transactions des utilisateurs grâce à des transactions préalables.

Ce risque est purement théorique, car il n'y a actuellement aucune preuve indiquant qu'une attaque de front-running a eu lieu sur Sui. Dans le nouveau système, la possibilité de front-running est plus élevée, mais d'un autre côté, en raison d'une compréhension déterministe des validateurs soumis, il est plus facile de les tenir responsables.

L'évolution du MEV de Sui

L'écosystème MEV de Sui est encore en formation, et de nouveaux mécanismes seront lancés plus tard cette année. Actuellement, les enchères de gaz prioritaires et l'amplification du consensus définissent le système actuel, tandis que les innovations à venir, telles que le cryptage par verrouillage temporel et le chemin rapide Mysticeti, transformeront l'exécution des transactions et la sécurité. Avec la mise en ligne de ces mécanismes, le MEV sur Sui continuera d'évoluer, créant un écosystème plus dynamique et transparent.

![Comprendre la situation et l'avenir du MEV sur Sui en un seul article]###https://img-cdn.gateio.im/webp-social/moments-6dae0c442b5d72296728a401858cf5ea.webp(

SUI-2.02%
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
  • Récompense
  • 8
  • Partager
Commentaire
0/400
liquidation_watchervip
· 07-08 06:34
Allez, rêve pas, je ne vais pas te filer un shitcoin.
Voir l'originalRépondre0
MEVHuntervip
· 07-08 04:32
Le matin, j'élève des Bots, à midi je surveille le mempool, c'est vraiment de plus en plus laisser emporter.
Voir l'originalRépondre0
FloorSweepervip
· 07-06 17:49
J'espère vraiment que sui prendra au sérieux mev.
Voir l'originalRépondre0
Lonely_Validatorvip
· 07-06 17:48
C'est encore le vieux tour des distributeurs automatiques magiques.
Voir l'originalRépondre0
PaperHandsCriminalvip
· 07-06 17:46
Ah chaque fois je perds... Bots faire de l'argent nous buvons de la soupe
Voir l'originalRépondre0
DegenGamblervip
· 07-06 17:46
Ce n'est pas juste Se faire prendre pour des cons, c'est déjà centralisé.
Voir l'originalRépondre0
NoodlesOrTokensvip
· 07-06 17:38
sui semble vouloir To the moon.
Voir l'originalRépondre0
CafeMinorvip
· 07-06 17:28
sui peut être, sans s'en rendre compte, To the moon.
Voir l'originalRépondre0
Trader les cryptos partout et à tout moment
qrCode
Scan pour télécharger Gate app
Communauté
Français (Afrique)
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)