Les transactions privées ne peuvent ni éliminer complètement le risque d'être attaqué ni réduire les frais du marché.
Discours : Wang Ye, professeur adjoint, Département des sciences de l'information et de l'informatique, Université de Macao
Compilation : aididiaojp.eth, Foresight News
*Cet article est une compilation de textes partagés par Wang Ye, professeur adjoint au Département des sciences de l'information et de l'informatique de l'Université de Macao dans le cadre du programme Young Scholars. Le programme Young Scholars est coparrainé par DRK Lab, imToken et Crytape. De jeunes chercheurs bien connus dans le domaine du chiffrement seront invités à partager certains des derniers résultats de recherche avec la communauté de langue chinoise. *
Avant de commencer, permettez-moi de me présenter brièvement. Je suis Wang Ye. Je travaille actuellement en tant que professeur adjoint au Département des sciences de l'information et de l'informatique de l'Université de Macao. Mes recherches actuelles portent sur DeFi et des domaines connexes. Nous considérons DeFi comme un marché financier émergent et recherchons des questions du point de vue de l'économie et de la finance, y compris l'analyse du comportement des utilisateurs et de la structure du marché. En outre, je prêterai également attention aux problèmes de sécurité potentiels qui existent lors de l'utilisation par l'utilisateur et à la manière de réduire certains dangers et problèmes de sécurité que les applications Web3 et DeFi peuvent entraîner en améliorant l'expérience utilisateur. Le contenu que je partage aujourd'hui est principalement lié à la première direction de recherche, c'est-à-dire que nous étudierons certains problèmes de comportement des utilisateurs sous le nouveau modèle dans un tel marché financier décentralisé émergent, et comment nous pouvons optimiser une telle structure de marché.
Un tel marché financier basé sur le système blockchain aura des problèmes endogènes.Nous ne connaissons pas certaines solutions communes sur le marché et l'impact de ces solutions sur l'ensemble du marché. Ensuite, nous présenterons comment modéliser les problèmes actuels du marché de la blockchain du point de vue de l'économie ou de la finance après avoir compris les problèmes existants, et comment utiliser le modèle pour l'analyse théorique. Dans la dernière partie, nous comparons et analysons les résultats de la recherche théorique avec les données expérimentales observées sur le marché de la blockchain, puis prouvons l'application de notre dérivation théorique sur le marché réel.
Tout le monde sait qu'il existe deux types différents de participants à la blockchain : l'un est des utilisateurs ordinaires, ce qu'ils font est d'envoyer leurs transactions à l'ensemble du réseau blockchain, puis s'attendre à ce que leurs transactions soient publiées sur le réseau est exécuté dans le système . L'autre type est généralement appelé un mineur, ou il peut être appelé un vérificateur dans le nouveau système.Ils recueilleront les transactions envoyées par ces utilisateurs dans le réseau et formeront un bloc. Lorsqu'un tel bloc est diffusé et vérifié par la plupart des participants au système, nous considérons que toutes les transactions de ce bloc ont été confirmées, ou complètement vérifiées avec succès. En cela, nous constaterons qu'il existe plusieurs problèmes fondamentaux qui sont très différents du marché financier traditionnel. Le premier problème est que les transactions sont transparentes jusqu'à ce qu'elles soient déterminées à s'exécuter et à s'exécuter. Au cours des deux dernières années, tout le monde a largement proposé le concept de Frontrunning. En fait, cette matière n'existe pas seulement dans le cadre de la finance décentralisée, mais a toujours existé dans la finance traditionnelle. Cela signifie simplement que la finance traditionnelle peut être utilisée. Certaines politiques ou règles et réglementations éliminent complètement les risques, mais dans le système blockchain, nous devons faire attention à ce problème.
Lorsqu'une transaction est diffusée sur le réseau public et avant qu'elle ne soit exécutée, elle est déjà observable par tous, ce qui implique un problème d'exposition au risque très sérieux. Deuxièmement, le deuxième problème très critique concerne l'ordre des transactions.À l'heure actuelle, le moyen le plus courant pour les mineurs de regrouper et de trier toutes les transactions est de les regrouper dans l'ordre en fonction du niveau des frais de traitement. Cela entraînera alors un problème très grave. À l'heure actuelle, les gens accordent de plus en plus d'attention à des problèmes connexes qui ne peuvent être ignorés sur le marché financier décentralisé, c'est-à-dire qu'il y aura un grand nombre d'attaques en cours d'exécution, ou nous pouvons collectivement référez-vous à eux dans de nombreux cas.Pour MEV, Running Attack peut être juste une partie de MEV.
Décrivons à nouveau brièvement ce processus : lorsque nous trouvons une transaction, elle n'a pas été exécutée. N'importe lequel de nos attaquants peut utiliser des informations connues pour créer une nouvelle transaction et fournir des frais de gaz plus élevés pour que la transaction nouvellement soumise soit exécutée avant la transaction divulguée. Cela est dû aux problèmes endogènes du système de blockchain, qui à l'heure actuelle ont toujours existé au moins dans le système de blockchain public et sont difficiles à interdire. Ensuite, passons en revue certains des modes d'attaque Frontrunning les plus courants.
Le premier mode d'attaque, je pense que beaucoup d'amis le connaissent peut-être, donnons donc une introduction plus claire ici. Ce mode s'appelle Sandwich Attack. Son point central est qu'il existe une tarification constante du fabricant de marché de produits via le mécanisme AMM lui-même. , avant qu'une transaction ne soit terminée, via une autre transaction à l'avance pour modifier le taux des frais de transaction sur le marché, puis après que le commerçant victime ait poussé davantage les frais de transaction vers un résultat plus extrême, puis via la transaction inverse pour obtenir Les fonds reçus sont échangés à un prix plus favorable, et les avantages sont obtenus grâce à la différence de taux de change contenue dans la transaction. Dans un tel mode d'attaque, nous pouvons voir que lorsqu'il y a une transaction victime sur le marché, cette transaction est généralement une transaction dans AMM, et l'attaquant utilisera une valeur plus élevée avant la transaction victime Frais de gaz pour une transaction frontale. Une fois cette transaction terminée, ils utiliseront une autre transaction pour effectuer une opération inverse et bénéficieront de la différence de taux de change entre les transactions précédentes et suivantes. C'est ce que nous appelons le premier type de Frontrunning.
Le deuxième type est l'attaque de suppression la plus courante. Sur le marché financier, le temps est un facteur très important. De nombreuses transactions exécutées un bloc plus tard et un bloc plus tôt entraîneront d'énormes fluctuations du marché, surtout si l'on considère que certaines transactions peuvent impliquer des prix de liquidation. La cible principale de cette classe d'attaques est telle opérations critiques. Par exemple, nous espérons que la transaction pourra être exécutée dans le bloc suivant. Si un attaquant malveillant observe cette transaction, puis expulse la demande de transaction d'un bloc spécifique avec une transaction qui propose des frais de gaz plus élevés, alors il est attaqué. La transaction peut attendre le ou les prochains blocs avant d'être exécuté. En raison du décalage horaire, nous pourrions ne pas être en mesure de terminer à temps les opérations de marché des transactions critiques, ce qui entraînerait des turbulences relativement graves sur le marché.
La troisième attaque s'appelle Displayment Attack, qui est une attaque d'arbitrage unique. Vous pouvez imaginer que lorsque nous effectuons des transactions cycliques, les prix du marché peuvent en fait être différents. Cependant, l'opportunité spéculative potentielle apportée par la différence de taux de change est ponctuelle. Si je peux lisser la différence de taux de change sur le marché grâce à des transactions répétées, les attaquants ultérieurs n'auront aucun moyen de spéculer pour réaliser un profit. visant à ce type d'opportunité d'arbitrage unique. Nous supposons que Tv est une transaction qui obtient des bénéfices par le biais de transactions de marché. Après qu'un attaquant malveillant a observé Tv, il peut effectuer exactement le même comportement de transaction de marché, mais la seule différence est qu'il utilisera sa propre transaction d'arbitrage Soumettre avec un gaz plus élevé frais. Ensuite, il sera exécuté à l'avance dans le véritable système de blockchain. Puisqu'il exécute d'abord l'opportunité d'arbitrage unique, la transaction de la télévision elle-même ne bénéficiera plus d'avantages.
Ces trois sont les attaques MEV sur lesquelles nous nous concentrons actuellement. En raison de la configuration du mécanisme du système, le réseau blockchain présente des problèmes endogènes. Lorsque nous disons que le Frontrunning est très courant, la prochaine question naturelle est de savoir si cette affaire est vraiment sérieuse et quelle perte de valeur le MEV entraînera-t-il ?
Nous avons une statistique selon laquelle en moins d'un an, les pertes financières causées par les attaques MEV sur le marché ont dépassé 80 000 Ethereum, ce qui signifie qu'il a causé pas mal de pertes économiques, c'est pourquoi tout le monde fera attention à ce problème , de nombreuses personnes réfléchissent également à la manière d'éliminer les attaques MEV. En plus de prêter attention aux pertes économiques, nous pensons également à l'impact supplémentaire de l'ensemble de l'incident sur le réseau blockchain, car il a non seulement causé des pertes économiques, mais a également gaspillé une certaine quantité d'espace de bloc.
Lorsque ce problème existe, tout le monde doit constamment réfléchir à la façon de le résoudre. La solution actuelle consiste à diffuser via Private Pool, qui s'appelait autrefois Relay Service. Les transactions ne se propagent pas seulement à travers un réseau distribué que les utilisateurs exposent, elles fournissent un canal de communication privé qui permet une connexion directe entre les utilisateurs et les mineurs. A travers un tel canal de communication, vous pouvez imaginer que l'avantage est que nous n'aurons plus de fuite d'informations. Puisque nous pensons que Frontrunning fait également partie de MEV, ce type de pool privé est introduit dans le réseau dans l'espoir de minimiser l'apparition de Frontrunning.
À l'heure actuelle, Frontrunning Attack est causée par une fuite d'informations dans le système de blockchain. Nous savons également que certaines personnes ont proposé de nouveaux mécanismes pour éviter cette situation. Donc, si le nouveau mécanisme peut jouer un rôle et quel type d'impact il aura sur le système de blockchain, deviennent naturellement les questions que nous voulons étudier.
Lorsque nous introduisons Private Channel dans la blockchain, quel impact cela aura-t-il sur l'ensemble de l'écosystème ? Tout d'abord, sera-t-il largement accepté par les utilisateurs et les validateurs de blocs ? Parce qu'ils sont les principaux participants de tout notre système. Ensuite, la deuxième question est de savoir s'il a atteint notre objectif après avoir été accepté, qui est de réduire les frais de transaction et d'éviter le Frontrunning. Le troisième point est qu'après l'introduction du nouveau mécanisme, quel genre d'impact aura-t-il sur tous les utilisateurs de l'ensemble du système ? Ce sont les trois questions de recherche que nous avons soulevées après avoir découvert des solutions possibles.
Nous construisons des modèles pour étudier et expliquer l'impact possible de différents choix faits par différents acteurs sur le marché, et enfin faire des prédictions, puis nous comparons et analysons le comportement des utilisateurs du marché lui-même et nos résultats d'analyse théorique. Ensuite, nous montrerons ici comment diviser le problème en trois étapes. Nous avons impliqué trois hypothèses différentes dans notre modèle en trois étapes. La première est que nous pensons que les participants sont rationnels, ce qui est une hypothèse courante dans de nombreuses recherches économiques et financières. Deuxièmement, nous penserons que certaines transactions courront le risque d'être attaquées, et il y aura des transactions qui ne seront jamais attaquées dans le système. En même temps, nous construirons un modèle basé sur les arbitragistes ou les attaquants qui existent dans ce marché.
Dans tout le système, nous pensons que toutes les transactions ont deux canaux de transaction différents, l'un est notre réseau public commun distribué Public Pool, et l'autre est le réseau privé Private Pool. Enfin, nous supposons que chaque bloc dispose de suffisamment d'espace pour accueillir les transactions. Ensuite, à différentes étapes de ce modèle, chaque utilisateur et chaque vérificateur doit choisir l'un des réseaux pour les transactions. Tout d'abord, le premier choix est le vérificateur, le second est l'utilisateur et le dernier est l'attaquant, ce qui est en fait conforme à notre mode de fonctionnement normal dans le système de blocs. Une fois que ces trois participants différents ont fait leur choix, nous effectuons ensuite un calcul inverse de l'état dans lequel l'ensemble du marché entrera finalement.
Tout d'abord, les mineurs ont deux options différentes : la première option est de ne pas rejoindre le système Flashbots et la seconde est de le rejoindre. Évidemment, ces deux options existent toujours pour eux, s'ils restent dans le canal public, ils ne peuvent voir que les transactions qui existent dans le Public Mempool. Mais s'ils rejoignent le pool privé, ils peuvent voir non seulement les transactions de Mempool, mais également les transactions du pool privé. Dans la première étape du modèle, chacun fera une sélection, puis nous utiliserons alpha pour indiquer la proportion de la sélection à l'aide de la flashbox.
La deuxième partie concerne le choix de l'utilisateur dans l'ensemble de la transaction. Vont-ils choisir de proposer leurs propres transactions dans le Mempool, ou choisiront-ils de proposer dans le Private Pool ? S'ils proposent des transactions dans le Mempool, ils risquent alors d'être attaqués. Ils peuvent également choisir Private Pool, mais il y a certains risques. La principale source de ce risque est que ces transactions qui rejoignent le Private Pool peuvent ne pas gagner à 100% le droit d'enregistrer le bloc suivant, mais nous pouvons continuer à proposer des transactions plus tard.
La troisième étape est que l'attaquant observera les transactions attaquables et effectuera les transactions d'attaque. Par exemple, un attaquant observe la transaction P et décide d'attaquer cette transaction publique. Lorsqu'un attaquant soumet sa propre transaction, il est également confronté à deux choix, soit dans le pool public, soit dans la Flashbox. Si un attaquant soumet une transaction dans le pool public, il peut enchérir pour des offres plus élevées en plusieurs tours, et le gaz de sa transaction augmentera progressivement. Il s'agit d'un mode d'attaque courant dans de nombreux cas. S'il se trouve dans le pool privé, l'attaquant ne sait pas s'il y a d'autres attaquants en concurrence avec lui en même temps. Si dans la piscine publique, si quelqu'un d'autre rivalise avec l'attaque, les attaquants peuvent en fait se connaître. Mais dans le pool privé, premièrement, l'attaquant ne sait pas s'il y a de la concurrence, et deuxièmement, je ne sais pas combien de frais d'essence le concurrent a payé, donc les attaquants deviennent une nouvelle relation concurrentielle, ce qui les causera faire des compromis. Les frais de gaz qu'ils sont prêts à payer seront en fait très différents. Si la transaction de l'attaquant est finalement acceptée, il finira par avoir un profit C, qui est également la perte économique causée.
Ensuite, il est temps d'équilibrer. Le premier concerne les utilisateurs et les attaquants, le principal compromis auquel ils sont confrontés est en fait le risque opérationnel.
Les utilisateurs doivent peser si mes informations de transaction seront divulguées ou si je suis en sécurité, et l'attaquant ne donnera pas ses informations de transaction à un autre attaquant. Ils sont également confrontés au même risque opérationnel, c'est-à-dire que les validateurs du pool privé n'ont pas le droit à 100% d'enregistrer le bloc suivant, il y a donc une forte probabilité que cette transaction ne soit pas incluse dans le bloc suivant, même si c'est inutile payer suffisamment de frais d'essence.
Les utilisateurs qui n'ont pas rejoint Flashbots, ils n'ont qu'à trier ces transactions en fonction des frais de gaz de haut en bas, mais s'ils rejoignent Flashbots, ils doivent d'abord classer les transactions proposées par le pool privé dans le bloc, puis vérifier Le reste de l'accord. Par exemple, la transaction K est inférieure aux frais de gaz de ses transactions précédentes et suivantes, mais la transaction K est toujours placée au premier plan pour vérification.
Une fois le catalogue des modèles hypothétiques établi, nous analyserons progressivement les choix que vous ferez selon trois perspectives. Nous effectuons d'abord une analyse comportementale du point de vue de l'attaquant. Les attaquants seront naturellement confrontés à des frais de gaz de plus en plus élevés après avoir traversé une concurrence continue.C'est une conclusion fondamentale, nous constaterons que le prix du gaz qu'ils doivent soumettre dans le pool privé est beaucoup plus élevé que le prix du gaz qu'ils doivent soumettre dans le pool public prix. Mais beaucoup d'entre eux choisiront toujours Private Pool. Il y a deux raisons principales. La première raison est que les transactions d'arbitrage qu'ils soumettent dans Private Pool ne seront pas vues par d'autres attaquants, et ils n'ont pas besoin de faire des enchères, c'est un avantage . Le second avantage réside dans l'ordre de tri des blocs : s'il est déposé via le Private Pool, sa priorité est naturellement supérieure à celles proposées par le Public Pool. Dans ce cas, les attaquants choisiront naturellement le Private Pool, mais en même temps, afin d'éviter l'impact des risques opérationnels, ils choisiront également de trader dans certains Public Pools en même temps.
L'étape suivante est le compromis pour les utilisateurs. Ils prendront principalement en compte deux facteurs, l'un étant le taux d'adoption et l'autre la probabilité d'attaques potentielles. Si a est relativement grand, alors vous pouvez en fait imaginer que le risque opérationnel auquel ils sont confrontés est relativement faible, et ils seront naturellement plus enclins à utiliser Private Pool. Si l'alpha est très petit, il peut ne pas être utile pour eux de soumettre dans le passé, donc la piscine publique deviendra leur choix.
Aussi pour la partie c, c'est en fait un facteur très important. Nous avons constaté que si C est suffisamment grand, ils n'ont en fait pas d'autre choix que de proposer une transaction dans le pool privé. Si cela se produit, nous pouvons le savoir. En fait, les opportunités d'arbitrage pour les attaquants sont complètement éliminées.Si tout le monde n'utilise pas le pool public, alors cette question n'existera plus du tout. Mais nous devons également considérer un point : en fait, en fonctionnement réel, toutes les transactions qui causent le MEV n'ont pas un espace d'arbitrage aussi élevé.
Ce que nous pouvons voir en ce moment, c'est dire que beaucoup d'offres peuvent être prises en sandwich et peut-être qu'elles n'ont que quelques dollars en retour. Une fois que l'attaquant a terminé l'attaque, il doit parfois même distribuer la plupart des bénéfices aux mineurs, et l'incitation restante peut être inférieure à 1 $. En fait, il existe de nombreux cas où C est très petit. Dans ce cas, ils ne choisiront pas Private Channel, car Private Channel n'est pas un choix optimal pour eux. La raison principale est que pour de nombreux utilisateurs, ils ne se soucient pas de savoir si leurs transactions sont attaquées ou non, ils sont prêts à assumer le risque d'être attaqués et ils estiment que courir des risques est pire pour eux. Dans ce cas, nous savons que si le taux d'adoption n'est pas de 100%, alors de nombreuses transactions doivent être attaquées.
Ensuite, pour répondre à la deuxième question, la taxe de priorité a-t-elle été réduite ? Notre conclusion finale est que même après l'introduction du pool privé, les frais de priorité ne seront pas réduits. Il y a deux facteurs principaux ici.La première partie, en fait, comme vous pouvez l'imaginer, les vérificateurs choisiront d'utiliser Private Pool uniquement lorsqu'ils obtiennent des frais plus élevés, ce qui augmente naturellement les frais de référence pour entrer dans le bloc. Un autre facteur est que certaines personnes peuvent être vulnérables aux attaques, elles ne sont donc pas disposées à choisir le pool public. Pour le moment, elles préfèrent utiliser le pool privé pour les transactions. Ces transactions qui n'apparaîtraient pas dans le pool privé augmenteront encore la priorité. frais. La conclusion fondamentale finale est qu'elle a entraîné une augmentation des taxes de priorité.
La dernière question centrale est de savoir si la valeur globale des blocs qui nous préoccupent a augmenté ? Nous pouvons penser à ce facteur central car la chaîne privée ne peut pas réellement atteindre un taux d'adoption de 100 %, il y aura donc encore beaucoup de Frontrunning, qui occupera notre propre espace de bloc. Ensuite, après l'introduction, puisque ces attaques en cours qui génèrent des MEV n'apportent pas réellement de nouveaux avantages réseau au système, elles obtiennent une partie des récompenses des utilisateurs attaqués en tant que leurs propres retours spéculatifs, et elles n'en apporteront pas au système. Nouvelle valeur, donc de ce point de vue, même après avoir un pool privé, nous ne pouvons toujours pas atteindre l'état d'allocation optimal et efficace du réseau. Dans le même temps, en raison de l'existence de MEV, dans l'ensemble du système, plus le bien-être global du réseau est élevé, plus le choix le plus avantageux pour les vérificateurs ne l'est pas. Dans ce cas, le choix des mineurs conduira également au fait que le bien-être du réseau de notre système final ne peut pas atteindre une solution optimale.
Ensuite, nous irons plus loin pour discuter s'il existe des méthodes potentielles pour nous aider à résoudre ces problèmes. L'argument central est que le retour spéculatif de l'attaquant et l'allocation optimale des ressources du réseau sont en fait incompatibles. Les attaquants ont besoin de la génération de MEV pour les aider à augmenter leur taux de rendement. En fait, une méthode possible consiste à modifier la répartition inégale de la valeur du réseau, c'est-à-dire à inciter les attaquants à s'engager dans une méthode de participation au réseau plus raisonnable et efficace.
Enfin, je voudrais partager brièvement avec vous quelques données que nous avons obtenues après analyse théorique. Tout d'abord, nous regardons en fait le taux d'acceptation des Flashbots. Ce que nous faisons principalement est de voir si le bloc de transaction est intuitivement reflété par cette partie des données. Ensuite, nous constatons que la transaction est toujours dans un tel état à l'heure actuelle, ni tout le monde ne l'a vu, ni cela ne signifie que tout le monde peut le voir.C'est notre première conclusion. La deuxième conclusion que nous avons obtenue est que la probabilité que les utilisateurs choisissent Private Pool a en fait une corrélation positive très évidente avec leur vulnérabilité aux attaques.
Dans la troisième partie, nous avons obtenu une conclusion temporelle. Nous avons constaté que, par rapport aux attaquants du Mempool, les attaquants du Private Pool n'ont pas besoin d'enchérir tour après tour. Les attaquants qui obtiennent le MEV doivent se soumettre à Les frais de mineur sont beaucoup plus élevés. Dans Public Pool, le taux de distribution moyen est d'environ 0,3, mais dans Flashbox, il est passé à près de 0,8. Nous avons constaté que la probabilité de choisir un Private Pool est en fait positivement corrélée avec leur risque d'être attaqué. Cette image est une telle distribution de probabilité que vous pouvez voir, puis nous avons constaté que lorsque la probabilité d'être attaqué augmente de 1 %, alors leur préférence pour le choix du Private Pool augmentera de 0,6 %.
Notre première et principale conclusion est que son Private Pool ne peut ni éliminer complètement le risque d'être attaqué, ni réduire les frais du marché. Deuxièmement, nous avons constaté que l'introduction du pool privé augmentera le bien-être des validateurs et réduira le bien-être des attaquants.Le bien-être global du réseau deviendra plus élevé en raison d'une allocation d'espace de bloc plus efficace, mais il ne peut pas atteindre l'état optimal.
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Wang Ye, Université de Macao : Inefficacité de l'allocation, MEV et transactions privées dans les chaînes de blocs publiques
Discours : Wang Ye, professeur adjoint, Département des sciences de l'information et de l'informatique, Université de Macao
Compilation : aididiaojp.eth, Foresight News
*Cet article est une compilation de textes partagés par Wang Ye, professeur adjoint au Département des sciences de l'information et de l'informatique de l'Université de Macao dans le cadre du programme Young Scholars. Le programme Young Scholars est coparrainé par DRK Lab, imToken et Crytape. De jeunes chercheurs bien connus dans le domaine du chiffrement seront invités à partager certains des derniers résultats de recherche avec la communauté de langue chinoise. *
Avant de commencer, permettez-moi de me présenter brièvement. Je suis Wang Ye. Je travaille actuellement en tant que professeur adjoint au Département des sciences de l'information et de l'informatique de l'Université de Macao. Mes recherches actuelles portent sur DeFi et des domaines connexes. Nous considérons DeFi comme un marché financier émergent et recherchons des questions du point de vue de l'économie et de la finance, y compris l'analyse du comportement des utilisateurs et de la structure du marché. En outre, je prêterai également attention aux problèmes de sécurité potentiels qui existent lors de l'utilisation par l'utilisateur et à la manière de réduire certains dangers et problèmes de sécurité que les applications Web3 et DeFi peuvent entraîner en améliorant l'expérience utilisateur. Le contenu que je partage aujourd'hui est principalement lié à la première direction de recherche, c'est-à-dire que nous étudierons certains problèmes de comportement des utilisateurs sous le nouveau modèle dans un tel marché financier décentralisé émergent, et comment nous pouvons optimiser une telle structure de marché.
Un tel marché financier basé sur le système blockchain aura des problèmes endogènes.Nous ne connaissons pas certaines solutions communes sur le marché et l'impact de ces solutions sur l'ensemble du marché. Ensuite, nous présenterons comment modéliser les problèmes actuels du marché de la blockchain du point de vue de l'économie ou de la finance après avoir compris les problèmes existants, et comment utiliser le modèle pour l'analyse théorique. Dans la dernière partie, nous comparons et analysons les résultats de la recherche théorique avec les données expérimentales observées sur le marché de la blockchain, puis prouvons l'application de notre dérivation théorique sur le marché réel.
Tout le monde sait qu'il existe deux types différents de participants à la blockchain : l'un est des utilisateurs ordinaires, ce qu'ils font est d'envoyer leurs transactions à l'ensemble du réseau blockchain, puis s'attendre à ce que leurs transactions soient publiées sur le réseau est exécuté dans le système . L'autre type est généralement appelé un mineur, ou il peut être appelé un vérificateur dans le nouveau système.Ils recueilleront les transactions envoyées par ces utilisateurs dans le réseau et formeront un bloc. Lorsqu'un tel bloc est diffusé et vérifié par la plupart des participants au système, nous considérons que toutes les transactions de ce bloc ont été confirmées, ou complètement vérifiées avec succès. En cela, nous constaterons qu'il existe plusieurs problèmes fondamentaux qui sont très différents du marché financier traditionnel. Le premier problème est que les transactions sont transparentes jusqu'à ce qu'elles soient déterminées à s'exécuter et à s'exécuter. Au cours des deux dernières années, tout le monde a largement proposé le concept de Frontrunning. En fait, cette matière n'existe pas seulement dans le cadre de la finance décentralisée, mais a toujours existé dans la finance traditionnelle. Cela signifie simplement que la finance traditionnelle peut être utilisée. Certaines politiques ou règles et réglementations éliminent complètement les risques, mais dans le système blockchain, nous devons faire attention à ce problème.
Lorsqu'une transaction est diffusée sur le réseau public et avant qu'elle ne soit exécutée, elle est déjà observable par tous, ce qui implique un problème d'exposition au risque très sérieux. Deuxièmement, le deuxième problème très critique concerne l'ordre des transactions.À l'heure actuelle, le moyen le plus courant pour les mineurs de regrouper et de trier toutes les transactions est de les regrouper dans l'ordre en fonction du niveau des frais de traitement. Cela entraînera alors un problème très grave. À l'heure actuelle, les gens accordent de plus en plus d'attention à des problèmes connexes qui ne peuvent être ignorés sur le marché financier décentralisé, c'est-à-dire qu'il y aura un grand nombre d'attaques en cours d'exécution, ou nous pouvons collectivement référez-vous à eux dans de nombreux cas.Pour MEV, Running Attack peut être juste une partie de MEV.
Décrivons à nouveau brièvement ce processus : lorsque nous trouvons une transaction, elle n'a pas été exécutée. N'importe lequel de nos attaquants peut utiliser des informations connues pour créer une nouvelle transaction et fournir des frais de gaz plus élevés pour que la transaction nouvellement soumise soit exécutée avant la transaction divulguée. Cela est dû aux problèmes endogènes du système de blockchain, qui à l'heure actuelle ont toujours existé au moins dans le système de blockchain public et sont difficiles à interdire. Ensuite, passons en revue certains des modes d'attaque Frontrunning les plus courants.
Le premier mode d'attaque, je pense que beaucoup d'amis le connaissent peut-être, donnons donc une introduction plus claire ici. Ce mode s'appelle Sandwich Attack. Son point central est qu'il existe une tarification constante du fabricant de marché de produits via le mécanisme AMM lui-même. , avant qu'une transaction ne soit terminée, via une autre transaction à l'avance pour modifier le taux des frais de transaction sur le marché, puis après que le commerçant victime ait poussé davantage les frais de transaction vers un résultat plus extrême, puis via la transaction inverse pour obtenir Les fonds reçus sont échangés à un prix plus favorable, et les avantages sont obtenus grâce à la différence de taux de change contenue dans la transaction. Dans un tel mode d'attaque, nous pouvons voir que lorsqu'il y a une transaction victime sur le marché, cette transaction est généralement une transaction dans AMM, et l'attaquant utilisera une valeur plus élevée avant la transaction victime Frais de gaz pour une transaction frontale. Une fois cette transaction terminée, ils utiliseront une autre transaction pour effectuer une opération inverse et bénéficieront de la différence de taux de change entre les transactions précédentes et suivantes. C'est ce que nous appelons le premier type de Frontrunning.
Le deuxième type est l'attaque de suppression la plus courante. Sur le marché financier, le temps est un facteur très important. De nombreuses transactions exécutées un bloc plus tard et un bloc plus tôt entraîneront d'énormes fluctuations du marché, surtout si l'on considère que certaines transactions peuvent impliquer des prix de liquidation. La cible principale de cette classe d'attaques est telle opérations critiques. Par exemple, nous espérons que la transaction pourra être exécutée dans le bloc suivant. Si un attaquant malveillant observe cette transaction, puis expulse la demande de transaction d'un bloc spécifique avec une transaction qui propose des frais de gaz plus élevés, alors il est attaqué. La transaction peut attendre le ou les prochains blocs avant d'être exécuté. En raison du décalage horaire, nous pourrions ne pas être en mesure de terminer à temps les opérations de marché des transactions critiques, ce qui entraînerait des turbulences relativement graves sur le marché.
La troisième attaque s'appelle Displayment Attack, qui est une attaque d'arbitrage unique. Vous pouvez imaginer que lorsque nous effectuons des transactions cycliques, les prix du marché peuvent en fait être différents. Cependant, l'opportunité spéculative potentielle apportée par la différence de taux de change est ponctuelle. Si je peux lisser la différence de taux de change sur le marché grâce à des transactions répétées, les attaquants ultérieurs n'auront aucun moyen de spéculer pour réaliser un profit. visant à ce type d'opportunité d'arbitrage unique. Nous supposons que Tv est une transaction qui obtient des bénéfices par le biais de transactions de marché. Après qu'un attaquant malveillant a observé Tv, il peut effectuer exactement le même comportement de transaction de marché, mais la seule différence est qu'il utilisera sa propre transaction d'arbitrage Soumettre avec un gaz plus élevé frais. Ensuite, il sera exécuté à l'avance dans le véritable système de blockchain. Puisqu'il exécute d'abord l'opportunité d'arbitrage unique, la transaction de la télévision elle-même ne bénéficiera plus d'avantages.
Ces trois sont les attaques MEV sur lesquelles nous nous concentrons actuellement. En raison de la configuration du mécanisme du système, le réseau blockchain présente des problèmes endogènes. Lorsque nous disons que le Frontrunning est très courant, la prochaine question naturelle est de savoir si cette affaire est vraiment sérieuse et quelle perte de valeur le MEV entraînera-t-il ?
Nous avons une statistique selon laquelle en moins d'un an, les pertes financières causées par les attaques MEV sur le marché ont dépassé 80 000 Ethereum, ce qui signifie qu'il a causé pas mal de pertes économiques, c'est pourquoi tout le monde fera attention à ce problème , de nombreuses personnes réfléchissent également à la manière d'éliminer les attaques MEV. En plus de prêter attention aux pertes économiques, nous pensons également à l'impact supplémentaire de l'ensemble de l'incident sur le réseau blockchain, car il a non seulement causé des pertes économiques, mais a également gaspillé une certaine quantité d'espace de bloc.
Lorsque ce problème existe, tout le monde doit constamment réfléchir à la façon de le résoudre. La solution actuelle consiste à diffuser via Private Pool, qui s'appelait autrefois Relay Service. Les transactions ne se propagent pas seulement à travers un réseau distribué que les utilisateurs exposent, elles fournissent un canal de communication privé qui permet une connexion directe entre les utilisateurs et les mineurs. A travers un tel canal de communication, vous pouvez imaginer que l'avantage est que nous n'aurons plus de fuite d'informations. Puisque nous pensons que Frontrunning fait également partie de MEV, ce type de pool privé est introduit dans le réseau dans l'espoir de minimiser l'apparition de Frontrunning.
À l'heure actuelle, Frontrunning Attack est causée par une fuite d'informations dans le système de blockchain. Nous savons également que certaines personnes ont proposé de nouveaux mécanismes pour éviter cette situation. Donc, si le nouveau mécanisme peut jouer un rôle et quel type d'impact il aura sur le système de blockchain, deviennent naturellement les questions que nous voulons étudier.
Lorsque nous introduisons Private Channel dans la blockchain, quel impact cela aura-t-il sur l'ensemble de l'écosystème ? Tout d'abord, sera-t-il largement accepté par les utilisateurs et les validateurs de blocs ? Parce qu'ils sont les principaux participants de tout notre système. Ensuite, la deuxième question est de savoir s'il a atteint notre objectif après avoir été accepté, qui est de réduire les frais de transaction et d'éviter le Frontrunning. Le troisième point est qu'après l'introduction du nouveau mécanisme, quel genre d'impact aura-t-il sur tous les utilisateurs de l'ensemble du système ? Ce sont les trois questions de recherche que nous avons soulevées après avoir découvert des solutions possibles.
Nous construisons des modèles pour étudier et expliquer l'impact possible de différents choix faits par différents acteurs sur le marché, et enfin faire des prédictions, puis nous comparons et analysons le comportement des utilisateurs du marché lui-même et nos résultats d'analyse théorique. Ensuite, nous montrerons ici comment diviser le problème en trois étapes. Nous avons impliqué trois hypothèses différentes dans notre modèle en trois étapes. La première est que nous pensons que les participants sont rationnels, ce qui est une hypothèse courante dans de nombreuses recherches économiques et financières. Deuxièmement, nous penserons que certaines transactions courront le risque d'être attaquées, et il y aura des transactions qui ne seront jamais attaquées dans le système. En même temps, nous construirons un modèle basé sur les arbitragistes ou les attaquants qui existent dans ce marché.
Dans tout le système, nous pensons que toutes les transactions ont deux canaux de transaction différents, l'un est notre réseau public commun distribué Public Pool, et l'autre est le réseau privé Private Pool. Enfin, nous supposons que chaque bloc dispose de suffisamment d'espace pour accueillir les transactions. Ensuite, à différentes étapes de ce modèle, chaque utilisateur et chaque vérificateur doit choisir l'un des réseaux pour les transactions. Tout d'abord, le premier choix est le vérificateur, le second est l'utilisateur et le dernier est l'attaquant, ce qui est en fait conforme à notre mode de fonctionnement normal dans le système de blocs. Une fois que ces trois participants différents ont fait leur choix, nous effectuons ensuite un calcul inverse de l'état dans lequel l'ensemble du marché entrera finalement.
Tout d'abord, les mineurs ont deux options différentes : la première option est de ne pas rejoindre le système Flashbots et la seconde est de le rejoindre. Évidemment, ces deux options existent toujours pour eux, s'ils restent dans le canal public, ils ne peuvent voir que les transactions qui existent dans le Public Mempool. Mais s'ils rejoignent le pool privé, ils peuvent voir non seulement les transactions de Mempool, mais également les transactions du pool privé. Dans la première étape du modèle, chacun fera une sélection, puis nous utiliserons alpha pour indiquer la proportion de la sélection à l'aide de la flashbox.
La deuxième partie concerne le choix de l'utilisateur dans l'ensemble de la transaction. Vont-ils choisir de proposer leurs propres transactions dans le Mempool, ou choisiront-ils de proposer dans le Private Pool ? S'ils proposent des transactions dans le Mempool, ils risquent alors d'être attaqués. Ils peuvent également choisir Private Pool, mais il y a certains risques. La principale source de ce risque est que ces transactions qui rejoignent le Private Pool peuvent ne pas gagner à 100% le droit d'enregistrer le bloc suivant, mais nous pouvons continuer à proposer des transactions plus tard.
La troisième étape est que l'attaquant observera les transactions attaquables et effectuera les transactions d'attaque. Par exemple, un attaquant observe la transaction P et décide d'attaquer cette transaction publique. Lorsqu'un attaquant soumet sa propre transaction, il est également confronté à deux choix, soit dans le pool public, soit dans la Flashbox. Si un attaquant soumet une transaction dans le pool public, il peut enchérir pour des offres plus élevées en plusieurs tours, et le gaz de sa transaction augmentera progressivement. Il s'agit d'un mode d'attaque courant dans de nombreux cas. S'il se trouve dans le pool privé, l'attaquant ne sait pas s'il y a d'autres attaquants en concurrence avec lui en même temps. Si dans la piscine publique, si quelqu'un d'autre rivalise avec l'attaque, les attaquants peuvent en fait se connaître. Mais dans le pool privé, premièrement, l'attaquant ne sait pas s'il y a de la concurrence, et deuxièmement, je ne sais pas combien de frais d'essence le concurrent a payé, donc les attaquants deviennent une nouvelle relation concurrentielle, ce qui les causera faire des compromis. Les frais de gaz qu'ils sont prêts à payer seront en fait très différents. Si la transaction de l'attaquant est finalement acceptée, il finira par avoir un profit C, qui est également la perte économique causée.
Ensuite, il est temps d'équilibrer. Le premier concerne les utilisateurs et les attaquants, le principal compromis auquel ils sont confrontés est en fait le risque opérationnel.
Les utilisateurs doivent peser si mes informations de transaction seront divulguées ou si je suis en sécurité, et l'attaquant ne donnera pas ses informations de transaction à un autre attaquant. Ils sont également confrontés au même risque opérationnel, c'est-à-dire que les validateurs du pool privé n'ont pas le droit à 100% d'enregistrer le bloc suivant, il y a donc une forte probabilité que cette transaction ne soit pas incluse dans le bloc suivant, même si c'est inutile payer suffisamment de frais d'essence.
Les utilisateurs qui n'ont pas rejoint Flashbots, ils n'ont qu'à trier ces transactions en fonction des frais de gaz de haut en bas, mais s'ils rejoignent Flashbots, ils doivent d'abord classer les transactions proposées par le pool privé dans le bloc, puis vérifier Le reste de l'accord. Par exemple, la transaction K est inférieure aux frais de gaz de ses transactions précédentes et suivantes, mais la transaction K est toujours placée au premier plan pour vérification.
Une fois le catalogue des modèles hypothétiques établi, nous analyserons progressivement les choix que vous ferez selon trois perspectives. Nous effectuons d'abord une analyse comportementale du point de vue de l'attaquant. Les attaquants seront naturellement confrontés à des frais de gaz de plus en plus élevés après avoir traversé une concurrence continue.C'est une conclusion fondamentale, nous constaterons que le prix du gaz qu'ils doivent soumettre dans le pool privé est beaucoup plus élevé que le prix du gaz qu'ils doivent soumettre dans le pool public prix. Mais beaucoup d'entre eux choisiront toujours Private Pool. Il y a deux raisons principales. La première raison est que les transactions d'arbitrage qu'ils soumettent dans Private Pool ne seront pas vues par d'autres attaquants, et ils n'ont pas besoin de faire des enchères, c'est un avantage . Le second avantage réside dans l'ordre de tri des blocs : s'il est déposé via le Private Pool, sa priorité est naturellement supérieure à celles proposées par le Public Pool. Dans ce cas, les attaquants choisiront naturellement le Private Pool, mais en même temps, afin d'éviter l'impact des risques opérationnels, ils choisiront également de trader dans certains Public Pools en même temps.
L'étape suivante est le compromis pour les utilisateurs. Ils prendront principalement en compte deux facteurs, l'un étant le taux d'adoption et l'autre la probabilité d'attaques potentielles. Si a est relativement grand, alors vous pouvez en fait imaginer que le risque opérationnel auquel ils sont confrontés est relativement faible, et ils seront naturellement plus enclins à utiliser Private Pool. Si l'alpha est très petit, il peut ne pas être utile pour eux de soumettre dans le passé, donc la piscine publique deviendra leur choix.
Aussi pour la partie c, c'est en fait un facteur très important. Nous avons constaté que si C est suffisamment grand, ils n'ont en fait pas d'autre choix que de proposer une transaction dans le pool privé. Si cela se produit, nous pouvons le savoir. En fait, les opportunités d'arbitrage pour les attaquants sont complètement éliminées.Si tout le monde n'utilise pas le pool public, alors cette question n'existera plus du tout. Mais nous devons également considérer un point : en fait, en fonctionnement réel, toutes les transactions qui causent le MEV n'ont pas un espace d'arbitrage aussi élevé.
Ce que nous pouvons voir en ce moment, c'est dire que beaucoup d'offres peuvent être prises en sandwich et peut-être qu'elles n'ont que quelques dollars en retour. Une fois que l'attaquant a terminé l'attaque, il doit parfois même distribuer la plupart des bénéfices aux mineurs, et l'incitation restante peut être inférieure à 1 $. En fait, il existe de nombreux cas où C est très petit. Dans ce cas, ils ne choisiront pas Private Channel, car Private Channel n'est pas un choix optimal pour eux. La raison principale est que pour de nombreux utilisateurs, ils ne se soucient pas de savoir si leurs transactions sont attaquées ou non, ils sont prêts à assumer le risque d'être attaqués et ils estiment que courir des risques est pire pour eux. Dans ce cas, nous savons que si le taux d'adoption n'est pas de 100%, alors de nombreuses transactions doivent être attaquées.
Ensuite, pour répondre à la deuxième question, la taxe de priorité a-t-elle été réduite ? Notre conclusion finale est que même après l'introduction du pool privé, les frais de priorité ne seront pas réduits. Il y a deux facteurs principaux ici.La première partie, en fait, comme vous pouvez l'imaginer, les vérificateurs choisiront d'utiliser Private Pool uniquement lorsqu'ils obtiennent des frais plus élevés, ce qui augmente naturellement les frais de référence pour entrer dans le bloc. Un autre facteur est que certaines personnes peuvent être vulnérables aux attaques, elles ne sont donc pas disposées à choisir le pool public. Pour le moment, elles préfèrent utiliser le pool privé pour les transactions. Ces transactions qui n'apparaîtraient pas dans le pool privé augmenteront encore la priorité. frais. La conclusion fondamentale finale est qu'elle a entraîné une augmentation des taxes de priorité.
La dernière question centrale est de savoir si la valeur globale des blocs qui nous préoccupent a augmenté ? Nous pouvons penser à ce facteur central car la chaîne privée ne peut pas réellement atteindre un taux d'adoption de 100 %, il y aura donc encore beaucoup de Frontrunning, qui occupera notre propre espace de bloc. Ensuite, après l'introduction, puisque ces attaques en cours qui génèrent des MEV n'apportent pas réellement de nouveaux avantages réseau au système, elles obtiennent une partie des récompenses des utilisateurs attaqués en tant que leurs propres retours spéculatifs, et elles n'en apporteront pas au système. Nouvelle valeur, donc de ce point de vue, même après avoir un pool privé, nous ne pouvons toujours pas atteindre l'état d'allocation optimal et efficace du réseau. Dans le même temps, en raison de l'existence de MEV, dans l'ensemble du système, plus le bien-être global du réseau est élevé, plus le choix le plus avantageux pour les vérificateurs ne l'est pas. Dans ce cas, le choix des mineurs conduira également au fait que le bien-être du réseau de notre système final ne peut pas atteindre une solution optimale.
Ensuite, nous irons plus loin pour discuter s'il existe des méthodes potentielles pour nous aider à résoudre ces problèmes. L'argument central est que le retour spéculatif de l'attaquant et l'allocation optimale des ressources du réseau sont en fait incompatibles. Les attaquants ont besoin de la génération de MEV pour les aider à augmenter leur taux de rendement. En fait, une méthode possible consiste à modifier la répartition inégale de la valeur du réseau, c'est-à-dire à inciter les attaquants à s'engager dans une méthode de participation au réseau plus raisonnable et efficace.
Enfin, je voudrais partager brièvement avec vous quelques données que nous avons obtenues après analyse théorique. Tout d'abord, nous regardons en fait le taux d'acceptation des Flashbots. Ce que nous faisons principalement est de voir si le bloc de transaction est intuitivement reflété par cette partie des données. Ensuite, nous constatons que la transaction est toujours dans un tel état à l'heure actuelle, ni tout le monde ne l'a vu, ni cela ne signifie que tout le monde peut le voir.C'est notre première conclusion. La deuxième conclusion que nous avons obtenue est que la probabilité que les utilisateurs choisissent Private Pool a en fait une corrélation positive très évidente avec leur vulnérabilité aux attaques.
Dans la troisième partie, nous avons obtenu une conclusion temporelle. Nous avons constaté que, par rapport aux attaquants du Mempool, les attaquants du Private Pool n'ont pas besoin d'enchérir tour après tour. Les attaquants qui obtiennent le MEV doivent se soumettre à Les frais de mineur sont beaucoup plus élevés. Dans Public Pool, le taux de distribution moyen est d'environ 0,3, mais dans Flashbox, il est passé à près de 0,8. Nous avons constaté que la probabilité de choisir un Private Pool est en fait positivement corrélée avec leur risque d'être attaqué. Cette image est une telle distribution de probabilité que vous pouvez voir, puis nous avons constaté que lorsque la probabilité d'être attaqué augmente de 1 %, alors leur préférence pour le choix du Private Pool augmentera de 0,6 %.
Notre première et principale conclusion est que son Private Pool ne peut ni éliminer complètement le risque d'être attaqué, ni réduire les frais du marché. Deuxièmement, nous avons constaté que l'introduction du pool privé augmentera le bien-être des validateurs et réduira le bien-être des attaquants.Le bien-être global du réseau deviendra plus élevé en raison d'une allocation d'espace de bloc plus efficace, mais il ne peut pas atteindre l'état optimal.