Temps, créneaux et ordre des événements dans l'attestation d'Ethereum

Le 2 avril, un participant malveillant a exploité une vulnérabilité dans le mev-boost-relay pour voler environ 20 millions de dollars. Dans les jours suivants, les développeurs ont corrigé cette vulnérabilité par le biais de cinq patchs, mais la combinaison des délais de réseau existants et des stratégies de validation a entraîné une brève instabilité du réseau Ethereum le 6 avril. Les réorganisations nuisent à la santé du réseau et peuvent réduire le taux de production de blocs et les garanties de règlement.

Cet article examine l'interaction entre mev-boost et le consensus, révèle les subtilités d'Ethereum PoS et propose certaines pistes d'amélioration.

introduction à mev-boost

mev-boost est un protocole destiné à atténuer l'impact négatif de la valeur maximale extractible (MEV) sur Ethereum. Il comprend trois rôles :

• Relais : connecte les soumissionnaires et les constructeurs des enchérisseurs de confiance
• Builders : entités complexes qui construisent des blocs pour maximiser le MEV
• Proposants : validateurs Ethereum PoS

Le processus général de chaque bloc est :

1. Builders reçoivent des transactions de diverses sources pour créer des blocs
2. Builders soumettent des blocs à Relay
3. Relay vérifie la validité des blocs et calcule les frais à payer au proposeur.
4. Relay envoie le "tête aveuglée" et la valeur de paiement au proposeur du créneau actuel.
5. Le proposeur évalue toutes les offres et signe la tête d'enchère aveugle du paiement le plus élevé.
6. Le proposeur renverra l'en-tête de signature au Relay
7. Relay publie des blocs via le nœud de balise local et les renvoie au proposeur

mev-boost est une infrastructure clé, car elle permet à tous les proposeurs d'accéder équitablement à l'MEV, sans avoir besoin d'établir une confiance avec les constructeurs ou les chercheurs, contribuant ainsi à la décentralisation à long terme d'Ethereum.

Règles de sélection des forks d'Ethereum et mev-boost

Dans le PoS d'Ethereum, le temps est divisé en intervalles de 12 secondes. Un validateur est désigné au hasard comme proposeur pour chaque intervalle. Les 12 secondes sont divisées en trois phases de 4 secondes.

Le moment clé dans la période est la date limite de preuve à t=4. Si le validateur ne voit pas de bloc avant cela, il votera pour la tête de chaîne précédente. Plus un bloc est publié tôt, plus le temps de propagation est long, et plus les preuves accumulées sont nombreuses.

D'un point de vue de la santé du réseau, le meilleur temps de bloc est t=0. Cependant, étant donné que la valeur des blocs augmente avec le temps, les proposeurs ont intérêt à retarder la publication pour accumuler plus de MEV.

Pour promouvoir la transition des comportements rationnels vers des comportements honnêtes, le mécanisme de "restructuration honnête" a été introduit.

Amélioration du proposeur et réorganisation honnête

Introduit deux nouveaux concepts :

• Amélioration de la proposition : accorder au proposeur un choix de "promotion" équivalent à 40 % du poids de preuve complet, pendant un seul intervalle de temps.
• Restructuration honnête : permet aux proposeurs honnêtes d'utiliser l'élévation des blocs avec un poids de preuve de restructuration inférieur à 20 %.

La réorganisation honnête peut être évitée dans certaines circonstances particulières, comme pendant les blocs de bordure d'époque, etc.

Correction des attaques de désassociation

Après l'attaque du 2 avril, l'équipe de relais et l'équipe de développement principal ont publié plusieurs correctifs :

1. Vérifier les proposeurs malveillants connus
2. Vérifiez si le bloc complet a été transmis au réseau P2P
3. Introduire un délai aléatoire avant la publication
4. Le nœud de balise vérifie la validité des blocs
5. Vérifiez s'il existe des blocs équivalents sur le réseau.

Ces changements ont augmenté le délai de publication des relais, ce qui a entraîné un risque de dépassement des délais d'attestation des blocs. Combiné avec la réorganisation honnête, cela a provoqué une augmentation drastique du nombre de fork.

direction future

La communauté de recherche devrait évaluer le nombre de réorganisations "acceptables" et prendre en compte le risque général d'attaques équivalentes. Les directions activement explorées comprennent :

• Réaliser la protection "headlock" mev-boost
• Augmenter le programme de primes de sécurité
• Logiciel de simulation étendu
• Optimiser le chemin de publication du relais
• Intégrer mev-boost dans le client de consensus (ePBS)
• Ajouter plus de tests
• Encourager la diversité des clients de relais
• Ajuster les mesures de sanction équivalentes

En résumé, les attaques par partition et les mesures d'atténuation nous ont 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.