L'état actuel et l'avenir de la MEV sur Sui
TechFlow SélectionTechFlow Sélection
L'état actuel et l'avenir de la MEV sur Sui
Décryptage du fonctionnement de la MEV sur Sui — mécanismes de classement des transactions, de protection et d'équité concurrentielle.
Dédié à des analyses Web3 approfondies
La valeur maximale extractible (MEV) est devenue un sujet important dans l'industrie blockchain, car elle touche à l'ordre des transactions et aux opportunités d'arbitrage. Afin d'assurer la transparence, protéger les transactions, maintenir la santé du réseau et récompenser les participants, nous mettons en œuvre de manière ciblée des propositions d'amélioration de Sui (SIPs) et d'autres mécanismes pour encadrer le MEV sur Sui.
Au-delà des mécanismes existants, nous prévoyons de mettre en place davantage de dispositifs afin que nos principes fondamentaux guident l'évolution du MEV sur Sui.
Principes de conception et considérations
Chaque transaction sur Sui introduit de nouvelles informations et des opportunités potentielles de profit. L'écosystème MEV sur Sui se construit autour de plusieurs mécanismes :
-
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 utilisateur
Nos priorités globales sont les suivantes :
-
La protection des transactions utilisateur prime sur la quantité de valeur extraite. Il faut privilégier une faible glissade plutôt qu'une grande extraction de valeur. Éviter les enchères hors-protocole qui augmentent la latence sans option de sortie.
-
La transparence du réseau est préférable aux transactions hors ligne avec les nœuds validateurs ou relais (relayers).
-
Promouvoir la concurrence via les enchères prioritaires de gas (priority gas auctions, PGA), et limiter les comportements de spam nuisant à l'efficacité du système : notre objectif idéal est que la stratégie dominante des chercheurs soit d'envoyer une transaction dont les frais prioritaires sont déterminés par la valeur extraite.
-
Encourager la distribution des récompenses vers les participants alignés sur l'écosystème : validateurs, stakers, applications et utilisateurs.
Soumission des transactions
Étant donné que les transactions modifiant le même objet s'exécutent séquentiellement, les clients entrent en compétition pour améliorer leur ordre d'exécution. Du point de vue du système, les PGA constituent un moyen efficace d'allocation des ressources permettant d'empêcher le spam, tout en redistribuant les frais de gas entre les participants.
Le moteur principal des enchères prioritaires de gas est la quantification de l'exécution :
-
Les transactions triées par consensus sont traitées dans un bloc. Les traders se disputent l'ordre prioritaire via les enchères de gas, que ce soit au sein d'une même soumission ou entre différentes soumissions.
-
Ceci diffère du marché des CEX, où la priorité d'exécution dépend entièrement de la vitesse, obtenue grâce à des réseaux à faible latence et des algorithmes.
-
Un taux plus élevé de soumission au consensus réduit l'effet de quantification, rendant l'exécution sur les DEX plus efficace, mais réduit également la fenêtre des PGA.
-
Actuellement, les PGA sont particulièrement importantes pour les chercheurs les plus rapides sur les objets non congestionnés. À un rythme de 15 soumissions par seconde sur Sui, un avantage de 70 millisecondes dans la soumission d'une transaction peut décider si celle-ci aboutit ou non.
-
Les objets congestionnés peuvent retarder l'exécution des transactions, amplifiant ainsi davantage l'importance des PGA, car la fenêtre de compétition entre transactions peut atteindre jusqu'à 10 fois celle d'une soumission consensus normale.
Deux mécanismes permettent de diriger des transactions vers une prochaine soumission Sui spécifique :
1 Soumettre un lot de transactions via des bundles souples : SIP-19
🌟 SIP-19 : https://github.com/sui-foundation/sips/blob/main/sips/sip-19.md
-
Les transactions soumises via des bundles souples ont une forte probabilité d'être incluses dans la même soumission de consensus que le bundle valide. La condition de validité du bundle exige que toutes les transactions aient le même prix de gas.
-
Dans la pratique, ce mécanisme permet aux transactions initiales et à leurs suites de participer à des enchères hors chaîne, comme celles gérées par Shio (https://www.getshio.com/explorer).
2 Amplifier les transactions prioritaires via le consensus : SIP-45
🌟 SIP-45 : https://github.com/sui-foundation/sips/blob/main/sips/sip-45.md
-
Le SIP-45 résout les problèmes potentiels de saccade dans la soumission de consensus, évitant ainsi que des transactions à bas prix de gas soumises simultanément soient placées après celles à prix de gas plus élevé.
-
Deux sources naturelles de saccade dans la soumission de consensus : (1) Le nœud validateur soumetteur est en retard de plusieurs tours de consensus : les transactions soumises par un autre validateur peuvent être classées en premier. (2) Le leader du tour de consensus a un avantage par rapport aux autres validateurs.
-
Le SIP-45 renforce la soumission de consensus en amplifiant les prix de gas supérieurs à k x RGP (k est un paramètre système, actuellement configuré à 5, RGP est le prix de référence du gas). Une transaction dont le prix de gas est de n x RGP est amplifiée par un facteur n.
-
L'adoption généralisée du SIP-45 créera un système plus efficace et équitable. Il convient de noter que le SIP-45 ne modifie pas les propriétés fondamentales du système depuis la perspective du client : il limite le spam en offrant une alternative plus efficace.
Choix du prix de gas approprié pour une transaction
Les clients doivent prendre en compte les facteurs suivants pour déterminer le prix de gas de leur transaction :
1 Enchères prioritaires de gas
Dans une soumission de consensus, les transactions modifiant le même objet sont triées selon leur prix de gas, offrant ainsi une chance équitable aux chercheurs.
2 Amplification de la soumission de consensus
Comme indiqué ci-dessus, les transactions dont le prix de gas dépasse 5 x RGP sont amplifiées lors de leur soumission au consensus par n nœuds validateurs. Tout prix de gas dépassant le seuil d'amplification réduit la saccade liée aux soumissions inefficaces. En pratique, un facteur d'amplification de 5 suffit à éliminer la saccade, tandis qu'un prix de gas à 100 x RGP aura une très forte probabilité de débloquer la soumission du leader du prochain tour.
3 Éviter les retards et annulations dus à la congestion
Sui limite le temps d'horloge murale (wall clock time) d'exécution des checkpoints en contrôlant le débit des transactions modifiant le même objet partagé. Les transactions modifiant un objet congestionné sont triées par prix de gas ; celles à prix plus bas sont retardées puis finalement annulées, afin de limiter la longueur maximale de la chaîne d'exécution séquentielle par checkpoint. Ce mécanisme est appelé marché local des frais basé sur l'objet. (Note : bien que le prix de gas puisse exploser lorsque les objets partagés offrent de fortes opportunités d'arbitrage, le reste du système reste inchangé.)
Les nœuds complets surveillent les prix de gas des transactions exécutées et annulées, en particulier celles impliquant la modification d'objets congestionnés. À partir du résultat d'une simulation de transaction (dry-run), on peut obtenir le prix de gas de la transaction exécutée ayant le prix le plus bas et celui de la transaction annulée ayant le prix le plus haut. Grâce à ces informations, un client peut déterminer le prix de gas nécessaire pour éviter avec une forte probabilité le report de sa transaction. (Note : cette fonctionnalité n'est actuellement qu'en partie implémentée et devrait être publiée dans les deux mois à venir dans le cadre du SDK.)
Publication des informations de transaction
Chaque transaction sur Sui introduit une opportunité potentielle de profit. Considérons le cycle de vie d'une transaction sur un objet partagé, depuis sa soumission par un client jusqu'à l'observation de ses effets par un tiers.
-
Soumission de la transaction par le client : Le client soumet la transaction à un nœud complet RPC (généralement choisi par l'application).
-
Diffusion de la transaction par le nœud RPC : Le nœud RPC diffuse la transaction aux validateurs, qui vérifient sa validité et la signent. Le nœud RPC assemble ensuite le certificat de transaction à partir des signatures collectives des validateurs.
-
Diffusion du certificat de transaction par le nœud RPC : Le nœud RPC diffuse le certificat de transaction aux validateurs.
-
Soumission de la transaction par un validateur : Un validateur sélectionné de manière déterministe soumet la transaction au consensus. Le consensus Mysticeti diffuse les blocs entre les validateurs ; en trois tours de consensus, le bloc contenant la transaction est soumis. Exécution de la transaction : la transaction est exécutée sur chaque nœud validateur.
-
Envoi du certificat d'effet de transaction au nœud RPC et au client : Le certificat d'effet post-exécution est renvoyé au nœud RPC et au client.
-
Génération d'un checkpoint : En 1 à 3 tours de consensus, chaque validateur forme et signe un checkpoint (un checkpoint est un regroupement de plusieurs soumissions de consensus).
-
Diffusion des signatures de checkpoint : Les signatures de checkpoint sont diffusées entre les validateurs, chacun formant son propre certificat de checkpoint.
-
Propagation du checkpoint par le protocole de synchronisation d'état : Le protocole de synchronisation d'état est chargé de propager les checkpoints authentifiés via un réseau pair-à-pair. Chaque validateur dispose généralement d'un nœud pair complet de synchronisation d'état — qui ne répond pas aux requêtes RPC — et qui reçoit les checkpoints de ce validateur.
-
Téléchargement du checkpoint par un nœud tiers : Un nœud complet tiers connecté à un nœud complet de synchronisation d'état récupère le checkpoint et en télécharge le contenu. À ce stade, nous supposons que le tiers directement connecté au nœud complet peut effectuer un post-traitement des effets de la transaction et y réagir.
Propagation 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, conformément au SIP-19. Ces enchères interceptent la soumission des transactions via un protocole hors chaîne entre l'application et le système d'enchères (par exemple Shio).
Cette propagation d'informations suppose que le système d'enchères agisse correctement pour protéger les transactions utilisateur contre d'éventuelles attaques de sandwich. Shio est incité à protéger les transactions utilisateur pour préserver son activité, et utilise donc certaines techniques d'enchères (transactions appâts, délais aléatoires) pour réduire les gains financiers des robots de sandwich.
Il est clair que cette propagation d'informations se produit en dehors de Sui (entre l'application et le système d'enchères), relève d'un choix volontaire de l'application et de l'utilisateur, fournit uniquement des informations spéculatives, et ne garantit pas que la transaction utilisateur initiale réussira.
Flux continu des blocs de consensus
Pour permettre un accès à faible latence aux transactions utilisateur, nous concevons un système permettant de transmettre directement en continu les blocs de consensus. Globalement, les nœuds complets pourront s'abonner directement aux blocs de consensus.
Grâce à cela, un nœud complet peut notifier de façon spéculative une transaction ayant une forte probabilité d'être soumise. La topologie du réseau utilise le protocole standard de découverte de pairs ouvert pour la synchronisation d'état.
Ces notifications spéculatives pourraient réduire significativement la latence de propagation des transactions, à environ 160 millisecondes seulement (2 tours de consensus), soit juste après la soumission par les validateurs.
Le projet de flux continu des blocs de consensus en est actuellement à la phase de conception, et un SIP devrait être publié dans les 1 à 2 mois à venir.
Protection des transactions utilisateur
Les transactions utilisateur doivent être protégées contre les attaques de front-running, de sandwich et les retards involontaires de soumission.
Pilote externe
La soumission des transactions Sui nécessite un pilote externe, généralement assuré par un nœud complet.
Si un validateur reçoit une demande de soumission de la transaction t et souhaite lancer une nouvelle transaction t', il sera en retard dans l'assemblage du certificat par rapport au pilote initial. Sauf si le nœud complet soumetteur a une mauvaise connexion avec le membre Sui, le validateur sera en retard dans l'assemblage du certificat de t' par rapport à t.
De plus, étant donné que la soumission de t au consensus est décentralisée, une fois que le certificat de t atteint le consensus, il ne peut plus être retardé de manière fiable. Par conséquent, si le certificat de t arrive au consensus Sui avant celui de t', t sera réglée avec une forte probabilité avant t'.
Ainsi, le pilote externe offre une protection naturelle contre le front-running, sous réserve de faire confiance au nœud complet chargé de la soumission des transactions (les attaques de front-running pouvant être facilement détectées sur chaîne, elles seront enregistrées par les clients et nuiront à la réputation de l'opérateur RPC).
Chemin rapide Mysticeti
Nous travaillons actuellement à un projet visant à modifier la soumission des transactions pour adopter le protocole de chemin rapide décrit dans l'article Mysticeti. Selon ce protocole, les transactions utilisateur peuvent être soumises à un seul nœud validateur, qui utilisera Mysticeti pour collecter et exécuter les certificats de transaction. Bien que cela augmente considérablement l'efficacité du système, cela donne aussi aux validateurs une opportunité de front-running sur les transactions utilisateur.
🌟 Article Mysticeti : https://arxiv.org/abs/2310.14821
Ce risque est purement théorique, car il n'existe actuellement aucune preuve d'attaques de front-running sur Sui. Dans le nouveau système, la possibilité de front-running est plus élevée, mais d'un autre côté, la connaissance déterministe du validateur soumetteur facilite davantage la responsabilisation.
Évolution du MEV sur Sui
L'écosystème MEV sur Sui est encore en formation, et de nouveaux mécanismes seront lancés plus tard cette année. Actuellement, les enchères prioritaires de gas et l'amplification de consensus définissent le système en place, tandis que des innovations à venir, telles que le chiffrement à blocage temporel (time-lock encryption) et le chemin rapide Mysticeti, redéfiniront l'exécution des transactions et la sécurité. Avec le déploiement de ces mécanismes, le MEV sur Sui continuera d'évoluer, créant un écosystème plus dynamique et transparent.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
Sui Network
