Temps, créneaux et ordre des événements dans l'attestation d'Ethereum
Le 2 avril, un participant malveillant au réseau Ethereum a exploité une vulnérabilité du mev-boost-relay pour voler 20 millions de dollars à un chercheur MEV. Les développeurs ont ensuite publié cinq correctifs pour résoudre cette vulnérabilité, mais l'interaction avec les retards du réseau existant et les stratégies des validateurs a entraîné une brève instabilité du réseau Ethereum le 6 avril. La reconstitution du réseau réduit le taux de production de blocs et les garanties de règlement, ce qui nuit à la santé du réseau.
Cet article vise à explorer l'interaction entre mev-boost et le mécanisme de consensus, à révéler les subtilités de l'attestation d'Ethereum et à discuter de certaines directions d'amélioration possibles. Notre inspiration provient de deux événements : les chercheurs subissant des attaques et l'instabilité temporaire du réseau.
le rôle de mev-boost
mev-boost est un protocole visant à atténuer l'impact négatif de la valeur maximale pouvant être extraite (MEV) sur le réseau Ethereum.
Il y a trois rôles dans mev-boost :
Relais - Connecte le proposeur à un intermédiaire de confiance des constructeurs de blocs.
Constructeur - Construire des blocs pour maximiser la complexité de l'entité MEV de soi-même et du proposer.
Proposant - Validateur d'attestation Ethereum.
L'ordre des événements dans chaque bloc est le suivant :
Les constructeurs reçoivent des transactions de création de blocs des utilisateurs, des chercheurs ou d'autres sources.
Les constructeurs soumettent les blocs au relais.
Valider l'efficacité des blocs de relais et calculer les frais à payer au proposeur.
Le relais envoie l'en-tête de bloc "masqué" et le montant du paiement au proposeur de la tranche actuelle.
Le proposant évalue toutes les offres reçues et signe l'en-tête de bloc masqué correspondant au paiement le plus élevé.
Le proposeur renverra l'en-tête de bloc signé au relais.
Le relais publie des blocs via le nœud de balise local et les renvoie au proposeur. Grâce aux transactions dans le bloc et aux récompenses de bloc, le constructeur et le proposeur reçoivent des récompenses.
Le relais, en tant que tiers de confiance, facilite l'échange équitable de l'espace de bloc pour les proposeurs, ainsi que le tri des transactions pour l'extraction de MEV par les constructeurs. Le relais protège les constructeurs contre le vol de MEV et protège également les proposeurs en vérifiant la validité des blocs, en traitant un grand nombre de blocs et en garantissant un paiement précis.
mev-boost est une infrastructure clé, car elle permet à tous les proposeurs d'accéder équitablement à l'MEV sans avoir besoin d'établir une relation de confiance, contribuant ainsi à la décentralisation à long terme d'Ethereum.
Règles de sélection des forks d'Ethereum et mev-boost
Avant d'explorer en profondeur les attaques et les réponses, comprenons d'abord le mécanisme d'attestation d'Ethereum ( PoS ) et ses règles de sélection de bifurcation. Les règles de sélection de bifurcation permettent au réseau d'atteindre un consensus sur le bloc de tête.
La règle de sélection de fork est une fonction évaluée par le client, qui prend en entrée des blocs connus et d'autres messages, et produit ce qu'est la "chaîne canonique". La nécessité de la règle de sélection de fork provient du fait qu'il peut exister plusieurs chaînes valides parmi lesquelles choisir.
La relation entre les règles de sélection des forks et le temps est peu connue, mais elle a un impact significatif sur la production de blocs.
périodes de slots et de sous-slots
Dans Ethereum PoS, le temps est divisé en intervalles de 12 secondes. L'algorithme PoS désigne aléatoirement un validateur pour proposer le bloc de cet intervalle, ce validateur est appelé le proposeur. Dans le même intervalle, d'autres validateurs sont désignés pour voter sur le dernier bloc à la position de l'en-tête de la chaîne dans leur vue locale, en appliquant les règles de sélection des forks. L'intervalle de 12 secondes est divisé en trois phases de 4 secondes.
Les événements dans le slot sont les suivants, t=0 indique le début du slot :
Le moment crucial dans le slot est la date limite d'attestation à t=4. Si le validateur d'attestation ne voit pas le bloc avant la date limite, il votera sur le bloc précédent confirmé sur la chaîne. Plus la proposition de bloc est faite tôt, plus le temps de propagation est long, et plus il y a de témoignages accumulés.
Du point de vue de la santé du réseau, le meilleur moment pour publier un bloc est t=0. Cependant, comme la valeur du bloc augmente de manière monotone avec le temps, les proposeurs ont une motivation à retarder la publication pour accumuler plus de MEV.
Dans l'histoire, même après la période d'attestation et même près de la fin du slot, tant que le prochain validateur observe le bloc avant de construire le bloc du slot suivant, le proposeur peut toujours publier le bloc. Pour encourager un comportement rationnel, ( retarder la publication du bloc ) vers un comportement honnête ( en publiant à temps ), "restructuration honnête" a été introduite.
Amélioration des propositions et réorganisation honnête
Deux nouveaux concepts ont été introduits dans le client de consensus, ayant un impact important sur la date limite d'attestation.
Augmentation des proposeurs - Tentative de minimiser l'attaque de réorganisation d'équilibre en accordant aux proposeurs une "augmentation" du choix de bifurcation équivalente à 40 % du poids de certification complet. Cette augmentation ne dure qu'un seul créneau.
Restructuration honnête - Adoption par les proposeurs, permettant aux proposeurs honnêtes de l'utiliser pour forcer la restructuration des blocs dont le poids de validation est inférieur à 20%. Cela est implémenté dans certains clients. Ce changement est optionnel, car il s'agit d'une décision locale des proposeurs, sans impact sur le comportement des validateurs.
Éviter la réorganisation honnête dans certaines circonstances particulières :
Pendant la période du bloc de frontière d'époque
Si la chaîne n'est pas terminée
Si la tête de chaîne n'est pas obtenue à partir de l'emplacement avant le bloc de réorganisation
Condition 3 Assurez-vous que la réorganisation honnête ne supprime qu'un seul bloc de la chaîne, servant de disjoncteur pour permettre à la chaîne de continuer à générer des blocs en cas de délais réseau extrêmes.
Réparation des relais et des nœuds de balisage contre les attaques de désassociation
Lors de l'attaque de désengagement du 2 avril, le proposeur a exploité une vulnérabilité de relais pour envoyer des en-têtes de signature invalides lors de l'attaque. Dans les jours suivants, l'équipe de développement de relais et de noyau a publié plusieurs correctifs logiciels pour atténuer le risque de récurrence des attaques. Les cinq principaux changements sont les suivants :
1.Changement de relais:
Vérifiez si la base de données contient des demandeurs malveillants connus.
Vérifiez si le bloc complet a été transmis au réseau P2P pendant cette période.
Introduire un délai aléatoire uniforme dans la plage de 0 à 500 ms avant la publication du bloc.
2.Changement de nœud de chaîne de balises ( uniquement applicable aux nœuds de chaîne de balises de relais ):
Valider l'efficacité du bloc de balise de diffusion.
Vérifiez s'il existe un équivalent sur le réseau avant de publier le bloc.
Ces changements combinés entraînent une instabilité du consensus, et la plupart des validateurs adoptent une stratégie de réorganisation honnête qui aggrave davantage la situation.
Conséquences inattendues
Chacune des 5 modifications susmentionnées augmentera le délai sur le chemin chaud de publication des blocs relais, augmentant ainsi la probabilité que le bloc relais soit diffusé après la date limite d'attestation.
Avant de mettre en œuvre ces vérifications, il n'y aura généralement pas de problème si l'en-tête de signature arrive aux alentours de t=3. Les frais de relais sont très faibles et il est possible de publier le bloc avant t=4.
Cependant, avec l'augmentation des retards causés par l'introduction des cinq correctifs, le relais pourrait en être en partie responsable. Dans certains cas, le fait que le proposeur envoie l'en-tête signé plus tard, combiné au retard supplémentaire introduit par le relais, peut entraîner un manquement à la date limite de certification. En l'absence de réorganisation honnête, ces blocs sont très susceptibles d'entrer sur la chaîne. Mais en cas de réorganisation honnête, le fait de manquer la date limite de certification signifie que ce bloc sera réorganisé par le prochain proposeur.
Ainsi, quelques jours après l'attaque, le nombre de blocs forkés a augmenté de manière spectaculaire. Dans le pire des cas, 13 blocs ont été réorganisés en une heure, soit 4,3 % de (, ce qui est environ 5 fois plus que la normale. Avec le lancement de diverses modifications par le relais, l'augmentation rapide du nombre de blocs forkés est devenue évidente. Grâce aux efforts de la communauté, de nombreux changements ont été annulés et le réseau a retrouvé un état de santé.
Le changement le plus utile actuellement est la vérification d'équivalence avant la validation et la diffusion des blocs par les nœuds de balise. Les proposeurs malveillants ne peuvent plus exécuter d'attaques en envoyant des en-têtes invalides au relais et en s'assurant que les nœuds de balise du relais ne voient pas de blocs équivalents avant leur publication. Néanmoins, le relais reste vulnérable à des attaques d'équivalence plus générales.
![Paradigm : explorer la relation entre MEV-Boost et le mécanisme de consensus d'Éthereum])https://img-cdn.gateio.im/webp-social/moments-00fb5ee47056beb2efc3ca4ac271a69c.webp(
) direction future
La communauté de recherche devrait évaluer le nombre de réorganisations "acceptables", en tenant compte des risques généralisés posés par les attaques équivalentes, et déterminer s'il est nécessaire de mettre en place des mesures d'atténuation.
Quelques directions en cours d'exploration :
Réaliser une protection "headlock" pour que mev-boost soit à l'abri des attaques équivalentes. Cela nécessite de modifier le logiciel du client de consensus, ce qui pourrait nécessiter de prolonger la date limite d'attestation.
Augmenter le programme de récompense pour les vulnérabilités du logiciel mev-boost.
Explorer l'impact de la synchronisation des sous-ports de simulation étendue sur la stabilité du réseau.
Optimiser le chemin de publication des blocs de relais pour réduire les délais inutiles.
Intégrer mev-boost dans le client de consensus, c'est-à-dire enshrined-PBS###ePBS(.
Ajouter des tests basés sur les problèmes de délai et de date limite d'attestation.
Encourager la diversité des clients de relais.
Envisagez d'ajuster les mesures de pénalité équivalentes.
Dans l'ensemble, nous sommes enthousiasmés par la dynamique renouvelée de l'écosystème MEV et mev-boost. En déliant les attaques et les mesures d'atténuation, nous avons compris la relation clé entre les délais, mev-boost et le mécanisme de consensus ; nous espérons que le protocole pourra continuer à se renforcer.
![Paradigm : explorer la relation entre MEV-Boost et le mécanisme de consensus d'Ethereum])https://img-cdn.gateio.im/webp-social/moments-9db8f9a0944e1eff6bde4db0c8343fbe.webp(
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.
14 J'aime
Récompense
14
6
Reposter
Partager
Commentaire
0/400
GasFeePhobia
· 08-13 08:57
Ah ? 2000w s'est volatilisé comme ça ?
Voir l'originalRépondre0
GlueGuy
· 08-13 08:55
Oh là là, 20 millions de dollars, dit-on que ça n'existe plus.
Voir l'originalRépondre0
HalfBuddhaMoney
· 08-13 08:54
Je suis un maître de l'arbitrage, alors je vais d'abord en profiter un peu, mais je sens que je vais perdre un peu.
Voir l'originalRépondre0
MetaverseVagabond
· 08-13 08:46
On a réussi à voler 20 millions, c'est vraiment tragique.
Voir l'originalRépondre0
BrokenDAO
· 08-13 08:42
Encore un cas prouvant que les attaquants sont toujours plus intelligents que les défenseurs... la conception des mécanismes est difficile
Ordonnancement du temps et des événements dans l'attestation d'Ethereum : l'interaction subtile entre mev-boost et le Mécanisme de consensus
Temps, créneaux et ordre des événements dans l'attestation d'Ethereum
Le 2 avril, un participant malveillant au réseau Ethereum a exploité une vulnérabilité du mev-boost-relay pour voler 20 millions de dollars à un chercheur MEV. Les développeurs ont ensuite publié cinq correctifs pour résoudre cette vulnérabilité, mais l'interaction avec les retards du réseau existant et les stratégies des validateurs a entraîné une brève instabilité du réseau Ethereum le 6 avril. La reconstitution du réseau réduit le taux de production de blocs et les garanties de règlement, ce qui nuit à la santé du réseau.
Cet article vise à explorer l'interaction entre mev-boost et le mécanisme de consensus, à révéler les subtilités de l'attestation d'Ethereum et à discuter de certaines directions d'amélioration possibles. Notre inspiration provient de deux événements : les chercheurs subissant des attaques et l'instabilité temporaire du réseau.
le rôle de mev-boost
mev-boost est un protocole visant à atténuer l'impact négatif de la valeur maximale pouvant être extraite (MEV) sur le réseau Ethereum.
Il y a trois rôles dans mev-boost :
L'ordre des événements dans chaque bloc est le suivant :
Les constructeurs reçoivent des transactions de création de blocs des utilisateurs, des chercheurs ou d'autres sources.
Les constructeurs soumettent les blocs au relais.
Valider l'efficacité des blocs de relais et calculer les frais à payer au proposeur.
Le relais envoie l'en-tête de bloc "masqué" et le montant du paiement au proposeur de la tranche actuelle.
Le proposant évalue toutes les offres reçues et signe l'en-tête de bloc masqué correspondant au paiement le plus élevé.
Le proposeur renverra l'en-tête de bloc signé au relais.
Le relais publie des blocs via le nœud de balise local et les renvoie au proposeur. Grâce aux transactions dans le bloc et aux récompenses de bloc, le constructeur et le proposeur reçoivent des récompenses.
Le relais, en tant que tiers de confiance, facilite l'échange équitable de l'espace de bloc pour les proposeurs, ainsi que le tri des transactions pour l'extraction de MEV par les constructeurs. Le relais protège les constructeurs contre le vol de MEV et protège également les proposeurs en vérifiant la validité des blocs, en traitant un grand nombre de blocs et en garantissant un paiement précis.
mev-boost est une infrastructure clé, car elle permet à tous les proposeurs d'accéder équitablement à l'MEV sans avoir besoin d'établir une relation de confiance, contribuant ainsi à la décentralisation à long terme d'Ethereum.
Règles de sélection des forks d'Ethereum et mev-boost
Avant d'explorer en profondeur les attaques et les réponses, comprenons d'abord le mécanisme d'attestation d'Ethereum ( PoS ) et ses règles de sélection de bifurcation. Les règles de sélection de bifurcation permettent au réseau d'atteindre un consensus sur le bloc de tête.
La règle de sélection de fork est une fonction évaluée par le client, qui prend en entrée des blocs connus et d'autres messages, et produit ce qu'est la "chaîne canonique". La nécessité de la règle de sélection de fork provient du fait qu'il peut exister plusieurs chaînes valides parmi lesquelles choisir.
La relation entre les règles de sélection des forks et le temps est peu connue, mais elle a un impact significatif sur la production de blocs.
périodes de slots et de sous-slots
Dans Ethereum PoS, le temps est divisé en intervalles de 12 secondes. L'algorithme PoS désigne aléatoirement un validateur pour proposer le bloc de cet intervalle, ce validateur est appelé le proposeur. Dans le même intervalle, d'autres validateurs sont désignés pour voter sur le dernier bloc à la position de l'en-tête de la chaîne dans leur vue locale, en appliquant les règles de sélection des forks. L'intervalle de 12 secondes est divisé en trois phases de 4 secondes.
Les événements dans le slot sont les suivants, t=0 indique le début du slot :
Le moment crucial dans le slot est la date limite d'attestation à t=4. Si le validateur d'attestation ne voit pas le bloc avant la date limite, il votera sur le bloc précédent confirmé sur la chaîne. Plus la proposition de bloc est faite tôt, plus le temps de propagation est long, et plus il y a de témoignages accumulés.
Du point de vue de la santé du réseau, le meilleur moment pour publier un bloc est t=0. Cependant, comme la valeur du bloc augmente de manière monotone avec le temps, les proposeurs ont une motivation à retarder la publication pour accumuler plus de MEV.
Dans l'histoire, même après la période d'attestation et même près de la fin du slot, tant que le prochain validateur observe le bloc avant de construire le bloc du slot suivant, le proposeur peut toujours publier le bloc. Pour encourager un comportement rationnel, ( retarder la publication du bloc ) vers un comportement honnête ( en publiant à temps ), "restructuration honnête" a été introduite.
Amélioration des propositions et réorganisation honnête
Deux nouveaux concepts ont été introduits dans le client de consensus, ayant un impact important sur la date limite d'attestation.
Augmentation des proposeurs - Tentative de minimiser l'attaque de réorganisation d'équilibre en accordant aux proposeurs une "augmentation" du choix de bifurcation équivalente à 40 % du poids de certification complet. Cette augmentation ne dure qu'un seul créneau.
Restructuration honnête - Adoption par les proposeurs, permettant aux proposeurs honnêtes de l'utiliser pour forcer la restructuration des blocs dont le poids de validation est inférieur à 20%. Cela est implémenté dans certains clients. Ce changement est optionnel, car il s'agit d'une décision locale des proposeurs, sans impact sur le comportement des validateurs.
Éviter la réorganisation honnête dans certaines circonstances particulières :
Condition 3 Assurez-vous que la réorganisation honnête ne supprime qu'un seul bloc de la chaîne, servant de disjoncteur pour permettre à la chaîne de continuer à générer des blocs en cas de délais réseau extrêmes.
Réparation des relais et des nœuds de balisage contre les attaques de désassociation
Lors de l'attaque de désengagement du 2 avril, le proposeur a exploité une vulnérabilité de relais pour envoyer des en-têtes de signature invalides lors de l'attaque. Dans les jours suivants, l'équipe de développement de relais et de noyau a publié plusieurs correctifs logiciels pour atténuer le risque de récurrence des attaques. Les cinq principaux changements sont les suivants :
1.Changement de relais:
Vérifiez si la base de données contient des demandeurs malveillants connus.
Vérifiez si le bloc complet a été transmis au réseau P2P pendant cette période.
Introduire un délai aléatoire uniforme dans la plage de 0 à 500 ms avant la publication du bloc.
2.Changement de nœud de chaîne de balises ( uniquement applicable aux nœuds de chaîne de balises de relais ):
Valider l'efficacité du bloc de balise de diffusion.
Vérifiez s'il existe un équivalent sur le réseau avant de publier le bloc.
Ces changements combinés entraînent une instabilité du consensus, et la plupart des validateurs adoptent une stratégie de réorganisation honnête qui aggrave davantage la situation.
Conséquences inattendues
Chacune des 5 modifications susmentionnées augmentera le délai sur le chemin chaud de publication des blocs relais, augmentant ainsi la probabilité que le bloc relais soit diffusé après la date limite d'attestation.
Avant de mettre en œuvre ces vérifications, il n'y aura généralement pas de problème si l'en-tête de signature arrive aux alentours de t=3. Les frais de relais sont très faibles et il est possible de publier le bloc avant t=4.
Cependant, avec l'augmentation des retards causés par l'introduction des cinq correctifs, le relais pourrait en être en partie responsable. Dans certains cas, le fait que le proposeur envoie l'en-tête signé plus tard, combiné au retard supplémentaire introduit par le relais, peut entraîner un manquement à la date limite de certification. En l'absence de réorganisation honnête, ces blocs sont très susceptibles d'entrer sur la chaîne. Mais en cas de réorganisation honnête, le fait de manquer la date limite de certification signifie que ce bloc sera réorganisé par le prochain proposeur.
Ainsi, quelques jours après l'attaque, le nombre de blocs forkés a augmenté de manière spectaculaire. Dans le pire des cas, 13 blocs ont été réorganisés en une heure, soit 4,3 % de (, ce qui est environ 5 fois plus que la normale. Avec le lancement de diverses modifications par le relais, l'augmentation rapide du nombre de blocs forkés est devenue évidente. Grâce aux efforts de la communauté, de nombreux changements ont été annulés et le réseau a retrouvé un état de santé.
Le changement le plus utile actuellement est la vérification d'équivalence avant la validation et la diffusion des blocs par les nœuds de balise. Les proposeurs malveillants ne peuvent plus exécuter d'attaques en envoyant des en-têtes invalides au relais et en s'assurant que les nœuds de balise du relais ne voient pas de blocs équivalents avant leur publication. Néanmoins, le relais reste vulnérable à des attaques d'équivalence plus générales.
![Paradigm : explorer la relation entre MEV-Boost et le mécanisme de consensus d'Éthereum])https://img-cdn.gateio.im/webp-social/moments-00fb5ee47056beb2efc3ca4ac271a69c.webp(
) direction future
La communauté de recherche devrait évaluer le nombre de réorganisations "acceptables", en tenant compte des risques généralisés posés par les attaques équivalentes, et déterminer s'il est nécessaire de mettre en place des mesures d'atténuation.
Quelques directions en cours d'exploration :
Réaliser une protection "headlock" pour que mev-boost soit à l'abri des attaques équivalentes. Cela nécessite de modifier le logiciel du client de consensus, ce qui pourrait nécessiter de prolonger la date limite d'attestation.
Augmenter le programme de récompense pour les vulnérabilités du logiciel mev-boost.
Explorer l'impact de la synchronisation des sous-ports de simulation étendue sur la stabilité du réseau.
Optimiser le chemin de publication des blocs de relais pour réduire les délais inutiles.
Intégrer mev-boost dans le client de consensus, c'est-à-dire enshrined-PBS###ePBS(.
Ajouter des tests basés sur les problèmes de délai et de date limite d'attestation.
Encourager la diversité des clients de relais.
Envisagez d'ajuster les mesures de pénalité équivalentes.
Dans l'ensemble, nous sommes enthousiasmés par la dynamique renouvelée de l'écosystème MEV et mev-boost. En déliant les attaques et les mesures d'atténuation, nous avons compris la relation clé entre les délais, mev-boost et le mécanisme de consensus ; nous espérons que le protocole pourra continuer à se renforcer.
![Paradigm : explorer la relation entre MEV-Boost et le mécanisme de consensus d'Ethereum])https://img-cdn.gateio.im/webp-social/moments-9db8f9a0944e1eff6bde4db0c8343fbe.webp(