Avant de lire cet article, vous devez avoir une compréhension de base de MEV, du rôle de Flashbot et de l’impact de Flashbot sur MEV.
Il est également nécessaire de connaître la compréhension de base du mécanisme PoS et des changements apportés par The Merge.
MEV
Tout d’abord, examinez ce qu’est le MEV.
La valeur extractible du mineur fait littéralement référence à « la valeur qu’un développeur de blocs peut extraire ».
Cette valeur ne fait pas référence aux frais payés par l’utilisateur au développeur du bloc pour regrouper la transaction de l’utilisateur dans le bloc. L’action de donner des frais est acceptée par l’utilisateur, et l’utilisateur peut ajuster les frais très bas, de sorte que sa transaction sera collectée pendant une longue période, mais au moins le développeur de blocs ne peut pas facturer de frais pour la transaction.
*Conseil de lecture : MEV est maintenant renommé Valeur Extractible Maximale, car le développement actuel de MEV n’est plus exclusif aux développeurs de blocs. *
« La valeur qu’un développeur de blocs peut obtenir » fait référence au fait qu’un développeur de blocs réalise un profit en changeant l’ordre des transactions, en insérant ses propres transactions et avant (ou après) les transactions qui sont exploitées. Alors, quels types d’avantages les développeurs de blocs peuvent-ils tirer ?
Par exemple, lorsqu’un NFT chaud propose des machines à sous de mint, et que seules les 100 personnes les plus rapides peuvent frapper avec succès, Carol, qui est amie avec le développeur de blocs ou qui a conclu une sorte d’accord avec le développeur de blocs hors chaîne, peut s’assurer que le développeur de blocs peut placer sa transaction de mint avant la transaction de mint de quelqu’un d’autre en organisant l’ordre de transaction.
△ Les développeurs de blocs donneront la priorité aux transactions de Carol avant celles des autres.
Un autre MEV courant est une transaction AMM qui pince les utilisateurs, forçant les utilisateurs à recevoir le pire prix (dans la fourchette acceptable), et la différence entre le prix attendu de l’utilisateur et le pire prix est le profit pressé par le développeur de blocs.
Dans l’exemple ci-dessous, Alice s’attend à échanger 1 WBTC contre 21 500 USDT, mais elle sait que dans le monde décentralisé, sa transaction peut ne pas être la première à être exécutée, et lorsque quelqu’un d’autre négocie également WBTC/USDT avant elle, le prix de l’AMM sera modifié, et 1 WBTC ne pourra pas être échangé contre 21 500 USDT, elle fixe donc un pire prix de 20 500 USDT dans la fourchette acceptable :
△Alice s’attend à échanger 1 WBTC contre 21 500 USDT, mais au pire, elle peut accepter 20 500 USDT.
À ce moment-là, Eve a découvert la transaction d’Alice et a décidé de vendre WBTC avant la transaction d’Alice, ce qui a fait chuter le prix du WBTC à 20 500 USDT, puis en exécutant la transaction d’Alice, Alice a été forcée de négocier à un prix de 20 500 USDT.
Enfin, Eve rachète le WBTC avec l’USDT obtenu en vendant le WBTC au début, et le prix du WBTC sera inférieur à 20 500 USDT, ce qui signifie qu’Eve a effectué un achat bas et une vente élevée (< acheter à 20 500 et vendre à 21 500) et gagner la différence de prix.
△ Le développeur de blocs Eve a trouvé rentable de vendre WBTC avant la transaction d’Alice, puis a racheté WBTC pour gagner le spread après l’exécution de la transaction d’Alice.
Les systèmes décentralisés doivent avoir un MEV
Dans un système centralisé, vous pouvez choisir de faire confiance aux rôles responsables du séquençage des transactions (opérateur, séquenceur) et de croire qu’ils ne feront rien de mal qui nuira à l’utilisateur pour le bien de la réputation, ou vous pouvez choisir de quitter le système. C’est également la situation actuelle de L2, et il est peu probable que les parties du projet L2 cassent leurs propres panneaux pour extraire le MEV.
Mais dans un système décentralisé, n’importe qui peut devenir un développeur de blocs, et nous ne pouvons pas prouver simplement et objectivement que le comportement d’un développeur de blocs est « mauvais », ce qui signifie que nous ne pouvons pas interdire efficacement aux développeurs de blocs d’exploiter les profits.
Nous ne devrions pas nous attendre à ce que les développeurs de blocs soient de « bonnes personnes », mais nous devrions nous inquiéter du fait que si un développeur de blocs gagne de plus en plus d’argent grâce au MEV et investit dans plus d’équipement de développement de blocs, il deviendra de plus en plus grand, ce qui l’amènera à éliminer d’autres concurrents, et le résultat sera un dilemme d’un seul développeur de blocs dans un système décentralisé, et finalement il sera en mesure d’imposer des règles de préférence personnelle sur les transactions des utilisateurs à volonté. Et c’est ainsi que Flashbot a vu le jour.
Flashbot
Afin d’éviter que MEV n’affecte le degré de décentralisation des développeurs de blocs, Flashbot a fait de MEV un marché ouvert où les développeurs de blocs et les chercheurs professionnels de MEV coopèrent et partagent MEV, et il existe un degré élevé de concurrence entre les développeurs de blocs et les chercheurs de MEV.
Grâce à une telle concurrence et à de tels partenariats, les développeurs de blocs et les chercheurs de MEV peuvent se concentrer sur leur propre spécialité, et les chercheurs de MEV n’ont pas à s’inquiéter que les développeurs de blocs puissent voler leurs opportunités d’arbitrage ou délibérément ne pas accepter leurs propres transactions.
△ Searcher trouve des transactions à partir du pool de trading ouvert pour l’arbitrage et enchérit pour les droits de revenu pour ses propres bundles, qui sont donnés à Flashbot puis sélectionnés par le développeur de blocs.
Risque de centralisation
Cependant, Flashbot a toujours un inconvénient, toutes les transactions d’arbitrage MEV searcher doivent passer par un serveur Flashbot centralisé, qui peut voler des opportunités d’arbitrage ou examiner des transactions d’arbitrage.
En plus de Flashbot, des projets comme Eden Network sont également apparus sur le marché. Il s’agit essentiellement de la même architecture que Flashbot, à l’exception de son propre jalonnement inutile, de la priorité des transactions intra-bloc et de mécanismes d’enchères supplémentaires. Mais au moins, lorsque Flashbot commence à faire le mal, les développeurs de blocs et les chercheurs ont d’autres options.
Le MEV est un fait établi qui doit être accepté
Les concepteurs de protocoles et les utilisateurs doivent être vigilants à l’égard du MEV. Si possible, l’intégration du MEV dans la conception du protocole et la transformation du MEV en un outil utile sont des éléments auxquels les concepteurs de protocoles doivent penser lorsqu’ils concevront des mécanismes à l’avenir. Des articles ultérieurs couvriront également la conception et les idées pour faire bon usage de MEV.
La fusion
Ethereum est passé au mécanisme PoS après The Merge, et d’un développeur de blocs en concurrence avec la puissance de calcul des machines de minage au jalonnement d’ETH, il peut devenir un validateur pour avoir la possibilité de proposer des blocs, ce qui signifie que le seuil d’obtention de blocs dans PoS est beaucoup plus bas. L’abaissement du seuil d’obtention d’opportunités de génération de blocs affecte en fait la concurrence et la coopération entre les différents rôles dans Flashbot.
*Conseil de lecture : Proposer ici est conservé en anglais pour éviter de mal interpréter le chinois de proposer block et build block car le sens est trop proche. *
Changement dans la relation de confiance
Avant le PoS, Searcher devait avoir confiance dans le fait que le développeur de blocs ne s’emparerait pas du contenu de son bundle, et même si le développeur de blocs le faisait, Searcher ne pouvait contrer que par des mécanismes hors chaîne, tels que la présentation de preuves pour demander à Flashbot de mettre le développeur de blocs sur liste noire ou la publication d’un message sur Twitter pour le fermer.
Cependant, les développeurs de blocs sont fondamentalement très coopératifs, car la relation entre le développeur de blocs et le Searcher est une coopération à long terme, et si le développeur de blocs saisit le Searcher pour un certain avantage MEV aujourd’hui, et que le développeur de blocs ne recevra aucune opportunité MEV à l’avenir, cela n’en vaudra pas la peine.
Cependant, après le PoS, vous pouvez avoir la possibilité de produire des blocs en jalonnant de l’ETH, et le seuil de production de blocs est abaissé. En conséquence, de nombreuses personnes ordinaires s’inscrivent en tant que validateurs, ce qui entraîne la possibilité d’obtenir des blocs lentement dilués.
Par rapport aux quelques pools de minage qui ont investi beaucoup de coûts dans le PoW et qui fonctionnent depuis longtemps, le validateur en PoS ne peut avoir qu’occasionnellement l’occasion de générer des blocs, et sa récompense de bloc plus le taux annualisé moyen de MEV est calculé même s’il est de 10%, le validateur a toujours une incitation très suffisante pour saisir le MEV du chercheur.
Conseils de lecture : Vous pouvez vous référer au classement MEV des statistiques de Flashbot, copiez le lien ci-dessous pour accéder au navigateur et afficher le contenu connexe :
△ Tant que vous saisissez l’opportunité de saisir plus de 3,2 ETH de MEV, cela dépassera les 10% annualisés.
Par conséquent, l’architecture de Flashbot doit être ajustée pour correspondre au changement de relation de confiance et au mécanisme PoS, et c’est devenu le mev-boost actuel.
MEV-BOOST
Dans mev-boost, le rôle de Relay entre le Searcher et le développeur de blocs du Flashbot a été divisé en deux, l’un est le Builder et l’autre s’appelle Relay mais avec des responsabilités différentes.
Le Chercheur remet le paquet au Constructeur, qui sélectionne plusieurs paquets parmi plusieurs paquets pour former un bloc, et remet le bloc au Relais, qui à son tour sélectionne l’un des blocs soumis par le Relais.
△ Searcher est en concurrence avec Searcher, Builder est en concurrence avec Builder, et Validator choisit le bloc le plus avantageux de celui-ci.
Le Builder est chargé de trouver la combinaison de bundles la plus favorable dans la capacité limitée d’un bloc, en espérant que le Validateur choisira son propre bloc.
Alors, à quoi sert le relais ? Comme mentionné ci-dessus, la relation de confiance a changé, de sorte que le chercheur/constructeur ne peut pas faire confiance au validateur, de sorte que le validateur dans mev-boost doit faire une promesse de « je vais proposer votre bloc » avant de recevoir le contenu réel du bloc.
Relay agit en tant qu’intermédiaire entre le Builder et le Validator pour aider à la coordination : Relay conserve le contenu du bloc jusqu’à ce qu’il obtienne la promesse du Validateur avant de remettre le bloc créé par le Builder au Validateur.
Dans la terminologie actuelle de la chaîne de balises Ethereum, le contenu du bloc créé par le constructeur est appelé ution Payload, et le validateur recevra des données de Relay appelées ution Payload Header, qui peuvent être considérées comme un engagement de Payload, et la signature de l’en-tête représente la signature de Payload.
Lorsque le Validateur choisit le bloc à proposer à Relay, il met l’en-tête de charge utile ution du bloc dans le bloc Beacon et le signe, puis remet le contenu signé à Relay comme preuve, et enfin Relay peut être assuré que le contenu du bloc sera donné au Validator et le laissera proposer le bloc.
△ Le Builder remet le bloc au Relais, et le Relais remet l’En-tête au Validateur
△ Si le validateur sélectionne le bloc, l’en-tête sera placé dans le bloc de balise, signé et remis au relais.
△ Le relais remet ensuite le morceau complet au validateur.
Si le Validateur finit par trahir Relay et choisit de proposer un autre bloc, alors Relay peut publier la signature que le Validateur lui a donnée comme preuve que le Validateur a proposé deux blocs différents, et alors le Validateur sera pénalisé pour avoir violé les règles de la Beacon Chain Ethereum.
△ Eve a été réduit (une partie de l’ETH promis a été confisquée) parce qu’il a proposé un autre blocage.
Hypothèse de confiance
Dans mev-boost, le Validateur doit faire confiance à Relay, si le contenu du bloc finalement révélé par Relay n’est pas légal, ou si l’argent réel reçu par le Validator n’est pas celui attendu, ou même si le Relay ne publie pas directement le contenu du bloc, le Validator ne peut pas proposer le bloc, alors le Validator ne peut contrer que par un mécanisme off-chain, comme faire connaître aux autres Validateurs le comportement malveillant du Relais.
Disjoncteur
Les validateurs ne peuvent pas être surveillés et intervenus 24 heures sur 24, donc lorsque le logiciel de validation constate que (le même relais ou plus) brise constamment la confiance, il doit être capable de réagir pour éviter de perdre des revenus tout le temps car il n’y a pas de blocage de proposition.
Par exemple, lorsque vous constatez que vous n’avez pas proposé de bloc pour plus de cinq emplacements, vous devez revenir en arrière et utiliser votre propre nœud pour rendre le bloc contenu.
Pour les documents pertinents, veuillez consulter :
Moniteur de relais
Afin de réduire l’impact des méfaits du personnage de Relay, la communauté Flashbot réfléchit également à la conception d’un monitoring du comportement de Relay.
Pour les documents pertinents, veuillez consulter :
Disponibilité des données C****ommittee
Une façon d’empêcher Relay de ne pas publier le contenu d’un bloc est de donner les données du bloc à un comité de nœuds qui sont responsables de la conservation et de la disponibilité du contenu du bloc, c’est-à-dire de la décentralisation de la responsabilité de la conservation du contenu du bloc.
Quels sont les constructeurs et les relais actuellement disponibles ? **
Ici vous pouvez voir le Builder et le Relay actuels :
MEV-Boost
Consultez le site Web :
Comme vous pouvez le voir, bien qu’il s’agisse de l’équipe de développement principale de mev-boost, Flashbot n’a pas le statut de Relay dominant, car Flashbot a développé mev-boost depuis le début et ne s’est pas défini comme le Relay par défaut dans le logiciel mev-boost.
Conseils de lecture : En savoir plus, s’il vous plaît voir
2023-04-02 Attaque contre le relais mev-boost
Un validateur malveillant a découvert une vulnérabilité dans Relay : Relay renverra le contenu de l’ensemble au validateur tant qu’il dispose d’une signature valide pour l’extraction (que le contenu soit légitime ou non).
Par conséquent, le validateur malveillant signe un contenu non valide (les valeurs de certains champs de l’en-tête ne sont pas valides), et après que le relais a renvoyé le contenu du bundle, le validateur vole la transaction d’arbitrage dans le bundle, puis propose un autre bloc valide.
Relay tente de diffuser l’en-tête signé par le Validateur, mais il est rejeté par les autres nœuds car le contenu n’est pas valide, donc tout le monde ne voit que le bloc valide proposé par le Validateur lui-même. Par la suite, le validateur a été rayé et expulsé de la liste des validateurs pour avoir signé deux en-têtes différents (pour Relay et Proposed), mais le mal était fait.
Le Relay mis à jour va maintenant essayer de diffuser l’en-tête Validator en premier, s’il est reçu avec succès par d’autres nœuds, cela signifie que le contenu du signe Validateur est légitime, et les autres noeuds verront le bloc diffusé par Relay en premier, si le Validateur tente de voler le contenu du bundle et le propose lui-même, il sera plus difficile de gagner le bloc diffusé par Relay (car il y a déjà beaucoup de noeuds qui ont vu le bloc diffusé par Relay).
Conseil de lecture 1 : Expliquez le fil de cette attaque et les preuves associées et les correctifs de relais, veuillez vous référer à ce fil de discussion, veuillez vous référer à ce fil de discussion pour plus de détails :
*Conseil de lecture 2 : En plus de voler des transactions d’arbitrage dans les bundles, les validateurs malveillants peuvent également attaquer les arbitragistes qui effectuent des strikes sandwich : les arbitragistes qui effectuent des strikes sandwich insèrent leurs propres transactions avant et après la transaction de la victime - achetant de manière préventive la victime, puis vendant après que la victime ait acheté pour gagner le spread, mais pour que le clipper réussisse, les deux transactions doivent être exécutées, sinon seule la transaction précédente sera exécutée, mais l’arbitragiste non seulement ne gagnera pas le spread, mais perdra également ses propres fonds. *
Cependant, les correctifs apportés en réponse à cette attaque vont augmenter le temps de retard de production des blocs, de sorte que le nombre d’occurrences de réorganisation de la chaîne PoS a considérablement augmenté dans les jours qui ont suivi l’attaque, et plusieurs solutions sont actuellement en cours de conception et de mise en œuvre pour éviter l’instabilité du réseau PoS causée par le retard de MEV-Boost.
Conseil de lecture : Pour des informations détaillées, vous pouvez copier le lien ci-dessous pour les afficher dans votre navigateur
Impact de Flashbot/mev-boost
Affecte l’efficacité du vote du validateur
À cause de Flashbot/mev-boost, le processus d’un bloc, de la production à la proposition effective, est passé par plus de niveaux, ce qui entraîne le retard du bloc de proposition du validateur, et les autres validateurs responsables du vote recevront le bloc plus tard, de sorte que leur temps de vote sera comprimé, ce qui affectera la sécurité de l’ensemble du réseau PoS.
Bien que cela ne semble pas être un impact important : une baisse estimée de 2 % de la participation et une diminution de 1 % des validateurs qui ont voté correctement, cela date d’octobre 2022, lorsque seulement un tiers des validateurs étaient connectés à MEV Relay.
Conseil de lecture : Pour plus d’informations, veuillez vous référer à l’article lié ci-dessous
Résumé et faits saillants
Le MEV est inévitable, et les développeurs de blocs ont le plus grand avantage du minage de MEV. Flashbot transforme le minage MEV en un marché ouvert, empêchant la centralisation des mineurs d’affecter la sécurité de l’ensemble de la chaîne.
mev-boost est né en réponse aux changements apportés par le PoS, mev-boost inverse la relation de confiance entre Searcher/Builder et Validator, et rend la compétition plus ouverte : il y a plusieurs Builders en concurrence les uns avec les autres, et plusieurs Relay en concurrence les uns avec les autres, réduisant encore le risque de centralisation de Flashbot.
Dans le prochain article, nous présenterons la séparation Proposer-Builder (PBS), qui intègre l’architecture mev-boost directement dans le protocole d’Ethereum, plutôt qu’une collaboration privée entre Validator, Builder et Searcher, ce qui rendra l’ensemble de l’écosystème MEV plus décentralisé et sécurisé.
Données de référence et recommandations pour une lecture complémentaire
*Statistiques:
*Statistiques:
*
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.
MEV après Ethereum Merge
Auteur : Nic @ imToken Labs
Conseils de lecture
MEV
Tout d’abord, examinez ce qu’est le MEV.
La valeur extractible du mineur fait littéralement référence à « la valeur qu’un développeur de blocs peut extraire ».
Cette valeur ne fait pas référence aux frais payés par l’utilisateur au développeur du bloc pour regrouper la transaction de l’utilisateur dans le bloc. L’action de donner des frais est acceptée par l’utilisateur, et l’utilisateur peut ajuster les frais très bas, de sorte que sa transaction sera collectée pendant une longue période, mais au moins le développeur de blocs ne peut pas facturer de frais pour la transaction.
*Conseil de lecture : MEV est maintenant renommé Valeur Extractible Maximale, car le développement actuel de MEV n’est plus exclusif aux développeurs de blocs. *
« La valeur qu’un développeur de blocs peut obtenir » fait référence au fait qu’un développeur de blocs réalise un profit en changeant l’ordre des transactions, en insérant ses propres transactions et avant (ou après) les transactions qui sont exploitées. Alors, quels types d’avantages les développeurs de blocs peuvent-ils tirer ?
Par exemple, lorsqu’un NFT chaud propose des machines à sous de mint, et que seules les 100 personnes les plus rapides peuvent frapper avec succès, Carol, qui est amie avec le développeur de blocs ou qui a conclu une sorte d’accord avec le développeur de blocs hors chaîne, peut s’assurer que le développeur de blocs peut placer sa transaction de mint avant la transaction de mint de quelqu’un d’autre en organisant l’ordre de transaction.
△ Les développeurs de blocs donneront la priorité aux transactions de Carol avant celles des autres.
Un autre MEV courant est une transaction AMM qui pince les utilisateurs, forçant les utilisateurs à recevoir le pire prix (dans la fourchette acceptable), et la différence entre le prix attendu de l’utilisateur et le pire prix est le profit pressé par le développeur de blocs.
Dans l’exemple ci-dessous, Alice s’attend à échanger 1 WBTC contre 21 500 USDT, mais elle sait que dans le monde décentralisé, sa transaction peut ne pas être la première à être exécutée, et lorsque quelqu’un d’autre négocie également WBTC/USDT avant elle, le prix de l’AMM sera modifié, et 1 WBTC ne pourra pas être échangé contre 21 500 USDT, elle fixe donc un pire prix de 20 500 USDT dans la fourchette acceptable :
△Alice s’attend à échanger 1 WBTC contre 21 500 USDT, mais au pire, elle peut accepter 20 500 USDT.
À ce moment-là, Eve a découvert la transaction d’Alice et a décidé de vendre WBTC avant la transaction d’Alice, ce qui a fait chuter le prix du WBTC à 20 500 USDT, puis en exécutant la transaction d’Alice, Alice a été forcée de négocier à un prix de 20 500 USDT.
Enfin, Eve rachète le WBTC avec l’USDT obtenu en vendant le WBTC au début, et le prix du WBTC sera inférieur à 20 500 USDT, ce qui signifie qu’Eve a effectué un achat bas et une vente élevée (< acheter à 20 500 et vendre à 21 500) et gagner la différence de prix.
△ Le développeur de blocs Eve a trouvé rentable de vendre WBTC avant la transaction d’Alice, puis a racheté WBTC pour gagner le spread après l’exécution de la transaction d’Alice.
Les systèmes décentralisés doivent avoir un MEV
Dans un système centralisé, vous pouvez choisir de faire confiance aux rôles responsables du séquençage des transactions (opérateur, séquenceur) et de croire qu’ils ne feront rien de mal qui nuira à l’utilisateur pour le bien de la réputation, ou vous pouvez choisir de quitter le système. C’est également la situation actuelle de L2, et il est peu probable que les parties du projet L2 cassent leurs propres panneaux pour extraire le MEV.
Mais dans un système décentralisé, n’importe qui peut devenir un développeur de blocs, et nous ne pouvons pas prouver simplement et objectivement que le comportement d’un développeur de blocs est « mauvais », ce qui signifie que nous ne pouvons pas interdire efficacement aux développeurs de blocs d’exploiter les profits.
Nous ne devrions pas nous attendre à ce que les développeurs de blocs soient de « bonnes personnes », mais nous devrions nous inquiéter du fait que si un développeur de blocs gagne de plus en plus d’argent grâce au MEV et investit dans plus d’équipement de développement de blocs, il deviendra de plus en plus grand, ce qui l’amènera à éliminer d’autres concurrents, et le résultat sera un dilemme d’un seul développeur de blocs dans un système décentralisé, et finalement il sera en mesure d’imposer des règles de préférence personnelle sur les transactions des utilisateurs à volonté. Et c’est ainsi que Flashbot a vu le jour.
Flashbot
Afin d’éviter que MEV n’affecte le degré de décentralisation des développeurs de blocs, Flashbot a fait de MEV un marché ouvert où les développeurs de blocs et les chercheurs professionnels de MEV coopèrent et partagent MEV, et il existe un degré élevé de concurrence entre les développeurs de blocs et les chercheurs de MEV.
Grâce à une telle concurrence et à de tels partenariats, les développeurs de blocs et les chercheurs de MEV peuvent se concentrer sur leur propre spécialité, et les chercheurs de MEV n’ont pas à s’inquiéter que les développeurs de blocs puissent voler leurs opportunités d’arbitrage ou délibérément ne pas accepter leurs propres transactions.
△ Searcher trouve des transactions à partir du pool de trading ouvert pour l’arbitrage et enchérit pour les droits de revenu pour ses propres bundles, qui sont donnés à Flashbot puis sélectionnés par le développeur de blocs.
Risque de centralisation
Cependant, Flashbot a toujours un inconvénient, toutes les transactions d’arbitrage MEV searcher doivent passer par un serveur Flashbot centralisé, qui peut voler des opportunités d’arbitrage ou examiner des transactions d’arbitrage.
En plus de Flashbot, des projets comme Eden Network sont également apparus sur le marché. Il s’agit essentiellement de la même architecture que Flashbot, à l’exception de son propre jalonnement inutile, de la priorité des transactions intra-bloc et de mécanismes d’enchères supplémentaires. Mais au moins, lorsque Flashbot commence à faire le mal, les développeurs de blocs et les chercheurs ont d’autres options.
Le MEV est un fait établi qui doit être accepté
Les concepteurs de protocoles et les utilisateurs doivent être vigilants à l’égard du MEV. Si possible, l’intégration du MEV dans la conception du protocole et la transformation du MEV en un outil utile sont des éléments auxquels les concepteurs de protocoles doivent penser lorsqu’ils concevront des mécanismes à l’avenir. Des articles ultérieurs couvriront également la conception et les idées pour faire bon usage de MEV.
La fusion
Ethereum est passé au mécanisme PoS après The Merge, et d’un développeur de blocs en concurrence avec la puissance de calcul des machines de minage au jalonnement d’ETH, il peut devenir un validateur pour avoir la possibilité de proposer des blocs, ce qui signifie que le seuil d’obtention de blocs dans PoS est beaucoup plus bas. L’abaissement du seuil d’obtention d’opportunités de génération de blocs affecte en fait la concurrence et la coopération entre les différents rôles dans Flashbot.
*Conseil de lecture : Proposer ici est conservé en anglais pour éviter de mal interpréter le chinois de proposer block et build block car le sens est trop proche. *
Changement dans la relation de confiance
Avant le PoS, Searcher devait avoir confiance dans le fait que le développeur de blocs ne s’emparerait pas du contenu de son bundle, et même si le développeur de blocs le faisait, Searcher ne pouvait contrer que par des mécanismes hors chaîne, tels que la présentation de preuves pour demander à Flashbot de mettre le développeur de blocs sur liste noire ou la publication d’un message sur Twitter pour le fermer.
Cependant, les développeurs de blocs sont fondamentalement très coopératifs, car la relation entre le développeur de blocs et le Searcher est une coopération à long terme, et si le développeur de blocs saisit le Searcher pour un certain avantage MEV aujourd’hui, et que le développeur de blocs ne recevra aucune opportunité MEV à l’avenir, cela n’en vaudra pas la peine.
Cependant, après le PoS, vous pouvez avoir la possibilité de produire des blocs en jalonnant de l’ETH, et le seuil de production de blocs est abaissé. En conséquence, de nombreuses personnes ordinaires s’inscrivent en tant que validateurs, ce qui entraîne la possibilité d’obtenir des blocs lentement dilués.
Par rapport aux quelques pools de minage qui ont investi beaucoup de coûts dans le PoW et qui fonctionnent depuis longtemps, le validateur en PoS ne peut avoir qu’occasionnellement l’occasion de générer des blocs, et sa récompense de bloc plus le taux annualisé moyen de MEV est calculé même s’il est de 10%, le validateur a toujours une incitation très suffisante pour saisir le MEV du chercheur.
Conseils de lecture : Vous pouvez vous référer au classement MEV des statistiques de Flashbot, copiez le lien ci-dessous pour accéder au navigateur et afficher le contenu connexe :
△ Tant que vous saisissez l’opportunité de saisir plus de 3,2 ETH de MEV, cela dépassera les 10% annualisés.
Par conséquent, l’architecture de Flashbot doit être ajustée pour correspondre au changement de relation de confiance et au mécanisme PoS, et c’est devenu le mev-boost actuel.
MEV-BOOST
Dans mev-boost, le rôle de Relay entre le Searcher et le développeur de blocs du Flashbot a été divisé en deux, l’un est le Builder et l’autre s’appelle Relay mais avec des responsabilités différentes.
Le Chercheur remet le paquet au Constructeur, qui sélectionne plusieurs paquets parmi plusieurs paquets pour former un bloc, et remet le bloc au Relais, qui à son tour sélectionne l’un des blocs soumis par le Relais.
△ Searcher est en concurrence avec Searcher, Builder est en concurrence avec Builder, et Validator choisit le bloc le plus avantageux de celui-ci.
Le Builder est chargé de trouver la combinaison de bundles la plus favorable dans la capacité limitée d’un bloc, en espérant que le Validateur choisira son propre bloc.
Alors, à quoi sert le relais ? Comme mentionné ci-dessus, la relation de confiance a changé, de sorte que le chercheur/constructeur ne peut pas faire confiance au validateur, de sorte que le validateur dans mev-boost doit faire une promesse de « je vais proposer votre bloc » avant de recevoir le contenu réel du bloc.
Relay agit en tant qu’intermédiaire entre le Builder et le Validator pour aider à la coordination : Relay conserve le contenu du bloc jusqu’à ce qu’il obtienne la promesse du Validateur avant de remettre le bloc créé par le Builder au Validateur.
Dans la terminologie actuelle de la chaîne de balises Ethereum, le contenu du bloc créé par le constructeur est appelé ution Payload, et le validateur recevra des données de Relay appelées ution Payload Header, qui peuvent être considérées comme un engagement de Payload, et la signature de l’en-tête représente la signature de Payload.
Lorsque le Validateur choisit le bloc à proposer à Relay, il met l’en-tête de charge utile ution du bloc dans le bloc Beacon et le signe, puis remet le contenu signé à Relay comme preuve, et enfin Relay peut être assuré que le contenu du bloc sera donné au Validator et le laissera proposer le bloc.
△ Le Builder remet le bloc au Relais, et le Relais remet l’En-tête au Validateur
△ Si le validateur sélectionne le bloc, l’en-tête sera placé dans le bloc de balise, signé et remis au relais.
△ Le relais remet ensuite le morceau complet au validateur.
Si le Validateur finit par trahir Relay et choisit de proposer un autre bloc, alors Relay peut publier la signature que le Validateur lui a donnée comme preuve que le Validateur a proposé deux blocs différents, et alors le Validateur sera pénalisé pour avoir violé les règles de la Beacon Chain Ethereum.
△ Eve a été réduit (une partie de l’ETH promis a été confisquée) parce qu’il a proposé un autre blocage.
Hypothèse de confiance
Dans mev-boost, le Validateur doit faire confiance à Relay, si le contenu du bloc finalement révélé par Relay n’est pas légal, ou si l’argent réel reçu par le Validator n’est pas celui attendu, ou même si le Relay ne publie pas directement le contenu du bloc, le Validator ne peut pas proposer le bloc, alors le Validator ne peut contrer que par un mécanisme off-chain, comme faire connaître aux autres Validateurs le comportement malveillant du Relais.
Disjoncteur
Les validateurs ne peuvent pas être surveillés et intervenus 24 heures sur 24, donc lorsque le logiciel de validation constate que (le même relais ou plus) brise constamment la confiance, il doit être capable de réagir pour éviter de perdre des revenus tout le temps car il n’y a pas de blocage de proposition.
Par exemple, lorsque vous constatez que vous n’avez pas proposé de bloc pour plus de cinq emplacements, vous devez revenir en arrière et utiliser votre propre nœud pour rendre le bloc contenu.
Pour les documents pertinents, veuillez consulter :
Moniteur de relais
Afin de réduire l’impact des méfaits du personnage de Relay, la communauté Flashbot réfléchit également à la conception d’un monitoring du comportement de Relay.
Pour les documents pertinents, veuillez consulter :
Disponibilité des données C****ommittee
Une façon d’empêcher Relay de ne pas publier le contenu d’un bloc est de donner les données du bloc à un comité de nœuds qui sont responsables de la conservation et de la disponibilité du contenu du bloc, c’est-à-dire de la décentralisation de la responsabilité de la conservation du contenu du bloc.
Quels sont les constructeurs et les relais actuellement disponibles ? **
Ici vous pouvez voir le Builder et le Relay actuels :
Consultez le site Web :
Comme vous pouvez le voir, bien qu’il s’agisse de l’équipe de développement principale de mev-boost, Flashbot n’a pas le statut de Relay dominant, car Flashbot a développé mev-boost depuis le début et ne s’est pas défini comme le Relay par défaut dans le logiciel mev-boost.
Conseils de lecture : En savoir plus, s’il vous plaît voir
2023-04-02 Attaque contre le relais mev-boost
Un validateur malveillant a découvert une vulnérabilité dans Relay : Relay renverra le contenu de l’ensemble au validateur tant qu’il dispose d’une signature valide pour l’extraction (que le contenu soit légitime ou non).
Par conséquent, le validateur malveillant signe un contenu non valide (les valeurs de certains champs de l’en-tête ne sont pas valides), et après que le relais a renvoyé le contenu du bundle, le validateur vole la transaction d’arbitrage dans le bundle, puis propose un autre bloc valide.
Relay tente de diffuser l’en-tête signé par le Validateur, mais il est rejeté par les autres nœuds car le contenu n’est pas valide, donc tout le monde ne voit que le bloc valide proposé par le Validateur lui-même. Par la suite, le validateur a été rayé et expulsé de la liste des validateurs pour avoir signé deux en-têtes différents (pour Relay et Proposed), mais le mal était fait.
Le Relay mis à jour va maintenant essayer de diffuser l’en-tête Validator en premier, s’il est reçu avec succès par d’autres nœuds, cela signifie que le contenu du signe Validateur est légitime, et les autres noeuds verront le bloc diffusé par Relay en premier, si le Validateur tente de voler le contenu du bundle et le propose lui-même, il sera plus difficile de gagner le bloc diffusé par Relay (car il y a déjà beaucoup de noeuds qui ont vu le bloc diffusé par Relay).
Conseil de lecture 1 : Expliquez le fil de cette attaque et les preuves associées et les correctifs de relais, veuillez vous référer à ce fil de discussion, veuillez vous référer à ce fil de discussion pour plus de détails :
*Conseil de lecture 2 : En plus de voler des transactions d’arbitrage dans les bundles, les validateurs malveillants peuvent également attaquer les arbitragistes qui effectuent des strikes sandwich : les arbitragistes qui effectuent des strikes sandwich insèrent leurs propres transactions avant et après la transaction de la victime - achetant de manière préventive la victime, puis vendant après que la victime ait acheté pour gagner le spread, mais pour que le clipper réussisse, les deux transactions doivent être exécutées, sinon seule la transaction précédente sera exécutée, mais l’arbitragiste non seulement ne gagnera pas le spread, mais perdra également ses propres fonds. *
Cependant, les correctifs apportés en réponse à cette attaque vont augmenter le temps de retard de production des blocs, de sorte que le nombre d’occurrences de réorganisation de la chaîne PoS a considérablement augmenté dans les jours qui ont suivi l’attaque, et plusieurs solutions sont actuellement en cours de conception et de mise en œuvre pour éviter l’instabilité du réseau PoS causée par le retard de MEV-Boost.
Conseil de lecture : Pour des informations détaillées, vous pouvez copier le lien ci-dessous pour les afficher dans votre navigateur
Impact de Flashbot/mev-boost
Affecte l’efficacité du vote du validateur
À cause de Flashbot/mev-boost, le processus d’un bloc, de la production à la proposition effective, est passé par plus de niveaux, ce qui entraîne le retard du bloc de proposition du validateur, et les autres validateurs responsables du vote recevront le bloc plus tard, de sorte que leur temps de vote sera comprimé, ce qui affectera la sécurité de l’ensemble du réseau PoS.
Bien que cela ne semble pas être un impact important : une baisse estimée de 2 % de la participation et une diminution de 1 % des validateurs qui ont voté correctement, cela date d’octobre 2022, lorsque seulement un tiers des validateurs étaient connectés à MEV Relay.
Conseil de lecture : Pour plus d’informations, veuillez vous référer à l’article lié ci-dessous
Résumé et faits saillants
Dans le prochain article, nous présenterons la séparation Proposer-Builder (PBS), qui intègre l’architecture mev-boost directement dans le protocole d’Ethereum, plutôt qu’une collaboration privée entre Validator, Builder et Searcher, ce qui rendra l’ensemble de l’écosystème MEV plus décentralisé et sécurisé.
Données de référence et recommandations pour une lecture complémentaire
*Statistiques: *Statistiques: *