Développement et avenir de l'MEV sur le réseau Sui
MEV (Maximum Extractable Value) est devenu un sujet très suivi dans l'industrie de la blockchain, impliquant le tri des transactions et les opportunités d'arbitrage. Afin d'améliorer la transparence, de protéger les transactions, de maintenir la santé du réseau et de récompenser les participants, le réseau Sui a mis en œuvre de manière ciblée des propositions d'amélioration et d'autres mécanismes pour guider le développement du MEV sur le réseau.
En plus des mécanismes existants, Sui prévoit d'établir d'autres mécanismes pour garantir que ses principes fondamentaux guident l'évolution du MEV sur le réseau.
Principes de conception et facteurs à considérer
Chaque transaction sur le réseau Sui introduit de nouvelles informations, créant des opportunités d'arbitrage potentielles. L'écosystème MEV sur Sui se forme par les 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 :
La protection des transactions des utilisateurs prime sur l'extraction de valeur. Privilégier des glissements plus faibles plutôt qu'une extraction de valeur plus importante. Éviter les enchères hors protocole qui augmentent les délais et n'ont pas d'option de sortie.
La transparence du réseau prime sur les transactions hors ligne avec les nœuds de validation ou les intermédiaires.
Favoriser la concurrence par des enchères de gas prioritaires (PGA), et réprimer les comportements indésirables qui entraînent une inefficacité du système : idéalement, la stratégie optimale du chercheur est d'envoyer une transaction dont le coût prioritaire est déterminé par la valeur extraite.
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ème, le PGA est un moyen efficace de répartition des ressources, permettant de prévenir les comportements indésirables tout en redistribuant les frais de gaz entre les participants.
Le facteur clé du PGA est la quantification de l'exécution :
Les transactions triées par consensus sont traitées dans le bloc. Les traders rivalisent pour l'ordre de priorité par le biais d'enchères de gas, à la fois en compétition interne lors de la soumission et en compétition 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 des réseaux à faible latence et des algorithmes.
Un taux de soumission de consensus plus élevé réduit l'effet de quantification, rendant le trading décentralisé plus efficace, mais réduit également 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 15 soumissions par seconde sur Sui, un avantage de vitesse de soumission de transaction de 70 millisecondes peut déterminer si une transaction peut être réalisée.
Les objets de congestion peuvent retarder l'exécution des transactions, ce qui amplifie encore l'importance du PGA, car la fenêtre des transactions concurrentes peut être jusqu'à 10 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 :
Soumettre un lot de transactions par liaison douce
Les transactions soumises par des liaisons souples ont une forte probabilité d'être incluses dans le même envoi de consensus qu'une liaison valide. La condition de validité de la liaison exige que toutes les transactions aient le même prix de gaz.
En pratique, ce mécanisme permet d'organiser des enchères hors chaîne pour les transactions originales et leurs transactions ultérieures.
Amplifier les transactions prioritaires par consensus
Ce mécanisme résout le problème potentiel de fluctuation dans la soumission de consensus, évitant ainsi que les transactions avec un prix de gas inférieur soumises simultanément soient placées après celles avec un prix de gas 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.
Ce mécanisme amplifie les soumissions de consensus en utilisant un RGP supérieur à k x RGP(, où k est un paramètre système, actuellement configuré à 5. Le RGP est le prix du gaz de référence ) pour renforcer les soumissions de consensus. Les transactions dont le prix du gaz est n x RGP seront amplifiées n fois.
L'application généralisée de ce mécanisme créera un système de concurrence plus efficace et équitable. Il convient de noter que ce mécanisme ne modifiera pas les propriétés fondamentales du système telles que perçues par le client : il réprime les comportements indésirables en offrant des alternatives plus efficaces.
Choisir le prix du gas de transaction approprié
Le client doit prendre en compte les principaux facteurs suivants pour déterminer le prix du gas pour soumettre une transaction :
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 chance de concurrence équitable.
Soumission de consensus amplifiée
Comme mentionné ci-dessus, les transactions dont le prix du gas dépasse 5 x RGP sont soumises à un consensus par n nœuds de validation pour amplifier la soumission du consensus. Tout prix du gas dépassant le seuil d'amplification réduira les fluctuations des soumissions inefficaces. Dans la pratique, un facteur d'amplification de 5 est suffisant pour éliminer les fluctuations, tandis qu'un prix du gas de 100 x RGP aura une très forte probabilité de débloquer la soumission du leader de la prochaine manche.
Éviter les retards et les annulations dus à l'engorgement
Sui limite le temps d'exécution des points de contrôle en contrôlant le taux de transactions sur le même objet partagé. Les transactions modifiant l'objet de congestion sont triées par prix du gas, les transactions au prix le plus bas étant retardées et finalement annulées, afin de limiter la plus longue chaîne d'exécution séquentielle pour chaque point de contrôle, ce qui est un mécanisme connu sous le nom de marché des frais locaux basé sur l'objet. ( Notez que, bien que les objets partagés offrent de grandes opportunités d'arbitrage, le prix du gas peut exploser, mais les autres parties du système restent inchangées. )
Le prix du gaz pour l'exécution et l'annulation des transactions suivies par un nœud complet, en particulier pour les transactions impliquant des modifications des objets de congestion. Grâce aux résultats des transactions exécutées, il est possible d'obtenir le prix du gaz pour les transactions d'exécution à prix minimum et pour les transactions annulées à prix maximum. En utilisant ces informations, le client peut déterminer le prix du gaz requis afin d'éviter avec une forte probabilité les retards de transaction. ( Notez que cette fonctionnalité est actuellement partiellement mise en œuvre et devrait être publiée dans les deux mois à venir dans le cadre du SDK. )
Publier des informations sur les transactions
Chaque transaction sur Sui introduit des opportunités d'arbitrage potentielles. Considérons le cycle de vie d'une transaction d'objet partagé, depuis le moment où le client soumet jusqu'à ce qu'un tiers observe son effet :
Soumission de transaction par le client : le client soumet la transaction à un nœud complet RPC ( généralement choisi par l'application ).
Diffusion des transactions par les nœuds RPC : Les nœuds RPC diffusent les transactions aux nœuds de validation, qui vérifient la validité des transactions et les signent. Les nœuds RPC assemblent ensuite le certificat de transaction à partir des signatures collectives des nœuds de validation.
Certificat de transaction diffusé par le nœud RPC : le nœud RPC diffuse le certificat de transaction aux nœuds de validation.
Soumission des transactions par le nœud de validation : un nœud de validation sélectionné de manière déterministe soumet la transaction au consensus. Le consensus diffuse le bloc entre les nœuds de validation, et dans les 3 tours de consensus, le bloc contenant la transaction sera soumis.
Exécution des transactions : Les transactions sont exécutées sur chaque nœud de validation.
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.
Génération de points de contrôle : Au cours de 1 à 3 tours de consensus, chaque nœud de validation forme et signe un point de contrôle (. Le point de contrôle est un lot de plusieurs soumissions de consensus ).
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.
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 a un nœud pair direct sans demande RPC - un nœud complet de synchronisation d'état, qui reçoit les points de contrôle de ce nœud de validation.
Points de contrôle de téléchargement des nœuds tiers : un nœud complet tiers connecté à un nœud complet de synchronisation d'état obtient les points de contrôle et télécharge leur contenu. À ce stade, nous supposons qu'un tiers connecté directement au nœud complet peut effectuer un post-traitement des effets des transactions et réagir.
Diffusion des informations de transaction avant soumission
Comme mentionné précédemment, Sui dispose d'un système d'enchères hors chaîne pour soumettre des bundles souples. 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 sur la 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 utilise certaines techniques d'enchères comme les transactions leurres, les délais aléatoires pour affaiblir les gains financiers apportés par les bots 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 seront couronnées de succès.
( Transmission de blocs de consensus en flux
Pour permettre un accès aux transactions des utilisateurs à faible latence, Sui est en train de concevoir 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 standard basé sur la synchronisation d'état ouvert.
Cet avis de spéculation pourrait considérablement réduire le délai de propagation des transactions, nécessitant seulement environ 160 millisecondes )2 tours de consensus ###, c'est-à-dire après que les nœuds de validation aient soumis.
Le projet de transmission de blocs de consensus est actuellement en phase de conception et devrait publier une proposition d'amélioration dans les 1 à 2 mois à venir.
Protection des transactions des utilisateurs
Les transactions des utilisateurs doivent être protégées contre les effets de front-running, de spoofing et de soumissions involontaires retardées.
( Membre externe entraîné
La soumission de transaction Sui nécessite l'intervention de membres externes, généralement exécutée 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 d'origine lors du 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 par rapport à t lors du processus d'assemblage du certificat de 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. Ainsi, si le certificat de t atteint le consensus de Sui avant t', il y a une forte probabilité que t soit réglé avant t'.
Ainsi, la conduite des membres externes offre une protection naturelle en amont, en supposant que la confiance repose sur le nœud complet responsable de la soumission des transactions ), qui peut facilement détecter les attaques en amont sur la chaîne. Ces attaques seront enregistrées par le client et nuiront à la réputation de l'opérateur RPC ###.
( Chemin rapide
Sui est actuellement en train de mener un projet pour modifier la soumission des transactions en un protocole de chemin rapide. Selon ce protocole, les transactions des utilisateurs peuvent être soumises à un seul nœud de validation, qui utilisera un mécanisme de consensus 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'accéder aux transactions des utilisateurs avant leur traitement.
Ce risque est purement théorique, car il n'existe 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 de la compréhension déterministe des nœuds de validation soumis, il est plus facile de les tenir responsables.
L'évolution de MEV de Sui
L'écosystème MEV de Sui est encore en cours de formation, 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, redéfiniront l'exécution des transactions et la sécurité. Avec le lancement de ces mécanismes, le MEV sur Sui continuera d'évoluer, créant un écosystème plus dynamique et transparent.
![Comprendre en un clin d'œil l'état et l'avenir du MEV sur Sui])https://img-cdn.gateio.im/webp-social/moments-6dae0c442b5d72296728a401858cf5ea.webp###
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.
8 J'aime
Récompense
8
7
Partager
Commentaire
0/400
GovernancePretender
· Il y a 2h
C'est dommage de ne pas suivre le marché avec cette vague mev.
Voir l'originalRépondre0
SadMoneyMeow
· Il y a 5h
S'enrichir grâce aux pertes quotidiennes
Voir l'originalRépondre0
FlyingLeek
· Il y a 19h
Encore une fois, c'est pour les pigeons. Prendre les gens pour des idiots et c'est tout.
Voir l'originalRépondre0
BearMarketGardener
· Il y a 20h
Les pigeons peuvent encore gagner de l'argent ?
Voir l'originalRépondre0
IfIWereOnChain
· Il y a 20h
Ah, mev est vraiment un vampire, il ne fait que tondre les pigeons. Sui peut-il résister ?
Voir l'originalRépondre0
QuorumVoter
· Il y a 20h
Encore en train de faire du buzz sur MEV ? Je ne sais vraiment pas qui joue encore à ce vieux piège.
Voir l'originalRépondre0
MEVSandwichMaker
· Il y a 20h
Vouloir couper les coupons, il faut aussi voir où se trouvent les coupons.
Développement et innovation des mécanismes MEV sur le réseau Sui : protection des utilisateurs, amélioration de la transparence
Développement et avenir de l'MEV sur le réseau Sui
MEV (Maximum Extractable Value) est devenu un sujet très suivi dans l'industrie de la blockchain, impliquant le tri des transactions et les opportunités d'arbitrage. Afin d'améliorer la transparence, de protéger les transactions, de maintenir la santé du réseau et de récompenser les participants, le réseau Sui a mis en œuvre de manière ciblée des propositions d'amélioration et d'autres mécanismes pour guider le développement du MEV sur le réseau.
En plus des mécanismes existants, Sui prévoit d'établir d'autres mécanismes pour garantir que ses principes fondamentaux guident l'évolution du MEV sur le réseau.
Principes de conception et facteurs à considérer
Chaque transaction sur le réseau Sui introduit de nouvelles informations, créant des opportunités d'arbitrage potentielles. L'écosystème MEV sur Sui se forme par les mécanismes suivants :
Les priorités globales de Sui sont les suivantes :
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ème, le PGA est un moyen efficace de répartition des ressources, permettant de prévenir les comportements indésirables tout en redistribuant les frais de gaz entre les participants.
Le facteur clé du PGA est la quantification de l'exécution :
Il existe deux mécanismes pour diriger les transactions vers des soumissions Sui spécifiques à venir :
Choisir le prix du gas de transaction approprié
Le client doit prendre en compte les principaux facteurs suivants pour déterminer le prix du gas pour soumettre une transaction :
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 chance de concurrence équitable.
Comme mentionné ci-dessus, les transactions dont le prix du gas dépasse 5 x RGP sont soumises à un consensus par n nœuds de validation pour amplifier la soumission du consensus. Tout prix du gas dépassant le seuil d'amplification réduira les fluctuations des soumissions inefficaces. Dans la pratique, un facteur d'amplification de 5 est suffisant pour éliminer les fluctuations, tandis qu'un prix du gas de 100 x RGP aura une très forte probabilité de débloquer la soumission du leader de la prochaine manche.
Sui limite le temps d'exécution des points de contrôle en contrôlant le taux de transactions sur le même objet partagé. Les transactions modifiant l'objet de congestion sont triées par prix du gas, les transactions au prix le plus bas étant retardées et finalement annulées, afin de limiter la plus longue chaîne d'exécution séquentielle pour chaque point de contrôle, ce qui est un mécanisme connu sous le nom de marché des frais locaux basé sur l'objet. ( Notez que, bien que les objets partagés offrent de grandes opportunités d'arbitrage, le prix du gas peut exploser, mais les autres parties du système restent inchangées. )
Le prix du gaz pour l'exécution et l'annulation des transactions suivies par un nœud complet, en particulier pour les transactions impliquant des modifications des objets de congestion. Grâce aux résultats des transactions exécutées, il est possible d'obtenir le prix du gaz pour les transactions d'exécution à prix minimum et pour les transactions annulées à prix maximum. En utilisant ces informations, le client peut déterminer le prix du gaz requis afin d'éviter avec une forte probabilité les retards de transaction. ( Notez que cette fonctionnalité est actuellement partiellement mise en œuvre et devrait être publiée dans les deux mois à venir dans le cadre du SDK. )
Publier des informations sur les transactions
Chaque transaction sur Sui introduit des opportunités d'arbitrage potentielles. Considérons le cycle de vie d'une transaction d'objet partagé, depuis le moment où le client soumet jusqu'à ce qu'un tiers observe son effet :
Diffusion des informations de transaction avant soumission
Comme mentionné précédemment, Sui dispose d'un système d'enchères hors chaîne pour soumettre des bundles souples. 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 sur la 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 utilise certaines techniques d'enchères comme les transactions leurres, les délais aléatoires pour affaiblir les gains financiers apportés par les bots 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 seront couronnées de succès.
( Transmission de blocs de consensus en flux
Pour permettre un accès aux transactions des utilisateurs à faible latence, Sui est en train de concevoir 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 standard basé sur la synchronisation d'état ouvert.
Cet avis de spéculation pourrait considérablement réduire le délai de propagation des transactions, nécessitant seulement environ 160 millisecondes )2 tours de consensus ###, c'est-à-dire après que les nœuds de validation aient soumis.
Le projet de transmission de blocs de consensus est actuellement en phase de conception et devrait publier une proposition d'amélioration dans les 1 à 2 mois à venir.
Protection des transactions des utilisateurs
Les transactions des utilisateurs doivent être protégées contre les effets de front-running, de spoofing et de soumissions involontaires retardées.
( Membre externe entraîné
La soumission de transaction Sui nécessite l'intervention de membres externes, généralement exécutée 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 d'origine lors du 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 par rapport à t lors du processus d'assemblage du certificat de 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. Ainsi, si le certificat de t atteint le consensus de Sui avant t', il y a une forte probabilité que t soit réglé avant t'.
Ainsi, la conduite des membres externes offre une protection naturelle en amont, en supposant que la confiance repose sur le nœud complet responsable de la soumission des transactions ), qui peut facilement détecter les attaques en amont sur la chaîne. Ces attaques seront enregistrées par le client et nuiront à la réputation de l'opérateur RPC ###.
( Chemin rapide
Sui est actuellement en train de mener un projet pour modifier la soumission des transactions en un protocole de chemin rapide. Selon ce protocole, les transactions des utilisateurs peuvent être soumises à un seul nœud de validation, qui utilisera un mécanisme de consensus 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'accéder aux transactions des utilisateurs avant leur traitement.
Ce risque est purement théorique, car il n'existe 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 de la compréhension déterministe des nœuds de validation soumis, il est plus facile de les tenir responsables.
L'évolution de MEV de Sui
L'écosystème MEV de Sui est encore en cours de formation, 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, redéfiniront l'exécution des transactions et la sécurité. Avec le lancement de ces mécanismes, le MEV sur Sui continuera d'évoluer, créant un écosystème plus dynamique et transparent.
![Comprendre en un clin d'œil l'état et l'avenir du MEV sur Sui])https://img-cdn.gateio.im/webp-social/moments-6dae0c442b5d72296728a401858cf5ea.webp###