Invité : Zihao Li, doctorant, Université polytechnique de Hong Kong
Organisé par : aididiao.eth, Foresight News
Cet article est un résumé de la vidéo partagée par Zihao Li, doctorant à l'Université polytechnique de Hong Kong dans le cadre du programme Web3 Young Scholars. Le programme Web3 Young Scholars est lancé conjointement par DRK Lab, imToken et Crytape. De jeunes chercheurs de renom dans le domaine du cryptage seront invités à partager certains des derniers résultats de recherche avec la communauté de langue chinoise.
Bonjour à tous, je m'appelle Zihao Li, doctorant en troisième année à l'Université polytechnique de Hong Kong. Le sujet que j'ai partagé aujourd'hui est "Découvrir les activités MEV dans le package de transactions Ethereum". En termes simples, il s'agit de découvrir des types inconnus d'activités MEV dans le réseau Ethereum via des paquets de transactions. Tout d'abord, je donnerai une introduction relativement basique, comme le concept de MEV, le mécanisme de paquet de transactions et le contexte de notre travail. Ensuite, je présenterai en détail le flux de travail complet et quelques idées de conception, telles que les principes de conception utilisés pour concevoir le flux de travail ; quels sont nos ensembles de données ; quels outils nous utilisons pour évaluer notre flux de travail sur quels indicateurs, etc. Enfin, je présente trois applications comprenant les résultats d’analyses empiriques connexes.
Introduction au contexte : MEV, package de transaction, motivation
L'activité MEV fait référence aux arbitragistes de la blockchain générant des transactions d'arbitrage en surveillant le réseau blockchain, y compris l'état des blocs. Certaines informations sur les transactions sont réparties sur le réseau blockchain P2P, ou certaines transactions qui n'ont pas été officiellement téléchargées sur la chaîne sont stockées dans le pool de transactions des mineurs ou des vérificateurs. Lorsque l'arbitragiste surveille ces informations sur les transactions, il génère les siennes grâce à certaines stratégies. La transaction d'arbitrage, puis spécifie la transaction d'arbitrage à une certaine position dans le bloc suivant, par exemple, il veut être à la tête du bloc suivant, ou en d'autres termes, exécuter une transaction stratégique immédiatement après une certaine transaction pour se propager le même métier d’arbitrage. De cette manière, nous pouvons considérer les activités d’arbitrage à une certaine position comme des activités MEV. Par exemple, si un arbitragiste surveille les fluctuations du prix d'un actif, il peut acheter l'actif correspondant dans un pool de négociation à bas prix, puis le revendre à un prix élevé dans un autre pool à prix élevé. Ceci est considéré comme une activité MEV.
À l'heure actuelle, les activités MEA sont principalement menées par des arbitragistes autour de l'écologie DeFi, car l'écologie DeFi rassemble actuellement principalement des actifs. Jusqu'à présent, l'écologie DeFi d'Ethereum et d'autres chaînes a attiré plus de 40 milliards de dollars de capitaux. Il faut ici mentionner un concept sur l'écologie DeFi, appelé action DeFi, qui correspond au fonctionnement de service atomique fourni par une application DeFi. Par exemple, on sait que l'AMM prend en charge l'échange entre différents types d'actifs. Les utilisateurs peuvent vendre un USDC , puis obtenez une somme d'ETH, une telle opération peut être définie comme une action DeFi. Nous pouvons utiliser l'action DeFi pour exprimer les activités MEV. Par exemple, si un utilisateur détecte qu'il existe un écart entre les prix des actifs sur différents AMM, l'utilisateur peut acheter à bas prix et vendre à un prix élevé, et finalement obtenir un profit sur la différence de prix. Nous pouvons exprimer cette activité MEV sous la forme de deux actions DeFi.
À l'heure actuelle, la recherche universitaire sur les activités MEV est principalement divisée en trois catégories, à savoir les attaques sandwich, l'arbitrage inversé et la liquidation. Dans l'ensemble de données sur lequel nous travaillons, nous avons constaté que ces trois types d'activités MEV apparaissent plus d'un million de fois. Il y a en fait un problème ici, une fois que nous connaissons la définition de ces activités MEV, comment identifier l'occurrence des activités. Si nous voulons identifier ces activités MEV, nous devons identifier toutes les activités de l'arbitragiste, telles que les transactions générées par l'arbitragiste et les types d'arbitrage inclus dans ces transactions. Nous pouvons ensuite déterminer quel type d'activité MEV se produit actuellement. . , et l’ensemble du processus repose en grande partie sur notre définition de l’activité MEV connue. Prenons l'exemple d'une attaque sandwich.Une fois que nous connaissons la définition d'une attaque sandwich, si nous voulons déterminer la valeur d'arbitrage de l'attaque sandwich et les transactions d'arbitrage correspondantes, nous devons établir de nombreuses règles basées sur la définition, puis filtrer les attaques sandwich candidates grâce à ces règles d'arbitrage de valeur et de commerce. Lors de l'identification des types d'attaques MEV connus de cette manière, deux questions se posent : La première est de savoir si les trois activités MEV courantes que nous connaissons peuvent représenter toutes les activités MEV ? Évidemment non, car l’écosystème DeFi est en constante évolution, de nouvelles applications sont toujours développées et les stratégies de ces arbitragistes sont en fait constamment itératives. La deuxième question est de savoir comment découvrir ces activités MEV inconnues. Jetons un coup d'œil au mécanisme du package de transactions en gardant cette question à l'esprit.
Le mécanisme de package de transactions a été proposé pour la première fois en 2021. En termes simples, les utilisateurs peuvent organiser une file d'attente de transactions. La longueur de cette file d'attente de transactions peut être une ou plusieurs transactions, puis l'utilisateur envoie ces transactions au réseau blockchain. Le relais les collecte transactions et les envoie directement et en privé aux mineurs ou vérificateurs concernés. Actuellement, les relayeurs exécuteront des packages de transactions pour entreprendre des tâches de relais. Le mécanisme du paquet de transactions a une fonctionnalité très importante : lorsque ces utilisateurs construisent un paquet de transactions, ils peuvent placer les transactions d'autres personnes qui n'ont pas été téléchargées dans la chaîne dans un paquet de transactions, et l'ordre des transactions dans le paquet de transactions peut être manipulé arbitrairement. . A ce moment, l'utilisateur du package de trading ou l'arbitragiste qui utilise le package de trading peut concevoir ses règles d'arbitrage. Par exemple, il peut concevoir une stratégie plus complexe et plus rentable pour les activités MEV. En prenant l'attaque sandwich comme exemple, si aucun package de transaction n'est utilisé, un arbitragiste dans une attaque sandwich doit générer au moins une paire de transactions pour réaliser l'arbitrage, et cette paire de transactions d'arbitrage ne peut cibler que cette seule transaction. L'arbitrage généré par cette transaction d'attaque doit être exécuté dans un certain ordre pour garantir qu'il puisse être arbitré avec succès. Mais si un arbitragiste utilise un package de trading, il peut collecter de nombreuses transactions pouvant être arbitrées.Il lui suffit d'utiliser une paire de transactions d'arbitrage correspondantes pour générer un arbitrage sur plusieurs transactions en même temps. Tant que ce paquet de transactions est sur la chaîne, il réussira certainement l'arbitrage, et comme il arbitre plusieurs transactions arbitrables en même temps, ses résultats d'arbitrage sont également plus rentables.
Le package commercial se caractérise par des activités MEV très riches et complexes. Parce que les utilisateurs qui utilisent des packages de transactions encapsulent leurs transactions complètes dans le package de transactions, puis l'envoient au relais du réseau P2P, et enfin aux mineurs et vérificateurs correspondants. Nous pouvons identifier avec précision et complètement toutes les activités grâce à des packages de transactions. Par conséquent, nous pouvons identifier plus précisément certaines activités MEV inconnues grâce au support du package de transaction.
Idées de flux de travail et de conception
Ensuite, nous présenterons notre flux de travail en détail. Comment pouvons-nous découvrir des activités MEV inconnues via un support tel que les packages de transactions ? Le flux de travail principal comprend deux outils. Premièrement, nous utilisons l'outil ActLifter pour identifier chaque action DeFi dans le package de transaction une fois que le relais a collecté le package de transaction. Après avoir obtenu le résultat, nous exprimons toutes les actions du package de transaction. Utilisez ensuite l'outil ActCluster pour rassembler les packages de transactions avec des activités similaires via la méthode de clustering et découvrez plus rapidement de nouvelles activités MEV grâce aux résultats du clustering. Si nous voulons découvrir des activités MEV inconnues, il est inévitable de confirmer manuellement si l'activité MEV est d'un type inconnu. Bien entendu, l'objectif de notre conception de travail est de minimiser autant que possible la charge de travail manuelle et de rendre l'ensemble du processus aussi fluide que possible et s'effectue automatiquement.
Il existe déjà des outils permettant d'identifier l'activité MEV à partir des transactions. Nous pouvons grossièrement le diviser en deux catégories : la première catégorie est constituée de règles récapitulatives purement manuelles et la deuxième catégorie est constituée de règles heuristiques pures, c'est-à-dire utilisant une règle heuristique purement automatisée pour identifier des types spécifiques d'activités MEV. Par exemple, après avoir reconnu certaines informations de transfert actuelles, il vérifie si les règles heuristiques sont satisfaites et, si elles sont satisfaites, il peut identifier les activités correspondantes. La première méthode purement manuelle de résumé des règles peut obtenir une meilleure précision, car ce processus est une analyse entièrement manuelle d'applications spécifiques, et elle peut ensuite garantir que les résultats de détection sont précis, mais la tâche d'analyse implique une charge de travail très importante, elle ne peut donc pas couvrir chaque application DeFi. Bien que le deuxième travail puisse réaliser une automatisation pure, les règles heuristiques ne peuvent couvrir que certains types spécifiques. D’un autre côté, il existe certains problèmes dans la conception de la règle heuristique, ce qui conduit à une précision de reconnaissance insatisfaisante.
Nous avons conçu notre flux de travail en combinant les avantages des deux méthodes. Nous pouvons identifier dix actions DeFi actuellement majeures. Il nous suffit de déterminer manuellement quel événement dans l'application DeFi correspond à quel type d'action DeFi après son lancement. Nous n'avons alors pas besoin d'analyse manuelle et pouvons complètement le laisser à une analyse automatisée. Le deuxième type de méthode peut identifier de manière entièrement automatique les actions DeFi, mais il ne peut pas déterminer si l'objet analysé est lié aux activités MEV. Par exemple, si nous identifions un transfert SWAP, il peut identifier deux combinaisons de transfert totalement indépendantes comme une seule action DeFi. Naturellement, le résultat de son identification sera erroné. Mais nous pouvons utiliser ces informations pour filtrer les informations réellement liées aux actions DeFi. Après avoir obtenu ces informations, nous pouvons éviter certaines erreurs comme celles qui se produisent dans le deuxième type de méthode grâce à des méthodes automatisées.
Par exemple, il s'agit ici d'une transaction impliquant un total de quatre transferts. Leur ordre d'occurrence, leur montant et leur catégorie de fonds sont marqués par des numéros de série. Au cours de ce processus, AMM a en fait déclenché un événement lié à l'action Swap. Une fois que le premier type de méthode a déterminé que l'événement est initié, il doit restaurer le contenu actuel via certains paramètres de l'événement. Par exemple, il doit examiner le code, la logique métier et certaines variables de fonction du contrat 699 pour récupérer le contenu actuel. Après avoir obtenu ces informations, nous avons conçu une règle basée sur ses caractéristiques uniques de transfert d'actifs. Par exemple, la règle que nous avons affinée est que le contrat DeFi actuellement en vigueur reçoit et transfère différents types d'actifs. Lorsque nous constatons qu'il existe deux transactions comme celle-ci Une fois que le transfert d'actifs répond à ces caractéristiques, nous pouvons restaurer le contenu de l'action d'échange correspondante. Le deuxième type de méthode associe directement deux transferts d'actifs : les deux comptes de transfert d'actifs reçoivent et transfèrent différents types d'actifs. Les premier et cinquième transferts seront considérés comme une paire de transferts liés, et le compte du milieu est considéré comme un AMM. Évidemment, nous pouvons intuitivement voir que le résultat de l'identification est inexact.
Les règles que nous résumons par analyse manuelle sont les types d'actions DeFi correspondant aux événements pertinents. Bien que les résultats soient résumés par analyse manuelle, nous faisons toujours de notre mieux pour affiner le processus d'analyse manuelle en un processus semi-automatique, afin de garantir que notre fiabilité totale du processus. Nous vérifierons le site officiel des applications DeFi, les documents des développeurs, y compris certains codes sources de contrat des sites officiels de DeFiPulse.com et Dapp.com. Nous développons des outils d'analyse qui peuvent extraire certaines descriptions d'événements dans les documents à partir de ces matériaux impliqués, comme la façon dont cet événement est défini avec des jetons et dans quelles fonctions, extraits de code et commentaires de code où ces événements sont utilisés. Après avoir extrait ces éléments, grâce à notre analyse manuelle et à nos discussions, nous avons finalement déterminé qu'il existe 88 événements correspondant à différents types d'actions DeFi.
Nous saisissons la transaction à analyser dans ce dictionnaire et analysons les événements survenus dans la transaction. Ensuite lorsqu'un événement apparaît dans ce dictionnaire, nous extrayons des informations clés selon les règles correspondantes, comme quel contrat opère cette action DeFi, puis quel est le type de cette DeFi, et quels transferts d'actifs sont liés à cette action DeFi. Après avoir obtenu ce contenu, nous résumerons les règles caractéristiques du transfert d'actifs, puis utiliserons cette règle pour correspondre à l'action DeFi finale. A partir de dix définitions de l’action DeFi, nous résumons les règles caractéristiques du transfert d’actifs. Après avoir collecté ces informations à l'étape précédente, nous utiliserons ces règles de correspondance pour la correspondance et nous aiderons enfin à identifier quel contenu spécifique s'est produit dans quelle DeFi dans cette transaction. Une fois qu'ActCluster a reconnu chaque transaction dans le package de transactions, nous pouvons exprimer le comportement du package de transactions.
Comprenons d'abord les principes de conception d'ActCluster. Nous savons que l'analyse manuelle est inévitable dans ce processus et qu'elle doit s'appuyer sur un travail manuel pour déterminer si l'activité du package de transaction est un type inconnu d'activité MEV. Sur cette base, notre idée de base est de regrouper certains packages de transactions avec des activités similaires. Pour chaque cluster, il nous suffit d'échantillonner au hasard un ou plusieurs packages de transactions pour analyse, ce qui peut accélérer le processus d'analyse manuelle et finalement découvrir différents types d'activités MEA. Lorsque nous utilisons l’analyse cluster pour regrouper des packages de transactions, nous sommes confrontés à un dilemme. Lorsque nous définissons la force de regroupement des packages de transactions de manière relativement grossière, les packages de transactions contenant différents types d'activités seront regroupés. À ce stade, même si le nombre de clusters deviendra plus petit, les tâches d'analyse manuelle correspondantes deviendront également plus petites. Moins, mais certaines nouvelles activités MEV nous manqueront. Si nous ajustons l'intensité du clustering pour qu'elle soit plus détaillée, même si nous pouvons distinguer certains paquets de transactions correspondant à des activités MEA similaires mais différentes, la charge de travail d'analyse manuelle impliquée sera considérablement augmentée.
Sur la base d'un tel problème, nous avons conçu une méthode d'analyse de clustering itérative, qui effectue une analyse de clustering en plusieurs itérations. À chaque tour, nous supprimerons les packages de transactions connus contenant de nouvelles activités MEV découvertes lors des tours précédents, puis améliorerons la force de clustering des packages de transactions restants. Nous ne pouvons pas utiliser directement les méthodes de clustering traditionnelles pour regrouper les packages de transactions, car les packages de transactions contiennent en fait plusieurs transactions et une transaction peut contenir plusieurs actions DeFi. Si l’on exprime l’ensemble de la transaction, sa structure est en réalité hétérogène et hiérarchique. À l’heure actuelle, nous utilisons la méthode d’apprentissage de la représentation pour représenter le contenu de ce package de transactions dans un espace de positionnement. L'avantage de l'apprentissage par représentation est que nous n'avons pas besoin d'un apprentissage et d'une compréhension approfondis des données que nous voulons analyser et traiter, ni d'une riche connaissance du domaine. Nous n'avons besoin que d'un simple traitement orienté données.
Par exemple, il nous suffit d'étiqueter le package de transactions pour indiquer quelles activités MEV sont incluses dans le package de transactions. Si nous connaissons la définition d’une activité MEV, il nous est plus facile de concevoir les règles correspondantes et de détecter automatiquement si elle existe. Nous pouvons automatiquement étiqueter ces packages de transactions pour représenter l’apprentissage. Notre analyse cluster est de type itératif, et après chaque itération, nous pouvons découvrir de nouvelles activités MEV. À ce stade, nous pouvons réellement enrichir les étiquettes correspondant à ces activités MEV nouvellement découvertes dans notre processus d'apprentissage des représentations. Lorsque les étiquettes utilisées dans notre processus d'apprentissage de représentation sont enrichies, les performances et l'efficacité de l'ensemble de la formation du modèle d'apprentissage de représentation peuvent être améliorées de manière itérative, et la capacité de cet apprentissage de représentation à exprimer les activités du package de transactions peut également être améliorée de manière itérative. Il peut en fait y avoir plusieurs transactions dans un package de transaction, et il peut en fait y avoir plusieurs actions DeFi dans une transaction. Nous devons exprimer les besoins du package de transaction. Premièrement, pour chaque type d’action DeFi, nous définissons un paramètre standardisé, tel que quel contrat est en vigueur, et quelle est la quantité et le type d’actifs reçus et transférés ? Nous définissons chaque action DeFi de cette manière. Si nous identifions qu'il y a plusieurs actions DeFi dans une transaction, nous les représentons sous forme de blocs d'action, de sorte que le bloc de transaction correspondant à la transaction puisse être représenté, qui contient les informations source de la transaction, telles que qui a initié la transaction, et la redirection À qui est-il envoyé ? Lorsqu'une action DeFi se produit dans une transaction, nous la remplirons de blocs d'action dans l'ordre. Chaque transaction est représentée par un bloc de transaction, et enfin on obtient la structure du package de transaction, qui peut être considérée comme une matrice. Une fois ce package de transactions représenté, nous pouvons l'utiliser pour l'apprentissage de la représentation. Chaque package de transaction est une structure unifiée, et nous pouvons ensuite utiliser le modèle pour le traitement par lots.
Évaluation des performances
Nous partageons ensuite les méthodes que nous avons utilisées pour évaluer les performances du flux de travail. L'ensemble des données pour l'ensemble de notre processus d'analyse est fourni via l'API fournie par Flashbots, et les données des packages de transactions de février 2021 à décembre 2022 sont collectées, comprenant plus de 6 millions de packages de transactions et 26 millions de transactions.
Nous avons conçu quelques outils pour comparer l'exactitude et l'exhaustivité des actions DeFi. Il convient de noter ici que parmi ces outils en chaîne, actuellement seul Etherscan peut restaurer l'action DeFi dans la transaction via sa page web et les informations qu'elle fournit. Et comme DeFiRanger, nous reproduisons leurs méthodes à partir de leurs articles. De plus, nous avons conçu un outil appelé EventLifter pour tenter de récupérer les actions DeFi directement à partir des événements de transaction. Nous avons testé ActLifter sous différentes configurations et utilisé divers outils pour comparer la précision de la reconnaissance. Pour ActCluster, notre idée principale est d'adopter la méthode d'apprentissage par ablation. Pour les nouvelles activités qui peuvent être identifiées, après ablation de certains modules d'ActCluster, si nous voulons encore identifier de nouvelles activités qui n'ont pas été trouvées, dans quelle mesure avons-nous besoin d'analyser manuellement ? Quelle est la taille du paquet de transactions ou la charge de travail de notre analyse manuelle. Par exemple, nous avons effectué une ablation de la mise à jour dynamique des étiquettes dans le module d'apprentissage de la représentation ActCluster, et nous avons en fait supprimé l'ensemble du processus. Nous prenons un échantillon aléatoire de 6 millions de paquets de transactions et voyons combien de paquets de transactions nous devons analyser manuellement pour découvrir la même quantité de nouvelle activité MEV.
Nos outils peuvent atteindre une précision et une exhaustivité proches de 100 % dans des conditions de configuration uniforme. Mais comme d’autres outils comme Etherscan, même si sa précision peut atteindre 100 %, ce qui est tout à fait satisfaisant, il manquera de nombreuses actions DeFi. Etherscan lui-même n'a pas de méthode open source. Nous pensons qu'il peut utiliser une analyse manuelle pour résumer les règles afin d'identifier les actions DeFi, et qu'il manquera certains types qui ne peuvent pas être couverts manuellement. Il convient de noter ici qu'Etherscan ne fournit pas d'interface automatisée. Si vous souhaitez effectuer une reconnaissance à grande échelle, vous ne pouvez pas effectuer directement une telle tâche. L'exactitude et l'exhaustivité de DeFiRanger, qui est entièrement identifié par des règles cachées, ne sont pas satisfaisantes. Après avoir expérimenté ActCluster, nous avons constaté qu'après quatre cycles d'analyse itérative, il nous suffisait d'analyser un total de 2 000 paquets de transactions pour trouver 17 activités MEV inconnues. Après avoir supprimé certains de ces modules, nous devrons peut-être analyser manuellement jusqu'à 170 000 paquets de transactions pour identifier les 17 activités MEV inconnues que nous venons de mentionner.
Analyse empirique et application
Quelles sont les applications spécifiques de notre méthode d’identification des types inconnus d’activité MEV ? Premièrement, il peut améliorer les mesures d’atténuation des MEV actuellement existantes et être en mesure de se défendre contre certaines activités du MEV. La seconde consiste à utiliser les résultats de l'analyse pour voir si nous pouvons analyser de manière plus complète l'impact des activités MEV sur l'écologie de la blockchain, y compris l'impact sur le fork et la réorganisation de la forêt de blocs et la sécurité financière des utilisateurs.
Nous avons mentionné plus tôt que les attaquants du réseau MEV Boost exécuteront des outils pour obtenir les paquets de transactions des utilisateurs, puis les distribueront finalement aux mineurs et aux validateurs qui les connectent. Les relais supprimeront les paquets de transactions contenant des activités MEA des paquets de transactions qu'ils reçoivent. De cette manière, ils pourront réduire certains impacts négatifs des activités MEA sur la blockchain. L'idée principale de ce lien est de concevoir des règles correspondantes à travers la définition des activités MEV existantes pour détecter si le package de transactions contient des activités MEV. Évidemment, ces relais ne sont pas en mesure d'exclure certains packages de transactions contenant des activités MEV inconnues. Sur la base de notre flux de travail, nous avons conçu un outil MEVHunter capable de détecter le nouveau type d'activité MEV que nous avons détecté à partir du package de transaction.
Les résultats de la détection montrent que plus d'un million de packages de trading contiennent des activités MEV d'arbitrage inversé, et que 30 % des 6 millions autres packages de trading contiennent trois activités MEV connues. Concernant nos activités MEV nouvellement découvertes, nous avons constaté que près de la moitié des packages de transactions contenaient uniquement ces nouvelles activités MEV. Si les relayeurs utilisent l'outil MEVHunter, cela peut les aider à filtrer 3 millions de packages de transactions contenant des activités MEV, puis ils peuvent choisir d'éliminer ces packages de transactions pour réduire l'impact négatif des activités MEV sur la blockchain.
La deuxième application est que nous explorons l’impact des nouvelles activités MEV sur les forks et les réorganisations de la blockchain. Certaines études antérieures ont indiqué que certains mineurs financiers seraient motivés par les avantages de certaines activités MEV pour créer et réorganiser la blockchain actuelle, mener eux-mêmes les activités MEV et profiter des avantages. Par exemple, lorsque le revenu de l'activité MEV d'un bloc est 4 fois supérieur à la récompense du bloc, pas moins de 10 % des mineurs vont bifurquer et réorganiser le bloc.
Nous identifions d'abord quels packages de transactions contiennent de nouvelles activités MEV sur la base de l'outil MEVHunter que nous venons de mentionner, puis utilisons les revenus des mineurs dans ces packages de transactions pour estimer l'intensité correspondante de ces activités MEV. Un concept doit être introduit ici : dans le mécanisme des paquets de transactions, afin de garantir que leurs paquets de transactions d'arbitrage puissent être mis en chaîne, ces arbitragistes partagent généralement une partie des revenus des activités MEV avec les mineurs, puis les mineurs finiront par choisir le package de transaction avec le rendement le plus élevé à mettre sur la chaîne. Nous pouvons utiliser ces revenus pour estimer uniformément l’activité MEV dans chaque package de transaction. Selon nos résultats statistiques, nous avons constaté qu'il existe plus de 900 blocs avec des récompenses MEV quatre à huit fois supérieures à la récompense de bloc. De plus, la récompense MEV d'un bloc est même plus de 700 fois supérieure à la récompense de bloc. Nous utilisons le cadre de prise de décision de Markov pour déterminer le nombre minimum de mineurs qui peuvent être motivés pour effectuer des forks de blocs et des réorganisations étant donné un revenu MEV. Nous avons finalement découvert qu'il existe plus de 1 000 blocs qui peuvent motiver pas moins de 10 % des mineurs à faire des forks et des réorganisations de blocs. Pour le bloc le plus sérieux, pas moins de 6 mineurs sur 10 000 sont chargés de bifurquer et de réorganiser le bloc.
La troisième application consiste à explorer l’impact des activités MEV sur la sécurité financière des utilisateurs de la blockchain. Les activités MEV peuvent en fait entraîner une prolongation du temps d'attente pour que les transactions des utilisateurs de blockchain soient téléchargées sur la chaîne du pool de transactions ou du réseau P2P. C'est également l'une des principales menaces pour la sécurité financière des utilisateurs causées par les activités MEV. Si les transactions des utilisateurs sont retardées en chaîne, les arbitragistes peuvent avoir plus de temps pour concevoir des activités MEV plus complexes et plus rentables. La troisième application consiste à comparer l'impact de l'activité MEV sur le temps d'attente pour que les transactions des utilisateurs soient finalement téléchargées sur la chaîne. La première étape consiste à collecter le temps d’attente de la transaction. Nous déployons principalement des nœuds sur le réseau, puis enregistrons l'heure à laquelle la transaction est découverte pour la première fois sur le réseau, l'heure à laquelle la transaction est finalement téléchargée sur la chaîne, et enfin calculons le temps d'attente. Nous utilisons les trois quartiles des temps d'attente de toutes les transactions dans chaque bloc pour réaliser des statistiques, afin de pouvoir organiser les temps d'attente des transactions en une série chronologique par bloc. Ensuite, l'activité MEV correspondante dans chaque bloc est également caractérisée par les revenus obtenus par les mineurs de chaque bloc à partir du package de transactions contenant la nouvelle activité MEV. De cette manière, nous obtenons plusieurs séries chronologiques. Nous évaluons l'impact de l'activité MEV sur le temps de négociation grâce au test de causalité de Granger. Le test de causalité peut déterminer si les fluctuations d'une série temporelle entraînent des fluctuations dans une autre série temporelle, et sur quelle plage cela affecte ou provoque d'autres fluctuations. Lorsque l'activité MEV fluctue, le temps d'attente pour les transactions des utilisateurs s'allonge-t-il, et sur combien de blocs ultérieurs l'impact se fera-t-il sentir ?
Lorsque la valeur P du test de causalité est inférieure ou égale à 0,5, cela signifie que le temps d'attente des transactions dans ce bloc a été prolongé par l'influence des activités MEV précédentes. Selon les résultats de l'analyse, on constate que lorsque l'activité MEV se produit, le temps d'attente de 50 % des transactions dans les deux blocs suivants sera prolongé. Lorsque l'activité MEV se produit, le temps d'attente pour 25 % des transactions dans les 30 prochains blocs sera prolongé. Les mineurs ou les validateurs placeront les transactions avec des frais de gaz relativement faibles à la fin du bloc encapsulé. Plus les frais de gaz d'une transaction d'un utilisateur sont bas, plus l'impact des activités MEV sera important et le temps d'attente sera prolongé.
En conclusion, nous avons d'abord expliqué comment trouver des activités MEV inconnues via le flux de travail et la conception détaillée des deux modules du flux de travail, puis nous avons vérifié l'efficacité du flux de travail grâce à une analyse empirique et répertorié trois applications en même temps. Jusqu'à présent, nous avons découvert 17 nouvelles activités MEV utilisant le workflow.
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.
Découverte du type inconnu de MEV dans les packages de transactions Ethereum
Invité : Zihao Li, doctorant, Université polytechnique de Hong Kong
Organisé par : aididiao.eth, Foresight News
Cet article est un résumé de la vidéo partagée par Zihao Li, doctorant à l'Université polytechnique de Hong Kong dans le cadre du programme Web3 Young Scholars. Le programme Web3 Young Scholars est lancé conjointement par DRK Lab, imToken et Crytape. De jeunes chercheurs de renom dans le domaine du cryptage seront invités à partager certains des derniers résultats de recherche avec la communauté de langue chinoise.
Bonjour à tous, je m'appelle Zihao Li, doctorant en troisième année à l'Université polytechnique de Hong Kong. Le sujet que j'ai partagé aujourd'hui est "Découvrir les activités MEV dans le package de transactions Ethereum". En termes simples, il s'agit de découvrir des types inconnus d'activités MEV dans le réseau Ethereum via des paquets de transactions. Tout d'abord, je donnerai une introduction relativement basique, comme le concept de MEV, le mécanisme de paquet de transactions et le contexte de notre travail. Ensuite, je présenterai en détail le flux de travail complet et quelques idées de conception, telles que les principes de conception utilisés pour concevoir le flux de travail ; quels sont nos ensembles de données ; quels outils nous utilisons pour évaluer notre flux de travail sur quels indicateurs, etc. Enfin, je présente trois applications comprenant les résultats d’analyses empiriques connexes.
Introduction au contexte : MEV, package de transaction, motivation
L'activité MEV fait référence aux arbitragistes de la blockchain générant des transactions d'arbitrage en surveillant le réseau blockchain, y compris l'état des blocs. Certaines informations sur les transactions sont réparties sur le réseau blockchain P2P, ou certaines transactions qui n'ont pas été officiellement téléchargées sur la chaîne sont stockées dans le pool de transactions des mineurs ou des vérificateurs. Lorsque l'arbitragiste surveille ces informations sur les transactions, il génère les siennes grâce à certaines stratégies. La transaction d'arbitrage, puis spécifie la transaction d'arbitrage à une certaine position dans le bloc suivant, par exemple, il veut être à la tête du bloc suivant, ou en d'autres termes, exécuter une transaction stratégique immédiatement après une certaine transaction pour se propager le même métier d’arbitrage. De cette manière, nous pouvons considérer les activités d’arbitrage à une certaine position comme des activités MEV. Par exemple, si un arbitragiste surveille les fluctuations du prix d'un actif, il peut acheter l'actif correspondant dans un pool de négociation à bas prix, puis le revendre à un prix élevé dans un autre pool à prix élevé. Ceci est considéré comme une activité MEV.
À l'heure actuelle, les activités MEA sont principalement menées par des arbitragistes autour de l'écologie DeFi, car l'écologie DeFi rassemble actuellement principalement des actifs. Jusqu'à présent, l'écologie DeFi d'Ethereum et d'autres chaînes a attiré plus de 40 milliards de dollars de capitaux. Il faut ici mentionner un concept sur l'écologie DeFi, appelé action DeFi, qui correspond au fonctionnement de service atomique fourni par une application DeFi. Par exemple, on sait que l'AMM prend en charge l'échange entre différents types d'actifs. Les utilisateurs peuvent vendre un USDC , puis obtenez une somme d'ETH, une telle opération peut être définie comme une action DeFi. Nous pouvons utiliser l'action DeFi pour exprimer les activités MEV. Par exemple, si un utilisateur détecte qu'il existe un écart entre les prix des actifs sur différents AMM, l'utilisateur peut acheter à bas prix et vendre à un prix élevé, et finalement obtenir un profit sur la différence de prix. Nous pouvons exprimer cette activité MEV sous la forme de deux actions DeFi.
À l'heure actuelle, la recherche universitaire sur les activités MEV est principalement divisée en trois catégories, à savoir les attaques sandwich, l'arbitrage inversé et la liquidation. Dans l'ensemble de données sur lequel nous travaillons, nous avons constaté que ces trois types d'activités MEV apparaissent plus d'un million de fois. Il y a en fait un problème ici, une fois que nous connaissons la définition de ces activités MEV, comment identifier l'occurrence des activités. Si nous voulons identifier ces activités MEV, nous devons identifier toutes les activités de l'arbitragiste, telles que les transactions générées par l'arbitragiste et les types d'arbitrage inclus dans ces transactions. Nous pouvons ensuite déterminer quel type d'activité MEV se produit actuellement. . , et l’ensemble du processus repose en grande partie sur notre définition de l’activité MEV connue. Prenons l'exemple d'une attaque sandwich.Une fois que nous connaissons la définition d'une attaque sandwich, si nous voulons déterminer la valeur d'arbitrage de l'attaque sandwich et les transactions d'arbitrage correspondantes, nous devons établir de nombreuses règles basées sur la définition, puis filtrer les attaques sandwich candidates grâce à ces règles d'arbitrage de valeur et de commerce. Lors de l'identification des types d'attaques MEV connus de cette manière, deux questions se posent : La première est de savoir si les trois activités MEV courantes que nous connaissons peuvent représenter toutes les activités MEV ? Évidemment non, car l’écosystème DeFi est en constante évolution, de nouvelles applications sont toujours développées et les stratégies de ces arbitragistes sont en fait constamment itératives. La deuxième question est de savoir comment découvrir ces activités MEV inconnues. Jetons un coup d'œil au mécanisme du package de transactions en gardant cette question à l'esprit.
Le mécanisme de package de transactions a été proposé pour la première fois en 2021. En termes simples, les utilisateurs peuvent organiser une file d'attente de transactions. La longueur de cette file d'attente de transactions peut être une ou plusieurs transactions, puis l'utilisateur envoie ces transactions au réseau blockchain. Le relais les collecte transactions et les envoie directement et en privé aux mineurs ou vérificateurs concernés. Actuellement, les relayeurs exécuteront des packages de transactions pour entreprendre des tâches de relais. Le mécanisme du paquet de transactions a une fonctionnalité très importante : lorsque ces utilisateurs construisent un paquet de transactions, ils peuvent placer les transactions d'autres personnes qui n'ont pas été téléchargées dans la chaîne dans un paquet de transactions, et l'ordre des transactions dans le paquet de transactions peut être manipulé arbitrairement. . A ce moment, l'utilisateur du package de trading ou l'arbitragiste qui utilise le package de trading peut concevoir ses règles d'arbitrage. Par exemple, il peut concevoir une stratégie plus complexe et plus rentable pour les activités MEV. En prenant l'attaque sandwich comme exemple, si aucun package de transaction n'est utilisé, un arbitragiste dans une attaque sandwich doit générer au moins une paire de transactions pour réaliser l'arbitrage, et cette paire de transactions d'arbitrage ne peut cibler que cette seule transaction. L'arbitrage généré par cette transaction d'attaque doit être exécuté dans un certain ordre pour garantir qu'il puisse être arbitré avec succès. Mais si un arbitragiste utilise un package de trading, il peut collecter de nombreuses transactions pouvant être arbitrées.Il lui suffit d'utiliser une paire de transactions d'arbitrage correspondantes pour générer un arbitrage sur plusieurs transactions en même temps. Tant que ce paquet de transactions est sur la chaîne, il réussira certainement l'arbitrage, et comme il arbitre plusieurs transactions arbitrables en même temps, ses résultats d'arbitrage sont également plus rentables.
Le package commercial se caractérise par des activités MEV très riches et complexes. Parce que les utilisateurs qui utilisent des packages de transactions encapsulent leurs transactions complètes dans le package de transactions, puis l'envoient au relais du réseau P2P, et enfin aux mineurs et vérificateurs correspondants. Nous pouvons identifier avec précision et complètement toutes les activités grâce à des packages de transactions. Par conséquent, nous pouvons identifier plus précisément certaines activités MEV inconnues grâce au support du package de transaction.
Idées de flux de travail et de conception
Ensuite, nous présenterons notre flux de travail en détail. Comment pouvons-nous découvrir des activités MEV inconnues via un support tel que les packages de transactions ? Le flux de travail principal comprend deux outils. Premièrement, nous utilisons l'outil ActLifter pour identifier chaque action DeFi dans le package de transaction une fois que le relais a collecté le package de transaction. Après avoir obtenu le résultat, nous exprimons toutes les actions du package de transaction. Utilisez ensuite l'outil ActCluster pour rassembler les packages de transactions avec des activités similaires via la méthode de clustering et découvrez plus rapidement de nouvelles activités MEV grâce aux résultats du clustering. Si nous voulons découvrir des activités MEV inconnues, il est inévitable de confirmer manuellement si l'activité MEV est d'un type inconnu. Bien entendu, l'objectif de notre conception de travail est de minimiser autant que possible la charge de travail manuelle et de rendre l'ensemble du processus aussi fluide que possible et s'effectue automatiquement.
Il existe déjà des outils permettant d'identifier l'activité MEV à partir des transactions. Nous pouvons grossièrement le diviser en deux catégories : la première catégorie est constituée de règles récapitulatives purement manuelles et la deuxième catégorie est constituée de règles heuristiques pures, c'est-à-dire utilisant une règle heuristique purement automatisée pour identifier des types spécifiques d'activités MEV. Par exemple, après avoir reconnu certaines informations de transfert actuelles, il vérifie si les règles heuristiques sont satisfaites et, si elles sont satisfaites, il peut identifier les activités correspondantes. La première méthode purement manuelle de résumé des règles peut obtenir une meilleure précision, car ce processus est une analyse entièrement manuelle d'applications spécifiques, et elle peut ensuite garantir que les résultats de détection sont précis, mais la tâche d'analyse implique une charge de travail très importante, elle ne peut donc pas couvrir chaque application DeFi. Bien que le deuxième travail puisse réaliser une automatisation pure, les règles heuristiques ne peuvent couvrir que certains types spécifiques. D’un autre côté, il existe certains problèmes dans la conception de la règle heuristique, ce qui conduit à une précision de reconnaissance insatisfaisante.
Nous avons conçu notre flux de travail en combinant les avantages des deux méthodes. Nous pouvons identifier dix actions DeFi actuellement majeures. Il nous suffit de déterminer manuellement quel événement dans l'application DeFi correspond à quel type d'action DeFi après son lancement. Nous n'avons alors pas besoin d'analyse manuelle et pouvons complètement le laisser à une analyse automatisée. Le deuxième type de méthode peut identifier de manière entièrement automatique les actions DeFi, mais il ne peut pas déterminer si l'objet analysé est lié aux activités MEV. Par exemple, si nous identifions un transfert SWAP, il peut identifier deux combinaisons de transfert totalement indépendantes comme une seule action DeFi. Naturellement, le résultat de son identification sera erroné. Mais nous pouvons utiliser ces informations pour filtrer les informations réellement liées aux actions DeFi. Après avoir obtenu ces informations, nous pouvons éviter certaines erreurs comme celles qui se produisent dans le deuxième type de méthode grâce à des méthodes automatisées.
Par exemple, il s'agit ici d'une transaction impliquant un total de quatre transferts. Leur ordre d'occurrence, leur montant et leur catégorie de fonds sont marqués par des numéros de série. Au cours de ce processus, AMM a en fait déclenché un événement lié à l'action Swap. Une fois que le premier type de méthode a déterminé que l'événement est initié, il doit restaurer le contenu actuel via certains paramètres de l'événement. Par exemple, il doit examiner le code, la logique métier et certaines variables de fonction du contrat 699 pour récupérer le contenu actuel. Après avoir obtenu ces informations, nous avons conçu une règle basée sur ses caractéristiques uniques de transfert d'actifs. Par exemple, la règle que nous avons affinée est que le contrat DeFi actuellement en vigueur reçoit et transfère différents types d'actifs. Lorsque nous constatons qu'il existe deux transactions comme celle-ci Une fois que le transfert d'actifs répond à ces caractéristiques, nous pouvons restaurer le contenu de l'action d'échange correspondante. Le deuxième type de méthode associe directement deux transferts d'actifs : les deux comptes de transfert d'actifs reçoivent et transfèrent différents types d'actifs. Les premier et cinquième transferts seront considérés comme une paire de transferts liés, et le compte du milieu est considéré comme un AMM. Évidemment, nous pouvons intuitivement voir que le résultat de l'identification est inexact.
Les règles que nous résumons par analyse manuelle sont les types d'actions DeFi correspondant aux événements pertinents. Bien que les résultats soient résumés par analyse manuelle, nous faisons toujours de notre mieux pour affiner le processus d'analyse manuelle en un processus semi-automatique, afin de garantir que notre fiabilité totale du processus. Nous vérifierons le site officiel des applications DeFi, les documents des développeurs, y compris certains codes sources de contrat des sites officiels de DeFiPulse.com et Dapp.com. Nous développons des outils d'analyse qui peuvent extraire certaines descriptions d'événements dans les documents à partir de ces matériaux impliqués, comme la façon dont cet événement est défini avec des jetons et dans quelles fonctions, extraits de code et commentaires de code où ces événements sont utilisés. Après avoir extrait ces éléments, grâce à notre analyse manuelle et à nos discussions, nous avons finalement déterminé qu'il existe 88 événements correspondant à différents types d'actions DeFi.
Nous saisissons la transaction à analyser dans ce dictionnaire et analysons les événements survenus dans la transaction. Ensuite lorsqu'un événement apparaît dans ce dictionnaire, nous extrayons des informations clés selon les règles correspondantes, comme quel contrat opère cette action DeFi, puis quel est le type de cette DeFi, et quels transferts d'actifs sont liés à cette action DeFi. Après avoir obtenu ce contenu, nous résumerons les règles caractéristiques du transfert d'actifs, puis utiliserons cette règle pour correspondre à l'action DeFi finale. A partir de dix définitions de l’action DeFi, nous résumons les règles caractéristiques du transfert d’actifs. Après avoir collecté ces informations à l'étape précédente, nous utiliserons ces règles de correspondance pour la correspondance et nous aiderons enfin à identifier quel contenu spécifique s'est produit dans quelle DeFi dans cette transaction. Une fois qu'ActCluster a reconnu chaque transaction dans le package de transactions, nous pouvons exprimer le comportement du package de transactions.
Comprenons d'abord les principes de conception d'ActCluster. Nous savons que l'analyse manuelle est inévitable dans ce processus et qu'elle doit s'appuyer sur un travail manuel pour déterminer si l'activité du package de transaction est un type inconnu d'activité MEV. Sur cette base, notre idée de base est de regrouper certains packages de transactions avec des activités similaires. Pour chaque cluster, il nous suffit d'échantillonner au hasard un ou plusieurs packages de transactions pour analyse, ce qui peut accélérer le processus d'analyse manuelle et finalement découvrir différents types d'activités MEA. Lorsque nous utilisons l’analyse cluster pour regrouper des packages de transactions, nous sommes confrontés à un dilemme. Lorsque nous définissons la force de regroupement des packages de transactions de manière relativement grossière, les packages de transactions contenant différents types d'activités seront regroupés. À ce stade, même si le nombre de clusters deviendra plus petit, les tâches d'analyse manuelle correspondantes deviendront également plus petites. Moins, mais certaines nouvelles activités MEV nous manqueront. Si nous ajustons l'intensité du clustering pour qu'elle soit plus détaillée, même si nous pouvons distinguer certains paquets de transactions correspondant à des activités MEA similaires mais différentes, la charge de travail d'analyse manuelle impliquée sera considérablement augmentée.
Sur la base d'un tel problème, nous avons conçu une méthode d'analyse de clustering itérative, qui effectue une analyse de clustering en plusieurs itérations. À chaque tour, nous supprimerons les packages de transactions connus contenant de nouvelles activités MEV découvertes lors des tours précédents, puis améliorerons la force de clustering des packages de transactions restants. Nous ne pouvons pas utiliser directement les méthodes de clustering traditionnelles pour regrouper les packages de transactions, car les packages de transactions contiennent en fait plusieurs transactions et une transaction peut contenir plusieurs actions DeFi. Si l’on exprime l’ensemble de la transaction, sa structure est en réalité hétérogène et hiérarchique. À l’heure actuelle, nous utilisons la méthode d’apprentissage de la représentation pour représenter le contenu de ce package de transactions dans un espace de positionnement. L'avantage de l'apprentissage par représentation est que nous n'avons pas besoin d'un apprentissage et d'une compréhension approfondis des données que nous voulons analyser et traiter, ni d'une riche connaissance du domaine. Nous n'avons besoin que d'un simple traitement orienté données.
Par exemple, il nous suffit d'étiqueter le package de transactions pour indiquer quelles activités MEV sont incluses dans le package de transactions. Si nous connaissons la définition d’une activité MEV, il nous est plus facile de concevoir les règles correspondantes et de détecter automatiquement si elle existe. Nous pouvons automatiquement étiqueter ces packages de transactions pour représenter l’apprentissage. Notre analyse cluster est de type itératif, et après chaque itération, nous pouvons découvrir de nouvelles activités MEV. À ce stade, nous pouvons réellement enrichir les étiquettes correspondant à ces activités MEV nouvellement découvertes dans notre processus d'apprentissage des représentations. Lorsque les étiquettes utilisées dans notre processus d'apprentissage de représentation sont enrichies, les performances et l'efficacité de l'ensemble de la formation du modèle d'apprentissage de représentation peuvent être améliorées de manière itérative, et la capacité de cet apprentissage de représentation à exprimer les activités du package de transactions peut également être améliorée de manière itérative. Il peut en fait y avoir plusieurs transactions dans un package de transaction, et il peut en fait y avoir plusieurs actions DeFi dans une transaction. Nous devons exprimer les besoins du package de transaction. Premièrement, pour chaque type d’action DeFi, nous définissons un paramètre standardisé, tel que quel contrat est en vigueur, et quelle est la quantité et le type d’actifs reçus et transférés ? Nous définissons chaque action DeFi de cette manière. Si nous identifions qu'il y a plusieurs actions DeFi dans une transaction, nous les représentons sous forme de blocs d'action, de sorte que le bloc de transaction correspondant à la transaction puisse être représenté, qui contient les informations source de la transaction, telles que qui a initié la transaction, et la redirection À qui est-il envoyé ? Lorsqu'une action DeFi se produit dans une transaction, nous la remplirons de blocs d'action dans l'ordre. Chaque transaction est représentée par un bloc de transaction, et enfin on obtient la structure du package de transaction, qui peut être considérée comme une matrice. Une fois ce package de transactions représenté, nous pouvons l'utiliser pour l'apprentissage de la représentation. Chaque package de transaction est une structure unifiée, et nous pouvons ensuite utiliser le modèle pour le traitement par lots.
Évaluation des performances
Nous partageons ensuite les méthodes que nous avons utilisées pour évaluer les performances du flux de travail. L'ensemble des données pour l'ensemble de notre processus d'analyse est fourni via l'API fournie par Flashbots, et les données des packages de transactions de février 2021 à décembre 2022 sont collectées, comprenant plus de 6 millions de packages de transactions et 26 millions de transactions.
Nous avons conçu quelques outils pour comparer l'exactitude et l'exhaustivité des actions DeFi. Il convient de noter ici que parmi ces outils en chaîne, actuellement seul Etherscan peut restaurer l'action DeFi dans la transaction via sa page web et les informations qu'elle fournit. Et comme DeFiRanger, nous reproduisons leurs méthodes à partir de leurs articles. De plus, nous avons conçu un outil appelé EventLifter pour tenter de récupérer les actions DeFi directement à partir des événements de transaction. Nous avons testé ActLifter sous différentes configurations et utilisé divers outils pour comparer la précision de la reconnaissance. Pour ActCluster, notre idée principale est d'adopter la méthode d'apprentissage par ablation. Pour les nouvelles activités qui peuvent être identifiées, après ablation de certains modules d'ActCluster, si nous voulons encore identifier de nouvelles activités qui n'ont pas été trouvées, dans quelle mesure avons-nous besoin d'analyser manuellement ? Quelle est la taille du paquet de transactions ou la charge de travail de notre analyse manuelle. Par exemple, nous avons effectué une ablation de la mise à jour dynamique des étiquettes dans le module d'apprentissage de la représentation ActCluster, et nous avons en fait supprimé l'ensemble du processus. Nous prenons un échantillon aléatoire de 6 millions de paquets de transactions et voyons combien de paquets de transactions nous devons analyser manuellement pour découvrir la même quantité de nouvelle activité MEV.
Nos outils peuvent atteindre une précision et une exhaustivité proches de 100 % dans des conditions de configuration uniforme. Mais comme d’autres outils comme Etherscan, même si sa précision peut atteindre 100 %, ce qui est tout à fait satisfaisant, il manquera de nombreuses actions DeFi. Etherscan lui-même n'a pas de méthode open source. Nous pensons qu'il peut utiliser une analyse manuelle pour résumer les règles afin d'identifier les actions DeFi, et qu'il manquera certains types qui ne peuvent pas être couverts manuellement. Il convient de noter ici qu'Etherscan ne fournit pas d'interface automatisée. Si vous souhaitez effectuer une reconnaissance à grande échelle, vous ne pouvez pas effectuer directement une telle tâche. L'exactitude et l'exhaustivité de DeFiRanger, qui est entièrement identifié par des règles cachées, ne sont pas satisfaisantes. Après avoir expérimenté ActCluster, nous avons constaté qu'après quatre cycles d'analyse itérative, il nous suffisait d'analyser un total de 2 000 paquets de transactions pour trouver 17 activités MEV inconnues. Après avoir supprimé certains de ces modules, nous devrons peut-être analyser manuellement jusqu'à 170 000 paquets de transactions pour identifier les 17 activités MEV inconnues que nous venons de mentionner.
Analyse empirique et application
Quelles sont les applications spécifiques de notre méthode d’identification des types inconnus d’activité MEV ? Premièrement, il peut améliorer les mesures d’atténuation des MEV actuellement existantes et être en mesure de se défendre contre certaines activités du MEV. La seconde consiste à utiliser les résultats de l'analyse pour voir si nous pouvons analyser de manière plus complète l'impact des activités MEV sur l'écologie de la blockchain, y compris l'impact sur le fork et la réorganisation de la forêt de blocs et la sécurité financière des utilisateurs.
Nous avons mentionné plus tôt que les attaquants du réseau MEV Boost exécuteront des outils pour obtenir les paquets de transactions des utilisateurs, puis les distribueront finalement aux mineurs et aux validateurs qui les connectent. Les relais supprimeront les paquets de transactions contenant des activités MEA des paquets de transactions qu'ils reçoivent. De cette manière, ils pourront réduire certains impacts négatifs des activités MEA sur la blockchain. L'idée principale de ce lien est de concevoir des règles correspondantes à travers la définition des activités MEV existantes pour détecter si le package de transactions contient des activités MEV. Évidemment, ces relais ne sont pas en mesure d'exclure certains packages de transactions contenant des activités MEV inconnues. Sur la base de notre flux de travail, nous avons conçu un outil MEVHunter capable de détecter le nouveau type d'activité MEV que nous avons détecté à partir du package de transaction.
Les résultats de la détection montrent que plus d'un million de packages de trading contiennent des activités MEV d'arbitrage inversé, et que 30 % des 6 millions autres packages de trading contiennent trois activités MEV connues. Concernant nos activités MEV nouvellement découvertes, nous avons constaté que près de la moitié des packages de transactions contenaient uniquement ces nouvelles activités MEV. Si les relayeurs utilisent l'outil MEVHunter, cela peut les aider à filtrer 3 millions de packages de transactions contenant des activités MEV, puis ils peuvent choisir d'éliminer ces packages de transactions pour réduire l'impact négatif des activités MEV sur la blockchain.
La deuxième application est que nous explorons l’impact des nouvelles activités MEV sur les forks et les réorganisations de la blockchain. Certaines études antérieures ont indiqué que certains mineurs financiers seraient motivés par les avantages de certaines activités MEV pour créer et réorganiser la blockchain actuelle, mener eux-mêmes les activités MEV et profiter des avantages. Par exemple, lorsque le revenu de l'activité MEV d'un bloc est 4 fois supérieur à la récompense du bloc, pas moins de 10 % des mineurs vont bifurquer et réorganiser le bloc.
Nous identifions d'abord quels packages de transactions contiennent de nouvelles activités MEV sur la base de l'outil MEVHunter que nous venons de mentionner, puis utilisons les revenus des mineurs dans ces packages de transactions pour estimer l'intensité correspondante de ces activités MEV. Un concept doit être introduit ici : dans le mécanisme des paquets de transactions, afin de garantir que leurs paquets de transactions d'arbitrage puissent être mis en chaîne, ces arbitragistes partagent généralement une partie des revenus des activités MEV avec les mineurs, puis les mineurs finiront par choisir le package de transaction avec le rendement le plus élevé à mettre sur la chaîne. Nous pouvons utiliser ces revenus pour estimer uniformément l’activité MEV dans chaque package de transaction. Selon nos résultats statistiques, nous avons constaté qu'il existe plus de 900 blocs avec des récompenses MEV quatre à huit fois supérieures à la récompense de bloc. De plus, la récompense MEV d'un bloc est même plus de 700 fois supérieure à la récompense de bloc. Nous utilisons le cadre de prise de décision de Markov pour déterminer le nombre minimum de mineurs qui peuvent être motivés pour effectuer des forks de blocs et des réorganisations étant donné un revenu MEV. Nous avons finalement découvert qu'il existe plus de 1 000 blocs qui peuvent motiver pas moins de 10 % des mineurs à faire des forks et des réorganisations de blocs. Pour le bloc le plus sérieux, pas moins de 6 mineurs sur 10 000 sont chargés de bifurquer et de réorganiser le bloc.
La troisième application consiste à explorer l’impact des activités MEV sur la sécurité financière des utilisateurs de la blockchain. Les activités MEV peuvent en fait entraîner une prolongation du temps d'attente pour que les transactions des utilisateurs de blockchain soient téléchargées sur la chaîne du pool de transactions ou du réseau P2P. C'est également l'une des principales menaces pour la sécurité financière des utilisateurs causées par les activités MEV. Si les transactions des utilisateurs sont retardées en chaîne, les arbitragistes peuvent avoir plus de temps pour concevoir des activités MEV plus complexes et plus rentables. La troisième application consiste à comparer l'impact de l'activité MEV sur le temps d'attente pour que les transactions des utilisateurs soient finalement téléchargées sur la chaîne. La première étape consiste à collecter le temps d’attente de la transaction. Nous déployons principalement des nœuds sur le réseau, puis enregistrons l'heure à laquelle la transaction est découverte pour la première fois sur le réseau, l'heure à laquelle la transaction est finalement téléchargée sur la chaîne, et enfin calculons le temps d'attente. Nous utilisons les trois quartiles des temps d'attente de toutes les transactions dans chaque bloc pour réaliser des statistiques, afin de pouvoir organiser les temps d'attente des transactions en une série chronologique par bloc. Ensuite, l'activité MEV correspondante dans chaque bloc est également caractérisée par les revenus obtenus par les mineurs de chaque bloc à partir du package de transactions contenant la nouvelle activité MEV. De cette manière, nous obtenons plusieurs séries chronologiques. Nous évaluons l'impact de l'activité MEV sur le temps de négociation grâce au test de causalité de Granger. Le test de causalité peut déterminer si les fluctuations d'une série temporelle entraînent des fluctuations dans une autre série temporelle, et sur quelle plage cela affecte ou provoque d'autres fluctuations. Lorsque l'activité MEV fluctue, le temps d'attente pour les transactions des utilisateurs s'allonge-t-il, et sur combien de blocs ultérieurs l'impact se fera-t-il sentir ?
Lorsque la valeur P du test de causalité est inférieure ou égale à 0,5, cela signifie que le temps d'attente des transactions dans ce bloc a été prolongé par l'influence des activités MEV précédentes. Selon les résultats de l'analyse, on constate que lorsque l'activité MEV se produit, le temps d'attente de 50 % des transactions dans les deux blocs suivants sera prolongé. Lorsque l'activité MEV se produit, le temps d'attente pour 25 % des transactions dans les 30 prochains blocs sera prolongé. Les mineurs ou les validateurs placeront les transactions avec des frais de gaz relativement faibles à la fin du bloc encapsulé. Plus les frais de gaz d'une transaction d'un utilisateur sont bas, plus l'impact des activités MEV sera important et le temps d'attente sera prolongé.
En conclusion, nous avons d'abord expliqué comment trouver des activités MEV inconnues via le flux de travail et la conception détaillée des deux modules du flux de travail, puis nous avons vérifié l'efficacité du flux de travail grâce à une analyse empirique et répertorié trois applications en même temps. Jusqu'à présent, nous avons découvert 17 nouvelles activités MEV utilisant le workflow.