Ordonnancement du temps, des créneaux et des événements dans l'attestation d'Ethereum
Le 2 avril, un participant malveillant a exploité une vulnérabilité dans mev-boost-relay pour voler 20 millions de dollars. Dans les jours suivants, les développeurs ont corrigé cette vulnérabilité en publiant cinq correctifs, ce qui, combiné aux délais de réseau existants et aux stratégies des validateurs, a entraîné une brève instabilité du réseau Ethereum le 6 avril. La restructuration nuit à la santé du réseau, ce qui réduit le taux de production des blocs et les garanties de règlement.
Cet article explore l'interaction entre mev-boost et le consensus, révèle les subtilités du mécanisme PoS d'Ethereum et propose quelques pistes d'amélioration.
introduction à mev-boost
mev-boost est un protocole conçu pour atténuer l'impact négatif de la valeur maximale extractible (MEV) sur le réseau Ethereum. Il comprend trois rôles :
Relais : un tiers de confiance reliant les proposeurs et les bâtisseurs de blocs.
Constructeurs : entités complexes construisant des blocs pour maximiser le MEV.
Proposant : validateurs Ethereum PoS.
mev-boost permet à tous les proposeurs d'accéder équitablement au MEV, sans avoir besoin d'établir une relation de confiance avec les constructeurs, ce qui contribue à la décentralisation à long terme d'Ethereum.
Règles de sélection des forks d'Ethereum
Dans le PoS d'Ethereum, le temps est divisé en créneaux de 12 secondes. À chaque créneau, un validateur est désigné au hasard comme proposeur pour soumettre un bloc. Les autres validateurs votent pour soutenir la tête de chaîne en appliquant les règles de sélection de fork.
Le moment le plus critique dans le slot est la date limite d'attestation à t=4. Si le validateur ne voit pas le bloc avant la date limite, il votera pour le head de chaîne précédent. Plus le bloc est publié tôt, plus il obtient d'attestations.
D'un point de vue de la santé du réseau, le meilleur moment pour publier est t=0. Cependant, étant donné que la valeur des blocs augmente avec le temps, le proposeur a des incitations à retarder la publication pour accumuler plus de MEV.
Pour promouvoir la publication rapide des actions, un mécanisme de "restructuration honnête" a été introduit.
Amélioration des propositions et réorganisation honnête
Amélioration du proposeur : donner au proposeur un choix de bifurcation "amélioration" équivalent à 40 % de poids d'attestation, ne durant qu'un seul créneau.
Restructuration honnête : permet aux proposeurs honnêtes de restructurer les blocs dont le poids d'attestation est inférieur à 20 %. C'est une fonctionnalité optionnelle, décidée par le proposeur lui-même.
La restructuration honnête peut être évitée dans certaines situations, comme pendant les blocs de frontière d'époque.
Correction des attaques de désassociation
Après l'attaque de désengagement du 2 avril, l'équipe de développement des relais et des noyaux a publié plusieurs correctifs :
Changement de relais :
Vérifier les proposeurs malveillants connus
Vérifiez si le slot a publié un bloc complet.
Introduire un délai aléatoire
Changement de nœud de la chaîne de balises :
Vérifier la validité des blocs
Vérifiez s'il existe des blocs équivalents sur le réseau.
Ces changements ont entraîné une instabilité du consensus, et la stratégie de réorganisation honnête a aggravé cette situation.
conséquences inattendues
Le correctif a augmenté le délai de publication des blocs de relais, ce qui peut entraîner des blocs dépassant la date limite d'attestation. Dans le cas d'une réorganisation honnête, ces blocs seront réorganisés par le prochain proposeur.
Le résultat est une augmentation rapide du nombre de blocs de fork, atteignant jusqu'à 4,3 % de blocs reconfigurés par heure à son maximum. Avec le déploiement des modifications de relais, la situation commence à revenir à la normale.
La réparation la plus efficace à ce jour est la validation des blocs des nœuds de balisage et la vérification d'équivalence. Cependant, les relais restent susceptibles à des attaques d'équivalence plus générales.
direction future
Il est nécessaire d'évaluer le nombre de réorganisations "acceptables" et de prendre en compte le risque d'attaques équivalentes. Quelques directions d'amélioration possibles :
Mettre en œuvre la protection "headlock" mev-boost
Augmenter le programme de récompense pour les vulnérabilités
Étendre la recherche de logiciels de simulation pour le minutage des sous-emplacements
Optimisation du chemin de publication du relais
Inclure mev-boost dans le client de consensus (ePBS)
Ajouter plus de tests
Encourager la diversité des clients de relais
Ajuster les mesures de pénalité équivalentes
En résumé, l'attaque de désengagement nous a permis de comprendre la relation clé entre la latence, mev-boost et le mécanisme de consensus. Nous espérons que le protocole pourra continuer à se renforcer pour faire face aux défis futurs.
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.
23 J'aime
Récompense
23
4
Reposter
Partager
Commentaire
0/400
probably_nothing_anon
· 08-14 12:43
Encore une journée avec une faille, ça ne tient plus.
Voir l'originalRépondre0
GmGmNoGn
· 08-12 06:06
Il s'avère que le PoS ne peut pas échapper aux failles ?!
Voir l'originalRépondre0
DogeBachelor
· 08-12 05:55
Encore une chute de l'Ethereum, mais notre DOGE est très stable.
Voir l'originalRépondre0
FlatTax
· 08-12 05:50
Encore quelqu'un a coupé les coupons de manière importante.
Discussion sur les vulnérabilités de mev-boost et la stabilité du réseau sous le mécanisme PoS d'Ethereum
Ordonnancement du temps, des créneaux et des événements dans l'attestation d'Ethereum
Le 2 avril, un participant malveillant a exploité une vulnérabilité dans mev-boost-relay pour voler 20 millions de dollars. Dans les jours suivants, les développeurs ont corrigé cette vulnérabilité en publiant cinq correctifs, ce qui, combiné aux délais de réseau existants et aux stratégies des validateurs, a entraîné une brève instabilité du réseau Ethereum le 6 avril. La restructuration nuit à la santé du réseau, ce qui réduit le taux de production des blocs et les garanties de règlement.
Cet article explore l'interaction entre mev-boost et le consensus, révèle les subtilités du mécanisme PoS d'Ethereum et propose quelques pistes d'amélioration.
introduction à mev-boost
mev-boost est un protocole conçu pour atténuer l'impact négatif de la valeur maximale extractible (MEV) sur le réseau Ethereum. Il comprend trois rôles :
mev-boost permet à tous les proposeurs d'accéder équitablement au MEV, sans avoir besoin d'établir une relation de confiance avec les constructeurs, ce qui contribue à la décentralisation à long terme d'Ethereum.
Règles de sélection des forks d'Ethereum
Dans le PoS d'Ethereum, le temps est divisé en créneaux de 12 secondes. À chaque créneau, un validateur est désigné au hasard comme proposeur pour soumettre un bloc. Les autres validateurs votent pour soutenir la tête de chaîne en appliquant les règles de sélection de fork.
Le moment le plus critique dans le slot est la date limite d'attestation à t=4. Si le validateur ne voit pas le bloc avant la date limite, il votera pour le head de chaîne précédent. Plus le bloc est publié tôt, plus il obtient d'attestations.
D'un point de vue de la santé du réseau, le meilleur moment pour publier est t=0. Cependant, étant donné que la valeur des blocs augmente avec le temps, le proposeur a des incitations à retarder la publication pour accumuler plus de MEV.
Pour promouvoir la publication rapide des actions, un mécanisme de "restructuration honnête" a été introduit.
Amélioration des propositions et réorganisation honnête
Amélioration du proposeur : donner au proposeur un choix de bifurcation "amélioration" équivalent à 40 % de poids d'attestation, ne durant qu'un seul créneau.
Restructuration honnête : permet aux proposeurs honnêtes de restructurer les blocs dont le poids d'attestation est inférieur à 20 %. C'est une fonctionnalité optionnelle, décidée par le proposeur lui-même.
La restructuration honnête peut être évitée dans certaines situations, comme pendant les blocs de frontière d'époque.
Correction des attaques de désassociation
Après l'attaque de désengagement du 2 avril, l'équipe de développement des relais et des noyaux a publié plusieurs correctifs :
Changement de relais :
Changement de nœud de la chaîne de balises :
Ces changements ont entraîné une instabilité du consensus, et la stratégie de réorganisation honnête a aggravé cette situation.
conséquences inattendues
Le correctif a augmenté le délai de publication des blocs de relais, ce qui peut entraîner des blocs dépassant la date limite d'attestation. Dans le cas d'une réorganisation honnête, ces blocs seront réorganisés par le prochain proposeur.
Le résultat est une augmentation rapide du nombre de blocs de fork, atteignant jusqu'à 4,3 % de blocs reconfigurés par heure à son maximum. Avec le déploiement des modifications de relais, la situation commence à revenir à la normale.
La réparation la plus efficace à ce jour est la validation des blocs des nœuds de balisage et la vérification d'équivalence. Cependant, les relais restent susceptibles à des attaques d'équivalence plus générales.
direction future
Il est nécessaire d'évaluer le nombre de réorganisations "acceptables" et de prendre en compte le risque d'attaques équivalentes. Quelques directions d'amélioration possibles :
En résumé, l'attaque de désengagement nous a permis de comprendre la relation clé entre la latence, mev-boost et le mécanisme de consensus. Nous espérons que le protocole pourra continuer à se renforcer pour faire face aux défis futurs.