Temps, créneaux et ordre des événements dans l'attestation d'Ethereum
Le 2 avril, un participant malveillant a utilisé une vulnérabilité de mev-boost-relay pour voler environ 20 millions de dollars. Dans les jours suivants, les développeurs ont publié cinq patchs pour corriger ce problème. En raison des délais de réseau existants et des stratégies des validateurs, le réseau Ethereum a connu une brève instabilité le 6 avril. Les réorganisations nuisent à la santé du réseau et diminuent 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 d'attestation d'Ethereum et discute de certaines pistes de développement possibles.
aperçu 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 comprend trois rôles :
Relais : intermédiaire entre les proposeurs et les constructeurs de blocs
Builders : entités qui construisent des blocs pour maximiser l'MEV
Proposers: validateurs d'attestation Ethereum
L'importance de mev-boost réside dans le fait qu'il permet à tous les proposeurs d'accéder équitablement au MEV, sans avoir besoin d'établir 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 Ethereum et mev-boost
Les règles de sélection des forks dans Ethereum attestation ( PoS ) déterminent comment le réseau parvient à un consensus sur le head de la chaîne. Le temps joue un rôle important dans ce processus.
Le PoS d'Ethereum divise le temps en intervalles de 12 secondes. À chaque intervalle, un validateurs est désigné comme proposeur pour suggérer un bloc. Les autres validateurs votent pour soutenir la tête de chaîne en appliquant des règles de sélection de fork.
Le moment clé dans l'intervalle de temps est la date limite d'attestation à t=4 secondes. Si le validateur ne voit pas le bloc avant cela, il votera pour la tête de chaîne précédente. Plus le bloc est publié tôt, plus la preuve accumulée est importante.
D'un 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 avec le temps, le proposeur a une incitation à retarder la publication pour obtenir plus de MEV.
Pour encourager les publications ponctuelles, un mécanisme de "restructuration honnête" a été introduit. Il permet aux proposeurs honnêtes de restructurer des blocs dont le poids de certification est inférieur à 20 %. Ce mécanisme ne se déclenche que dans des conditions spécifiques, afin d'éviter l'interruption de la production de blocs en cas de latence extrême du réseau.
Correction pour l'attaque de désassociation
Après l'attaque du 2 avril, l'équipe de développement de relais et de cœur a publié plusieurs correctifs :
Vérifier les proposeurs malveillants connus
Vérifiez si le bloc complet a été transmis au réseau P2P
Introduction d'un délai aléatoire
Vérification de la validité des blocs de balise
Vérifiez s'il existe des blocs équivalents sur le réseau
Ces changements ont augmenté le délai de publication des blocs, combiné avec le mécanisme de réorganisation honnête, entraînant une instabilité du réseau.
conséquences imprévues
Le retard supplémentaire introduit par le patch entraîne la publication possible de blocs après la date limite d'attestation. Combiné avec le mécanisme de réorganisation honnête, ces blocs en retard seront réorganisés, entraînant une augmentation spectaculaire du nombre de fourches.
Au plus fort de la crise, environ 4,3 % des blocs étaient réorganisés chaque heure, soit cinq fois plus que la normale. Avec l'annulation de certaines modifications des relais, le réseau a progressivement retrouvé sa stabilité.
La réparation la plus efficace actuellement est la vérification et la vérification d'équivalence des blocs de nœuds de balises avant leur publication. Cependant, le relais reste vulnérable à des attaques d'équivalence plus générales.
direction future
Pour ces problèmes, vous pouvez envisager les directions suivantes :
Mettre en œuvre le mécanisme "headlock" pour protéger mev-boost
Augmenter le programme de récompense pour les vulnérabilités
Étendre la simulation pour explorer l'impact du timing des sous-fenêtres
Optimisation du chemin de publication des blocs de relais
Intégrer mev-boost dans le client de consensus (ePBS)
Ajouter des tests pertinents
Encourager la diversité des clients de relais
Ajuster les mesures de pénalité équivalentes
Dans l'ensemble, cet événement nous a permis de mieux comprendre les relations clés entre les retards, mev-boost et le mécanisme de consensus. Nous espérons que le protocole pourra être continuellement renforcé et perfectionné.
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.
11 J'aime
Récompense
11
6
Reposter
Partager
Commentaire
0/400
MemeKingNFT
· Il y a 11h
Les vulnérabilités MEV sont trop mortelles.
Voir l'originalRépondre0
ILCollector
· Il y a 15h
débutant de bull run
Voir l'originalRépondre0
LongTermDreamer
· Il y a 22h
On ne peut jamais se lasser des correctifs d'utilisation
Voir l'originalRépondre0
MetaverseVagabond
· Il y a 22h
la sécurité mev est vraiment mortelle
Voir l'originalRépondre0
MetaLord420
· Il y a 22h
Un patch ne résout que les symptômes, pas le problème.
Analyse des défis et des solutions de MEV-Boost dans le cadre du mécanisme d'attestation d'Ethereum
Temps, créneaux et ordre des événements dans l'attestation d'Ethereum
Le 2 avril, un participant malveillant a utilisé une vulnérabilité de mev-boost-relay pour voler environ 20 millions de dollars. Dans les jours suivants, les développeurs ont publié cinq patchs pour corriger ce problème. En raison des délais de réseau existants et des stratégies des validateurs, le réseau Ethereum a connu une brève instabilité le 6 avril. Les réorganisations nuisent à la santé du réseau et diminuent 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 d'attestation d'Ethereum et discute de certaines pistes de développement possibles.
aperçu 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 comprend trois rôles :
L'importance de mev-boost réside dans le fait qu'il permet à tous les proposeurs d'accéder équitablement au MEV, sans avoir besoin d'établir 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 Ethereum et mev-boost
Les règles de sélection des forks dans Ethereum attestation ( PoS ) déterminent comment le réseau parvient à un consensus sur le head de la chaîne. Le temps joue un rôle important dans ce processus.
Le PoS d'Ethereum divise le temps en intervalles de 12 secondes. À chaque intervalle, un validateurs est désigné comme proposeur pour suggérer un bloc. Les autres validateurs votent pour soutenir la tête de chaîne en appliquant des règles de sélection de fork.
Le moment clé dans l'intervalle de temps est la date limite d'attestation à t=4 secondes. Si le validateur ne voit pas le bloc avant cela, il votera pour la tête de chaîne précédente. Plus le bloc est publié tôt, plus la preuve accumulée est importante.
D'un 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 avec le temps, le proposeur a une incitation à retarder la publication pour obtenir plus de MEV.
Pour encourager les publications ponctuelles, un mécanisme de "restructuration honnête" a été introduit. Il permet aux proposeurs honnêtes de restructurer des blocs dont le poids de certification est inférieur à 20 %. Ce mécanisme ne se déclenche que dans des conditions spécifiques, afin d'éviter l'interruption de la production de blocs en cas de latence extrême du réseau.
Correction pour l'attaque de désassociation
Après l'attaque du 2 avril, l'équipe de développement de relais et de cœur a publié plusieurs correctifs :
Ces changements ont augmenté le délai de publication des blocs, combiné avec le mécanisme de réorganisation honnête, entraînant une instabilité du réseau.
conséquences imprévues
Le retard supplémentaire introduit par le patch entraîne la publication possible de blocs après la date limite d'attestation. Combiné avec le mécanisme de réorganisation honnête, ces blocs en retard seront réorganisés, entraînant une augmentation spectaculaire du nombre de fourches.
Au plus fort de la crise, environ 4,3 % des blocs étaient réorganisés chaque heure, soit cinq fois plus que la normale. Avec l'annulation de certaines modifications des relais, le réseau a progressivement retrouvé sa stabilité.
La réparation la plus efficace actuellement est la vérification et la vérification d'équivalence des blocs de nœuds de balises avant leur publication. Cependant, le relais reste vulnérable à des attaques d'équivalence plus générales.
direction future
Pour ces problèmes, vous pouvez envisager les directions suivantes :
Dans l'ensemble, cet événement nous a permis de mieux comprendre les relations clés entre les retards, mev-boost et le mécanisme de consensus. Nous espérons que le protocole pourra être continuellement renforcé et perfectionné.