Le 2 avril, des acteurs malveillants du réseau Ethereum ont exploité une vulnérabilité du relais MEV-Boost pour voler 20 millions de dollars à un chercheur MEV (voir le rapport Flashbots). Au cours des jours suivants, les développeurs ont corrigé la vulnérabilité en publiant cinq correctifs. Ces correctifs, combinés aux retards du réseau et aux politiques de validation, ont provoqué une brève fluctuation du réseau Ethereum le 6 avril. La réorganisation des blocs peut être préjudiciable à la santé du réseau car elle ralentit le taux de production de blocs et réduit les assurances de règlement.
Dans cet article, avec Seekers attaqué et le réseau temporairement instable, nous explorons l'interaction entre MEV-Boost et le consensus, analysons les subtilités du mécanisme de preuve de participation d'Ethereum et énumérons quelques voies possibles.
MEV-Boost et pourquoi c'est important
MEV-Boost est un protocole conçu par Flashbots et la communauté pour atténuer l'impact négatif de la valeur extractible maximale (MEV) sur le réseau Ethereum.
Il y a 3 acteurs dans MEV-Boost :
Relais - Des commissaires-priseurs qui se font confiance, connectant les producteurs de blocs et les constructeurs de blocs
Constructeurs - entités complexes qui construisent des blocs pour maximiser le MEV pour eux-mêmes et les créateurs de blocs
Producteurs de blocs - Vérificateurs de preuve de participation d'Ethereum
La séquence approximative des événements pour chaque bloc est :
Les constructeurs créent un bloc en recevant des transactions d'utilisateurs, de chercheurs ou d'autres flux de commande (privés ou publics)
Le constructeur soumet le bloc au relais
Le relais vérifie la validité du bloc et calcule le montant qu'il verse au producteur du bloc
Le relais envoie un titre vierge et une valeur de paiement au producteur de blocs du créneau actuel
Les producteurs de blocs évaluent toutes les offres qu'ils ont reçues et signent l'en-tête vierge associé au paiement le plus élevé
Le producteur de blocs renvoie cet en-tête signé au relais
Les relais publient des blocs à l'aide de leurs nœuds de balise natifs et les renvoient au donneur de blocs. Les récompenses sont distribuées aux constructeurs et aux proposants par le biais de transactions au sein de blocs et de récompenses de bloc.
Un relais est un tiers de confiance qui facilite un échange équitable d'espace de blocs par les producteurs de blocs et la commande de transactions par les constructeurs pour l'extraction de MEV. Les relais protègent les constructeurs en protégeant les constructeurs contre le vol de MEV, empêchant les producteurs de blocs de copier les transactions des constructeurs pour retirer le MEV sans le distribuer aux chercheurs/constructeurs qui l'ont trouvé. Les relais protègent les producteurs de blocs en confirmant la validité de leurs blocs, en traitant des centaines de blocs par créneau en leur nom et en garantissant l'exactitude des paiements des producteurs de blocs.
MEV-Boost est une infrastructure de protocole clé car elle permet à tous les producteurs de blocs d'accéder démocratiquement à MEV sans nécessiter une relation de confiance avec les constructeurs ou les chercheurs, ce qui contribue à la décentralisation à long terme d'Ethereum.
Règles de sélection de fork d'Ethereum et MEV-Boost
Avant de discuter de l'attaque et de la réponse, examinons le mécanisme de preuve de participation d'Ethereum et les règles de sélection de fork associées. La règle de choix de la fourche permet au réseau de parvenir à un consensus sur la tête de chaîne, telle que définie dans l'article "Ethereum post-merger reorganization":
"La règle de choix de fourche est une fonction évaluée par le client, qui prend en entrée les blocs vus et d'autres informations, et sort la" chaîne canonique "au client. La règle de choix de fourche est importante car il peut y avoir plusieurs chaînes valides parmi lesquelles choisir (par exemple, si deux blocs concurrents avec le même bloc parent sont publiés en même temps). "
Les règles de sélection de fourche dépendent également du temps, ce qui a un impact significatif sur la génération de blocs.
cycle de slot et de sous-slot
Dans le mécanisme de preuve de participation d'Ethereum, le temps est divisé en créneaux toutes les 12 secondes. L'algorithme de preuve de participation attribue au hasard à un validateur une licence pour proposer un bloc dans ce créneau ; ce validateur est appelé un producteur de bloc. Dans le même créneau, d'autres validateurs se voient confier la tâche de valider (voter) pour le chef de chaîne en appliquant les règles de choix de fourche en fonction de leurs vues locales. Ce créneau de 12 secondes est subdivisé en trois phases, chacune coûtant 4 secondes.
Les événements qui se produisent dans le créneau sont les suivants, où t=0 indique le début du créneau.
Pendant le créneau, le moment le plus critique est le délai d'authentification à t=4. Si les validateurs attestants ne voient pas le bloc avant la date limite d'attestation, ils voteront pour le chef de chaîne précédemment accepté (selon la règle de choix de la fourchette). Plus un bloc est proposé tôt, plus il a de temps pour se propager et donc accumuler plus d'approbations (car plus de validateurs le voient avant la date limite d'approbation).
Du point de vue de la santé du réseau, le moment optimal pour une libération de bloc est t=0 (selon la spécification). Cependant, étant donné que la valeur du bloc augmente de manière monotone au fil du temps, les producteurs de blocs sont incités à retarder la libération de leurs blocs afin que davantage de MEV puissent s'accumuler. Voir Jeux de chronométrage dans Proof-of-Stake et cette discussion pour plus de détails.
Auparavant, un producteur de blocs pouvait publier un bloc après la date limite de certification (même proche de la fin du créneau), tant que le validateur suivant observait le bloc avant d'établir le bloc pour son créneau suivant. Cela est dû au fait que le bloc enfant hérite du poids du bloc parent et que la règle de sélection de fourche se termine au nœud feuille. Par conséquent, le report des libérations en bloc n'a aucun effet secondaire. Pour aider à passer d'un comportement rationnel (reporter les publications en bloc) à un comportement honnête (publier à temps), une "réorganisation honnête" a été mise en place.
Mécanisme de récompense des producteurs de blocs et réorganisation honnête
Deux nouveaux concepts sont introduits dans le client de consensus qui ont un impact critique sur le délai d'authentification.
Mécanisme de récompense du producteur de blocs - Vise à minimiser les attaques de rééquilibrage en attribuant aux producteurs de blocs une "récompense" de sélection de fourche égale à 40 % du poids total de l'authentification. Il est important de noter que cette récompense ne dure que pendant toute la durée de l'emplacement.
Réorganisation honnête - profitez de l'accélération des producteurs de blocs, permettant aux producteurs de blocs honnêtes de forcer la réorganisation des blocs avec des poids d'authentification inférieurs à 20 %. Ceci est déjà implémenté dans Lighthouse et Prysm (à partir de la v4.0 - version Capella). Ce changement est facultatif car il s'agit d'une décision prise par les producteurs de blocs et n'affecte pas le comportement des validateurs d'authentification. Nous ne l'appliquons donc pas à tous les clients en même temps, ni à un hard fork particulier.
Il convient de noter que la réorganisation honnête est évitée dans certains cas particuliers :
Pendant les blocs de délimitation d'époque
Si la chaîne n'est pas finalisée
Si le chef de chaîne n'est pas le chef de créneau avant réorganisation
Le cas 3 garantit que les réorganisations honnêtes ne suppriment qu'un seul bloc de la chaîne, qui agit comme un disjoncteur, permettant à la chaîne de continuer à produire des blocs pendant les périodes de latence extrême du réseau. Cela reflète également le fait que les proposants ont moins confiance dans la perception du réseau, car ils ne peuvent pas être sûrs que les blocs améliorés qu'ils proposent seront considérés comme la norme.
La figure ci-dessous montre comment un comportement honnête peut être modifié pour mettre en œuvre une stratégie de restructuration.
Dans ce cas, soit b1 représenter un bloc tardif. En raison du retard, b1 n'a que 19 % du poids de preuve de la nième tranche. Les 81 % restants du poids de preuve sont attribués au bloc parent HEAD car de nombreux démonstrateurs n'ont pas vu b1 avant la date limite de preuve.
S'il n'y a pas de réorganisation honnête, le proposant du slot n+1 considérera b1 comme tête de chaîne et construira le sous-bloc b2. Le proposant n'a fait aucun effort pour réorganiser b1, même s'il n'a que 19% de poids de preuve. Au créneau n + 1, b2 a l'amélioration du proposant, en supposant qu'il soit livré à temps, b2 deviendra la norme en accumulant une majorité de preuves pour ce créneau.
Avec Honest Reorganization, les choses sont très différentes. Maintenant, le proposant de l'emplacement n+1 voit que 19 % des poids de preuve de b1 sont inférieurs au seuil de réorganisation, il construit donc un bloc avec HEAD comme parent et force b1 à se réorganiser. Lorsque nous atteignons la date limite de preuve pour le créneau n + 1, le prouveur honnête comparera les poids relatifs de b1 (19%) à b2 (40% du boost du proposant). Tous les clients implémentent l'amélioration du proposant, donc b2 sera considéré comme le chef de la chaîne et accumulera des preuves pour le slot n+1.
Correctifs des nœuds Relay et Beacon pour les attaques de dégroupage
Lors de l'attaque de dégroupage du 2 avril, le proposant a exploité une vulnérabilité de relais pour envoyer un en-tête de signature invalide au relais. Au cours des jours suivants, les équipes de relais et de développement principal ont publié de nombreux correctifs logiciels pour atténuer le risque d'attaques répétées. Les cinq principaux changements sont les suivants :
Changements de relais : vérifiez la base de données pour les proposants malveillants connus (utilisés en production par Ultrasonic Relay uniquement et a été supprimé). Vérifie si le relais a livré le bloc complet à un emplacement du réseau P2P. Introduit un délai aléatoire uniforme dans la plage de 0 à 500 ms avant la publication d'un bloc (supprimé de tous les relais).
Changement de nœud de balise (nœuds de balise relais uniquement) : Validez les blocs de balise avant la diffusion. Vérifiez le réseau pour de fausses confirmations avant de publier un bloc. La combinaison de ces changements a conduit à une instabilité du consensus, un problème exacerbé par le fait qu'une majorité de validateurs utilisent désormais la stratégie de réorganisation honnête décrite ci-dessus.
CONSÉQUENCES INATTENDUES
Les cinq changements introduisent avant tout des retards dans le chemin chaud de l'émission des blocs de relais, ce qui augmente la probabilité que les blocs de relais soient diffusés après la date limite de confirmation. Le schéma ci-dessous montre l'enchaînement de ces cinq contrôles et comment le retard introduit fait que la publication en bloc dépasse le délai de confirmation.
Un grand nombre d'en-têtes signés avec un décalage de t = 0 (par exemple t = 3) ne pose généralement pas de problèmes jusqu'à ce que ces vérifications soient mises en œuvre. Étant donné que le relais a une surcharge très faible, il publiera le bloc avant t = 4 sans attendre la date limite de confirmation.
Cependant, en raison de l'introduction tardive de ces cinq correctifs, le relais peut désormais être partiellement responsable de la diffusion retardée. Regardons le processus hypothétique de publication en bloc ci-dessous.
Le relais reçoit l'en-tête signé du producteur de blocs à t = 3. À t = 4, le relais effectue toujours des vérifications, donc la diffusion aura lieu après la date limite de confirmation. Dans ce cas, la combinaison de l'en-tête signé retardé envoyé par le producteur de blocs et d'un délai supplémentaire introduit par le relais a provoqué l'échec de la diffusion avant la date limite de confirmation. S'il n'y avait pas eu une réorganisation honnête, ces blocs auraient probablement été intégrés à la chaîne. Comme le montre la figure 2, les producteurs de blocs honnêtes du créneau suivant ne se réorganiseront pas délibérément car ces blocs sont en retard. Cependant, si le délai de confirmation n'est pas respecté, les blocs seront réorganisés par le prochain producteur de blocs.
Par conséquent, le nombre de blocs fourchus a considérablement augmenté dans les jours qui ont suivi l'attaque.
Deux semaines de données de Metrika montrent que dans le pire des cas, 13 blocs (4,3 %) pourraient être réorganisés en une heure, soit environ 5 fois le taux normal. L'augmentation spectaculaire du nombre de blocs fourchus est devenue évidente lorsque les relayeurs ont déployé divers changements. Grâce aux grands efforts de la communauté des opérateurs de relais et des principaux développeurs, une fois l'impact connu, de nombreux changements ont été annulés et le réseau a été restauré dans un état sain.
À ce jour, les modifications les plus utiles sont la validation du bloc de nœud de balise et les vérifications de répudiation avant l'émission. Les producteurs de blocs malveillants ne peuvent plus effectuer d'attaques en envoyant des en-têtes invalides aux relais et en s'assurant que les nœuds de balise de relais ne voient pas les blocs répudiés avant de les publier. Néanmoins, les relais sont toujours confrontés au déni d'attaques plus général proposé dans MEV-Boost et ePBS.
Prochaine action
Dans cet article, nous soulignons le fonctionnement de MEV-Boost et son importance pour le consensus Ethereum. Nous fournissons également une analyse détaillée de certains aspects moins connus des règles de choix de fork Ethereum liées au timing. En utilisant l'attaque de « dégroupage » et les réponses des développeurs comme étude de cas, nous mettons en évidence la vulnérabilité potentielle des aspects dépendant du temps de la règle de choix du fork et son impact sur la stabilité du réseau.
Dans cet esprit, la communauté des chercheurs devrait évaluer ce qui est un nombre "acceptable" de réorganisations, en tenant compte de l'exposition plus générale des attaques par déni, afin de déterminer si des mesures d'atténuation doivent être mises en œuvre.
De plus, plusieurs directions futures sont actuellement activement explorées :
Implémenter un mécanisme de prise de tête pour protéger MEV-boost des attaques par erreur d'équivalence. Cela nécessiterait également des modifications du logiciel client de consensus et éventuellement des modifications des spécifications pour prolonger la date limite de soumission des preuves.
Augmenter le nombre et la distribution des programmes de primes de bogues pour le logiciel MEV-Boost.
Étendez le logiciel de simulation pour explorer comment la synchronisation des sous-créneaux affecte la stabilité du réseau, ce qui peut être utilisé pour évaluer comment ajuster les délais de soumission des preuves afin de réduire la réorganisation.
Optimiser le chemin de libération de bloc sur le relais pour réduire les retards inutiles - ceci est déjà en cours d'exploration.
Reconnaître que MEV-boost est une caractéristique essentielle du protocole et l'incorporer dans le client consensuel, c'est-à-dire "enshrined-PBS (ePBS)". L'ePBS à deux emplacements est vulnérable aux attaques évidentes, donc la mise en œuvre d'un "mécanisme de prise de tête" est toujours une option.
En ajoutant plus de tests de ruche et/ou de spécifications autour des problèmes de latence et des délais de certification.
Encouragez la diversité des clients de relais en créant des implémentations supplémentaires de la spécification de relais.
Envisagez d'ajuster les pénalités pour les attaques évidentes, mais gardez à l'esprit que même une pénalité complète de 32 ETH peut ne pas dissuader les comportements malveillants lorsque l'opportunité extrême de MEV existe.
Revoyez la synchronisation des sous-créneaux et envisagez d'ajuster la phase de propagation du bloc (par exemple, ajuster le délai de certification de t=4 à t=6).
Dans l'ensemble, nous sommes ravis de la résurgence du MEV et de l'écosystème mev-boost. Grâce au dégroupage des attaques et des atténuations, nous avons appris la relation critique entre la latence, le boost MEV et les mécanismes de consensus ; nous espérons que le protocole continuera à être renforcé pour gérer cela.
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.
Explication détaillée du principe de fonctionnement de MEV-Boost et des règles de sélection de la fourche Ethereum
Auteur : Georgios Konstantopoulos, Mike Neuder
Compilation : Kxp, BlockBeats
Introduction
Le 2 avril, des acteurs malveillants du réseau Ethereum ont exploité une vulnérabilité du relais MEV-Boost pour voler 20 millions de dollars à un chercheur MEV (voir le rapport Flashbots). Au cours des jours suivants, les développeurs ont corrigé la vulnérabilité en publiant cinq correctifs. Ces correctifs, combinés aux retards du réseau et aux politiques de validation, ont provoqué une brève fluctuation du réseau Ethereum le 6 avril. La réorganisation des blocs peut être préjudiciable à la santé du réseau car elle ralentit le taux de production de blocs et réduit les assurances de règlement.
Dans cet article, avec Seekers attaqué et le réseau temporairement instable, nous explorons l'interaction entre MEV-Boost et le consensus, analysons les subtilités du mécanisme de preuve de participation d'Ethereum et énumérons quelques voies possibles.
MEV-Boost et pourquoi c'est important
MEV-Boost est un protocole conçu par Flashbots et la communauté pour atténuer l'impact négatif de la valeur extractible maximale (MEV) sur le réseau Ethereum.
Il y a 3 acteurs dans MEV-Boost :
Relais - Des commissaires-priseurs qui se font confiance, connectant les producteurs de blocs et les constructeurs de blocs
Constructeurs - entités complexes qui construisent des blocs pour maximiser le MEV pour eux-mêmes et les créateurs de blocs
Producteurs de blocs - Vérificateurs de preuve de participation d'Ethereum
La séquence approximative des événements pour chaque bloc est :
Les constructeurs créent un bloc en recevant des transactions d'utilisateurs, de chercheurs ou d'autres flux de commande (privés ou publics)
Le constructeur soumet le bloc au relais
Le relais vérifie la validité du bloc et calcule le montant qu'il verse au producteur du bloc
Le relais envoie un titre vierge et une valeur de paiement au producteur de blocs du créneau actuel
Les producteurs de blocs évaluent toutes les offres qu'ils ont reçues et signent l'en-tête vierge associé au paiement le plus élevé
Le producteur de blocs renvoie cet en-tête signé au relais
Les relais publient des blocs à l'aide de leurs nœuds de balise natifs et les renvoient au donneur de blocs. Les récompenses sont distribuées aux constructeurs et aux proposants par le biais de transactions au sein de blocs et de récompenses de bloc.
Un relais est un tiers de confiance qui facilite un échange équitable d'espace de blocs par les producteurs de blocs et la commande de transactions par les constructeurs pour l'extraction de MEV. Les relais protègent les constructeurs en protégeant les constructeurs contre le vol de MEV, empêchant les producteurs de blocs de copier les transactions des constructeurs pour retirer le MEV sans le distribuer aux chercheurs/constructeurs qui l'ont trouvé. Les relais protègent les producteurs de blocs en confirmant la validité de leurs blocs, en traitant des centaines de blocs par créneau en leur nom et en garantissant l'exactitude des paiements des producteurs de blocs.
MEV-Boost est une infrastructure de protocole clé car elle permet à tous les producteurs de blocs d'accéder démocratiquement à MEV sans nécessiter une relation de confiance avec les constructeurs ou les chercheurs, ce qui contribue à la décentralisation à long terme d'Ethereum.
Règles de sélection de fork d'Ethereum et MEV-Boost
Avant de discuter de l'attaque et de la réponse, examinons le mécanisme de preuve de participation d'Ethereum et les règles de sélection de fork associées. La règle de choix de la fourche permet au réseau de parvenir à un consensus sur la tête de chaîne, telle que définie dans l'article "Ethereum post-merger reorganization":
"La règle de choix de fourche est une fonction évaluée par le client, qui prend en entrée les blocs vus et d'autres informations, et sort la" chaîne canonique "au client. La règle de choix de fourche est importante car il peut y avoir plusieurs chaînes valides parmi lesquelles choisir (par exemple, si deux blocs concurrents avec le même bloc parent sont publiés en même temps). "
Les règles de sélection de fourche dépendent également du temps, ce qui a un impact significatif sur la génération de blocs.
cycle de slot et de sous-slot
Dans le mécanisme de preuve de participation d'Ethereum, le temps est divisé en créneaux toutes les 12 secondes. L'algorithme de preuve de participation attribue au hasard à un validateur une licence pour proposer un bloc dans ce créneau ; ce validateur est appelé un producteur de bloc. Dans le même créneau, d'autres validateurs se voient confier la tâche de valider (voter) pour le chef de chaîne en appliquant les règles de choix de fourche en fonction de leurs vues locales. Ce créneau de 12 secondes est subdivisé en trois phases, chacune coûtant 4 secondes.
Les événements qui se produisent dans le créneau sont les suivants, où t=0 indique le début du créneau.
Pendant le créneau, le moment le plus critique est le délai d'authentification à t=4. Si les validateurs attestants ne voient pas le bloc avant la date limite d'attestation, ils voteront pour le chef de chaîne précédemment accepté (selon la règle de choix de la fourchette). Plus un bloc est proposé tôt, plus il a de temps pour se propager et donc accumuler plus d'approbations (car plus de validateurs le voient avant la date limite d'approbation).
Du point de vue de la santé du réseau, le moment optimal pour une libération de bloc est t=0 (selon la spécification). Cependant, étant donné que la valeur du bloc augmente de manière monotone au fil du temps, les producteurs de blocs sont incités à retarder la libération de leurs blocs afin que davantage de MEV puissent s'accumuler. Voir Jeux de chronométrage dans Proof-of-Stake et cette discussion pour plus de détails.
Auparavant, un producteur de blocs pouvait publier un bloc après la date limite de certification (même proche de la fin du créneau), tant que le validateur suivant observait le bloc avant d'établir le bloc pour son créneau suivant. Cela est dû au fait que le bloc enfant hérite du poids du bloc parent et que la règle de sélection de fourche se termine au nœud feuille. Par conséquent, le report des libérations en bloc n'a aucun effet secondaire. Pour aider à passer d'un comportement rationnel (reporter les publications en bloc) à un comportement honnête (publier à temps), une "réorganisation honnête" a été mise en place.
Mécanisme de récompense des producteurs de blocs et réorganisation honnête
Deux nouveaux concepts sont introduits dans le client de consensus qui ont un impact critique sur le délai d'authentification.
Mécanisme de récompense du producteur de blocs - Vise à minimiser les attaques de rééquilibrage en attribuant aux producteurs de blocs une "récompense" de sélection de fourche égale à 40 % du poids total de l'authentification. Il est important de noter que cette récompense ne dure que pendant toute la durée de l'emplacement.
Réorganisation honnête - profitez de l'accélération des producteurs de blocs, permettant aux producteurs de blocs honnêtes de forcer la réorganisation des blocs avec des poids d'authentification inférieurs à 20 %. Ceci est déjà implémenté dans Lighthouse et Prysm (à partir de la v4.0 - version Capella). Ce changement est facultatif car il s'agit d'une décision prise par les producteurs de blocs et n'affecte pas le comportement des validateurs d'authentification. Nous ne l'appliquons donc pas à tous les clients en même temps, ni à un hard fork particulier.
Il convient de noter que la réorganisation honnête est évitée dans certains cas particuliers :
Pendant les blocs de délimitation d'époque
Si la chaîne n'est pas finalisée
Si le chef de chaîne n'est pas le chef de créneau avant réorganisation
Le cas 3 garantit que les réorganisations honnêtes ne suppriment qu'un seul bloc de la chaîne, qui agit comme un disjoncteur, permettant à la chaîne de continuer à produire des blocs pendant les périodes de latence extrême du réseau. Cela reflète également le fait que les proposants ont moins confiance dans la perception du réseau, car ils ne peuvent pas être sûrs que les blocs améliorés qu'ils proposent seront considérés comme la norme.
La figure ci-dessous montre comment un comportement honnête peut être modifié pour mettre en œuvre une stratégie de restructuration.
Dans ce cas, soit b1 représenter un bloc tardif. En raison du retard, b1 n'a que 19 % du poids de preuve de la nième tranche. Les 81 % restants du poids de preuve sont attribués au bloc parent HEAD car de nombreux démonstrateurs n'ont pas vu b1 avant la date limite de preuve.
S'il n'y a pas de réorganisation honnête, le proposant du slot n+1 considérera b1 comme tête de chaîne et construira le sous-bloc b2. Le proposant n'a fait aucun effort pour réorganiser b1, même s'il n'a que 19% de poids de preuve. Au créneau n + 1, b2 a l'amélioration du proposant, en supposant qu'il soit livré à temps, b2 deviendra la norme en accumulant une majorité de preuves pour ce créneau.
Avec Honest Reorganization, les choses sont très différentes. Maintenant, le proposant de l'emplacement n+1 voit que 19 % des poids de preuve de b1 sont inférieurs au seuil de réorganisation, il construit donc un bloc avec HEAD comme parent et force b1 à se réorganiser. Lorsque nous atteignons la date limite de preuve pour le créneau n + 1, le prouveur honnête comparera les poids relatifs de b1 (19%) à b2 (40% du boost du proposant). Tous les clients implémentent l'amélioration du proposant, donc b2 sera considéré comme le chef de la chaîne et accumulera des preuves pour le slot n+1.
Correctifs des nœuds Relay et Beacon pour les attaques de dégroupage
Lors de l'attaque de dégroupage du 2 avril, le proposant a exploité une vulnérabilité de relais pour envoyer un en-tête de signature invalide au relais. Au cours des jours suivants, les équipes de relais et de développement principal ont publié de nombreux correctifs logiciels pour atténuer le risque d'attaques répétées. Les cinq principaux changements sont les suivants :
Changements de relais : vérifiez la base de données pour les proposants malveillants connus (utilisés en production par Ultrasonic Relay uniquement et a été supprimé). Vérifie si le relais a livré le bloc complet à un emplacement du réseau P2P. Introduit un délai aléatoire uniforme dans la plage de 0 à 500 ms avant la publication d'un bloc (supprimé de tous les relais).
Changement de nœud de balise (nœuds de balise relais uniquement) : Validez les blocs de balise avant la diffusion. Vérifiez le réseau pour de fausses confirmations avant de publier un bloc. La combinaison de ces changements a conduit à une instabilité du consensus, un problème exacerbé par le fait qu'une majorité de validateurs utilisent désormais la stratégie de réorganisation honnête décrite ci-dessus.
CONSÉQUENCES INATTENDUES
Les cinq changements introduisent avant tout des retards dans le chemin chaud de l'émission des blocs de relais, ce qui augmente la probabilité que les blocs de relais soient diffusés après la date limite de confirmation. Le schéma ci-dessous montre l'enchaînement de ces cinq contrôles et comment le retard introduit fait que la publication en bloc dépasse le délai de confirmation.
Un grand nombre d'en-têtes signés avec un décalage de t = 0 (par exemple t = 3) ne pose généralement pas de problèmes jusqu'à ce que ces vérifications soient mises en œuvre. Étant donné que le relais a une surcharge très faible, il publiera le bloc avant t = 4 sans attendre la date limite de confirmation.
Cependant, en raison de l'introduction tardive de ces cinq correctifs, le relais peut désormais être partiellement responsable de la diffusion retardée. Regardons le processus hypothétique de publication en bloc ci-dessous.
Le relais reçoit l'en-tête signé du producteur de blocs à t = 3. À t = 4, le relais effectue toujours des vérifications, donc la diffusion aura lieu après la date limite de confirmation. Dans ce cas, la combinaison de l'en-tête signé retardé envoyé par le producteur de blocs et d'un délai supplémentaire introduit par le relais a provoqué l'échec de la diffusion avant la date limite de confirmation. S'il n'y avait pas eu une réorganisation honnête, ces blocs auraient probablement été intégrés à la chaîne. Comme le montre la figure 2, les producteurs de blocs honnêtes du créneau suivant ne se réorganiseront pas délibérément car ces blocs sont en retard. Cependant, si le délai de confirmation n'est pas respecté, les blocs seront réorganisés par le prochain producteur de blocs.
Par conséquent, le nombre de blocs fourchus a considérablement augmenté dans les jours qui ont suivi l'attaque.
Deux semaines de données de Metrika montrent que dans le pire des cas, 13 blocs (4,3 %) pourraient être réorganisés en une heure, soit environ 5 fois le taux normal. L'augmentation spectaculaire du nombre de blocs fourchus est devenue évidente lorsque les relayeurs ont déployé divers changements. Grâce aux grands efforts de la communauté des opérateurs de relais et des principaux développeurs, une fois l'impact connu, de nombreux changements ont été annulés et le réseau a été restauré dans un état sain.
À ce jour, les modifications les plus utiles sont la validation du bloc de nœud de balise et les vérifications de répudiation avant l'émission. Les producteurs de blocs malveillants ne peuvent plus effectuer d'attaques en envoyant des en-têtes invalides aux relais et en s'assurant que les nœuds de balise de relais ne voient pas les blocs répudiés avant de les publier. Néanmoins, les relais sont toujours confrontés au déni d'attaques plus général proposé dans MEV-Boost et ePBS.
Prochaine action
Dans cet article, nous soulignons le fonctionnement de MEV-Boost et son importance pour le consensus Ethereum. Nous fournissons également une analyse détaillée de certains aspects moins connus des règles de choix de fork Ethereum liées au timing. En utilisant l'attaque de « dégroupage » et les réponses des développeurs comme étude de cas, nous mettons en évidence la vulnérabilité potentielle des aspects dépendant du temps de la règle de choix du fork et son impact sur la stabilité du réseau.
Dans cet esprit, la communauté des chercheurs devrait évaluer ce qui est un nombre "acceptable" de réorganisations, en tenant compte de l'exposition plus générale des attaques par déni, afin de déterminer si des mesures d'atténuation doivent être mises en œuvre.
De plus, plusieurs directions futures sont actuellement activement explorées :
Implémenter un mécanisme de prise de tête pour protéger MEV-boost des attaques par erreur d'équivalence. Cela nécessiterait également des modifications du logiciel client de consensus et éventuellement des modifications des spécifications pour prolonger la date limite de soumission des preuves.
Augmenter le nombre et la distribution des programmes de primes de bogues pour le logiciel MEV-Boost.
Étendez le logiciel de simulation pour explorer comment la synchronisation des sous-créneaux affecte la stabilité du réseau, ce qui peut être utilisé pour évaluer comment ajuster les délais de soumission des preuves afin de réduire la réorganisation.
Optimiser le chemin de libération de bloc sur le relais pour réduire les retards inutiles - ceci est déjà en cours d'exploration.
Reconnaître que MEV-boost est une caractéristique essentielle du protocole et l'incorporer dans le client consensuel, c'est-à-dire "enshrined-PBS (ePBS)". L'ePBS à deux emplacements est vulnérable aux attaques évidentes, donc la mise en œuvre d'un "mécanisme de prise de tête" est toujours une option.
En ajoutant plus de tests de ruche et/ou de spécifications autour des problèmes de latence et des délais de certification.
Encouragez la diversité des clients de relais en créant des implémentations supplémentaires de la spécification de relais.
Envisagez d'ajuster les pénalités pour les attaques évidentes, mais gardez à l'esprit que même une pénalité complète de 32 ETH peut ne pas dissuader les comportements malveillants lorsque l'opportunité extrême de MEV existe.
Revoyez la synchronisation des sous-créneaux et envisagez d'ajuster la phase de propagation du bloc (par exemple, ajuster le délai de certification de t=4 à t=6).
Dans l'ensemble, nous sommes ravis de la résurgence du MEV et de l'écosystème mev-boost. Grâce au dégroupage des attaques et des atténuations, nous avons appris la relation critique entre la latence, le boost MEV et les mécanismes de consensus ; nous espérons que le protocole continuera à être renforcé pour gérer cela.